add new lkml archive mirror - sfeed_tests - sfeed tests and RSS and Atom files
(HTM) git clone git://git.codemadness.org/sfeed_tests
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) LICENSE
---
(DIR) commit 6de9906eebff96b53482508fe1dc32e2e0c16fbc
(DIR) parent ede74f61a785ba85c315159f0a154c3272155c02
(HTM) Author: Hiltjo Posthuma <hiltjo@codemadness.org>
Date: Fri, 1 Nov 2024 16:53:19 +0100
add new lkml archive mirror
https://lore.kernel.org/lkml/new.atom
Diffstat:
A input/sfeed/realworld/lore_kernel_… | 2184 +++++++++++++++++++++++++++++++
1 file changed, 2184 insertions(+), 0 deletions(-)
---
(DIR) diff --git a/input/sfeed/realworld/lore_kernel_org_lkml.atom.xml b/input/sfeed/realworld/lore_kernel_org_lkml.atom.xml
@@ -0,0 +1,2183 @@
+<?xml version="1.0" encoding="us-ascii"?>
+<feed
+xmlns="http://www.w3.org/2005/Atom"
+xmlns:thr="http://purl.org/syndication/thread/1.0"><title>linux-kernel.vger.kernel.org archive mirror</title><link
+rel="alternate"
+type="text/html"
+href="http://lore.kernel.org/lkml/"/><link
+rel="self"
+href="http://lore.kernel.org/lkml/new.atom"/><id>mailto:linux-kernel@vger.kernel.org</id><updated>2024-11-01T15:48:54Z</updated><entry><author><name>George Stark</name><email>gnstark@salutedevices.com</email></author><title>[PATCH v2 2/2] leds: pwm: Add optional DT property default-brightness</title><updated>2024-11-01T15:48:54Z</updated><link
+href="http://lore.kernel.org/lkml/20241101154844.1175860-3-gnstark@salutedevices.com/"/><id>urn:uuid:27f6ef67-80c6-373c-fedb-1f3bd59fea2e</id><thr:in-reply-to
+ref="urn:uuid:8c64a34f-09cd-4fba-a1f1-e0655404bfeb"
+href="http://lore.kernel.org/lkml/20241101154844.1175860-1-gnstark@salutedevices.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">When probing if default LED state is on then default brightness will be
+applied instead of max brightness.
+
+Signed-off-by: George Stark <gnstark@salutedevices.com>
+---
+ drivers/leds/leds-pwm.c | 17 ++++++++++++++++-
+ 1 file <a href="http://lore.kernel.org/lkml/20241101154844.1175860-3-gnstark@salutedevices.com/#related">changed</a>, 16 insertions(+), 1 deletion(-)
+
+<span
+class="head">diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
+index 7961dca0db2f..7636ee178c39 100644
+--- a/drivers/leds/leds-pwm.c
++++ b/drivers/leds/leds-pwm.c
+</span><span
+class="hunk">@@ -63,6 +63,20 @@ static int led_pwm_set(struct led_classdev *led_cdev,
+</span> return pwm_apply_might_sleep(led_dat->pwm, &led_dat->pwmstate);
+ }
+
+<span
+class="add">+static int led_pwm_default_brightness_get(struct fwnode_handle *fwnode,
++ int max_brightness)
++{
++ unsigned int default_brightness;
++ int ret;
++
++ ret = fwnode_property_read_u32(fwnode, "default-brightness",
++ &default_brightness);
++ if (ret < 0 || default_brightness > max_brightness)
++ default_brightness = max_brightness;
++
++ return default_brightness;
++}
++
+</span> __attribute__((nonnull))
+ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
+ struct led_pwm *led, struct fwnode_handle *fwnode)
+<span
+class="hunk">@@ -104,7 +118,8 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
+</span> /* set brightness */
+ switch (led->default_state) {
+ case LEDS_DEFSTATE_ON:
+<span
+class="del">- led_data->cdev.brightness = led->max_brightness;
+</span><span
+class="add">+ led_data->cdev.brightness =
++ led_pwm_default_brightness_get(fwnode, led->max_brightness);
+</span> break;
+ case LEDS_DEFSTATE_KEEP:
+ {
+--
+2.25.1
+
+</pre></div></content></entry><entry><author><name>George Stark</name><email>gnstark@salutedevices.com</email></author><title>[PATCH v2 1/2] dt-bindings: leds: pwm: Add default-brightness property</title><updated>2024-11-01T15:48:54Z</updated><link
+href="http://lore.kernel.org/lkml/20241101154844.1175860-2-gnstark@salutedevices.com/"/><id>urn:uuid:b4d60b44-7fb5-c644-c4d7-786bf6b2d4b9</id><thr:in-reply-to
+ref="urn:uuid:8c64a34f-09cd-4fba-a1f1-e0655404bfeb"
+href="http://lore.kernel.org/lkml/20241101154844.1175860-1-gnstark@salutedevices.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">Optional default-brightness property specifies brightness value to be
+used if default LED state is on.
+
+Signed-off-by: George Stark <gnstark@salutedevices.com>
+---
+ Documentation/devicetree/bindings/leds/leds-pwm.yaml | 6 ++++++
+ 1 file <a href="http://lore.kernel.org/lkml/20241101154844.1175860-2-gnstark@salutedevices.com/#related">changed</a>, 6 insertions(+)
+
+<span
+class="head">diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.yaml b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
+index 113b7c218303..61b97e8bc36d 100644
+--- a/Documentation/devicetree/bindings/leds/leds-pwm.yaml
++++ b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
+</span><span
+class="hunk">@@ -34,6 +34,12 @@ patternProperties:
+</span> Maximum brightness possible for the LED
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+<span
+class="add">+ default-brightness:
++ description:
++ Brightness to be set if LED's default state is on. Used only during
++ initialization. If the option is not set then max brightness is used.
++ $ref: /schemas/types.yaml#/definitions/uint32
++
+</span> required:
+ - pwms
+ - max-brightness
+--
+2.25.1
+
+</pre></div></content></entry><entry><author><name>George Stark</name><email>gnstark@salutedevices.com</email></author><title>[PATCH v2 0/2] leds: pwm: Add default-brightness property</title><updated>2024-11-01T15:48:53Z</updated><link
+href="http://lore.kernel.org/lkml/20241101154844.1175860-1-gnstark@salutedevices.com/"/><id>urn:uuid:8c64a34f-09cd-4fba-a1f1-e0655404bfeb</id><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">led-pwm driver supports default-state DT property and if that state is on then
+the driver during initialization turns on the LED setting maximum brightness.
+Sometimes it's desirable to use lower initial brightness.
+This patch series adds support for DT property default-brightness.
+
+Things to discuss:
+If such a property is acceptable it could be moved to leds/common.yaml due to
+several drivers support multiple brightness levels and could support the property
+too.
+
+Changes in v2:
+ leds: pwm: Add optional DT property default-brightness
+ - refactor patch to make it more accurate
+ link to v1: [1]
+
+[1] <a
+href="https://lore.kernel.org/lkml/20241015151410.2158102-3-gnstark@salutedevices.com/T/">https://lore.kernel.org/lkml/20241015151410.2158102-3-gnstark@salutedevices.com/T/</a>
+
+George Stark (2):
+ dt-bindings: leds: pwm: Add default-brightness property
+ leds: pwm: Add optional DT property default-brightness
+
+ .../devicetree/bindings/leds/leds-pwm.yaml | 6 ++++++
+ drivers/leds/leds-pwm.c | 17 ++++++++++++++++-
+ 2 files changed, 22 insertions(+), 1 deletion(-)
+
+--
+2.25.1
+
+</pre></div></content></entry><entry><author><name>Markus Elfring</name><email>Markus.Elfring@web.de</email></author><title>Re: [PATCH v5 6/7] pinctrl: s32cc: add driver for GPIO functionality</title><updated>2024-11-01T15:46:16Z</updated><link
+href="http://lore.kernel.org/lkml/fdf5702a-b739-4643-8288-86e6cfb8403d@web.de/"/><id>urn:uuid:3e278eb7-0877-0270-118e-37defc2a70f4</id><thr:in-reply-to
+ref="urn:uuid:e028ca59-5d0a-f486-732a-92c7cb8d2f9c"
+href="http://lore.kernel.org/lkml/20241101080614.1070819-7-andrei.stefanescu@oss.nxp.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap"><span
+class="q">> Add basic GPIO functionality (request, free, get, set) for the existing
+> pinctrl SIUL2 driver since the hardware for pinctrl&GPIO is tightly
+> coupled.
+</span>…
+<span
+class="q">> +++ b/drivers/pinctrl/nxp/pinctrl-s32cc.c
+</span>…
+<span
+class="q">> +static int s32_gpio_request(struct gpio_chip *gc, unsigned int gpio)
+> +{
+</span>…
+<span
+class="q">> + spin_lock_irqsave(&ipctl->gpio_configs_lock, flags);
+> + list_add(&gpio_pin->list, &ipctl->gpio_configs);
+> + spin_unlock_irqrestore(&ipctl->gpio_configs_lock, flags);
+</span>…
+
+Under which circumstances would you become interested to apply a statement
+like “guard(spinlock_irqsave)(&ipctl->gpio_configs_lock);”?
+<a
+href="https://elixir.bootlin.com/linux/v6.12-rc5/source/include/linux/spinlock.h#L551">https://elixir.bootlin.com/linux/v6.12-rc5/source/include/linux/spinlock.h#L551</a>
+
+Regards,
+Markus
+</pre></div></content></entry><entry><author><name>kernel test robot</name><email>lkp@intel.com</email></author><title>Re: [PATCH v3 20/22] ACPI: platform_profile: Register class device for platform profile handlers</title><updated>2024-11-01T15:45:51Z</updated><link
+href="http://lore.kernel.org/lkml/202411012317.1pQLOspC-lkp@intel.com/"/><id>urn:uuid:ea88037d-f268-1598-cc32-9ead01144b06</id><thr:in-reply-to
+ref="urn:uuid:59853637-7e32-04c8-211e-ba7cc208f49f"
+href="http://lore.kernel.org/lkml/20241031040952.109057-21-mario.limonciello@amd.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">Hi Mario,
+
+kernel test robot noticed the following build errors:
+
+[auto build test ERROR on rafael-pm/linux-next]
+[also build test ERROR on rafael-pm/bleeding-edge linus/master v6.12-rc5 next-20241101]
+[If your patch is applied to the wrong git tree, kindly drop us a note.
+And when submitting patch, we suggest to use '--base' as documented in
+<a
+href="https://git-scm.com/docs/git-format-patch#_base_tree_information">https://git-scm.com/docs/git-format-patch#_base_tree_information</a>]
+
+url: <a
+href="https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/ACPI-platform-profile-Add-a-name-member-to-handlers/20241031-121650">https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/ACPI-platform-profile-Add-a-name-member-to-handlers/20241031-121650</a>
+base: <a
+href="https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git">https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git</a> linux-next
+patch link: <a
+href="https://lore.kernel.org/r/20241031040952.109057-21-mario.limonciello%40amd.com">https://lore.kernel.org/r/20241031040952.109057-21-mario.limonciello%40amd.com</a>
+patch subject: [PATCH v3 20/22] ACPI: platform_profile: Register class device for platform profile handlers
+config: x86_64-buildonly-randconfig-005-20241101 (<a
+href="https://download.01.org/0day-ci/archive/20241101/202411012317.1pQLOspC-lkp@intel.com/config">https://download.01.org/0day-ci/archive/20241101/202411012317.1pQLOspC-lkp@intel.com/config</a>)
+compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
+reproduce (this is a W=1 build): (<a
+href="https://download.01.org/0day-ci/archive/20241101/202411012317.1pQLOspC-lkp@intel.com/reproduce">https://download.01.org/0day-ci/archive/20241101/202411012317.1pQLOspC-lkp@intel.com/reproduce</a>)
+
+If you fix the issue in a separate patch/commit (i.e. not just a new version of
+the same patch/commit), kindly add following tags
+| Reported-by: kernel test robot <lkp@intel.com>
+| Closes: <a
+href="https://lore.kernel.org/oe-kbuild-all/202411012317.1pQLOspC-lkp@intel.com/">https://lore.kernel.org/oe-kbuild-all/202411012317.1pQLOspC-lkp@intel.com/</a>
+
+All errors (new ones prefixed by >>):
+
+ drivers/acpi/platform_profile.c: In function 'platform_profile_register':
+<span
+class="q">>> drivers/acpi/platform_profile.c:303:42: error: implicit declaration of function 'MKDEV' [-Werror=implicit-function-declaration]
+</span> 303 | MKDEV(0, pprof->minor), NULL, "platform-profile-%s",
+ | ^~~~~
+ cc1: some warnings being treated as errors
+
+
+vim +/MKDEV +303 drivers/acpi/platform_profile.c
+
+ 261
+ 262 int platform_profile_register(struct platform_profile_handler *pprof)
+ 263 {
+ 264 bool registered;
+ 265 int err;
+ 266
+ 267 /* Sanity check the profile handler */
+ 268 if (!pprof || bitmap_empty(pprof->choices, PLATFORM_PROFILE_LAST) ||
+ 269 !pprof->profile_set || !pprof->profile_get) {
+ 270 pr_err("platform_profile: handler is invalid\n");
+ 271 return -EINVAL;
+ 272 }
+ 273 if (!test_bit(PLATFORM_PROFILE_BALANCED, pprof->choices)) {
+ 274 pr_err("platform_profile: handler does not support balanced profile\n");
+ 275 return -EINVAL;
+ 276 }
+ 277 if (!pprof->dev) {
+ 278 pr_err("platform_profile: handler device is not set\n");
+ 279 return -EINVAL;
+ 280 }
+ 281
+ 282 guard(mutex)(&profile_lock);
+ 283 /* We can only have one active profile */
+ 284 if (cur_profile)
+ 285 return -EEXIST;
+ 286
+ 287 registered = platform_profile_is_registered();
+ 288 if (!registered) {
+ 289 /* class for individual handlers */
+ 290 err = class_register(&platform_profile_class);
+ 291 if (err)
+ 292 return err;
+ 293 /* legacy sysfs files */
+ 294 err = sysfs_create_group(acpi_kobj, &platform_profile_group);
+ 295 if (err)
+ 296 goto cleanup_class;
+ 297
+ 298 }
+ 299
+ 300 /* create class interface for individual handler */
+ 301 pprof->minor = idr_alloc(&platform_profile_minor_idr, pprof, 0, 0, GFP_KERNEL);
+ 302 pprof->class_dev = device_create(&platform_profile_class, pprof->dev,
+ > 303 MKDEV(0, pprof->minor), NULL, "platform-profile-%s",
+ 304 pprof->name);
+ 305 if (IS_ERR(pprof->class_dev)) {
+ 306 err = PTR_ERR(pprof->class_dev);
+ 307 goto cleanup_legacy;
+ 308 }
+ 309 err = sysfs_create_group(&pprof->class_dev->kobj, &platform_profile_group);
+ 310 if (err)
+ 311 goto cleanup_device;
+ 312
+ 313 list_add_tail(&pprof->list, &platform_profile_handler_list);
+ 314 sysfs_notify(acpi_kobj, NULL, "platform_profile");
+ 315
+ 316 cur_profile = pprof;
+ 317 return 0;
+ 318
+ 319 cleanup_device:
+ 320 device_destroy(&platform_profile_class, MKDEV(0, pprof->minor));
+ 321
+ 322 cleanup_legacy:
+ 323 if (!registered)
+ 324 sysfs_remove_group(acpi_kobj, &platform_profile_group);
+ 325 cleanup_class:
+ 326 if (!registered)
+ 327 class_unregister(&platform_profile_class);
+ 328
+ 329 return err;
+ 330 }
+ 331 EXPORT_SYMBOL_GPL(platform_profile_register);
+ 332
+
+--
+0-DAY CI Kernel Test Service
+<a
+href="https://github.com/intel/lkp-tests/wiki">https://github.com/intel/lkp-tests/wiki</a>
+</pre></div></content></entry><entry><author><name>Bjorn Andersson</name><email>andersson@kernel.org</email></author><title>Re: [PATCH v4] usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier</title><updated>2024-11-01T15:45:15Z</updated><link
+href="http://lore.kernel.org/lkml/cmudnqum4qaec6hjoxj7wxfkdui65nkij4q2fziihf7tsmg7ry@qa3lkf4g7npw/"/><id>urn:uuid:adb0ed56-ef08-3b2c-d96a-ca0774a183da</id><thr:in-reply-to
+ref="urn:uuid:086dd36b-4979-5bdf-d1ff-ad4b260b842d"
+href="http://lore.kernel.org/lkml/20241030133632.2116-1-rex.nie@jaguarmicro.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">On Wed, Oct 30, 2024 at 09:36:32PM GMT, Rex Nie wrote:
+<span
+class="q">> If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and
+> txbuf_len are uninitialized. This commit stops to print uninitialized
+> value and misleading/false data.
+>
+> Cc: stable@vger.kernel.org
+> Fixes: a4422ff22142 (" usb: typec: qcom: Add Qualcomm PMIC Type-C driver")
+> Signed-off-by: Rex Nie <rex.nie@jaguarmicro.com>
+</span>
+Reviewed-by: Bjorn Andersson <andersson@kernel.org>
+
+Nice job. Next time, please don't use In-Reply-To between patch
+versions.
+
+Regards,
+Bjorn
+
+<span
+class="q">> ---
+> V2 -> V3:
+> - add changelog, add Fixes tag, add Cc stable ml. Thanks heikki
+> - Link to v2: <a
+href="https://lore.kernel.org/all/20241030022753.2045-1-rex.nie@jaguarmicro.com/">https://lore.kernel.org/all/20241030022753.2045-1-rex.nie@jaguarmicro.com/</a>
+> V1 -> V2:
+> - keep printout when data didn't transmit, thanks Bjorn, bod, greg k-h
+> - Links: <a
+href="https://lore.kernel.org/all/b177e736-e640-47ed-9f1e-ee65971dfc9c@linaro.org/">https://lore.kernel.org/all/b177e736-e640-47ed-9f1e-ee65971dfc9c@linaro.org/</a>
+> ---
+> drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c | 8 ++++----
+> 1 file changed, 4 insertions(+), 4 deletions(-)
+>
+> diff --git a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c
+> index 5b7f52b74a40..726423684bae 100644
+> --- a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c
+> +++ b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c
+> @@ -227,6 +227,10 @@ qcom_pmic_typec_pdphy_pd_transmit_payload(struct pmic_typec_pdphy *pmic_typec_pd
+>
+> spin_lock_irqsave(&pmic_typec_pdphy->lock, flags);
+>
+> + hdr_len = sizeof(msg->header);
+> + txbuf_len = pd_header_cnt_le(msg->header) * 4;
+> + txsize_len = hdr_len + txbuf_len - 1;
+> +
+> ret = regmap_read(pmic_typec_pdphy->regmap,
+> pmic_typec_pdphy->base + USB_PDPHY_RX_ACKNOWLEDGE_REG,
+> &val);
+> @@ -244,10 +248,6 @@ qcom_pmic_typec_pdphy_pd_transmit_payload(struct pmic_typec_pdphy *pmic_typec_pd
+> if (ret)
+> goto done;
+>
+> - hdr_len = sizeof(msg->header);
+> - txbuf_len = pd_header_cnt_le(msg->header) * 4;
+> - txsize_len = hdr_len + txbuf_len - 1;
+> -
+> /* Write message header sizeof(u16) to USB_PDPHY_TX_BUFFER_HDR_REG */
+> ret = regmap_bulk_write(pmic_typec_pdphy->regmap,
+> pmic_typec_pdphy->base + USB_PDPHY_TX_BUFFER_HDR_REG,
+> --
+> 2.17.1
+>
+>
+</span></pre></div></content></entry><entry><author><name>Jonathan Cameron</name><email>jic23@kernel.org</email></author><title>Re: [PATCH v2 06/15] iio: light: adux1020: write_event_config: use local variable for interrupt value</title><updated>2024-11-01T15:45:04Z</updated><link
+href="http://lore.kernel.org/lkml/20241101154451.227defba@jic23-huawei/"/><id>urn:uuid:637122ea-f8ad-6028-0dd8-41c4bbc74581</id><thr:in-reply-to
+ref="urn:uuid:ee4c190c-4254-fe26-18b7-7c815612ce4c"
+href="http://lore.kernel.org/lkml/ef4fe230-b7fb-4f7e-9173-ae85d305e9ae@baylibre.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">On Thu, 31 Oct 2024 11:27:45 -0500
+David Lechner <dlechner@baylibre.com> wrote:
+
+<span
+class="q">> On 10/31/24 10:27 AM, Julien Stephan wrote:
+> > state parameter is currently an int, but it is actually a boolean.
+> > iio_ev_state_store is actually using kstrtobool to check user input,
+> > then gives the converted boolean value to write_event_config. The code
+> > in adux1020_write_event_config re-uses state parameter to store an
+> > integer value. To prepare for updating the write_event_config signature
+> > to use a boolean for state, introduce a new local int variable.
+> >
+> > Signed-off-by: Julien Stephan <jstephan@baylibre.com>
+> > ---
+> > drivers/iio/light/adux1020.c | 8 ++++----
+> > 1 file changed, 4 insertions(+), 4 deletions(-)
+> >
+> > diff --git a/drivers/iio/light/adux1020.c b/drivers/iio/light/adux1020.c
+> > index 2e0170be077aef9aa194fab51afbb33aec02e513..db57d84da616b91add8c5d1aba08a73ce18c367e 100644
+> > --- a/drivers/iio/light/adux1020.c
+> > +++ b/drivers/iio/light/adux1020.c
+> > @@ -505,7 +505,7 @@ static int adux1020_write_event_config(struct iio_dev *indio_dev,
+> > enum iio_event_direction dir, int state)
+> > {
+> > struct adux1020_data *data = iio_priv(indio_dev);
+> > - int ret, mask;
+> > + int ret, mask, val;
+> >
+> > mutex_lock(&data->lock);
+> >
+> > @@ -526,12 +526,12 @@ static int adux1020_write_event_config(struct iio_dev *indio_dev,
+> > mask = ADUX1020_PROX_OFF1_INT;
+> >
+> > if (state)
+> > - state = 0;
+> > + val = 0;
+> > else
+> > - state = mask;
+> > + val = mask;
+> >
+> > ret = regmap_update_bits(data->regmap, ADUX1020_REG_INT_MASK,
+> > - mask, state);
+> > + mask, val);
+> > if (ret < 0)
+> > goto fail;
+> >
+> >
+>
+> Instead of introducing `val`, I would rewrite this as:
+>
+> if (state)
+> ret = regmap_clear_bits(...);
+> else
+> ret = regmap_set_bits(...);
+>
+</span>Good idea. Rather than go around again and potentially stall the end of this series.
+I made that change whilst applying. Shout if either of you doesn't
+like the result. Diff doesn't do a perfect job on readability (it does
+if I add a line break but then the code looks worse in the end!)
+
+From 06a1ca816450d1b5524f6010581a83ab9935d51b Mon Sep 17 00:00:00 2001
+From: Julien Stephan <jstephan@baylibre.com>
+Date: Thu, 31 Oct 2024 16:27:01 +0100
+Subject: [PATCH] iio: light: adux1020: write_event_config: use local variable
+ for interrupt value
+
+state parameter is currently an int, but it is actually a boolean.
+iio_ev_state_store is actually using kstrtobool to check user input,
+then gives the converted boolean value to write_event_config. The code
+in adux1020_write_event_config re-uses state parameter to store an
+integer value. To prepare for updating the write_event_config signature
+to use a boolean for state, introduce a new local int variable.
+
+Signed-off-by: Julien Stephan <jstephan@baylibre.com>
+Link: <a
+href="https://patch.msgid.link/20241031-iio-fix-write-event-config-signature-v2-6-2bcacbb517a2@baylibre.com">https://patch.msgid.link/20241031-iio-fix-write-event-config-signature-v2-6-2bcacbb517a2@baylibre.com</a>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+---
+ drivers/iio/light/adux1020.c | 9 ++++-----
+ 1 file <a href="http://lore.kernel.org/lkml/20241101154451.227defba@jic23-huawei/#related">changed</a>, 4 insertions(+), 5 deletions(-)
+
+<span
+class="head">diff --git a/drivers/iio/light/adux1020.c b/drivers/iio/light/adux1020.c
+index 2e0170be077a..06d5bc1d246c 100644
+--- a/drivers/iio/light/adux1020.c
++++ b/drivers/iio/light/adux1020.c
+</span><span
+class="hunk">@@ -526,12 +526,11 @@ static int adux1020_write_event_config(struct iio_dev *indio_dev,
+</span> mask = ADUX1020_PROX_OFF1_INT;
+
+ if (state)
+<span
+class="del">- state = 0;
+</span><span
+class="add">+ ret = regmap_clear_bits(data->regmap,
++ ADUX1020_REG_INT_MASK, mask);
+</span> else
+<span
+class="del">- state = mask;
+-
+- ret = regmap_update_bits(data->regmap, ADUX1020_REG_INT_MASK,
+- mask, state);
+</span><span
+class="add">+ ret = regmap_set_bits(data->regmap,
++ ADUX1020_REG_INT_MASK, mask);
+</span> if (ret < 0)
+ goto fail;
+
+--
+2.46.2
+
+
+
+<span
+class="q">>
+>
+</span>
+</pre></div></content></entry><entry><author><name>Rob Herring (Arm)</name><email>robh@kernel.org</email></author><title>Re: [PATCH v2 1/3] dt-bindings: spi: apple,spi: Add binding for Apple SPI controllers</title><updated>2024-11-01T15:43:15Z</updated><link
+href="http://lore.kernel.org/lkml/173047579349.3488175.222264580667894425.robh@kernel.org/"/><id>urn:uuid:b34217b9-76fa-1d6a-6a04-f4acc7c05359</id><thr:in-reply-to
+ref="urn:uuid:854bcda4-a0b6-3948-c365-5fcf2e39136c"
+href="http://lore.kernel.org/lkml/20241101-asahi-spi-v2-1-763a8a84d834@jannau.net/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">
+On Fri, 01 Nov 2024 15:25:03 +0100, Janne Grunau wrote:
+<span
+class="q">> From: Hector Martin <marcan@marcan.st>
+>
+> The Apple SPI controller is present in SoCs such as the M1 (t8103) and
+> M1 Pro/Max (t600x). This controller uses one IRQ and one clock, and
+> doesn't need any special properties, so the binding is trivial.
+>
+> Signed-off-by: Hector Martin <marcan@marcan.st>
+> Signed-off-by: Janne Grunau <j@jannau.net>
+> ---
+> .../devicetree/bindings/spi/apple,spi.yaml | 62 ++++++++++++++++++++++
+> 1 file changed, 62 insertions(+)
+>
+</span>
+My bot found errors running 'make dt_binding_check' on your patch:
+
+yamllint warnings/errors:
+./Documentation/devicetree/bindings/spi/apple,spi.yaml:10:11: [error] string value is redundantly quoted with any quotes (quoted-strings)
+
+dtschema/dtc warnings/errors:
+
+doc reference errors (make refcheckdocs):
+
+See <a
+href="https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241101-asahi-spi-v2-1-763a8a84d834@jannau.net">https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241101-asahi-spi-v2-1-763a8a84d834@jannau.net</a>
+
+The base for the series is generally the latest rc1. A different dependency
+should be noted in *this* patch.
+
+If you already ran 'make dt_binding_check' and didn't see the above
+error(s), then make sure 'yamllint' is installed and dt-schema is up to
+date:
+
+pip3 install dtschema --upgrade
+
+Please check and re-submit after running the above command yourself. Note
+that DT_SCHEMA_FILES can be set to your schema file to speed up checking
+your schema. However, it must be unset to test all examples with your schema.
+
+</pre></div></content></entry><entry><author><name>Doug Anderson</name><email>dianders@chromium.org</email></author><title>Re: [PATCH] kdb: Fix incomplete usage help of md, mds and btc commands</title><updated>2024-11-01T15:43:04Z</updated><link
+href="http://lore.kernel.org/lkml/CAD=FV=XY-mH2FxnnMsA99jQ2ZCcd=psTn+VJ4R9h9htK-f2ihw@mail.gmail.com/"/><id>urn:uuid:dc6d9489-7717-219b-3de4-493fa30755bf</id><thr:in-reply-to
+ref="urn:uuid:26810420-d0a9-f486-7f7b-7f82c31643cf"
+href="http://lore.kernel.org/lkml/20241031204041.GA27585@lichtman.org/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">Hi,
+
+On Thu, Oct 31, 2024 at 1:40 PM Nir Lichtman <nir@lichtman.org> wrote:
+<span
+class="q">>
+> Fix kdb usage help to document some currently missing CLI commands options
+>
+> Signed-off-by: Nir Lichtman <nir@lichtman.org>
+> ---
+> kernel/debug/kdb/kdb_main.c | 8 ++++----
+> 1 file changed, 4 insertions(+), 4 deletions(-)
+</span>
+Some of this is a bit similar to what I tried to do at :
+
+<a
+href="https://lore.kernel.org/r/20240617173426.2.I5621f286f5131c84ac71a212508ba1467ac443f2@changeid">https://lore.kernel.org/r/20240617173426.2.I5621f286f5131c84ac71a212508ba1467ac443f2@changeid</a>
+
+...but that series kinda fell on the floor because my end goal was to
+try to get it so I could access IO memory and Daniel pointed out that
+what I was doing was unsafe. The earlier patches in the series are
+overall good cleanups, though. If you're interested feel free to
+iterate on any of them.
+
+
+<span
+class="q">> diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
+> index f5f7d7fb5936..0bdffb17b163 100644
+> --- a/kernel/debug/kdb/kdb_main.c
+> +++ b/kernel/debug/kdb/kdb_main.c
+> @@ -2667,7 +2667,7 @@ EXPORT_SYMBOL_GPL(kdb_unregister);
+> static kdbtab_t maintab[] = {
+> { .name = "md",
+> .func = kdb_md,
+> - .usage = "<vaddr>",
+> + .usage = "<vaddr> [lines] [radix]",
+</span>
+In my patch, I said:
+
+.usage = "<vaddr> [<lines> [<radix>]]",
+
+...so I had the <> characters and nested the []. I think that the <>
+is supposed to signify that you're not supposed to write the text
+"lines" but that it's a variable.
+
+
+<span
+class="q">> .help = "Display Memory Contents, also mdWcN, e.g. md8c1",
+> .minlen = 1,
+> .flags = KDB_ENABLE_MEM_READ | KDB_REPEAT_NO_ARGS,
+> @@ -2686,7 +2686,7 @@ static kdbtab_t maintab[] = {
+> },
+> { .name = "mds",
+> .func = kdb_md,
+> - .usage = "<vaddr>",
+> + .usage = "<vaddr> [lines] [radix]",
+</span>
+From my prior research, "mds" doesn't support <radix>. However, some
+of the other "md" commands that you didn't modify do support
+lines/radix. Let me know if I got that wrong.
+
+
+-Doug
+</pre></div></content></entry><entry><author><name>George Stark</name><email>gnstark@salutedevices.com</email></author><title>Re: [PATCH 2/2] leds: pwm: Add optional DT property default-brightness</title><updated>2024-11-01T15:42:38Z</updated><link
+href="http://lore.kernel.org/lkml/e37f23e6-f471-4061-b346-4b082f37060d@salutedevices.com/"/><id>urn:uuid:3725b04d-a9fc-e988-d606-967ab01b1b3f</id><thr:in-reply-to
+ref="urn:uuid:05782edb-e993-bc96-9aad-9dcb63b5ab56"
+href="http://lore.kernel.org/lkml/20241031143250.GH10824@google.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">Hello Lee
+
+Thanks for the review!
+
+On 10/31/24 17:32, Lee Jones wrote:
+<span
+class="q">> On Tue, 15 Oct 2024, George Stark wrote:
+>
+>> When probing if default LED state is on then default brightness will be
+>> applied instead of max brightness.
+>>
+>> Signed-off-by: George Stark <gnstark@salutedevices.com>
+>> ---
+>> drivers/leds/leds-pwm.c | 13 ++++++++++---
+>> 1 file changed, 10 insertions(+), 3 deletions(-)
+>>
+>> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
+>> index 7961dca0db2f..514fc8ca3e80 100644
+>> --- a/drivers/leds/leds-pwm.c
+>> +++ b/drivers/leds/leds-pwm.c
+>> @@ -65,7 +65,8 @@ static int led_pwm_set(struct led_classdev *led_cdev,
+>>
+>> __attribute__((nonnull))
+>> static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
+>> - struct led_pwm *led, struct fwnode_handle *fwnode)
+>> + struct led_pwm *led, struct fwnode_handle *fwnode,
+>> + unsigned int default_brightness)
+>> {
+>> struct led_pwm_data *led_data = &priv->leds[priv->num_leds];
+>> struct led_init_data init_data = { .fwnode = fwnode };
+>> @@ -104,7 +105,7 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
+>> /* set brightness */
+>> switch (led->default_state) {
+>> case LEDS_DEFSTATE_ON:
+>> - led_data->cdev.brightness = led->max_brightness;
+>> + led_data->cdev.brightness = default_brightness;
+>> break;
+>> case LEDS_DEFSTATE_KEEP:
+>> {
+>> @@ -141,6 +142,7 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
+>> static int led_pwm_create_fwnode(struct device *dev, struct led_pwm_priv *priv)
+>> {
+>> struct led_pwm led;
+>> + unsigned int default_brightness;
+>> int ret;
+>>
+>> device_for_each_child_node_scoped(dev, fwnode) {
+>> @@ -160,7 +162,12 @@ static int led_pwm_create_fwnode(struct device *dev, struct led_pwm_priv *priv)
+>>
+>> led.default_state = led_init_default_state_get(fwnode);
+>>
+>> - ret = led_pwm_add(dev, priv, &led, fwnode);
+>> + ret = fwnode_property_read_u32(fwnode, "default-brightness",
+>> + &default_brightness);
+>> + if (ret < 0 || default_brightness > led.max_brightness)
+>> + default_brightness = led.max_brightness;
+>> +
+>> + ret = led_pwm_add(dev, priv, &led, fwnode, default_brightness);
+>
+> This creates a lot more hopping around than is necessary.
+>
+> Since led_pwm_add() already has access to the fwnode, why not look up
+> the property in there instead, thus massively simplifying things.
+</span>
+I looked up the new property here to be near to
+led_init_default_state_get (both props are from the same group) and
+led_pwm_add is big enough already. And you're absolutely right that the
+patch can be optimized. Please take a look at the v2
+
+<span
+class="q">>
+>
+>> if (ret)
+>> return ret;
+>> }
+>> --
+>> 2.25.1
+>>
+>
+</span>
+--
+Best regards
+George
+</pre></div></content></entry><entry><author><name>Mathieu Poirier</name><email>mathieu.poirier@linaro.org</email></author><title>Re: [PATCH V5] remoteproc: Documentation: update with details</title><updated>2024-11-01T15:41:29Z</updated><link
+href="http://lore.kernel.org/lkml/ZyT2piU27MF28XcN@p14s/"/><id>urn:uuid:245ae693-dda8-67e2-5447-c96feb798e8f</id><thr:in-reply-to
+ref="urn:uuid:4ad4a1f2-5c65-5556-9d95-c1f0b643fadb"
+href="http://lore.kernel.org/lkml/20241026212259.31950-1-yesanishhere@gmail.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">On Sat, Oct 26, 2024 at 02:22:59PM -0700, anish kumar wrote:
+<span
+class="q">> Added details as below:
+> 1. added sysfs information
+> 2. verbose details about remoteproc driver/framework
+> responsibilites.
+> 3. example for resource request
+>
+> Signed-off-by: anish kumar <yesanishhere@gmail.com>
+> ---
+> V5:
+> based on comment from mathieu poirier, remove all files
+> and combined that in the original file and as he adviced
+> nothing with respect to old documentation was changed.
+>
+> V4:
+> Fixed compilation errors and moved documentation to
+> driver-api directory.
+>
+> V3:
+> Seperated out the patches further to make the intention
+> clear for each patch.
+>
+> V2:
+> Reported-by: kernel test robot <lkp@intel.com>
+> Closes: <a
+href="https://lore.kernel.org/oe-kbuild-all/202410161444.jOKMsoGS-lkp@intel.com/">https://lore.kernel.org/oe-kbuild-all/202410161444.jOKMsoGS-lkp@intel.com/</a>
+>
+> Documentation/staging/remoteproc.rst | 483 +++++++++++++++++++++++++++
+> 1 file changed, 483 insertions(+)
+>
+> diff --git a/Documentation/staging/remoteproc.rst b/Documentation/staging/remoteproc.rst
+> index 348ee7e508ac..1c15f4d1b9eb 100644
+> --- a/Documentation/staging/remoteproc.rst
+> +++ b/Documentation/staging/remoteproc.rst
+> @@ -29,6 +29,68 @@ remoteproc will add those devices. This makes it possible to reuse the
+> existing virtio drivers with remote processor backends at a minimal development
+> cost.
+>
+> +The primary purpose of the remoteproc framework is to download firmware
+> +for remote processors and manage their lifecycle. The framework consists
+> +of several key components:
+> +
+> +- **Character Driver**: Provides userspace access to control the remote
+> + processor.
+> +- **ELF Utility**: Offers functions for handling ELF files and managing
+> + resources requested by the remote processor.
+> +- **Remoteproc Core**: Manages firmware downloads and recovery actions
+> + in case of a remote processor crash.
+> +- **Coredump**: Provides facilities for coredumping and tracing from
+> + the remote processor in the event of a crash.
+> +- **Userspace Interaction**: Uses sysfs and debugfs to manage the
+> + lifecycle and status of the remote processor.
+> +- **Virtio Support**: Facilitates interaction with the virtio and
+> + rpmsg bus.
+> +
+> +Remoteproc framework Responsibilities
+> +=====================================
+> +
+> +The framework begins by gathering information about the firmware file
+> +to be downloaded through the request_firmware function. It supports
+> +the ELF format and parses the firmware image to identify the physical
+> +addresses that need to be populated from the corresponding ELF sections.
+> +The framework also requires knowledge of the logical or I/O-mapped
+> +addresses in the application processor. Once this information is
+</span>
+"The framework also requires knowledge of the logical or I/O-mapped addresses in
+the application processor". What is that about?
+
+<span
+class="q">> +obtained from the driver, the framework transfers the data to the
+> +specified addresses and starts the remote, along with
+</span>
+"remote" what?
+
+<span
+class="q">> +any devices physically or logically connected to it.
+</span>
+I have never seen this happening.
+
+<span
+class="q">> +
+> +Dependent devices, referred to as `subdevices` within the framework,
+> +are also managed post-registration by their respective drivers.
+> +Subdevices can register themselves using `rproc_(add/remove)_subdev`.
+> +Non-remoteproc drivers can use subdevices as a way to logically connect
+> +to remote and get lifecycle notifications of the remote.
+> +
+> +The framework oversees the lifecycle of the remote and
+> +provides the `rproc_report_crash` function, which the driver invokes
+> +upon receiving a crash notification from the remote. The
+> +notification method can differ based on the design of the remote
+> +processor and its communication with the application processor. For
+> +instance, if the remote is a DSP equipped with a watchdog,
+> +unresponsive behavior triggers the watchdog, generating an interrupt
+> +that routes to the application processor, allowing it to call
+> +`rproc_report_crash` in the driver's interrupt context.
+> +
+> +During crash handling, the framework performs the following actions:
+> +
+> +a. Sends a request to stop the remote and any connected or
+> + dependent subdevices.
+> +b. Generates a coredump, dumping all `resources` requested by the
+> + remote alongside relevant debugging information. Resources are
+> + explained below.
+> +c. Reloads the firmware and restarts the remote.
+> +
+> +If the `RPROC_FEAT_ATTACH_ON_RECOVERY` flag is set, the detach and
+> +attach callbacks of the driver are invoked without reloading the
+> +firmware. This is useful when the remote requires no
+> +assistance for recovery, or when the application processor can restart
+> +independently. After recovery, the application processor can reattach
+> +to the remote.
+> +
+</span>
+The above provides a description of some of the things the remoteproc subsystem
+does and as such, I would call it "overview" rather than responsabilities.
+
+<span
+class="q">> User API
+> ========
+>
+> @@ -107,6 +169,239 @@ Typical usage
+> API for implementors
+> ====================
+>
+> +It describes the API that can be used by remote processor Drivers
+> +that want to use the remote processor Driver Core Framework. This
+> +framework provides all interfacing towards user space so that the
+> +same code does not have to be reproduced each time. This also means
+> +that a remote processor driver then only needs to provide the different
+> +routines(operations) that control the remote processor.
+> +
+> +Each remote processor driver that wants to use the remote processor Driver Core
+> +must #include <linux/remoteproc.h> (you would have to do this anyway when
+> +writing a rproc device driver). This include file contains following
+> +register routine::
+> +
+</span>
+The above is very basic information about subsystems in general - please remove.
+
+<span
+class="q">> + int devm_rproc_add(struct device *dev, struct rproc *rproc)
+> +
+> +The devm_rproc_add routine registers a remote processor device.
+> +The parameter of this routine is a pointer to a rproc device structure.
+> +This routine returns zero on success and a negative errno code for failure.
+</span>
+Look at what is documented for other API functions and do the same here.
+
+<span
+class="q">> +
+> +The rproc device structure looks like this::
+> +
+> + struct rproc {
+> + struct list_head node;
+> + struct iommu_domain *domain;
+> + const char *name;
+> + const char *firmware;
+> + void *priv;
+> + struct rproc_ops *ops;
+> + struct device dev;
+> + atomic_t power;
+> + unsigned int state;
+> + enum rproc_dump_mechanism dump_conf;
+> + struct mutex lock;
+> + struct dentry *dbg_dir;
+> + struct list_head traces;
+> + int num_traces;
+> + struct list_head carveouts;
+> + struct list_head mappings;
+> + u64 bootaddr;
+> + struct list_head rvdevs;
+> + struct list_head subdevs;
+> + struct idr notifyids;
+> + int index;
+> + struct work_struct crash_handler;
+> + unsigned int crash_cnt;
+> + bool recovery_disabled;
+> + int max_notifyid;
+> + struct resource_table *table_ptr;
+> + struct resource_table *clean_table;
+> + struct resource_table *cached_table;
+> + size_t table_sz;
+> + bool has_iommu;
+> + bool auto_boot;
+> + bool sysfs_read_only;
+> + struct list_head dump_segments;
+> + int nb_vdev;
+> + u8 elf_class;
+> + u16 elf_machine;
+> + struct cdev cdev;
+> + bool cdev_put_on_release;
+> + DECLARE_BITMAP(features, RPROC_MAX_FEATURES);
+> + };
+</span>
+All that is already part of remoteproc.h and doesn't need to be duplicated here
+- please remove.
+
+<span
+class="q">> +
+> +It contains following fields:
+> +
+> +* node: list node of this rproc object
+> +* domain: iommu domain
+> +* name: human readable name of the rproc
+> +* firmware: name of firmware file to be loaded
+> +* priv: private data which belongs to the platform-specific rproc module
+> +* ops: platform-specific start/stop rproc handlers
+> +* dev: virtual device for refcounting and common remoteproc behavior
+> +* power: refcount of users who need this rproc powered up
+> +* state: state of the device
+> +* dump_conf: Currently selected coredump configuration
+> +* lock: lock which protects concurrent manipulations of the rproc
+> +* dbg_dir: debugfs directory of this rproc device
+> +* traces: list of trace buffers
+> +* num_traces: number of trace buffers
+> +* carveouts: list of physically contiguous memory allocations
+> +* mappings: list of iommu mappings we initiated, needed on shutdown
+> +* bootaddr: address of first instruction to boot rproc with (optional)
+> +* rvdevs: list of remote virtio devices
+> +* subdevs: list of subdevices, to following the running state
+> +* notifyids: idr for dynamically assigning rproc-wide unique notify ids
+> +* index: index of this rproc device
+> +* crash_handler: workqueue for handling a crash
+> +* crash_cnt: crash counter
+> +* recovery_disabled: flag that state if recovery was disabled
+> +* max_notifyid: largest allocated notify id.
+> +* table_ptr: pointer to the resource table in effect
+> +* clean_table: copy of the resource table without modifications. Used
+> +* when a remote processor is attached or detached from the core
+> +* cached_table: copy of the resource table
+> +* table_sz: size of @cached_table
+> +* has_iommu: flag to indicate if remote processor is behind an MMU
+> +* auto_boot: flag to indicate if remote processor should be auto-started
+> +* sysfs_read_only: flag to make remoteproc sysfs files read only
+> +* dump_segments: list of segments in the firmware
+> +* nb_vdev: number of vdev currently handled by rproc
+> +* elf_class: firmware ELF class
+> +* elf_machine: firmware ELF machine
+> +* cdev: character device of the rproc
+> +* cdev_put_on_release: flag to indicate if remoteproc should be shutdown on @char_dev release
+> +* features: indicate remoteproc features
+> +
+</span>
+Remove
+
+<span
+class="q">> +The list of rproc operations is defined as::
+> +
+> + struct rproc_ops {
+> + int (*prepare)(struct rproc *rproc);
+> + int (*unprepare)(struct rproc *rproc);
+> + int (*start)(struct rproc *rproc);
+> + int (*stop)(struct rproc *rproc);
+> + int (*attach)(struct rproc *rproc);
+> + int (*detach)(struct rproc *rproc);
+> + void (*kick)(struct rproc *rproc, int vqid);
+> + void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
+> + int (*parse_fw)(struct rproc *rproc, const struct firmware *fw);
+> + int (*handle_rsc)(struct rproc *rproc, u32 rsc_type, void *rsc,
+> + int offset, int avail);
+> + struct resource_table *(*find_loaded_rsc_table)(
+> + struct rproc *rproc, const struct firmware *fw);
+> + struct resource_table *(*get_loaded_rsc_table)(
+> + struct rproc *rproc, size_t *size);
+> + int (*load)(struct rproc *rproc, const struct firmware *fw);
+> + int (*sanity_check)(struct rproc *rproc, const struct firmware *fw);
+> + u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
+> + unsigned long (*panic)(struct rproc *rproc);
+> + void (*coredump)(struct rproc *rproc);
+> + };
+> +
+</span>
+If you really want to document all the callbacks, it should be done in the
+"Implementation callbacks" section following the style that is already in place.
+
+<span
+class="q">> +Most of the operations are optional. Currently in the implementation
+> +there are no mandatory operations, however from the practical standpoint
+> +minimum ops are:
+> +
+> +* start: this is a pointer to the routine that starts the remote processor
+> + device.
+> + The routine needs a pointer to the remote processor device structure as a
+> + parameter. It returns zero on success or a negative errno code for failure.
+> +
+> +* stop: with this routine the remote processor device is being stopped.
+> +
+> + The routine needs a pointer to the remote processor device structure as a
+> + parameter. It returns zero on success or a negative errno code for failure.
+> +
+> +* da_to_va: this is the routine that needs to translate device address to
+> + application processor virtual address that it can copy code to.
+> +
+> + The routine needs a pointer to the remote processor device structure as a
+> + parameter. It returns zero on success or a negative errno code for failure.
+> +
+> + The routine provides the device address it finds in the ELF firmware and asks
+> + the driver to convert that to virtual address.
+> +
+> +All other callbacks are optional in case of ELF provided firmware.
+> +
+> +* load: this is to load the firmware on to the remote device.
+> +
+> + The routine needs firmware file that it needs to load on to the remote processor.
+> + If the driver overrides this callback then default ELF loader will not get used.
+> + Otherwise default framework provided loader gets used.
+> +
+> + load = rproc_elf_load_segments;
+> + parse_fw = rproc_elf_load_rsc_table;
+> + find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table;
+> + sanity_check = rproc_elf_sanity_check;
+> + get_boot_addr = rproc_elf_get_boot_addr;
+> +
+> +* parse_fw: this routing parses the provided firmware. In case of ELF format,
+> + framework provided rproc_elf_load_rsc_table function can be used.
+> +
+> +* sanity_check: Check the format of the firmware.
+> +
+> +* coredump: If the driver prefers to manage coredumps independently, it can
+> + implement its own coredump handling. However, the framework offers a default
+> + implementation for the ELF format by assigning this callback to
+> + rproc_coredump, unless the driver has overridden it.
+> +
+> +* get_boot_addr: In case the bootaddr defined in ELF firmware is different, driver
+> + can use this callback to set a different boot address for remote processor to
+> + starts its reset vector from.
+> +
+> +* find_loaded_rsc_table: this routine gets the loaded resource table from the firmware.
+> +
+> + resource table should have a section named (.resource_table) for the framework
+> + to understand and interpret its content. Resource table is a way for remote
+> + processor to ask for resources such as memory for dumping and logging. Look
+> + at core documentation to know how to create the ELF section for the same.
+> +
+> +* get_loaded_rsc_table: Driver can customize passing the resource table by overriding
+> + this callback. Framework doesn't provide any default implementation for the same.
+> +
+> +The driver must provide the following information to the core:
+> +
+> +a. Translate device addresses (physical addresses) found in the ELF
+> + firmware to virtual addresses in Linux using the `da_to_va`
+> + callback. This allows the framework to copy ELF firmware from the
+> + filesystem to the addresses expected by the remote since
+> + the framework cannot directly access those physical addresses.
+> +b. Prepare/unprepare the remote prior to firmware loading,
+> + which may involve allocating carveout and reserved memory regions.
+> +c. Implement methods for starting and stopping the remote,
+> + whether by setting registers or sending explicit interrupts,
+> + depending on the hardware design.
+> +d. Provide attach and detach callbacks to start the remote
+> + without loading the firmware. This is beneficial when the remote
+> + processor is already loaded and running.
+> +e. Implement a load callback for firmware loading, typically using
+> + the ELF loader provided by the framework; currently, only ELF
+> + format is supported.
+> +f. Invoke the framework's crash handler API upon detecting a remote
+> + crash.
+> +
+> +Drivers must fill the `rproc_ops` structure and call `rproc_alloc`
+> +to register themselves with the framework.
+> +
+> +.. code-block:: c
+> +
+> + struct rproc_ops {
+> + int (*prepare)(struct rproc *rproc);
+> + int (*unprepare)(struct rproc *rproc);
+> + int (*start)(struct rproc *rproc);
+> + int (*stop)(struct rproc *rproc);
+> + int (*attach)(struct rproc *rproc);
+> + int (*detach)(struct rproc *rproc);
+> + void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len,
+> + bool *is_iomem);
+> + int (*parse_fw)(struct rproc *rproc, const struct firmware *fw);
+> + int (*handle_rsc)(struct rproc *rproc, u32 rsc_type,
+> + void *rsc, int offset, int avail);
+> + int (*load)(struct rproc *rproc, const struct firmware *fw);
+> + //snip
+> + };
+</span>
+This is already added above, why is it repeated here?
+
+<span
+class="q">> +
+> ::
+>
+> struct rproc *rproc_alloc(struct device *dev, const char *name,
+> @@ -190,6 +485,35 @@ platform specific rproc implementation. This should not be called from a
+> non-remoteproc driver. This function can be called from atomic/interrupt
+> context.
+>
+> +To add a subdev corresponding driver can call
+> +
+> +::
+> +
+> + void rproc_add_subdev(struct rproc *rproc, struct rproc_subdev *subdev)
+> +
+> +To remove a subdev, driver can call.
+> +
+> +::
+> +
+> + void rproc_remove_subdev(struct rproc *rproc, struct rproc_subdev *subdev)
+> +
+</span>
+The above doesn't add value to the documentation and users needing to use these
+functions will need to look at the code anyway - please remove.
+
+<span
+class="q">> +To work with ELF coredump below function can be called
+> +
+> +::
+> +
+> + void rproc_coredump_cleanup(struct rproc *rproc)
+> + void rproc_coredump(struct rproc *rproc)
+> + void rproc_coredump_using_sections(struct rproc *rproc)
+> + int rproc_coredump_add_segment(struct rproc *rproc, dma_addr_t da, size_t size)
+> + int rproc_coredump_add_custom_segment(struct rproc *rproc,
+> + dma_addr_t da, size_t size,
+> + void (*dumpfn)(struct rproc *rproc,
+> + struct rproc_dump_segment *segment,
+> + void *dest, size_t offset,
+> + size_t size))
+> +
+> +Remember that coredump functions provided by the framework only works with ELF format.
+> +
+</span>
+Remove
+
+<span
+class="q">> Implementation callbacks
+> ========================
+>
+> @@ -228,6 +552,123 @@ the exact virtqueue index to look in is optional: it is easy (and not
+> too expensive) to go through the existing virtqueues and look for new buffers
+> in the used rings.
+>
+> +Userspace control methods
+> +==========================
+> +
+> +At times, userspace may need to check the state of the remote processor to
+> +prevent other processes from using it. For instance, if the remote processor
+> +is a DSP used for playback, there may be situations where the DSP is
+> +undergoing recovery and cannot be used. In such cases, attempts to access the
+> +DSP for playback should be blocked. The rproc framework provides sysfs APIs
+> +to inform userspace of the processor's current status which should be utilised
+> +to achieve the same.
+> +
+</span>
+Remove
+
+<span
+class="q">> +Additionally, there are scenarios where userspace applications need to explicitly
+> +control the rproc. In these cases, rproc also offers the file descriptors.
+> +
+> +Below set of commands can be used to start and stop the rproc
+> +where 'X' refers to instance of associated remoteproc. There can be systems
+> +where there are more than one rprocs such as multiple DSP's
+> +connected to application processors running Linux.
+> +
+> +.. code-block:: c
+> +
+> + echo start > /sys/class/remoteproc/remoteprocX/state
+> + echo stop > /sys/class/remoteproc/remoteprocX/state
+> +
+> +To know the state of rproc:
+> +
+> +.. code-block:: c
+> +
+> + cat /sys/class/remoteproc/remoteprocX/state
+> +
+> +
+> +To dynamically replace firmware, execute the following commands:
+> +
+> +.. code-block:: c
+> +
+> + echo stop > /sys/class/remoteproc/remoteprocX/state
+> + echo -n <firmware_name> >
+> + /sys/class/remoteproc/remoteprocX/firmware
+> + echo start > /sys/class/remoteproc/remoteprocX/state
+> +
+> +To simulate a remote crash, execute:
+> +
+> +.. code-block:: c
+> +
+> + echo 1 > /sys/kernel/debug/remoteproc/remoteprocX/crash
+> +
+> +To get the trace logs, execute
+> +
+> +.. code-block:: c
+> +
+> + cat /sys/kernel/debug/remoteproc/remoteprocX/crashX
+> +
+> +where X will be 0 or 1 if there are 2 resources. Also, this
+> +file will only exist if resources are defined in ELF firmware
+> +file.
+> +
+> +The coredump feature can be disabled with the following command:
+> +
+> +.. code-block:: c
+> +
+> + echo disabled > /sys/kernel/debug/remoteproc/remoteprocX/coredump
+> +
+> +Userspace can also control start/stop of rproc by using a
+</span>
+s/rproc/remote processor
+
+<span
+class="q">> +remoteproc Character Device, it can open the open a file descriptor
+</span>
+s/Character Device/character device
+
+<span
+class="q">> +and write `start` to initiate it, and `stop` to terminate it.
+> +Below set of api's can be used to start and stop the rproc
+> +where 'X' refers to instance of associated remoteproc. There can be systems
+> +where there are more than one rprocs such as multiple DSP's
+> +connected to application processors running Linux.
+</span>
+Duplication from above - remove.
+
+<span
+class="q">> +
+> +.. code-block:: c
+> +
+> + echo start > /sys/class/remoteproc/remoteprocX/state
+> + echo stop > /sys/class/remoteproc/remoteprocX/state
+> +
+> +To know the state of rproc:
+> +
+> +.. code-block:: c
+> +
+> + cat /sys/class/remoteproc/remoteprocX/state
+> +
+</span>
+Remove
+
+<span
+class="q">> +
+> +To dynamically replace firmware, execute the following commands:
+> +
+> +.. code-block:: c
+> +
+> + echo stop > /sys/class/remoteproc/remoteprocX/state
+> + echo -n <firmware_name> >
+> + /sys/class/remoteproc/remoteprocX/firmware
+> + echo start > /sys/class/remoteproc/remoteprocX/state
+> +
+> +To simulate a remote crash, execute:
+> +
+> +.. code-block:: c
+> +
+> + echo 1 > /sys/kernel/debug/remoteproc/remoteprocX/crash
+> +
+> +To get the trace logs, execute
+> +
+> +.. code-block:: c
+> +
+> + cat /sys/kernel/debug/remoteproc/remoteprocX/crashX
+> +
+> +where X will be 0 or 1 if there are 2 resources. Also, this
+> +file will only exist if resources are defined in ELF firmware
+> +file.
+> +
+> +The coredump feature can be disabled with the following command:
+> +
+> +.. code-block:: c
+> +
+> + echo disabled > /sys/kernel/debug/remoteproc/remoteprocX/coredump
+> +
+> +Userspace can also control start/stop of rproc by using a
+> +remoteproc Character Device, it can open the open a file descriptor
+> +and write `start` to initiate it, and `stop` to terminate it.
+</span>
+Duplication from above - remove.
+
+<span
+class="q">> +
+> Binary Firmware Structure
+> =========================
+>
+> @@ -340,6 +781,48 @@ We also expect that platform-specific resource entries will show up
+> at some point. When that happens, we could easily add a new RSC_PLATFORM
+> type, and hand those resources to the platform-specific rproc driver to handle.
+>
+> +if the remote requests both `RSC_TRACE` and `RSC_CARVEOUT` for memory
+> +allocation, the ELF firmware can be structured as follows:
+> +
+> +.. code-block:: c
+> +
+> + #define MAX_SHARED_RESOURCE 2
+> + #define LOG_BUF_SIZE 1000
+> + #define CARVEOUT_DUMP_PA 0x12345678
+> + #define CARVEOUT_DUMP_SIZE 2000
+> +
+> + struct shared_resource_table {
+> + u32 ver;
+> + u32 num;
+> + u32 reserved[2];
+> + u32 offset[MAX_SHARED_RESOURCE];
+> + struct fw_rsc_trace log_trace;
+> + struct fw_rsc_carveout dump_carveout;
+> + };
+> +
+> + volatile struct shared_resource_table table = {
+> + .ver = 1,
+> + .num = 2,
+> + .reserved = {0, 0},
+> + .offset = {
+> + offsetof(struct resource_table, log_trace),
+> + offsetof(struct resource_table, dump_carveout),
+> + },
+> + .log_trace = {
+> + RSC_TRACE,
+> + (u32)log_buf, LOG_BUF_SIZE, 0, "log_trace",
+> + },
+> + .dump_carveout = {
+> + RSC_CARVEOUT,
+> + (u32)FW_RSC_ADDR_ANY, CARVEOUT_PA, 0, "carveout_dump",
+> + },
+> + };
+> +
+> +The framework creates a sysfs file when it encounters the `RSC_TRACE`
+> +type to expose log information to userspace. Other resource types are
+> +handled accordingly. In the example above, `CARVEOUT_DUMP_SIZE` bytes
+> +of DMA memory will be allocated starting from `CARVEOUT_DUMP_PA`.
+> +
+</span>
+Remove
+
+<span
+class="q">> Virtio and remoteproc
+> =====================
+>
+</span>
+Before spinning off another revision I encourage you to spend time looking at
+existing documentation. Reading various mailing lists with a special
+focus on how people split their patches based on topics would also be
+beneficial.
+
+Lastly, typing my email address correctly would be highly appreciated.
+
+Thanks,
+Mathieu
+
+<span
+class="q">> --
+> 2.39.3 (Apple Git-146)
+>
+>
+</span></pre></div></content></entry><entry><author><name>Borislav Petkov</name><email>bp@alien8.de</email></author><title>Re: [PATCH v5 0/4] Distinguish between variants of IBPB</title><updated>2024-11-01T15:41:19Z</updated><link
+href="http://lore.kernel.org/lkml/20241101153857.GAZyT2EdLXKs7ZmDFx@fat_crate.local/"/><id>urn:uuid:87315698-5cce-93e0-116f-32d3d054c439</id><thr:in-reply-to
+ref="urn:uuid:7848ad27-59f2-66a2-0604-1759555ec538"
+href="http://lore.kernel.org/lkml/173039500211.1507616.16831780895322741303.b4-ty@google.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">On Thu, Oct 31, 2024 at 12:51:33PM -0700, Sean Christopherson wrote:
+<span
+class="q">> [1/4] x86/cpufeatures: Clarify semantics of X86_FEATURE_IBPB
+> <a
+href="https://github.com/kvm-x86/linux/commit/43801a0dbb38">https://github.com/kvm-x86/linux/commit/43801a0dbb38</a>
+> [2/4] x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET
+> <a
+href="https://github.com/kvm-x86/linux/commit/99d252e3ae3e">https://github.com/kvm-x86/linux/commit/99d252e3ae3e</a>
+</span>
+ff898623af2e ("x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET")
+
+--
+Regards/Gruss,
+ Boris.
+
+<a
+href="https://people.kernel.org/tglx/notes-about-netiquette">https://people.kernel.org/tglx/notes-about-netiquette</a>
+</pre></div></content></entry><entry><author><name>Krzysztof Kozlowski</name><email>krzk@kernel.org</email></author><title>Re: [PATCH v4 14/16] net: stmmac: dwmac-s32: add basic NXP S32G/S32R glue driver</title><updated>2024-11-01T15:41:02Z</updated><link
+href="http://lore.kernel.org/lkml/9e876379-c555-45e6-8a8a-752d90fdc8ed@kernel.org/"/><id>urn:uuid:30c4433f-89b6-f3b7-80b7-9c9eeb95f8aa</id><thr:in-reply-to
+ref="urn:uuid:fbcfeeed-2e04-e19b-b7e8-7edb91c7374e"
+href="http://lore.kernel.org/lkml/ZyO9Mfq+znZdJJrJ@lsv051416.swis.nl-cdc01.nxp.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">On 31/10/2024 18:24, Jan Petrous wrote:
+<span
+class="q">> On Thu, Oct 31, 2024 at 06:16:46PM +0100, Jan Petrous wrote:
+>> On Thu, Oct 31, 2024 at 04:44:45PM +0100, Krzysztof Kozlowski wrote:
+>>> On 31/10/2024 15:43, Jan Petrous wrote:
+>>>> On Tue, Oct 29, 2024 at 08:13:40AM +0100, Krzysztof Kozlowski wrote:
+>>>>> On Mon, Oct 28, 2024 at 09:24:56PM +0100, Jan Petrous (OSS) wrote:
+>>>>>> + plat->init = s32_gmac_init;
+>>>>>> + plat->exit = s32_gmac_exit;
+>>>>>> + plat->fix_mac_speed = s32_fix_mac_speed;
+>>>>>> +
+>>>>>> + plat->bsp_priv = gmac;
+>>>>>> +
+>>>>>> + return stmmac_pltfr_probe(pdev, plat, &res);
+>>>>>> +}
+>>>>>> +
+>>>>>> +static const struct of_device_id s32_dwmac_match[] = {
+>>>>>> + { .compatible = "nxp,s32g2-dwmac" },
+>>>>>> + { .compatible = "nxp,s32g3-dwmac" },
+>>>>>> + { .compatible = "nxp,s32r-dwmac" },
+>>>>>
+>>>>> Why do you need three same entries?
+>>>>>
+>>>>
+>>>> We have three different SoCs and in v3 review you told me
+>>>> to return all back:
+>>>> <a
+href="https://patchwork.kernel.org/comment/26067257/">https://patchwork.kernel.org/comment/26067257/</a>
+>>>
+>>> It was about binding, not driver.
+>>>
+>>> I also asked there: use proper fallback and compatibility. Both comments
+>>> of course affect your driver, but why choosing only first part?
+>>>
+>>
+>> Does it mean I should remove first two (G2/G3) members from match array
+>> and use "nxp,s32r-dwmac" as fallback for G2/G3? And similarly change
+>> the bindings to:
+>>
+>> compatible:
+>> oneOf:
+>> - const: nxp,s32r-dwmac
+>> - items:
+>> - enum:
+>> - nxp,s32g2-dwmac
+>> - nxp,s32g3-dwmac
+>> - const: nxp,s32r-dwmac
+>>
+>> And add here, into the driver, those members back when some device
+>> specific feature will be needed? Am I understand your hints right?
+>>
+>
+> Sorry, it's not correct. This way I'm not able to detect S32R which is
+> the only one with higher speed.
+>
+> Then I could use the G2 as fallback I think, Ie.:
+>
+> compatible:
+> oneOf:
+> - const: nxp,s32g2-dwmac
+> - items:
+> - enum:
+> - nxp,s32g3-dwmac
+> - nxp,s32r-dwmac
+> - const: nxp,s32g2-dwmac
+</span>
+I don't understand. In both cases you can 'detect r', if by this you
+meant match and bind. I don't care which one is the fallback, but if one
+does not work it points to different issues with your code.
+
+Best regards,
+Krzysztof
+
+</pre></div></content></entry><entry><author><name>Bjorn Andersson</name><email>andersson@kernel.org</email></author><title>Re: [PATCH v3 3/3] PCI: qcom: Update ICC and OPP values during link up event</title><updated>2024-11-01T15:40:58Z</updated><link
+href="http://lore.kernel.org/lkml/bsxaq6zilwaavcwi25dbz2wgrgqrqxfme6a5lfdg6jqfl4kspj@xahygne3tqg4/"/><id>urn:uuid:c1a51ad4-30df-8454-421f-cfa43c8a4dd0</id><thr:in-reply-to
+ref="urn:uuid:60c26f9c-0686-e5b4-b0fd-213e2ead902f"
+href="http://lore.kernel.org/lkml/20241101-remove_wait-v3-3-7accf27f7202@quicinc.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">On Fri, Nov 01, 2024 at 05:04:14PM GMT, Krishna chaitanya chundru wrote:
+<span
+class="q">> As part of the PCIe link up event, update ICC and OPP values
+> as at this point only driver can know the link speed and
+> width of the PCIe link.
+>
+</span>
+It would be nice if you were to write your commit messages in the style
+documented at <a
+href="https://docs.kernel.org/process/submitting-patches.html#describe-your-changes">https://docs.kernel.org/process/submitting-patches.html#describe-your-changes</a>
+I.e. start with a clear problem description, then move into describing
+the solution.
+
+Your commit message is stating that this is the only place the driver
+can know the link speed, but wouldn't that imply that there's some
+actual problem with the code currently?
+
+
+I'm guessing (because that's what your commit message is forcing me to
+do) that in the case that we don't detect anything connected at probe
+time and then we get a "hotplug" interrupt, we will have completely
+incorrect bus votes?
+
+If so, it would seem that this patch should have a:
+Fixes: 4581403f6792 ("PCI: qcom: Enumerate endpoints based on Link up event in 'global_irq' interrupt")
+
+And of course, a proper description of that problem.
+
+Regards,
+Bjorn
+
+<span
+class="q">> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
+> ---
+> drivers/pci/controller/dwc/pcie-qcom.c | 2 ++
+> 1 file changed, 2 insertions(+)
+>
+> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
+> index 474b7525442d..5826c0e7ca0b 100644
+> --- a/drivers/pci/controller/dwc/pcie-qcom.c
+> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
+> @@ -1558,6 +1558,8 @@ static irqreturn_t qcom_pcie_global_irq_thread(int irq, void *data)
+> pci_lock_rescan_remove();
+> pci_rescan_bus(pp->bridge->bus);
+> pci_unlock_rescan_remove();
+> +
+> + qcom_pcie_icc_opp_update(pcie);
+> } else {
+> dev_WARN_ONCE(dev, 1, "Received unknown event. INT_STATUS: 0x%08x\n",
+> status);
+>
+> --
+> 2.34.1
+>
+>
+</span></pre></div></content></entry><entry><author><name>Krzysztof Kozlowski</name><email>krzk@kernel.org</email></author><title>Re: [PATCH asahi-soc/dt 01/10] dt-bindings: arm: apple: apple,pmgr: Add A7-A11 compatibles</title><updated>2024-11-01T15:39:39Z</updated><link
+href="http://lore.kernel.org/lkml/4ce01e3b-9bcd-4d8c-bfe1-c2b17a4c2566@kernel.org/"/><id>urn:uuid:0326f435-109d-72bc-0241-95f810e4c4e3</id><thr:in-reply-to
+ref="urn:uuid:7100b345-9ca2-8988-dd45-907cd539adb4"
+href="http://lore.kernel.org/lkml/5e0b5238-d781-458a-9285-df54a16232af@marcan.st/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">On 01/11/2024 13:33, Hector Martin wrote:
+<span
+class="q">> - First the ancient s5l series
+> - Then all the t/sXXXX chips up to t8103 (M1) (numeric order, ignoring
+> prefix letter)
+> - Then the rest of the "baseline" Ax,Mx chips that continue after M1,
+> which are all numbered t8xxx (numeric order)
+> - Finally the t6xxx series (Mx Pro/Mx Max), which forks the timeline and
+> numbering after t8103/M1 (M1 Pro = t6000).
+>
+> Unless there's significant objection I'd like to keep this pattern, it
+> makes sense from the POV of people working on these chips.
+</span>
+No, no, it's fine, I am just forgetting where do we have exceptions. :)
+
+Best regards,
+Krzysztof
+
+</pre></div></content></entry><entry><author><name>Oliver Upton</name><email>oliver.upton@linux.dev</email></author><title>Re: [PATCH v3 03/14] KVM: selftests: Return a value from vcpu_get_reg() instead of using an out-param</title><updated>2024-11-01T15:38:59Z</updated><link
+href="http://lore.kernel.org/lkml/ZyT2CB6zodtbWEI9@linux.dev/"/><id>urn:uuid:8e0284c3-77ef-8e37-aab3-cf5125f83ce8</id><thr:in-reply-to
+ref="urn:uuid:eaa12fb4-732a-6676-4b84-22d6654838f7"
+href="http://lore.kernel.org/lkml/ZyTpwwm0s89iU9Pk@google.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">Hey,
+
+On Fri, Nov 01, 2024 at 07:48:00AM -0700, Sean Christopherson wrote:
+<span
+class="q">> On Fri, Nov 01, 2024, Mark Brown wrote:
+> > On Wed, Oct 09, 2024 at 08:49:42AM -0700, Sean Christopherson wrote:
+> > > Return a uint64_t from vcpu_get_reg() instead of having the caller provide
+> > > a pointer to storage, as none of the vcpu_get_reg() usage in KVM selftests
+> > > accesses a register larger than 64 bits, and vcpu_set_reg() only accepts a
+> > > 64-bit value. If a use case comes along that needs to get a register that
+> > > is larger than 64 bits, then a utility can be added to assert success and
+> > > take a void pointer, but until then, forcing an out param yields ugly code
+> > > and prevents feeding the output of vcpu_get_reg() into vcpu_set_reg().
+> >
+> > This commit, which is in today's -next as 5c6c7b71a45c9c, breaks the
+> > build on arm64:
+> >
+> > aarch64/psci_test.c: In function ‘host_test_system_off2’:
+> > aarch64/psci_test.c:247:9: error: too many arguments to function ‘vcpu_get_reg’
+> > 247 | vcpu_get_reg(target, KVM_REG_ARM_PSCI_VERSION, &psci_version);
+> > | ^~~~~~~~~~~~
+> > In file included from aarch64/psci_test.c:18:
+> > include/kvm_util.h:705:24: note: declared here
+> > 705 | static inline uint64_t vcpu_get_reg(struct kvm_vcpu *vcpu, uint64_t id)
+> > | ^~~~~~~~~~~~
+> > At top level:
+> > cc1: note: unrecognized command-line option ‘-Wno-gnu-variable-sized-type-not-at
+> > -end’ may have been intended to silence earlier diagnostics
+> >
+> > since the updates done to that file did not take account of 72be5aa6be4
+> > ("KVM: selftests: Add test for PSCI SYSTEM_OFF2") which has been merged
+> > in the kvm-arm64 tree.
+>
+> Bugger. In hindsight, it's obvious that of course arch selftests would add usage
+> of vcpu_get_reg().
+>
+> Unless someone has a better idea, I'll drop the series from kvm-x86, post a new
+> version that applies on linux-next, and then re-apply the series just before the
+> v6.13 merge window (rinse and repeat as needed if more vcpu_get_reg() users come
+> along).
+</span>
+Can you instead just push out a topic branch and let the affected
+maintainers deal with it? This is the usual way we handle conflicts
+between trees...
+
+<span
+class="q">> That would be a good oppurtunity to do the $(ARCH) directory switch[*] too, e.g.
+> have a "selftests_late" or whatever topic branch.
+</span>
+The right time to do KVM-wide changes (even selftests) is *early* in the
+development cycle, not last minute. It gives us plenty of time to iron out
+the wrinkles.
+
+<span
+class="q">> Sorry for the pain Mark, you've been playing janitor for us too much lately.
+</span>
++1, appreciate your help on this.
+
+--
+Thanks,
+Oliver
+</pre></div></content></entry><entry><author><name>Jonathan Cameron</name><email>jic23@kernel.org</email></author><title>Re: [PATCH v2 05/15] iio: proximity: sx9500: simplify code in write_event_config callback</title><updated>2024-11-01T15:37:09Z</updated><link
+href="http://lore.kernel.org/lkml/20241101153656.43e27240@jic23-huawei/"/><id>urn:uuid:c655d237-138d-92db-3a39-fc0924f674ea</id><thr:in-reply-to
+ref="urn:uuid:da253a47-1fe4-d6ec-5897-5cfcd6c7fd9f"
+href="http://lore.kernel.org/lkml/20241031-iio-fix-write-event-config-signature-v2-5-2bcacbb517a2@baylibre.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">On Thu, 31 Oct 2024 16:27:00 +0100
+Julien Stephan <jstephan@baylibre.com> wrote:
+
+<span
+class="q">> iio_ev_state_store is actually using kstrtobool to check user
+> input, then gives the converted boolean value to the write_event_config
+> callback.
+>
+> Remove useless code in write_event_config callback.
+>
+> Signed-off-by: Julien Stephan <jstephan@baylibre.com>
+</span>Applied and pushed out as testing. Still time for other reviews if anyone
+cares to take a look.
+
+Thanks,
+
+Jonathan
+
+<span
+class="q">> ---
+> drivers/iio/proximity/sx9500.c | 4 ++--
+> 1 file changed, 2 insertions(+), 2 deletions(-)
+>
+> diff --git a/drivers/iio/proximity/sx9500.c b/drivers/iio/proximity/sx9500.c
+> index 3f4eace05cfc6a4679fe82854dc059aa4a710d6d..e3da709424d5b2bd4e746df7adc4a4969e62f2a6 100644
+> --- a/drivers/iio/proximity/sx9500.c
+> +++ b/drivers/iio/proximity/sx9500.c
+> @@ -551,7 +551,7 @@ static int sx9500_write_event_config(struct iio_dev *indio_dev,
+>
+> mutex_lock(&data->mutex);
+>
+> - if (state == 1) {
+> + if (state) {
+> ret = sx9500_inc_chan_users(data, chan->channel);
+> if (ret < 0)
+> goto out_unlock;
+> @@ -571,7 +571,7 @@ static int sx9500_write_event_config(struct iio_dev *indio_dev,
+> goto out_unlock;
+>
+> out_undo_chan:
+> - if (state == 1)
+> + if (state)
+> sx9500_dec_chan_users(data, chan->channel);
+> else
+> sx9500_inc_chan_users(data, chan->channel);
+>
+</span>
+</pre></div></content></entry><entry><author><name>Kevin Hilman</name><email>khilman@baylibre.com</email></author><title>[PATCH v5 3/3] pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups</title><updated>2024-11-01T15:36:48Z</updated><link
+href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-3-3011aa04622f@baylibre.com/"/><id>urn:uuid:11615bf4-8ff2-c4a8-144c-ff8bb03cdf31</id><thr:in-reply-to
+ref="urn:uuid:4b4b1161-c4f3-5b7a-f4fd-b9a8d5e4d864"
+href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-0-3011aa04622f@baylibre.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">When a device supports IO daisy-chain wakeups, it uses a dedicated
+wake IRQ. Devices with IO daisy-chain wakeups enabled should not set
+wakeup constraints since these can happen even from deep power states,
+so should not prevent the DM from picking deep power states.
+
+Wake IRQs are set with dev_pm_set_wake_irq() or
+dev_pm_set_dedicated_wake_irq(). The latter is used by the serial
+driver used on K3 platforms (drivers/tty/serial/8250/8250_omap.c)
+when the interrupts-extended property is used to describe the
+dedicated wakeup interrupt.
+
+Detect these wake IRQs in the suspend path, and if set, skip sending
+constraint.
+
+Tested-by: Dhruva Gole <d-gole@ti.com>
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+---
+ drivers/pmdomain/ti/ti_sci_pm_domains.c | 9 +++++++++
+ 1 file <a href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-3-3011aa04622f@baylibre.com/#related">changed</a>, 9 insertions(+)
+
+<span
+class="head">diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
+index ff529fa2d6135cc2fb32ae8a3ca26ac055f66cf5..8c46ca428f60b3d42a5a43488538f16b7ffaa3ac 100644
+--- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
++++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
+</span><span
+class="hunk">@@ -82,6 +82,15 @@ static inline void ti_sci_pd_set_wkup_constraint(struct device *dev)
+</span> int ret;
+
+ if (device_may_wakeup(dev)) {
+<span
+class="add">+ /*
++ * If device can wakeup using IO daisy chain wakeups,
++ * we do not want to set a constraint.
++ */
++ if (dev->power.wakeirq) {
++ dev_dbg(dev, "%s: has wake IRQ, not setting constraints\n", __func__);
++ return;
++ }
++
+</span> ret = ti_sci->ops.pm_ops.set_device_constraint(ti_sci, pd->idx,
+ TISCI_MSG_CONSTRAINT_SET);
+ if (!ret)
+
+--
+2.46.2
+
+</pre></div></content></entry><entry><author><name>Kevin Hilman</name><email>khilman@baylibre.com</email></author><title>[PATCH v5 2/3] pmdomain: ti_sci: add wakeup constraint management</title><updated>2024-11-01T15:36:47Z</updated><link
+href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-2-3011aa04622f@baylibre.com/"/><id>urn:uuid:48eb97d7-ab67-98c3-64b3-b03b2a84f61b</id><thr:in-reply-to
+ref="urn:uuid:4b4b1161-c4f3-5b7a-f4fd-b9a8d5e4d864"
+href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-0-3011aa04622f@baylibre.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">During system-wide suspend, check all devices connected to PM domain
+to see if they are wakeup-enabled. If so, set a TI SCI device
+constraint.
+
+Note: DM firmware clears all constraints on resume.
+
+Co-developed-by: Vibhore Vardhan <vibhore@ti.com>
+Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
+Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
+Tested-by: Dhruva Gole <d-gole@ti.com>
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+---
+ drivers/pmdomain/ti/ti_sci_pm_domains.c | 17 +++++++++++++++++
+ 1 file <a href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-2-3011aa04622f@baylibre.com/#related">changed</a>, 17 insertions(+)
+
+<span
+class="head">diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
+index c976a382d64c807daea72fa1ea9d6c11c8773762..ff529fa2d6135cc2fb32ae8a3ca26ac055f66cf5 100644
+--- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
++++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
+</span><span
+class="hunk">@@ -74,6 +74,21 @@ static void ti_sci_pd_set_lat_constraint(struct device *dev, s32 val)
+</span> pd->idx, val);
+ }
+
+<span
+class="add">+static inline void ti_sci_pd_set_wkup_constraint(struct device *dev)
++{
++ struct generic_pm_domain *genpd = pd_to_genpd(dev->pm_domain);
++ struct ti_sci_pm_domain *pd = genpd_to_ti_sci_pd(genpd);
++ const struct ti_sci_handle *ti_sci = pd->parent->ti_sci;
++ int ret;
++
++ if (device_may_wakeup(dev)) {
++ ret = ti_sci->ops.pm_ops.set_device_constraint(ti_sci, pd->idx,
++ TISCI_MSG_CONSTRAINT_SET);
++ if (!ret)
++ dev_dbg(dev, "ti_sci_pd: ID:%d set device constraint.\n", pd->idx);
++ }
++}
++
+</span> /*
+ * ti_sci_pd_power_off(): genpd power down hook
+ * @domain: pointer to the powerdomain to power off
+<span
+class="hunk">@@ -116,6 +131,8 @@ static int ti_sci_pd_suspend(struct device *dev)
+</span> if (ti_sci_pd_is_valid_constraint(val))
+ ti_sci_pd_set_lat_constraint(dev, val);
+
+<span
+class="add">+ ti_sci_pd_set_wkup_constraint(dev);
++
+</span> return 0;
+ }
+ #else
+
+--
+2.46.2
+
+</pre></div></content></entry><entry><author><name>Kevin Hilman</name><email>khilman@baylibre.com</email></author><title>[PATCH v5 1/3] pmdomain: ti_sci: add per-device latency constraint management</title><updated>2024-11-01T15:36:47Z</updated><link
+href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-1-3011aa04622f@baylibre.com/"/><id>urn:uuid:31e47c58-c301-6d44-2c84-1d34a06ae318</id><thr:in-reply-to
+ref="urn:uuid:4b4b1161-c4f3-5b7a-f4fd-b9a8d5e4d864"
+href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-0-3011aa04622f@baylibre.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">For each device in a TI SCI PM domain, check whether the device has
+any resume latency constraints set via per-device PM QoS. If
+constraints are set, send them to DM via the new SCI constraints API.
+
+Checking for constraints happen for each device before system-wide
+suspend (via ->suspend() hook.)
+
+An important detail here is that the PM domain driver inserts itself
+into the path of both the ->suspend() and ->resume() hook path
+of *all* devices in the PM domain. This allows generic PM domain code
+to handle the constraint management and communication with TI SCI.
+
+Further, this allows device drivers to use existing PM QoS APIs to
+add/update constraints.
+
+DM firmware clears constraints during its resume, so Linux has
+to check/update/send constraints each time system suspends.
+
+Co-developed-by: Vibhore Vardhan <vibhore@ti.com>
+Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
+Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>
+Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
+Tested-by: Dhruva Gole <d-gole@ti.com>
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+---
+ drivers/pmdomain/ti/ti_sci_pm_domains.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
+ 1 file <a href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-1-3011aa04622f@baylibre.com/#related">changed</a>, 50 insertions(+)
+
+<span
+class="head">diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
+index 1510d5ddae3decd5b70f835338ed4e0b2a3c9373..c976a382d64c807daea72fa1ea9d6c11c8773762 100644
+--- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
++++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
+</span><span
+class="hunk">@@ -13,6 +13,8 @@
+</span> #include <linux/platform_device.h>
+ #include <linux/pm_domain.h>
+ #include <linux/slab.h>
+<span
+class="add">+#include <linux/pm_qos.h>
++#include <linux/pm_runtime.h>
+</span> #include <linux/soc/ti/ti_sci_protocol.h>
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+<span
+class="hunk">@@ -51,6 +53,27 @@ struct ti_sci_pm_domain {
+</span>
+ #define genpd_to_ti_sci_pd(gpd) container_of(gpd, struct ti_sci_pm_domain, pd)
+
+<span
+class="add">+static inline bool ti_sci_pd_is_valid_constraint(s32 val)
++{
++ return val != PM_QOS_RESUME_LATENCY_NO_CONSTRAINT;
++}
++
++static void ti_sci_pd_set_lat_constraint(struct device *dev, s32 val)
++{
++ struct generic_pm_domain *genpd = pd_to_genpd(dev->pm_domain);
++ struct ti_sci_pm_domain *pd = genpd_to_ti_sci_pd(genpd);
++ const struct ti_sci_handle *ti_sci = pd->parent->ti_sci;
++ int ret;
++
++ ret = ti_sci->ops.pm_ops.set_latency_constraint(ti_sci, val, TISCI_MSG_CONSTRAINT_SET);
++ if (ret)
++ dev_err(dev, "ti_sci_pd: set latency constraint failed: ret=%d\n",
++ ret);
++ else
++ dev_dbg(dev, "ti_sci_pd: ID:%d set latency constraint %d\n",
++ pd->idx, val);
++}
++
+</span> /*
+ * ti_sci_pd_power_off(): genpd power down hook
+ * @domain: pointer to the powerdomain to power off
+<span
+class="hunk">@@ -79,6 +102,26 @@ static int ti_sci_pd_power_on(struct generic_pm_domain *domain)
+</span> return ti_sci->ops.dev_ops.get_device(ti_sci, pd->idx);
+ }
+
+<span
+class="add">+#ifdef CONFIG_PM_SLEEP
++static int ti_sci_pd_suspend(struct device *dev)
++{
++ int ret;
++ s32 val;
++
++ ret = pm_generic_suspend(dev);
++ if (ret)
++ return ret;
++
++ val = dev_pm_qos_read_value(dev, DEV_PM_QOS_RESUME_LATENCY);
++ if (ti_sci_pd_is_valid_constraint(val))
++ ti_sci_pd_set_lat_constraint(dev, val);
++
++ return 0;
++}
++#else
++#define ti_sci_pd_suspend NULL
++#endif
++
+</span> /*
+ * ti_sci_pd_xlate(): translation service for TI SCI genpds
+ * @genpdspec: DT identification data for the genpd
+<span
+class="hunk">@@ -188,6 +231,13 @@ static int ti_sci_pm_domain_probe(struct platform_device *pdev)
+</span> pd->pd.power_on = ti_sci_pd_power_on;
+ pd->idx = args.args[0];
+ pd->parent = pd_provider;
+<span
+class="add">+ /*
++ * If SCI constraint functions are present, then firmware
++ * supports the constraints API.
++ */
++ if (pd_provider->ti_sci->ops.pm_ops.set_device_constraint &&
++ pd_provider->ti_sci->ops.pm_ops.set_latency_constraint)
++ pd->pd.domain.ops.suspend = ti_sci_pd_suspend;
+</span>
+ pm_genpd_init(&pd->pd, NULL, true);
+
+
+--
+2.46.2
+
+</pre></div></content></entry><entry><author><name>Kevin Hilman</name><email>khilman@baylibre.com</email></author><title>[PATCH v5 0/3] pmdomain: ti_sci: collect and send low-power mode constraints</title><updated>2024-11-01T15:36:46Z</updated><link
+href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-0-3011aa04622f@baylibre.com/"/><id>urn:uuid:4b4b1161-c4f3-5b7a-f4fd-b9a8d5e4d864</id><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">The latest (10.x) version of the firmware for the PM co-processor (aka
+device manager, or DM) adds support for a "managed" mode, where the DM
+firmware will select the specific low power state which is entered
+when Linux requests a system-wide suspend.
+
+In this mode, the DM will always attempt the deepest low-power state
+available for the SoC.
+
+However, Linux (or OSes running on other cores) may want to constrain
+the DM for certain use cases. For example, the deepest state may have
+a wakeup/resume latency that is too long for certain use cases. Or,
+some wakeup-capable devices may potentially be powered off in deep
+low-power states, but if one of those devices is enabled as a wakeup
+source, it should not be powered off.
+
+These kinds of constraints are are already known in Linux by the use
+of existing APIs such as per-device PM QoS and device wakeup APIs, but
+now we need to communicate these constraints to the DM.
+
+For TI SoCs with TI SCI support, all DM-managed devices will be
+connected to a TI SCI PM domain. So the goal of this series is to use
+the PM domain driver for TI SCI devices to collect constraints, and
+communicate them to the DM via the new TI SCI APIs.
+
+This is all managed by TI SCI PM domain code. No new APIs are needed
+by Linux drivers. Any device that is managed by TI SCI will be
+checked for QoS constraints or wakeup capability and the constraints
+will be collected and sent to the DM.
+
+This series depends on the support for the new TI SCI APIs (v10) and
+was also tested with this series to update 8250_omap serial support
+for AM62x[2].
+
+[1] <a
+href="https://lore.kernel.org/all/20240801195422.2296347-1-msp@baylibre.com">https://lore.kernel.org/all/20240801195422.2296347-1-msp@baylibre.com</a>
+[2] <a
+href="https://lore.kernel.org/all/20240807141227.1093006-1-msp@baylibre.com/">https://lore.kernel.org/all/20240807141227.1093006-1-msp@baylibre.com/</a>
+
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+---
+Changes in v5:
+- fix build-error when CONFIG_PM_SLEEP not defined
+- Link to v4: <a
+href="https://lore.kernel.org/r/20240906-lpm-v6-10-constraints-pmdomain-v4-0-4055557fafbc@baylibre.com">https://lore.kernel.org/r/20240906-lpm-v6-10-constraints-pmdomain-v4-0-4055557fafbc@baylibre.com</a>
+
+Changes in v4:
+- fixed missing return in wakeirq error path
+- updated trailers with reviewed & tested tags
+- Link to v3: <a
+href="https://lore.kernel.org/r/20240905-lpm-v6-10-constraints-pmdomain-v3-0-e359cbb39654@baylibre.com">https://lore.kernel.org/r/20240905-lpm-v6-10-constraints-pmdomain-v3-0-e359cbb39654@baylibre.com</a>
+
+Changes in v3:
+- change latency set functions to static void
+- Link to v2: <a
+href="https://lore.kernel.org/r/20240819-lpm-v6-10-constraints-pmdomain-v2-0-461325a6008f@baylibre.com">https://lore.kernel.org/r/20240819-lpm-v6-10-constraints-pmdomain-v2-0-461325a6008f@baylibre.com</a>
+
+Changes in v2:
+- To simplify this version a bit, drop the pmdomain ->power_off()
+ changes. Constraints only sent during ->suspend() path. The pmdomain
+ path was an optimization that may be added back later.
+- With the above simplification, drop the extra state variables that
+ had been added to keep track of constraint status.
+- Link to v1: <a
+href="https://lore.kernel.org/r/20240805-lpm-v6-10-constraints-pmdomain-v1-0-d186b68ded4c@baylibre.com">https://lore.kernel.org/r/20240805-lpm-v6-10-constraints-pmdomain-v1-0-d186b68ded4c@baylibre.com</a>
+
+---
+Kevin Hilman (3):
+ pmdomain: ti_sci: add per-device latency constraint management
+ pmdomain: ti_sci: add wakeup constraint management
+ pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups
+
+ drivers/pmdomain/ti/ti_sci_pm_domains.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 76 insertions(+)
+---
+base-commit: ad7eb1b6b92ee0c959a0a6ae846ddadd7a79ea64
+change-id: 20240802-lpm-v6-10-constraints-pmdomain-f33df5aef449
+prerequisite-change-id: 20241006-tisci-syssuspendresume-e6550720a50f:v13
+prerequisite-patch-id: 945b15416a011cb40007c5d95561786c1776bb98
+prerequisite-patch-id: 69a741b9c81d7990937483fc481aafa70e67669d
+prerequisite-patch-id: 15e97947da8cb7055745151990c756d81fded804
+prerequisite-patch-id: a0efbf22e69d23dba8bb96db4032ca644935709b
+prerequisite-patch-id: 2999da190c1ba63aabecc55fae501d442e4e0d7b
+
+Best regards,
+--
+Kevin Hilman <khilman@baylibre.com>
+
+</pre></div></content></entry><entry><author><name>Jonathan Cameron</name><email>jic23@kernel.org</email></author><title>Re: [PATCH v2 04/15] iio: proximity: irsd200: simplify code in write_event_config callback</title><updated>2024-11-01T15:36:20Z</updated><link
+href="http://lore.kernel.org/lkml/20241101153608.23a9c6f1@jic23-huawei/"/><id>urn:uuid:74f09b13-8157-93a6-328b-90d18d2afd4b</id><thr:in-reply-to
+ref="urn:uuid:447a8057-432d-a0a9-a141-fc5025a1a9a0"
+href="http://lore.kernel.org/lkml/20241031-iio-fix-write-event-config-signature-v2-4-2bcacbb517a2@baylibre.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">On Thu, 31 Oct 2024 16:26:59 +0100
+Julien Stephan <jstephan@baylibre.com> wrote:
+
+<span
+class="q">> iio_ev_state_store is actually using kstrtobool to check user
+> input, then gives the converted boolean value to the write_event_config
+> callback.
+>
+> Remove useless code in write_event_config callback.
+>
+> Signed-off-by: Julien Stephan <jstephan@baylibre.com>
+</span>Applied and pushed out as testing. If anyone has time to review
+I can still add tags (or pull the patches if there is something I missed!)
+
+Thanks,
+
+Jonathan
+
+<span
+class="q">> ---
+> drivers/iio/proximity/irsd200.c | 2 +-
+> 1 file changed, 1 insertion(+), 1 deletion(-)
+>
+> diff --git a/drivers/iio/proximity/irsd200.c b/drivers/iio/proximity/irsd200.c
+> index 6e96b764fed8b577d71c3146210679b0b61d4c38..fb0691da99ee621e19013a64d122f097e793efd9 100644
+> --- a/drivers/iio/proximity/irsd200.c
+> +++ b/drivers/iio/proximity/irsd200.c
+> @@ -662,7 +662,7 @@ static int irsd200_write_event_config(struct iio_dev *indio_dev,
+> return ret;
+>
+> return regmap_field_write(
+> - data->regfields[IRS_REGF_INTR_COUNT_THR_OR], !!state);
+> + data->regfields[IRS_REGF_INTR_COUNT_THR_OR], state);
+> default:
+> return -EINVAL;
+> }
+>
+</span>
+</pre></div></content></entry><entry><author><name>Kevin Hilman</name><email>khilman@baylibre.com</email></author><title>Re: [PATCH v4 0/3] pmdomain: ti_sci: collect and send low-power mode constraints</title><updated>2024-11-01T15:35:30Z</updated><link
+href="http://lore.kernel.org/lkml/7hwmhnnf0f.fsf@baylibre.com/"/><id>urn:uuid:c61ea5b1-48e8-c3d0-eac6-5fc9154ec730</id><thr:in-reply-to
+ref="urn:uuid:cc2c9c2c-260b-f814-2876-26305aeca478"
+href="http://lore.kernel.org/lkml/20241101144445.56ejnuoxshqwns37@boots/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">Nishanth Menon <nm@ti.com> writes:
+
+<span
+class="q">> On 11:11-20241031, Ulf Hansson wrote:
+>> On Wed, 30 Oct 2024 at 20:43, Kevin Hilman <khilman@baylibre.com> wrote:
+>> >
+>> > Ulf Hansson <ulf.hansson@linaro.org> writes:
+>> >
+>> > > On Wed, 30 Oct 2024 at 14:01, Nishanth Menon <nm@ti.com> wrote:
+>> > >>
+>> > >> Hi Kevin Hilman,
+>> > >>
+>> > >> On Fri, 06 Sep 2024 09:14:48 -0700, Kevin Hilman wrote:
+>> > >> > The latest (10.x) version of the firmware for the PM co-processor (aka
+>> > >> > device manager, or DM) adds support for a "managed" mode, where the DM
+>> > >> > firmware will select the specific low power state which is entered
+>> > >> > when Linux requests a system-wide suspend.
+>> > >> >
+>> > >> > In this mode, the DM will always attempt the deepest low-power state
+>> > >> > available for the SoC.
+>> > >> >
+>> > >> > [...]
+>> > >>
+>> > >> I have applied the following to branch ti-drivers-soc-next on [1].
+>> > >> Thank you!
+>> > >>
+>> > >> Ulf, based on your ack[2], I have assumed that you want me to pick
+>> > >> this series up. Let me know if that is not the case and I can drop the
+>> > >> series.
+>> > >
+>> > > Well, that was a while ago. The reason was because there was a
+>> > > dependency to another series [2], when this was posted.
+>> > >
+>> > > If that's not the case anymore, I think it's better to funnel this via
+>> > > my pmdomain tree. Please let me know how to proceed.
+>> >
+>> > The build-time dependency on [2] still exists, and since that was just
+>> > queued up by Nishanth, I think this series should (still) go along with
+>> > it to keep things simple.
+>> >
+>> > Kevin
+>>
+>> Right, that makes perfect sense to me too. If we discover conflicts,
+>> let's deal with them then.
+>
+>
+> oops.. I missed this response. OK, I will let things be.
+>
+</span>
+Oops, 0day bot found a build error in linux-next when CONFIG_PM_SLEEP is
+not defined[1]. Need to respin to fix this.
+
+v5 coming right up....
+
+Kevin
+
+[1] <a
+href="https://lore.kernel.org/all/CA+G9fYtioQ22nVr9m22+qyMqUNRsGdA=cFw_j1OUv=x8Pcs-bw@mail.gmail.com/">https://lore.kernel.org/all/CA+G9fYtioQ22nVr9m22+qyMqUNRsGdA=cFw_j1OUv=x8Pcs-bw@mail.gmail.com/</a>
+</pre></div></content></entry><entry><author><name>Jonathan Cameron</name><email>jic23@kernel.org</email></author><title>Re: [PATCH v2 03/15] iio: light: tsl2772: simplify code in write_event_config callback</title><updated>2024-11-01T15:35:21Z</updated><link
+href="http://lore.kernel.org/lkml/20241101153509.11ae74b9@jic23-huawei/"/><id>urn:uuid:ba78cdbf-6561-c6ef-f0fd-10f343557c18</id><thr:in-reply-to
+ref="urn:uuid:c9c12e36-c944-62c0-f373-d6c3c51e217e"
+href="http://lore.kernel.org/lkml/20241031-iio-fix-write-event-config-signature-v2-3-2bcacbb517a2@baylibre.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">On Thu, 31 Oct 2024 16:26:58 +0100
+Julien Stephan <jstephan@baylibre.com> wrote:
+
+<span
+class="q">> iio_ev_state_store is actually using kstrtobool to check user
+> input, then gives the converted boolean value to the write_event_config
+> callback.
+>
+> Remove useless code in write_event_config callback.
+>
+> Signed-off-by: Julien Stephan <jstephan@baylibre.com>
+</span>Applied.
+<span
+class="q">> ---
+> drivers/iio/light/tsl2772.c | 4 ++--
+> 1 file changed, 2 insertions(+), 2 deletions(-)
+>
+> diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
+> index cab468a82b616a23394977da1d8822d29d8941d3..26082f239c4c3aeabfe73ed100d6e885f5266329 100644
+> --- a/drivers/iio/light/tsl2772.c
+> +++ b/drivers/iio/light/tsl2772.c
+> @@ -1086,9 +1086,9 @@ static int tsl2772_write_interrupt_config(struct iio_dev *indio_dev,
+> struct tsl2772_chip *chip = iio_priv(indio_dev);
+>
+> if (chan->type == IIO_INTENSITY)
+> - chip->settings.als_interrupt_en = val ? true : false;
+> + chip->settings.als_interrupt_en = val;
+> else
+> - chip->settings.prox_interrupt_en = val ? true : false;
+> + chip->settings.prox_interrupt_en = val;
+>
+> return tsl2772_invoke_change(indio_dev);
+> }
+>
+</span>
+</pre></div></content></entry><entry><author><name>Jonathan Cameron</name><email>jic23@kernel.org</email></author><title>Re: [PATCH v2 02/15] iio: proximity: hx9023s: simplify code in write_event_config callback</title><updated>2024-11-01T15:34:46Z</updated><link
+href="http://lore.kernel.org/lkml/20241101153434.11d85f8b@jic23-huawei/"/><id>urn:uuid:c8a9619e-10eb-3a16-1f56-21cbfa9dc5e5</id><thr:in-reply-to
+ref="urn:uuid:86f1d001-2b45-a3aa-44a1-1b4b99f208db"
+href="http://lore.kernel.org/lkml/20241031-iio-fix-write-event-config-signature-v2-2-2bcacbb517a2@baylibre.com/"/><content
+type="xhtml"><div
+xmlns="http://www.w3.org/1999/xhtml"><pre
+style="white-space:pre-wrap">On Thu, 31 Oct 2024 16:26:57 +0100
+Julien Stephan <jstephan@baylibre.com> wrote:
+
+<span
+class="q">> iio_ev_state_store is actually using kstrtobool to check user
+> input, then gives the converted boolean value to the write_event_config
+> callback.
+>
+> Remove useless code in write_event_config callback.
+>
+> Signed-off-by: Julien Stephan <jstephan@baylibre.com>
+</span>Applied to the togreg branch of iio.git and pushed out as testing.
+Note if anyone else has time to review, I can still add tags for now.
+
+I'll probably push it out as an (in theory) not rebasing tree early
+next week to give a bit of time in next before a pull request.
+
+Jonathan
+
+<span
+class="q">> ---
+> drivers/iio/proximity/hx9023s.c | 2 +-
+> 1 file changed, 1 insertion(+), 1 deletion(-)
+>
+> diff --git a/drivers/iio/proximity/hx9023s.c b/drivers/iio/proximity/hx9023s.c
+> index d8fb34060d3db88a3ba5ecdc209b14be8e42e8b9..38441b1ee040c7c26047b0cb2ac443ecb8396df3 100644
+> --- a/drivers/iio/proximity/hx9023s.c
+> +++ b/drivers/iio/proximity/hx9023s.c
+> @@ -879,7 +879,7 @@ static int hx9023s_write_event_config(struct iio_dev *indio_dev,
+> struct hx9023s_data *data = iio_priv(indio_dev);
+>
+> if (test_bit(chan->channel, &data->chan_in_use)) {
+> - hx9023s_ch_en(data, chan->channel, !!state);
+> + hx9023s_ch_en(data, chan->channel, state);
+> __assign_bit(chan->channel, &data->chan_event,
+> data->ch_data[chan->channel].enable);
+> }
+>
+</span>
+</pre></div></content></entry></feed>
+\ No newline at end of file