lore_kernel_org_lkml.atom.xml - sfeed_tests - sfeed tests and RSS and Atom files
HTML git clone git://git.codemadness.org/sfeed_tests
DIR Log
DIR Files
DIR Refs
DIR README
DIR LICENSE
---
lore_kernel_org_lkml.atom.xml (98859B)
---
1 <?xml version="1.0" encoding="us-ascii"?>
2 <feed
3 xmlns="http://www.w3.org/2005/Atom"
4 xmlns:thr="http://purl.org/syndication/thread/1.0"><title>linux-kernel.vger.kernel.org archive mirror</title><link
5 rel="alternate"
6 type="text/html"
7 href="http://lore.kernel.org/lkml/"/><link
8 rel="self"
9 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
10 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
11 ref="urn:uuid:8c64a34f-09cd-4fba-a1f1-e0655404bfeb"
12 href="http://lore.kernel.org/lkml/20241101154844.1175860-1-gnstark@salutedevices.com/"/><content
13 type="xhtml"><div
14 xmlns="http://www.w3.org/1999/xhtml"><pre
15 style="white-space:pre-wrap">When probing if default LED state is on then default brightness will be
16 applied instead of max brightness.
17
18 Signed-off-by: George Stark <gnstark@salutedevices.com>
19 ---
20 drivers/leds/leds-pwm.c | 17 ++++++++++++++++-
21 1 file <a href="http://lore.kernel.org/lkml/20241101154844.1175860-3-gnstark@salutedevices.com/#related">changed</a>, 16 insertions(+), 1 deletion(-)
22
23 <span
24 class="head">diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
25 index 7961dca0db2f..7636ee178c39 100644
26 --- a/drivers/leds/leds-pwm.c
27 +++ b/drivers/leds/leds-pwm.c
28 </span><span
29 class="hunk">@@ -63,6 +63,20 @@ static int led_pwm_set(struct led_classdev *led_cdev,
30 </span> return pwm_apply_might_sleep(led_dat->pwm, &led_dat->pwmstate);
31 }
32
33 <span
34 class="add">+static int led_pwm_default_brightness_get(struct fwnode_handle *fwnode,
35 + int max_brightness)
36 +{
37 + unsigned int default_brightness;
38 + int ret;
39 +
40 + ret = fwnode_property_read_u32(fwnode, "default-brightness",
41 + &default_brightness);
42 + if (ret < 0 || default_brightness > max_brightness)
43 + default_brightness = max_brightness;
44 +
45 + return default_brightness;
46 +}
47 +
48 </span> __attribute__((nonnull))
49 static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
50 struct led_pwm *led, struct fwnode_handle *fwnode)
51 <span
52 class="hunk">@@ -104,7 +118,8 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
53 </span> /* set brightness */
54 switch (led->default_state) {
55 case LEDS_DEFSTATE_ON:
56 <span
57 class="del">- led_data->cdev.brightness = led->max_brightness;
58 </span><span
59 class="add">+ led_data->cdev.brightness =
60 + led_pwm_default_brightness_get(fwnode, led->max_brightness);
61 </span> break;
62 case LEDS_DEFSTATE_KEEP:
63 {
64 --
65 2.25.1
66
67 </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
68 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
69 ref="urn:uuid:8c64a34f-09cd-4fba-a1f1-e0655404bfeb"
70 href="http://lore.kernel.org/lkml/20241101154844.1175860-1-gnstark@salutedevices.com/"/><content
71 type="xhtml"><div
72 xmlns="http://www.w3.org/1999/xhtml"><pre
73 style="white-space:pre-wrap">Optional default-brightness property specifies brightness value to be
74 used if default LED state is on.
75
76 Signed-off-by: George Stark <gnstark@salutedevices.com>
77 ---
78 Documentation/devicetree/bindings/leds/leds-pwm.yaml | 6 ++++++
79 1 file <a href="http://lore.kernel.org/lkml/20241101154844.1175860-2-gnstark@salutedevices.com/#related">changed</a>, 6 insertions(+)
80
81 <span
82 class="head">diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.yaml b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
83 index 113b7c218303..61b97e8bc36d 100644
84 --- a/Documentation/devicetree/bindings/leds/leds-pwm.yaml
85 +++ b/Documentation/devicetree/bindings/leds/leds-pwm.yaml
86 </span><span
87 class="hunk">@@ -34,6 +34,12 @@ patternProperties:
88 </span> Maximum brightness possible for the LED
89 $ref: /schemas/types.yaml#/definitions/uint32
90
91 <span
92 class="add">+ default-brightness:
93 + description:
94 + Brightness to be set if LED's default state is on. Used only during
95 + initialization. If the option is not set then max brightness is used.
96 + $ref: /schemas/types.yaml#/definitions/uint32
97 +
98 </span> required:
99 - pwms
100 - max-brightness
101 --
102 2.25.1
103
104 </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
105 href="http://lore.kernel.org/lkml/20241101154844.1175860-1-gnstark@salutedevices.com/"/><id>urn:uuid:8c64a34f-09cd-4fba-a1f1-e0655404bfeb</id><content
106 type="xhtml"><div
107 xmlns="http://www.w3.org/1999/xhtml"><pre
108 style="white-space:pre-wrap">led-pwm driver supports default-state DT property and if that state is on then
109 the driver during initialization turns on the LED setting maximum brightness.
110 Sometimes it's desirable to use lower initial brightness.
111 This patch series adds support for DT property default-brightness.
112
113 Things to discuss:
114 If such a property is acceptable it could be moved to leds/common.yaml due to
115 several drivers support multiple brightness levels and could support the property
116 too.
117
118 Changes in v2:
119 leds: pwm: Add optional DT property default-brightness
120 - refactor patch to make it more accurate
121 link to v1: [1]
122
123 [1] <a
124 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>
125
126 George Stark (2):
127 dt-bindings: leds: pwm: Add default-brightness property
128 leds: pwm: Add optional DT property default-brightness
129
130 .../devicetree/bindings/leds/leds-pwm.yaml | 6 ++++++
131 drivers/leds/leds-pwm.c | 17 ++++++++++++++++-
132 2 files changed, 22 insertions(+), 1 deletion(-)
133
134 --
135 2.25.1
136
137 </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
138 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
139 ref="urn:uuid:e028ca59-5d0a-f486-732a-92c7cb8d2f9c"
140 href="http://lore.kernel.org/lkml/20241101080614.1070819-7-andrei.stefanescu@oss.nxp.com/"/><content
141 type="xhtml"><div
142 xmlns="http://www.w3.org/1999/xhtml"><pre
143 style="white-space:pre-wrap"><span
144 class="q">> Add basic GPIO functionality (request, free, get, set) for the existing
145 > pinctrl SIUL2 driver since the hardware for pinctrl&GPIO is tightly
146 > coupled.
147 </span>…
148 <span
149 class="q">> +++ b/drivers/pinctrl/nxp/pinctrl-s32cc.c
150 </span>…
151 <span
152 class="q">> +static int s32_gpio_request(struct gpio_chip *gc, unsigned int gpio)
153 > +{
154 </span>…
155 <span
156 class="q">> + spin_lock_irqsave(&ipctl->gpio_configs_lock, flags);
157 > + list_add(&gpio_pin->list, &ipctl->gpio_configs);
158 > + spin_unlock_irqrestore(&ipctl->gpio_configs_lock, flags);
159 </span>…
160
161 Under which circumstances would you become interested to apply a statement
162 like “guard(spinlock_irqsave)(&ipctl->gpio_configs_lock);”?
163 <a
164 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>
165
166 Regards,
167 Markus
168 </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
169 href="http://lore.kernel.org/lkml/202411012317.1pQLOspC-lkp@intel.com/"/><id>urn:uuid:ea88037d-f268-1598-cc32-9ead01144b06</id><thr:in-reply-to
170 ref="urn:uuid:59853637-7e32-04c8-211e-ba7cc208f49f"
171 href="http://lore.kernel.org/lkml/20241031040952.109057-21-mario.limonciello@amd.com/"/><content
172 type="xhtml"><div
173 xmlns="http://www.w3.org/1999/xhtml"><pre
174 style="white-space:pre-wrap">Hi Mario,
175
176 kernel test robot noticed the following build errors:
177
178 [auto build test ERROR on rafael-pm/linux-next]
179 [also build test ERROR on rafael-pm/bleeding-edge linus/master v6.12-rc5 next-20241101]
180 [If your patch is applied to the wrong git tree, kindly drop us a note.
181 And when submitting patch, we suggest to use '--base' as documented in
182 <a
183 href="https://git-scm.com/docs/git-format-patch#_base_tree_information">https://git-scm.com/docs/git-format-patch#_base_tree_information</a>]
184
185 url: <a
186 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>
187 base: <a
188 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
189 patch link: <a
190 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>
191 patch subject: [PATCH v3 20/22] ACPI: platform_profile: Register class device for platform profile handlers
192 config: x86_64-buildonly-randconfig-005-20241101 (<a
193 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>)
194 compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
195 reproduce (this is a W=1 build): (<a
196 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>)
197
198 If you fix the issue in a separate patch/commit (i.e. not just a new version of
199 the same patch/commit), kindly add following tags
200 | Reported-by: kernel test robot <lkp@intel.com>
201 | Closes: <a
202 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>
203
204 All errors (new ones prefixed by >>):
205
206 drivers/acpi/platform_profile.c: In function 'platform_profile_register':
207 <span
208 class="q">>> drivers/acpi/platform_profile.c:303:42: error: implicit declaration of function 'MKDEV' [-Werror=implicit-function-declaration]
209 </span> 303 | MKDEV(0, pprof->minor), NULL, "platform-profile-%s",
210 | ^~~~~
211 cc1: some warnings being treated as errors
212
213
214 vim +/MKDEV +303 drivers/acpi/platform_profile.c
215
216 261
217 262 int platform_profile_register(struct platform_profile_handler *pprof)
218 263 {
219 264 bool registered;
220 265 int err;
221 266
222 267 /* Sanity check the profile handler */
223 268 if (!pprof || bitmap_empty(pprof->choices, PLATFORM_PROFILE_LAST) ||
224 269 !pprof->profile_set || !pprof->profile_get) {
225 270 pr_err("platform_profile: handler is invalid\n");
226 271 return -EINVAL;
227 272 }
228 273 if (!test_bit(PLATFORM_PROFILE_BALANCED, pprof->choices)) {
229 274 pr_err("platform_profile: handler does not support balanced profile\n");
230 275 return -EINVAL;
231 276 }
232 277 if (!pprof->dev) {
233 278 pr_err("platform_profile: handler device is not set\n");
234 279 return -EINVAL;
235 280 }
236 281
237 282 guard(mutex)(&profile_lock);
238 283 /* We can only have one active profile */
239 284 if (cur_profile)
240 285 return -EEXIST;
241 286
242 287 registered = platform_profile_is_registered();
243 288 if (!registered) {
244 289 /* class for individual handlers */
245 290 err = class_register(&platform_profile_class);
246 291 if (err)
247 292 return err;
248 293 /* legacy sysfs files */
249 294 err = sysfs_create_group(acpi_kobj, &platform_profile_group);
250 295 if (err)
251 296 goto cleanup_class;
252 297
253 298 }
254 299
255 300 /* create class interface for individual handler */
256 301 pprof->minor = idr_alloc(&platform_profile_minor_idr, pprof, 0, 0, GFP_KERNEL);
257 302 pprof->class_dev = device_create(&platform_profile_class, pprof->dev,
258 > 303 MKDEV(0, pprof->minor), NULL, "platform-profile-%s",
259 304 pprof->name);
260 305 if (IS_ERR(pprof->class_dev)) {
261 306 err = PTR_ERR(pprof->class_dev);
262 307 goto cleanup_legacy;
263 308 }
264 309 err = sysfs_create_group(&pprof->class_dev->kobj, &platform_profile_group);
265 310 if (err)
266 311 goto cleanup_device;
267 312
268 313 list_add_tail(&pprof->list, &platform_profile_handler_list);
269 314 sysfs_notify(acpi_kobj, NULL, "platform_profile");
270 315
271 316 cur_profile = pprof;
272 317 return 0;
273 318
274 319 cleanup_device:
275 320 device_destroy(&platform_profile_class, MKDEV(0, pprof->minor));
276 321
277 322 cleanup_legacy:
278 323 if (!registered)
279 324 sysfs_remove_group(acpi_kobj, &platform_profile_group);
280 325 cleanup_class:
281 326 if (!registered)
282 327 class_unregister(&platform_profile_class);
283 328
284 329 return err;
285 330 }
286 331 EXPORT_SYMBOL_GPL(platform_profile_register);
287 332
288
289 --
290 0-DAY CI Kernel Test Service
291 <a
292 href="https://github.com/intel/lkp-tests/wiki">https://github.com/intel/lkp-tests/wiki</a>
293 </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
294 href="http://lore.kernel.org/lkml/cmudnqum4qaec6hjoxj7wxfkdui65nkij4q2fziihf7tsmg7ry@qa3lkf4g7npw/"/><id>urn:uuid:adb0ed56-ef08-3b2c-d96a-ca0774a183da</id><thr:in-reply-to
295 ref="urn:uuid:086dd36b-4979-5bdf-d1ff-ad4b260b842d"
296 href="http://lore.kernel.org/lkml/20241030133632.2116-1-rex.nie@jaguarmicro.com/"/><content
297 type="xhtml"><div
298 xmlns="http://www.w3.org/1999/xhtml"><pre
299 style="white-space:pre-wrap">On Wed, Oct 30, 2024 at 09:36:32PM GMT, Rex Nie wrote:
300 <span
301 class="q">> If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and
302 > txbuf_len are uninitialized. This commit stops to print uninitialized
303 > value and misleading/false data.
304 >
305 > Cc: stable@vger.kernel.org
306 > Fixes: a4422ff22142 (" usb: typec: qcom: Add Qualcomm PMIC Type-C driver")
307 > Signed-off-by: Rex Nie <rex.nie@jaguarmicro.com>
308 </span>
309 Reviewed-by: Bjorn Andersson <andersson@kernel.org>
310
311 Nice job. Next time, please don't use In-Reply-To between patch
312 versions.
313
314 Regards,
315 Bjorn
316
317 <span
318 class="q">> ---
319 > V2 -> V3:
320 > - add changelog, add Fixes tag, add Cc stable ml. Thanks heikki
321 > - Link to v2: <a
322 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>
323 > V1 -> V2:
324 > - keep printout when data didn't transmit, thanks Bjorn, bod, greg k-h
325 > - Links: <a
326 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>
327 > ---
328 > drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c | 8 ++++----
329 > 1 file changed, 4 insertions(+), 4 deletions(-)
330 >
331 > diff --git a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c
332 > index 5b7f52b74a40..726423684bae 100644
333 > --- a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c
334 > +++ b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c
335 > @@ -227,6 +227,10 @@ qcom_pmic_typec_pdphy_pd_transmit_payload(struct pmic_typec_pdphy *pmic_typec_pd
336 >
337 > spin_lock_irqsave(&pmic_typec_pdphy->lock, flags);
338 >
339 > + hdr_len = sizeof(msg->header);
340 > + txbuf_len = pd_header_cnt_le(msg->header) * 4;
341 > + txsize_len = hdr_len + txbuf_len - 1;
342 > +
343 > ret = regmap_read(pmic_typec_pdphy->regmap,
344 > pmic_typec_pdphy->base + USB_PDPHY_RX_ACKNOWLEDGE_REG,
345 > &val);
346 > @@ -244,10 +248,6 @@ qcom_pmic_typec_pdphy_pd_transmit_payload(struct pmic_typec_pdphy *pmic_typec_pd
347 > if (ret)
348 > goto done;
349 >
350 > - hdr_len = sizeof(msg->header);
351 > - txbuf_len = pd_header_cnt_le(msg->header) * 4;
352 > - txsize_len = hdr_len + txbuf_len - 1;
353 > -
354 > /* Write message header sizeof(u16) to USB_PDPHY_TX_BUFFER_HDR_REG */
355 > ret = regmap_bulk_write(pmic_typec_pdphy->regmap,
356 > pmic_typec_pdphy->base + USB_PDPHY_TX_BUFFER_HDR_REG,
357 > --
358 > 2.17.1
359 >
360 >
361 </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
362 href="http://lore.kernel.org/lkml/20241101154451.227defba@jic23-huawei/"/><id>urn:uuid:637122ea-f8ad-6028-0dd8-41c4bbc74581</id><thr:in-reply-to
363 ref="urn:uuid:ee4c190c-4254-fe26-18b7-7c815612ce4c"
364 href="http://lore.kernel.org/lkml/ef4fe230-b7fb-4f7e-9173-ae85d305e9ae@baylibre.com/"/><content
365 type="xhtml"><div
366 xmlns="http://www.w3.org/1999/xhtml"><pre
367 style="white-space:pre-wrap">On Thu, 31 Oct 2024 11:27:45 -0500
368 David Lechner <dlechner@baylibre.com> wrote:
369
370 <span
371 class="q">> On 10/31/24 10:27 AM, Julien Stephan wrote:
372 > > state parameter is currently an int, but it is actually a boolean.
373 > > iio_ev_state_store is actually using kstrtobool to check user input,
374 > > then gives the converted boolean value to write_event_config. The code
375 > > in adux1020_write_event_config re-uses state parameter to store an
376 > > integer value. To prepare for updating the write_event_config signature
377 > > to use a boolean for state, introduce a new local int variable.
378 > >
379 > > Signed-off-by: Julien Stephan <jstephan@baylibre.com>
380 > > ---
381 > > drivers/iio/light/adux1020.c | 8 ++++----
382 > > 1 file changed, 4 insertions(+), 4 deletions(-)
383 > >
384 > > diff --git a/drivers/iio/light/adux1020.c b/drivers/iio/light/adux1020.c
385 > > index 2e0170be077aef9aa194fab51afbb33aec02e513..db57d84da616b91add8c5d1aba08a73ce18c367e 100644
386 > > --- a/drivers/iio/light/adux1020.c
387 > > +++ b/drivers/iio/light/adux1020.c
388 > > @@ -505,7 +505,7 @@ static int adux1020_write_event_config(struct iio_dev *indio_dev,
389 > > enum iio_event_direction dir, int state)
390 > > {
391 > > struct adux1020_data *data = iio_priv(indio_dev);
392 > > - int ret, mask;
393 > > + int ret, mask, val;
394 > >
395 > > mutex_lock(&data->lock);
396 > >
397 > > @@ -526,12 +526,12 @@ static int adux1020_write_event_config(struct iio_dev *indio_dev,
398 > > mask = ADUX1020_PROX_OFF1_INT;
399 > >
400 > > if (state)
401 > > - state = 0;
402 > > + val = 0;
403 > > else
404 > > - state = mask;
405 > > + val = mask;
406 > >
407 > > ret = regmap_update_bits(data->regmap, ADUX1020_REG_INT_MASK,
408 > > - mask, state);
409 > > + mask, val);
410 > > if (ret < 0)
411 > > goto fail;
412 > >
413 > >
414 >
415 > Instead of introducing `val`, I would rewrite this as:
416 >
417 > if (state)
418 > ret = regmap_clear_bits(...);
419 > else
420 > ret = regmap_set_bits(...);
421 >
422 </span>Good idea. Rather than go around again and potentially stall the end of this series.
423 I made that change whilst applying. Shout if either of you doesn't
424 like the result. Diff doesn't do a perfect job on readability (it does
425 if I add a line break but then the code looks worse in the end!)
426
427 From 06a1ca816450d1b5524f6010581a83ab9935d51b Mon Sep 17 00:00:00 2001
428 From: Julien Stephan <jstephan@baylibre.com>
429 Date: Thu, 31 Oct 2024 16:27:01 +0100
430 Subject: [PATCH] iio: light: adux1020: write_event_config: use local variable
431 for interrupt value
432
433 state parameter is currently an int, but it is actually a boolean.
434 iio_ev_state_store is actually using kstrtobool to check user input,
435 then gives the converted boolean value to write_event_config. The code
436 in adux1020_write_event_config re-uses state parameter to store an
437 integer value. To prepare for updating the write_event_config signature
438 to use a boolean for state, introduce a new local int variable.
439
440 Signed-off-by: Julien Stephan <jstephan@baylibre.com>
441 Link: <a
442 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>
443 Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
444 ---
445 drivers/iio/light/adux1020.c | 9 ++++-----
446 1 file <a href="http://lore.kernel.org/lkml/20241101154451.227defba@jic23-huawei/#related">changed</a>, 4 insertions(+), 5 deletions(-)
447
448 <span
449 class="head">diff --git a/drivers/iio/light/adux1020.c b/drivers/iio/light/adux1020.c
450 index 2e0170be077a..06d5bc1d246c 100644
451 --- a/drivers/iio/light/adux1020.c
452 +++ b/drivers/iio/light/adux1020.c
453 </span><span
454 class="hunk">@@ -526,12 +526,11 @@ static int adux1020_write_event_config(struct iio_dev *indio_dev,
455 </span> mask = ADUX1020_PROX_OFF1_INT;
456
457 if (state)
458 <span
459 class="del">- state = 0;
460 </span><span
461 class="add">+ ret = regmap_clear_bits(data->regmap,
462 + ADUX1020_REG_INT_MASK, mask);
463 </span> else
464 <span
465 class="del">- state = mask;
466 -
467 - ret = regmap_update_bits(data->regmap, ADUX1020_REG_INT_MASK,
468 - mask, state);
469 </span><span
470 class="add">+ ret = regmap_set_bits(data->regmap,
471 + ADUX1020_REG_INT_MASK, mask);
472 </span> if (ret < 0)
473 goto fail;
474
475 --
476 2.46.2
477
478
479
480 <span
481 class="q">>
482 >
483 </span>
484 </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
485 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
486 ref="urn:uuid:854bcda4-a0b6-3948-c365-5fcf2e39136c"
487 href="http://lore.kernel.org/lkml/20241101-asahi-spi-v2-1-763a8a84d834@jannau.net/"/><content
488 type="xhtml"><div
489 xmlns="http://www.w3.org/1999/xhtml"><pre
490 style="white-space:pre-wrap">
491 On Fri, 01 Nov 2024 15:25:03 +0100, Janne Grunau wrote:
492 <span
493 class="q">> From: Hector Martin <marcan@marcan.st>
494 >
495 > The Apple SPI controller is present in SoCs such as the M1 (t8103) and
496 > M1 Pro/Max (t600x). This controller uses one IRQ and one clock, and
497 > doesn't need any special properties, so the binding is trivial.
498 >
499 > Signed-off-by: Hector Martin <marcan@marcan.st>
500 > Signed-off-by: Janne Grunau <j@jannau.net>
501 > ---
502 > .../devicetree/bindings/spi/apple,spi.yaml | 62 ++++++++++++++++++++++
503 > 1 file changed, 62 insertions(+)
504 >
505 </span>
506 My bot found errors running 'make dt_binding_check' on your patch:
507
508 yamllint warnings/errors:
509 ./Documentation/devicetree/bindings/spi/apple,spi.yaml:10:11: [error] string value is redundantly quoted with any quotes (quoted-strings)
510
511 dtschema/dtc warnings/errors:
512
513 doc reference errors (make refcheckdocs):
514
515 See <a
516 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>
517
518 The base for the series is generally the latest rc1. A different dependency
519 should be noted in *this* patch.
520
521 If you already ran 'make dt_binding_check' and didn't see the above
522 error(s), then make sure 'yamllint' is installed and dt-schema is up to
523 date:
524
525 pip3 install dtschema --upgrade
526
527 Please check and re-submit after running the above command yourself. Note
528 that DT_SCHEMA_FILES can be set to your schema file to speed up checking
529 your schema. However, it must be unset to test all examples with your schema.
530
531 </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
532 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
533 ref="urn:uuid:26810420-d0a9-f486-7f7b-7f82c31643cf"
534 href="http://lore.kernel.org/lkml/20241031204041.GA27585@lichtman.org/"/><content
535 type="xhtml"><div
536 xmlns="http://www.w3.org/1999/xhtml"><pre
537 style="white-space:pre-wrap">Hi,
538
539 On Thu, Oct 31, 2024 at 1:40 PM Nir Lichtman <nir@lichtman.org> wrote:
540 <span
541 class="q">>
542 > Fix kdb usage help to document some currently missing CLI commands options
543 >
544 > Signed-off-by: Nir Lichtman <nir@lichtman.org>
545 > ---
546 > kernel/debug/kdb/kdb_main.c | 8 ++++----
547 > 1 file changed, 4 insertions(+), 4 deletions(-)
548 </span>
549 Some of this is a bit similar to what I tried to do at :
550
551 <a
552 href="https://lore.kernel.org/r/20240617173426.2.I5621f286f5131c84ac71a212508ba1467ac443f2@changeid">https://lore.kernel.org/r/20240617173426.2.I5621f286f5131c84ac71a212508ba1467ac443f2@changeid</a>
553
554 ...but that series kinda fell on the floor because my end goal was to
555 try to get it so I could access IO memory and Daniel pointed out that
556 what I was doing was unsafe. The earlier patches in the series are
557 overall good cleanups, though. If you're interested feel free to
558 iterate on any of them.
559
560
561 <span
562 class="q">> diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
563 > index f5f7d7fb5936..0bdffb17b163 100644
564 > --- a/kernel/debug/kdb/kdb_main.c
565 > +++ b/kernel/debug/kdb/kdb_main.c
566 > @@ -2667,7 +2667,7 @@ EXPORT_SYMBOL_GPL(kdb_unregister);
567 > static kdbtab_t maintab[] = {
568 > { .name = "md",
569 > .func = kdb_md,
570 > - .usage = "<vaddr>",
571 > + .usage = "<vaddr> [lines] [radix]",
572 </span>
573 In my patch, I said:
574
575 .usage = "<vaddr> [<lines> [<radix>]]",
576
577 ...so I had the <> characters and nested the []. I think that the <>
578 is supposed to signify that you're not supposed to write the text
579 "lines" but that it's a variable.
580
581
582 <span
583 class="q">> .help = "Display Memory Contents, also mdWcN, e.g. md8c1",
584 > .minlen = 1,
585 > .flags = KDB_ENABLE_MEM_READ | KDB_REPEAT_NO_ARGS,
586 > @@ -2686,7 +2686,7 @@ static kdbtab_t maintab[] = {
587 > },
588 > { .name = "mds",
589 > .func = kdb_md,
590 > - .usage = "<vaddr>",
591 > + .usage = "<vaddr> [lines] [radix]",
592 </span>
593 From my prior research, "mds" doesn't support <radix>. However, some
594 of the other "md" commands that you didn't modify do support
595 lines/radix. Let me know if I got that wrong.
596
597
598 -Doug
599 </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
600 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
601 ref="urn:uuid:05782edb-e993-bc96-9aad-9dcb63b5ab56"
602 href="http://lore.kernel.org/lkml/20241031143250.GH10824@google.com/"/><content
603 type="xhtml"><div
604 xmlns="http://www.w3.org/1999/xhtml"><pre
605 style="white-space:pre-wrap">Hello Lee
606
607 Thanks for the review!
608
609 On 10/31/24 17:32, Lee Jones wrote:
610 <span
611 class="q">> On Tue, 15 Oct 2024, George Stark wrote:
612 >
613 >> When probing if default LED state is on then default brightness will be
614 >> applied instead of max brightness.
615 >>
616 >> Signed-off-by: George Stark <gnstark@salutedevices.com>
617 >> ---
618 >> drivers/leds/leds-pwm.c | 13 ++++++++++---
619 >> 1 file changed, 10 insertions(+), 3 deletions(-)
620 >>
621 >> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
622 >> index 7961dca0db2f..514fc8ca3e80 100644
623 >> --- a/drivers/leds/leds-pwm.c
624 >> +++ b/drivers/leds/leds-pwm.c
625 >> @@ -65,7 +65,8 @@ static int led_pwm_set(struct led_classdev *led_cdev,
626 >>
627 >> __attribute__((nonnull))
628 >> static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
629 >> - struct led_pwm *led, struct fwnode_handle *fwnode)
630 >> + struct led_pwm *led, struct fwnode_handle *fwnode,
631 >> + unsigned int default_brightness)
632 >> {
633 >> struct led_pwm_data *led_data = &priv->leds[priv->num_leds];
634 >> struct led_init_data init_data = { .fwnode = fwnode };
635 >> @@ -104,7 +105,7 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
636 >> /* set brightness */
637 >> switch (led->default_state) {
638 >> case LEDS_DEFSTATE_ON:
639 >> - led_data->cdev.brightness = led->max_brightness;
640 >> + led_data->cdev.brightness = default_brightness;
641 >> break;
642 >> case LEDS_DEFSTATE_KEEP:
643 >> {
644 >> @@ -141,6 +142,7 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
645 >> static int led_pwm_create_fwnode(struct device *dev, struct led_pwm_priv *priv)
646 >> {
647 >> struct led_pwm led;
648 >> + unsigned int default_brightness;
649 >> int ret;
650 >>
651 >> device_for_each_child_node_scoped(dev, fwnode) {
652 >> @@ -160,7 +162,12 @@ static int led_pwm_create_fwnode(struct device *dev, struct led_pwm_priv *priv)
653 >>
654 >> led.default_state = led_init_default_state_get(fwnode);
655 >>
656 >> - ret = led_pwm_add(dev, priv, &led, fwnode);
657 >> + ret = fwnode_property_read_u32(fwnode, "default-brightness",
658 >> + &default_brightness);
659 >> + if (ret < 0 || default_brightness > led.max_brightness)
660 >> + default_brightness = led.max_brightness;
661 >> +
662 >> + ret = led_pwm_add(dev, priv, &led, fwnode, default_brightness);
663 >
664 > This creates a lot more hopping around than is necessary.
665 >
666 > Since led_pwm_add() already has access to the fwnode, why not look up
667 > the property in there instead, thus massively simplifying things.
668 </span>
669 I looked up the new property here to be near to
670 led_init_default_state_get (both props are from the same group) and
671 led_pwm_add is big enough already. And you're absolutely right that the
672 patch can be optimized. Please take a look at the v2
673
674 <span
675 class="q">>
676 >
677 >> if (ret)
678 >> return ret;
679 >> }
680 >> --
681 >> 2.25.1
682 >>
683 >
684 </span>
685 --
686 Best regards
687 George
688 </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
689 href="http://lore.kernel.org/lkml/ZyT2piU27MF28XcN@p14s/"/><id>urn:uuid:245ae693-dda8-67e2-5447-c96feb798e8f</id><thr:in-reply-to
690 ref="urn:uuid:4ad4a1f2-5c65-5556-9d95-c1f0b643fadb"
691 href="http://lore.kernel.org/lkml/20241026212259.31950-1-yesanishhere@gmail.com/"/><content
692 type="xhtml"><div
693 xmlns="http://www.w3.org/1999/xhtml"><pre
694 style="white-space:pre-wrap">On Sat, Oct 26, 2024 at 02:22:59PM -0700, anish kumar wrote:
695 <span
696 class="q">> Added details as below:
697 > 1. added sysfs information
698 > 2. verbose details about remoteproc driver/framework
699 > responsibilites.
700 > 3. example for resource request
701 >
702 > Signed-off-by: anish kumar <yesanishhere@gmail.com>
703 > ---
704 > V5:
705 > based on comment from mathieu poirier, remove all files
706 > and combined that in the original file and as he adviced
707 > nothing with respect to old documentation was changed.
708 >
709 > V4:
710 > Fixed compilation errors and moved documentation to
711 > driver-api directory.
712 >
713 > V3:
714 > Seperated out the patches further to make the intention
715 > clear for each patch.
716 >
717 > V2:
718 > Reported-by: kernel test robot <lkp@intel.com>
719 > Closes: <a
720 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>
721 >
722 > Documentation/staging/remoteproc.rst | 483 +++++++++++++++++++++++++++
723 > 1 file changed, 483 insertions(+)
724 >
725 > diff --git a/Documentation/staging/remoteproc.rst b/Documentation/staging/remoteproc.rst
726 > index 348ee7e508ac..1c15f4d1b9eb 100644
727 > --- a/Documentation/staging/remoteproc.rst
728 > +++ b/Documentation/staging/remoteproc.rst
729 > @@ -29,6 +29,68 @@ remoteproc will add those devices. This makes it possible to reuse the
730 > existing virtio drivers with remote processor backends at a minimal development
731 > cost.
732 >
733 > +The primary purpose of the remoteproc framework is to download firmware
734 > +for remote processors and manage their lifecycle. The framework consists
735 > +of several key components:
736 > +
737 > +- **Character Driver**: Provides userspace access to control the remote
738 > + processor.
739 > +- **ELF Utility**: Offers functions for handling ELF files and managing
740 > + resources requested by the remote processor.
741 > +- **Remoteproc Core**: Manages firmware downloads and recovery actions
742 > + in case of a remote processor crash.
743 > +- **Coredump**: Provides facilities for coredumping and tracing from
744 > + the remote processor in the event of a crash.
745 > +- **Userspace Interaction**: Uses sysfs and debugfs to manage the
746 > + lifecycle and status of the remote processor.
747 > +- **Virtio Support**: Facilitates interaction with the virtio and
748 > + rpmsg bus.
749 > +
750 > +Remoteproc framework Responsibilities
751 > +=====================================
752 > +
753 > +The framework begins by gathering information about the firmware file
754 > +to be downloaded through the request_firmware function. It supports
755 > +the ELF format and parses the firmware image to identify the physical
756 > +addresses that need to be populated from the corresponding ELF sections.
757 > +The framework also requires knowledge of the logical or I/O-mapped
758 > +addresses in the application processor. Once this information is
759 </span>
760 "The framework also requires knowledge of the logical or I/O-mapped addresses in
761 the application processor". What is that about?
762
763 <span
764 class="q">> +obtained from the driver, the framework transfers the data to the
765 > +specified addresses and starts the remote, along with
766 </span>
767 "remote" what?
768
769 <span
770 class="q">> +any devices physically or logically connected to it.
771 </span>
772 I have never seen this happening.
773
774 <span
775 class="q">> +
776 > +Dependent devices, referred to as `subdevices` within the framework,
777 > +are also managed post-registration by their respective drivers.
778 > +Subdevices can register themselves using `rproc_(add/remove)_subdev`.
779 > +Non-remoteproc drivers can use subdevices as a way to logically connect
780 > +to remote and get lifecycle notifications of the remote.
781 > +
782 > +The framework oversees the lifecycle of the remote and
783 > +provides the `rproc_report_crash` function, which the driver invokes
784 > +upon receiving a crash notification from the remote. The
785 > +notification method can differ based on the design of the remote
786 > +processor and its communication with the application processor. For
787 > +instance, if the remote is a DSP equipped with a watchdog,
788 > +unresponsive behavior triggers the watchdog, generating an interrupt
789 > +that routes to the application processor, allowing it to call
790 > +`rproc_report_crash` in the driver's interrupt context.
791 > +
792 > +During crash handling, the framework performs the following actions:
793 > +
794 > +a. Sends a request to stop the remote and any connected or
795 > + dependent subdevices.
796 > +b. Generates a coredump, dumping all `resources` requested by the
797 > + remote alongside relevant debugging information. Resources are
798 > + explained below.
799 > +c. Reloads the firmware and restarts the remote.
800 > +
801 > +If the `RPROC_FEAT_ATTACH_ON_RECOVERY` flag is set, the detach and
802 > +attach callbacks of the driver are invoked without reloading the
803 > +firmware. This is useful when the remote requires no
804 > +assistance for recovery, or when the application processor can restart
805 > +independently. After recovery, the application processor can reattach
806 > +to the remote.
807 > +
808 </span>
809 The above provides a description of some of the things the remoteproc subsystem
810 does and as such, I would call it "overview" rather than responsabilities.
811
812 <span
813 class="q">> User API
814 > ========
815 >
816 > @@ -107,6 +169,239 @@ Typical usage
817 > API for implementors
818 > ====================
819 >
820 > +It describes the API that can be used by remote processor Drivers
821 > +that want to use the remote processor Driver Core Framework. This
822 > +framework provides all interfacing towards user space so that the
823 > +same code does not have to be reproduced each time. This also means
824 > +that a remote processor driver then only needs to provide the different
825 > +routines(operations) that control the remote processor.
826 > +
827 > +Each remote processor driver that wants to use the remote processor Driver Core
828 > +must #include <linux/remoteproc.h> (you would have to do this anyway when
829 > +writing a rproc device driver). This include file contains following
830 > +register routine::
831 > +
832 </span>
833 The above is very basic information about subsystems in general - please remove.
834
835 <span
836 class="q">> + int devm_rproc_add(struct device *dev, struct rproc *rproc)
837 > +
838 > +The devm_rproc_add routine registers a remote processor device.
839 > +The parameter of this routine is a pointer to a rproc device structure.
840 > +This routine returns zero on success and a negative errno code for failure.
841 </span>
842 Look at what is documented for other API functions and do the same here.
843
844 <span
845 class="q">> +
846 > +The rproc device structure looks like this::
847 > +
848 > + struct rproc {
849 > + struct list_head node;
850 > + struct iommu_domain *domain;
851 > + const char *name;
852 > + const char *firmware;
853 > + void *priv;
854 > + struct rproc_ops *ops;
855 > + struct device dev;
856 > + atomic_t power;
857 > + unsigned int state;
858 > + enum rproc_dump_mechanism dump_conf;
859 > + struct mutex lock;
860 > + struct dentry *dbg_dir;
861 > + struct list_head traces;
862 > + int num_traces;
863 > + struct list_head carveouts;
864 > + struct list_head mappings;
865 > + u64 bootaddr;
866 > + struct list_head rvdevs;
867 > + struct list_head subdevs;
868 > + struct idr notifyids;
869 > + int index;
870 > + struct work_struct crash_handler;
871 > + unsigned int crash_cnt;
872 > + bool recovery_disabled;
873 > + int max_notifyid;
874 > + struct resource_table *table_ptr;
875 > + struct resource_table *clean_table;
876 > + struct resource_table *cached_table;
877 > + size_t table_sz;
878 > + bool has_iommu;
879 > + bool auto_boot;
880 > + bool sysfs_read_only;
881 > + struct list_head dump_segments;
882 > + int nb_vdev;
883 > + u8 elf_class;
884 > + u16 elf_machine;
885 > + struct cdev cdev;
886 > + bool cdev_put_on_release;
887 > + DECLARE_BITMAP(features, RPROC_MAX_FEATURES);
888 > + };
889 </span>
890 All that is already part of remoteproc.h and doesn't need to be duplicated here
891 - please remove.
892
893 <span
894 class="q">> +
895 > +It contains following fields:
896 > +
897 > +* node: list node of this rproc object
898 > +* domain: iommu domain
899 > +* name: human readable name of the rproc
900 > +* firmware: name of firmware file to be loaded
901 > +* priv: private data which belongs to the platform-specific rproc module
902 > +* ops: platform-specific start/stop rproc handlers
903 > +* dev: virtual device for refcounting and common remoteproc behavior
904 > +* power: refcount of users who need this rproc powered up
905 > +* state: state of the device
906 > +* dump_conf: Currently selected coredump configuration
907 > +* lock: lock which protects concurrent manipulations of the rproc
908 > +* dbg_dir: debugfs directory of this rproc device
909 > +* traces: list of trace buffers
910 > +* num_traces: number of trace buffers
911 > +* carveouts: list of physically contiguous memory allocations
912 > +* mappings: list of iommu mappings we initiated, needed on shutdown
913 > +* bootaddr: address of first instruction to boot rproc with (optional)
914 > +* rvdevs: list of remote virtio devices
915 > +* subdevs: list of subdevices, to following the running state
916 > +* notifyids: idr for dynamically assigning rproc-wide unique notify ids
917 > +* index: index of this rproc device
918 > +* crash_handler: workqueue for handling a crash
919 > +* crash_cnt: crash counter
920 > +* recovery_disabled: flag that state if recovery was disabled
921 > +* max_notifyid: largest allocated notify id.
922 > +* table_ptr: pointer to the resource table in effect
923 > +* clean_table: copy of the resource table without modifications. Used
924 > +* when a remote processor is attached or detached from the core
925 > +* cached_table: copy of the resource table
926 > +* table_sz: size of @cached_table
927 > +* has_iommu: flag to indicate if remote processor is behind an MMU
928 > +* auto_boot: flag to indicate if remote processor should be auto-started
929 > +* sysfs_read_only: flag to make remoteproc sysfs files read only
930 > +* dump_segments: list of segments in the firmware
931 > +* nb_vdev: number of vdev currently handled by rproc
932 > +* elf_class: firmware ELF class
933 > +* elf_machine: firmware ELF machine
934 > +* cdev: character device of the rproc
935 > +* cdev_put_on_release: flag to indicate if remoteproc should be shutdown on @char_dev release
936 > +* features: indicate remoteproc features
937 > +
938 </span>
939 Remove
940
941 <span
942 class="q">> +The list of rproc operations is defined as::
943 > +
944 > + struct rproc_ops {
945 > + int (*prepare)(struct rproc *rproc);
946 > + int (*unprepare)(struct rproc *rproc);
947 > + int (*start)(struct rproc *rproc);
948 > + int (*stop)(struct rproc *rproc);
949 > + int (*attach)(struct rproc *rproc);
950 > + int (*detach)(struct rproc *rproc);
951 > + void (*kick)(struct rproc *rproc, int vqid);
952 > + void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len, bool *is_iomem);
953 > + int (*parse_fw)(struct rproc *rproc, const struct firmware *fw);
954 > + int (*handle_rsc)(struct rproc *rproc, u32 rsc_type, void *rsc,
955 > + int offset, int avail);
956 > + struct resource_table *(*find_loaded_rsc_table)(
957 > + struct rproc *rproc, const struct firmware *fw);
958 > + struct resource_table *(*get_loaded_rsc_table)(
959 > + struct rproc *rproc, size_t *size);
960 > + int (*load)(struct rproc *rproc, const struct firmware *fw);
961 > + int (*sanity_check)(struct rproc *rproc, const struct firmware *fw);
962 > + u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
963 > + unsigned long (*panic)(struct rproc *rproc);
964 > + void (*coredump)(struct rproc *rproc);
965 > + };
966 > +
967 </span>
968 If you really want to document all the callbacks, it should be done in the
969 "Implementation callbacks" section following the style that is already in place.
970
971 <span
972 class="q">> +Most of the operations are optional. Currently in the implementation
973 > +there are no mandatory operations, however from the practical standpoint
974 > +minimum ops are:
975 > +
976 > +* start: this is a pointer to the routine that starts the remote processor
977 > + device.
978 > + The routine needs a pointer to the remote processor device structure as a
979 > + parameter. It returns zero on success or a negative errno code for failure.
980 > +
981 > +* stop: with this routine the remote processor device is being stopped.
982 > +
983 > + The routine needs a pointer to the remote processor device structure as a
984 > + parameter. It returns zero on success or a negative errno code for failure.
985 > +
986 > +* da_to_va: this is the routine that needs to translate device address to
987 > + application processor virtual address that it can copy code to.
988 > +
989 > + The routine needs a pointer to the remote processor device structure as a
990 > + parameter. It returns zero on success or a negative errno code for failure.
991 > +
992 > + The routine provides the device address it finds in the ELF firmware and asks
993 > + the driver to convert that to virtual address.
994 > +
995 > +All other callbacks are optional in case of ELF provided firmware.
996 > +
997 > +* load: this is to load the firmware on to the remote device.
998 > +
999 > + The routine needs firmware file that it needs to load on to the remote processor.
1000 > + If the driver overrides this callback then default ELF loader will not get used.
1001 > + Otherwise default framework provided loader gets used.
1002 > +
1003 > + load = rproc_elf_load_segments;
1004 > + parse_fw = rproc_elf_load_rsc_table;
1005 > + find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table;
1006 > + sanity_check = rproc_elf_sanity_check;
1007 > + get_boot_addr = rproc_elf_get_boot_addr;
1008 > +
1009 > +* parse_fw: this routing parses the provided firmware. In case of ELF format,
1010 > + framework provided rproc_elf_load_rsc_table function can be used.
1011 > +
1012 > +* sanity_check: Check the format of the firmware.
1013 > +
1014 > +* coredump: If the driver prefers to manage coredumps independently, it can
1015 > + implement its own coredump handling. However, the framework offers a default
1016 > + implementation for the ELF format by assigning this callback to
1017 > + rproc_coredump, unless the driver has overridden it.
1018 > +
1019 > +* get_boot_addr: In case the bootaddr defined in ELF firmware is different, driver
1020 > + can use this callback to set a different boot address for remote processor to
1021 > + starts its reset vector from.
1022 > +
1023 > +* find_loaded_rsc_table: this routine gets the loaded resource table from the firmware.
1024 > +
1025 > + resource table should have a section named (.resource_table) for the framework
1026 > + to understand and interpret its content. Resource table is a way for remote
1027 > + processor to ask for resources such as memory for dumping and logging. Look
1028 > + at core documentation to know how to create the ELF section for the same.
1029 > +
1030 > +* get_loaded_rsc_table: Driver can customize passing the resource table by overriding
1031 > + this callback. Framework doesn't provide any default implementation for the same.
1032 > +
1033 > +The driver must provide the following information to the core:
1034 > +
1035 > +a. Translate device addresses (physical addresses) found in the ELF
1036 > + firmware to virtual addresses in Linux using the `da_to_va`
1037 > + callback. This allows the framework to copy ELF firmware from the
1038 > + filesystem to the addresses expected by the remote since
1039 > + the framework cannot directly access those physical addresses.
1040 > +b. Prepare/unprepare the remote prior to firmware loading,
1041 > + which may involve allocating carveout and reserved memory regions.
1042 > +c. Implement methods for starting and stopping the remote,
1043 > + whether by setting registers or sending explicit interrupts,
1044 > + depending on the hardware design.
1045 > +d. Provide attach and detach callbacks to start the remote
1046 > + without loading the firmware. This is beneficial when the remote
1047 > + processor is already loaded and running.
1048 > +e. Implement a load callback for firmware loading, typically using
1049 > + the ELF loader provided by the framework; currently, only ELF
1050 > + format is supported.
1051 > +f. Invoke the framework's crash handler API upon detecting a remote
1052 > + crash.
1053 > +
1054 > +Drivers must fill the `rproc_ops` structure and call `rproc_alloc`
1055 > +to register themselves with the framework.
1056 > +
1057 > +.. code-block:: c
1058 > +
1059 > + struct rproc_ops {
1060 > + int (*prepare)(struct rproc *rproc);
1061 > + int (*unprepare)(struct rproc *rproc);
1062 > + int (*start)(struct rproc *rproc);
1063 > + int (*stop)(struct rproc *rproc);
1064 > + int (*attach)(struct rproc *rproc);
1065 > + int (*detach)(struct rproc *rproc);
1066 > + void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len,
1067 > + bool *is_iomem);
1068 > + int (*parse_fw)(struct rproc *rproc, const struct firmware *fw);
1069 > + int (*handle_rsc)(struct rproc *rproc, u32 rsc_type,
1070 > + void *rsc, int offset, int avail);
1071 > + int (*load)(struct rproc *rproc, const struct firmware *fw);
1072 > + //snip
1073 > + };
1074 </span>
1075 This is already added above, why is it repeated here?
1076
1077 <span
1078 class="q">> +
1079 > ::
1080 >
1081 > struct rproc *rproc_alloc(struct device *dev, const char *name,
1082 > @@ -190,6 +485,35 @@ platform specific rproc implementation. This should not be called from a
1083 > non-remoteproc driver. This function can be called from atomic/interrupt
1084 > context.
1085 >
1086 > +To add a subdev corresponding driver can call
1087 > +
1088 > +::
1089 > +
1090 > + void rproc_add_subdev(struct rproc *rproc, struct rproc_subdev *subdev)
1091 > +
1092 > +To remove a subdev, driver can call.
1093 > +
1094 > +::
1095 > +
1096 > + void rproc_remove_subdev(struct rproc *rproc, struct rproc_subdev *subdev)
1097 > +
1098 </span>
1099 The above doesn't add value to the documentation and users needing to use these
1100 functions will need to look at the code anyway - please remove.
1101
1102 <span
1103 class="q">> +To work with ELF coredump below function can be called
1104 > +
1105 > +::
1106 > +
1107 > + void rproc_coredump_cleanup(struct rproc *rproc)
1108 > + void rproc_coredump(struct rproc *rproc)
1109 > + void rproc_coredump_using_sections(struct rproc *rproc)
1110 > + int rproc_coredump_add_segment(struct rproc *rproc, dma_addr_t da, size_t size)
1111 > + int rproc_coredump_add_custom_segment(struct rproc *rproc,
1112 > + dma_addr_t da, size_t size,
1113 > + void (*dumpfn)(struct rproc *rproc,
1114 > + struct rproc_dump_segment *segment,
1115 > + void *dest, size_t offset,
1116 > + size_t size))
1117 > +
1118 > +Remember that coredump functions provided by the framework only works with ELF format.
1119 > +
1120 </span>
1121 Remove
1122
1123 <span
1124 class="q">> Implementation callbacks
1125 > ========================
1126 >
1127 > @@ -228,6 +552,123 @@ the exact virtqueue index to look in is optional: it is easy (and not
1128 > too expensive) to go through the existing virtqueues and look for new buffers
1129 > in the used rings.
1130 >
1131 > +Userspace control methods
1132 > +==========================
1133 > +
1134 > +At times, userspace may need to check the state of the remote processor to
1135 > +prevent other processes from using it. For instance, if the remote processor
1136 > +is a DSP used for playback, there may be situations where the DSP is
1137 > +undergoing recovery and cannot be used. In such cases, attempts to access the
1138 > +DSP for playback should be blocked. The rproc framework provides sysfs APIs
1139 > +to inform userspace of the processor's current status which should be utilised
1140 > +to achieve the same.
1141 > +
1142 </span>
1143 Remove
1144
1145 <span
1146 class="q">> +Additionally, there are scenarios where userspace applications need to explicitly
1147 > +control the rproc. In these cases, rproc also offers the file descriptors.
1148 > +
1149 > +Below set of commands can be used to start and stop the rproc
1150 > +where 'X' refers to instance of associated remoteproc. There can be systems
1151 > +where there are more than one rprocs such as multiple DSP's
1152 > +connected to application processors running Linux.
1153 > +
1154 > +.. code-block:: c
1155 > +
1156 > + echo start > /sys/class/remoteproc/remoteprocX/state
1157 > + echo stop > /sys/class/remoteproc/remoteprocX/state
1158 > +
1159 > +To know the state of rproc:
1160 > +
1161 > +.. code-block:: c
1162 > +
1163 > + cat /sys/class/remoteproc/remoteprocX/state
1164 > +
1165 > +
1166 > +To dynamically replace firmware, execute the following commands:
1167 > +
1168 > +.. code-block:: c
1169 > +
1170 > + echo stop > /sys/class/remoteproc/remoteprocX/state
1171 > + echo -n <firmware_name> >
1172 > + /sys/class/remoteproc/remoteprocX/firmware
1173 > + echo start > /sys/class/remoteproc/remoteprocX/state
1174 > +
1175 > +To simulate a remote crash, execute:
1176 > +
1177 > +.. code-block:: c
1178 > +
1179 > + echo 1 > /sys/kernel/debug/remoteproc/remoteprocX/crash
1180 > +
1181 > +To get the trace logs, execute
1182 > +
1183 > +.. code-block:: c
1184 > +
1185 > + cat /sys/kernel/debug/remoteproc/remoteprocX/crashX
1186 > +
1187 > +where X will be 0 or 1 if there are 2 resources. Also, this
1188 > +file will only exist if resources are defined in ELF firmware
1189 > +file.
1190 > +
1191 > +The coredump feature can be disabled with the following command:
1192 > +
1193 > +.. code-block:: c
1194 > +
1195 > + echo disabled > /sys/kernel/debug/remoteproc/remoteprocX/coredump
1196 > +
1197 > +Userspace can also control start/stop of rproc by using a
1198 </span>
1199 s/rproc/remote processor
1200
1201 <span
1202 class="q">> +remoteproc Character Device, it can open the open a file descriptor
1203 </span>
1204 s/Character Device/character device
1205
1206 <span
1207 class="q">> +and write `start` to initiate it, and `stop` to terminate it.
1208 > +Below set of api's can be used to start and stop the rproc
1209 > +where 'X' refers to instance of associated remoteproc. There can be systems
1210 > +where there are more than one rprocs such as multiple DSP's
1211 > +connected to application processors running Linux.
1212 </span>
1213 Duplication from above - remove.
1214
1215 <span
1216 class="q">> +
1217 > +.. code-block:: c
1218 > +
1219 > + echo start > /sys/class/remoteproc/remoteprocX/state
1220 > + echo stop > /sys/class/remoteproc/remoteprocX/state
1221 > +
1222 > +To know the state of rproc:
1223 > +
1224 > +.. code-block:: c
1225 > +
1226 > + cat /sys/class/remoteproc/remoteprocX/state
1227 > +
1228 </span>
1229 Remove
1230
1231 <span
1232 class="q">> +
1233 > +To dynamically replace firmware, execute the following commands:
1234 > +
1235 > +.. code-block:: c
1236 > +
1237 > + echo stop > /sys/class/remoteproc/remoteprocX/state
1238 > + echo -n <firmware_name> >
1239 > + /sys/class/remoteproc/remoteprocX/firmware
1240 > + echo start > /sys/class/remoteproc/remoteprocX/state
1241 > +
1242 > +To simulate a remote crash, execute:
1243 > +
1244 > +.. code-block:: c
1245 > +
1246 > + echo 1 > /sys/kernel/debug/remoteproc/remoteprocX/crash
1247 > +
1248 > +To get the trace logs, execute
1249 > +
1250 > +.. code-block:: c
1251 > +
1252 > + cat /sys/kernel/debug/remoteproc/remoteprocX/crashX
1253 > +
1254 > +where X will be 0 or 1 if there are 2 resources. Also, this
1255 > +file will only exist if resources are defined in ELF firmware
1256 > +file.
1257 > +
1258 > +The coredump feature can be disabled with the following command:
1259 > +
1260 > +.. code-block:: c
1261 > +
1262 > + echo disabled > /sys/kernel/debug/remoteproc/remoteprocX/coredump
1263 > +
1264 > +Userspace can also control start/stop of rproc by using a
1265 > +remoteproc Character Device, it can open the open a file descriptor
1266 > +and write `start` to initiate it, and `stop` to terminate it.
1267 </span>
1268 Duplication from above - remove.
1269
1270 <span
1271 class="q">> +
1272 > Binary Firmware Structure
1273 > =========================
1274 >
1275 > @@ -340,6 +781,48 @@ We also expect that platform-specific resource entries will show up
1276 > at some point. When that happens, we could easily add a new RSC_PLATFORM
1277 > type, and hand those resources to the platform-specific rproc driver to handle.
1278 >
1279 > +if the remote requests both `RSC_TRACE` and `RSC_CARVEOUT` for memory
1280 > +allocation, the ELF firmware can be structured as follows:
1281 > +
1282 > +.. code-block:: c
1283 > +
1284 > + #define MAX_SHARED_RESOURCE 2
1285 > + #define LOG_BUF_SIZE 1000
1286 > + #define CARVEOUT_DUMP_PA 0x12345678
1287 > + #define CARVEOUT_DUMP_SIZE 2000
1288 > +
1289 > + struct shared_resource_table {
1290 > + u32 ver;
1291 > + u32 num;
1292 > + u32 reserved[2];
1293 > + u32 offset[MAX_SHARED_RESOURCE];
1294 > + struct fw_rsc_trace log_trace;
1295 > + struct fw_rsc_carveout dump_carveout;
1296 > + };
1297 > +
1298 > + volatile struct shared_resource_table table = {
1299 > + .ver = 1,
1300 > + .num = 2,
1301 > + .reserved = {0, 0},
1302 > + .offset = {
1303 > + offsetof(struct resource_table, log_trace),
1304 > + offsetof(struct resource_table, dump_carveout),
1305 > + },
1306 > + .log_trace = {
1307 > + RSC_TRACE,
1308 > + (u32)log_buf, LOG_BUF_SIZE, 0, "log_trace",
1309 > + },
1310 > + .dump_carveout = {
1311 > + RSC_CARVEOUT,
1312 > + (u32)FW_RSC_ADDR_ANY, CARVEOUT_PA, 0, "carveout_dump",
1313 > + },
1314 > + };
1315 > +
1316 > +The framework creates a sysfs file when it encounters the `RSC_TRACE`
1317 > +type to expose log information to userspace. Other resource types are
1318 > +handled accordingly. In the example above, `CARVEOUT_DUMP_SIZE` bytes
1319 > +of DMA memory will be allocated starting from `CARVEOUT_DUMP_PA`.
1320 > +
1321 </span>
1322 Remove
1323
1324 <span
1325 class="q">> Virtio and remoteproc
1326 > =====================
1327 >
1328 </span>
1329 Before spinning off another revision I encourage you to spend time looking at
1330 existing documentation. Reading various mailing lists with a special
1331 focus on how people split their patches based on topics would also be
1332 beneficial.
1333
1334 Lastly, typing my email address correctly would be highly appreciated.
1335
1336 Thanks,
1337 Mathieu
1338
1339 <span
1340 class="q">> --
1341 > 2.39.3 (Apple Git-146)
1342 >
1343 >
1344 </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
1345 href="http://lore.kernel.org/lkml/20241101153857.GAZyT2EdLXKs7ZmDFx@fat_crate.local/"/><id>urn:uuid:87315698-5cce-93e0-116f-32d3d054c439</id><thr:in-reply-to
1346 ref="urn:uuid:7848ad27-59f2-66a2-0604-1759555ec538"
1347 href="http://lore.kernel.org/lkml/173039500211.1507616.16831780895322741303.b4-ty@google.com/"/><content
1348 type="xhtml"><div
1349 xmlns="http://www.w3.org/1999/xhtml"><pre
1350 style="white-space:pre-wrap">On Thu, Oct 31, 2024 at 12:51:33PM -0700, Sean Christopherson wrote:
1351 <span
1352 class="q">> [1/4] x86/cpufeatures: Clarify semantics of X86_FEATURE_IBPB
1353 > <a
1354 href="https://github.com/kvm-x86/linux/commit/43801a0dbb38">https://github.com/kvm-x86/linux/commit/43801a0dbb38</a>
1355 > [2/4] x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET
1356 > <a
1357 href="https://github.com/kvm-x86/linux/commit/99d252e3ae3e">https://github.com/kvm-x86/linux/commit/99d252e3ae3e</a>
1358 </span>
1359 ff898623af2e ("x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET")
1360
1361 --
1362 Regards/Gruss,
1363 Boris.
1364
1365 <a
1366 href="https://people.kernel.org/tglx/notes-about-netiquette">https://people.kernel.org/tglx/notes-about-netiquette</a>
1367 </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
1368 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
1369 ref="urn:uuid:fbcfeeed-2e04-e19b-b7e8-7edb91c7374e"
1370 href="http://lore.kernel.org/lkml/ZyO9Mfq+znZdJJrJ@lsv051416.swis.nl-cdc01.nxp.com/"/><content
1371 type="xhtml"><div
1372 xmlns="http://www.w3.org/1999/xhtml"><pre
1373 style="white-space:pre-wrap">On 31/10/2024 18:24, Jan Petrous wrote:
1374 <span
1375 class="q">> On Thu, Oct 31, 2024 at 06:16:46PM +0100, Jan Petrous wrote:
1376 >> On Thu, Oct 31, 2024 at 04:44:45PM +0100, Krzysztof Kozlowski wrote:
1377 >>> On 31/10/2024 15:43, Jan Petrous wrote:
1378 >>>> On Tue, Oct 29, 2024 at 08:13:40AM +0100, Krzysztof Kozlowski wrote:
1379 >>>>> On Mon, Oct 28, 2024 at 09:24:56PM +0100, Jan Petrous (OSS) wrote:
1380 >>>>>> + plat->init = s32_gmac_init;
1381 >>>>>> + plat->exit = s32_gmac_exit;
1382 >>>>>> + plat->fix_mac_speed = s32_fix_mac_speed;
1383 >>>>>> +
1384 >>>>>> + plat->bsp_priv = gmac;
1385 >>>>>> +
1386 >>>>>> + return stmmac_pltfr_probe(pdev, plat, &res);
1387 >>>>>> +}
1388 >>>>>> +
1389 >>>>>> +static const struct of_device_id s32_dwmac_match[] = {
1390 >>>>>> + { .compatible = "nxp,s32g2-dwmac" },
1391 >>>>>> + { .compatible = "nxp,s32g3-dwmac" },
1392 >>>>>> + { .compatible = "nxp,s32r-dwmac" },
1393 >>>>>
1394 >>>>> Why do you need three same entries?
1395 >>>>>
1396 >>>>
1397 >>>> We have three different SoCs and in v3 review you told me
1398 >>>> to return all back:
1399 >>>> <a
1400 href="https://patchwork.kernel.org/comment/26067257/">https://patchwork.kernel.org/comment/26067257/</a>
1401 >>>
1402 >>> It was about binding, not driver.
1403 >>>
1404 >>> I also asked there: use proper fallback and compatibility. Both comments
1405 >>> of course affect your driver, but why choosing only first part?
1406 >>>
1407 >>
1408 >> Does it mean I should remove first two (G2/G3) members from match array
1409 >> and use "nxp,s32r-dwmac" as fallback for G2/G3? And similarly change
1410 >> the bindings to:
1411 >>
1412 >> compatible:
1413 >> oneOf:
1414 >> - const: nxp,s32r-dwmac
1415 >> - items:
1416 >> - enum:
1417 >> - nxp,s32g2-dwmac
1418 >> - nxp,s32g3-dwmac
1419 >> - const: nxp,s32r-dwmac
1420 >>
1421 >> And add here, into the driver, those members back when some device
1422 >> specific feature will be needed? Am I understand your hints right?
1423 >>
1424 >
1425 > Sorry, it's not correct. This way I'm not able to detect S32R which is
1426 > the only one with higher speed.
1427 >
1428 > Then I could use the G2 as fallback I think, Ie.:
1429 >
1430 > compatible:
1431 > oneOf:
1432 > - const: nxp,s32g2-dwmac
1433 > - items:
1434 > - enum:
1435 > - nxp,s32g3-dwmac
1436 > - nxp,s32r-dwmac
1437 > - const: nxp,s32g2-dwmac
1438 </span>
1439 I don't understand. In both cases you can 'detect r', if by this you
1440 meant match and bind. I don't care which one is the fallback, but if one
1441 does not work it points to different issues with your code.
1442
1443 Best regards,
1444 Krzysztof
1445
1446 </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
1447 href="http://lore.kernel.org/lkml/bsxaq6zilwaavcwi25dbz2wgrgqrqxfme6a5lfdg6jqfl4kspj@xahygne3tqg4/"/><id>urn:uuid:c1a51ad4-30df-8454-421f-cfa43c8a4dd0</id><thr:in-reply-to
1448 ref="urn:uuid:60c26f9c-0686-e5b4-b0fd-213e2ead902f"
1449 href="http://lore.kernel.org/lkml/20241101-remove_wait-v3-3-7accf27f7202@quicinc.com/"/><content
1450 type="xhtml"><div
1451 xmlns="http://www.w3.org/1999/xhtml"><pre
1452 style="white-space:pre-wrap">On Fri, Nov 01, 2024 at 05:04:14PM GMT, Krishna chaitanya chundru wrote:
1453 <span
1454 class="q">> As part of the PCIe link up event, update ICC and OPP values
1455 > as at this point only driver can know the link speed and
1456 > width of the PCIe link.
1457 >
1458 </span>
1459 It would be nice if you were to write your commit messages in the style
1460 documented at <a
1461 href="https://docs.kernel.org/process/submitting-patches.html#describe-your-changes">https://docs.kernel.org/process/submitting-patches.html#describe-your-changes</a>
1462 I.e. start with a clear problem description, then move into describing
1463 the solution.
1464
1465 Your commit message is stating that this is the only place the driver
1466 can know the link speed, but wouldn't that imply that there's some
1467 actual problem with the code currently?
1468
1469
1470 I'm guessing (because that's what your commit message is forcing me to
1471 do) that in the case that we don't detect anything connected at probe
1472 time and then we get a "hotplug" interrupt, we will have completely
1473 incorrect bus votes?
1474
1475 If so, it would seem that this patch should have a:
1476 Fixes: 4581403f6792 ("PCI: qcom: Enumerate endpoints based on Link up event in 'global_irq' interrupt")
1477
1478 And of course, a proper description of that problem.
1479
1480 Regards,
1481 Bjorn
1482
1483 <span
1484 class="q">> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
1485 > ---
1486 > drivers/pci/controller/dwc/pcie-qcom.c | 2 ++
1487 > 1 file changed, 2 insertions(+)
1488 >
1489 > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
1490 > index 474b7525442d..5826c0e7ca0b 100644
1491 > --- a/drivers/pci/controller/dwc/pcie-qcom.c
1492 > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
1493 > @@ -1558,6 +1558,8 @@ static irqreturn_t qcom_pcie_global_irq_thread(int irq, void *data)
1494 > pci_lock_rescan_remove();
1495 > pci_rescan_bus(pp->bridge->bus);
1496 > pci_unlock_rescan_remove();
1497 > +
1498 > + qcom_pcie_icc_opp_update(pcie);
1499 > } else {
1500 > dev_WARN_ONCE(dev, 1, "Received unknown event. INT_STATUS: 0x%08x\n",
1501 > status);
1502 >
1503 > --
1504 > 2.34.1
1505 >
1506 >
1507 </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
1508 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
1509 ref="urn:uuid:7100b345-9ca2-8988-dd45-907cd539adb4"
1510 href="http://lore.kernel.org/lkml/5e0b5238-d781-458a-9285-df54a16232af@marcan.st/"/><content
1511 type="xhtml"><div
1512 xmlns="http://www.w3.org/1999/xhtml"><pre
1513 style="white-space:pre-wrap">On 01/11/2024 13:33, Hector Martin wrote:
1514 <span
1515 class="q">> - First the ancient s5l series
1516 > - Then all the t/sXXXX chips up to t8103 (M1) (numeric order, ignoring
1517 > prefix letter)
1518 > - Then the rest of the "baseline" Ax,Mx chips that continue after M1,
1519 > which are all numbered t8xxx (numeric order)
1520 > - Finally the t6xxx series (Mx Pro/Mx Max), which forks the timeline and
1521 > numbering after t8103/M1 (M1 Pro = t6000).
1522 >
1523 > Unless there's significant objection I'd like to keep this pattern, it
1524 > makes sense from the POV of people working on these chips.
1525 </span>
1526 No, no, it's fine, I am just forgetting where do we have exceptions. :)
1527
1528 Best regards,
1529 Krzysztof
1530
1531 </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
1532 href="http://lore.kernel.org/lkml/ZyT2CB6zodtbWEI9@linux.dev/"/><id>urn:uuid:8e0284c3-77ef-8e37-aab3-cf5125f83ce8</id><thr:in-reply-to
1533 ref="urn:uuid:eaa12fb4-732a-6676-4b84-22d6654838f7"
1534 href="http://lore.kernel.org/lkml/ZyTpwwm0s89iU9Pk@google.com/"/><content
1535 type="xhtml"><div
1536 xmlns="http://www.w3.org/1999/xhtml"><pre
1537 style="white-space:pre-wrap">Hey,
1538
1539 On Fri, Nov 01, 2024 at 07:48:00AM -0700, Sean Christopherson wrote:
1540 <span
1541 class="q">> On Fri, Nov 01, 2024, Mark Brown wrote:
1542 > > On Wed, Oct 09, 2024 at 08:49:42AM -0700, Sean Christopherson wrote:
1543 > > > Return a uint64_t from vcpu_get_reg() instead of having the caller provide
1544 > > > a pointer to storage, as none of the vcpu_get_reg() usage in KVM selftests
1545 > > > accesses a register larger than 64 bits, and vcpu_set_reg() only accepts a
1546 > > > 64-bit value. If a use case comes along that needs to get a register that
1547 > > > is larger than 64 bits, then a utility can be added to assert success and
1548 > > > take a void pointer, but until then, forcing an out param yields ugly code
1549 > > > and prevents feeding the output of vcpu_get_reg() into vcpu_set_reg().
1550 > >
1551 > > This commit, which is in today's -next as 5c6c7b71a45c9c, breaks the
1552 > > build on arm64:
1553 > >
1554 > > aarch64/psci_test.c: In function ‘host_test_system_off2’:
1555 > > aarch64/psci_test.c:247:9: error: too many arguments to function ‘vcpu_get_reg’
1556 > > 247 | vcpu_get_reg(target, KVM_REG_ARM_PSCI_VERSION, &psci_version);
1557 > > | ^~~~~~~~~~~~
1558 > > In file included from aarch64/psci_test.c:18:
1559 > > include/kvm_util.h:705:24: note: declared here
1560 > > 705 | static inline uint64_t vcpu_get_reg(struct kvm_vcpu *vcpu, uint64_t id)
1561 > > | ^~~~~~~~~~~~
1562 > > At top level:
1563 > > cc1: note: unrecognized command-line option ‘-Wno-gnu-variable-sized-type-not-at
1564 > > -end’ may have been intended to silence earlier diagnostics
1565 > >
1566 > > since the updates done to that file did not take account of 72be5aa6be4
1567 > > ("KVM: selftests: Add test for PSCI SYSTEM_OFF2") which has been merged
1568 > > in the kvm-arm64 tree.
1569 >
1570 > Bugger. In hindsight, it's obvious that of course arch selftests would add usage
1571 > of vcpu_get_reg().
1572 >
1573 > Unless someone has a better idea, I'll drop the series from kvm-x86, post a new
1574 > version that applies on linux-next, and then re-apply the series just before the
1575 > v6.13 merge window (rinse and repeat as needed if more vcpu_get_reg() users come
1576 > along).
1577 </span>
1578 Can you instead just push out a topic branch and let the affected
1579 maintainers deal with it? This is the usual way we handle conflicts
1580 between trees...
1581
1582 <span
1583 class="q">> That would be a good oppurtunity to do the $(ARCH) directory switch[*] too, e.g.
1584 > have a "selftests_late" or whatever topic branch.
1585 </span>
1586 The right time to do KVM-wide changes (even selftests) is *early* in the
1587 development cycle, not last minute. It gives us plenty of time to iron out
1588 the wrinkles.
1589
1590 <span
1591 class="q">> Sorry for the pain Mark, you've been playing janitor for us too much lately.
1592 </span>
1593 +1, appreciate your help on this.
1594
1595 --
1596 Thanks,
1597 Oliver
1598 </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
1599 href="http://lore.kernel.org/lkml/20241101153656.43e27240@jic23-huawei/"/><id>urn:uuid:c655d237-138d-92db-3a39-fc0924f674ea</id><thr:in-reply-to
1600 ref="urn:uuid:da253a47-1fe4-d6ec-5897-5cfcd6c7fd9f"
1601 href="http://lore.kernel.org/lkml/20241031-iio-fix-write-event-config-signature-v2-5-2bcacbb517a2@baylibre.com/"/><content
1602 type="xhtml"><div
1603 xmlns="http://www.w3.org/1999/xhtml"><pre
1604 style="white-space:pre-wrap">On Thu, 31 Oct 2024 16:27:00 +0100
1605 Julien Stephan <jstephan@baylibre.com> wrote:
1606
1607 <span
1608 class="q">> iio_ev_state_store is actually using kstrtobool to check user
1609 > input, then gives the converted boolean value to the write_event_config
1610 > callback.
1611 >
1612 > Remove useless code in write_event_config callback.
1613 >
1614 > Signed-off-by: Julien Stephan <jstephan@baylibre.com>
1615 </span>Applied and pushed out as testing. Still time for other reviews if anyone
1616 cares to take a look.
1617
1618 Thanks,
1619
1620 Jonathan
1621
1622 <span
1623 class="q">> ---
1624 > drivers/iio/proximity/sx9500.c | 4 ++--
1625 > 1 file changed, 2 insertions(+), 2 deletions(-)
1626 >
1627 > diff --git a/drivers/iio/proximity/sx9500.c b/drivers/iio/proximity/sx9500.c
1628 > index 3f4eace05cfc6a4679fe82854dc059aa4a710d6d..e3da709424d5b2bd4e746df7adc4a4969e62f2a6 100644
1629 > --- a/drivers/iio/proximity/sx9500.c
1630 > +++ b/drivers/iio/proximity/sx9500.c
1631 > @@ -551,7 +551,7 @@ static int sx9500_write_event_config(struct iio_dev *indio_dev,
1632 >
1633 > mutex_lock(&data->mutex);
1634 >
1635 > - if (state == 1) {
1636 > + if (state) {
1637 > ret = sx9500_inc_chan_users(data, chan->channel);
1638 > if (ret < 0)
1639 > goto out_unlock;
1640 > @@ -571,7 +571,7 @@ static int sx9500_write_event_config(struct iio_dev *indio_dev,
1641 > goto out_unlock;
1642 >
1643 > out_undo_chan:
1644 > - if (state == 1)
1645 > + if (state)
1646 > sx9500_dec_chan_users(data, chan->channel);
1647 > else
1648 > sx9500_inc_chan_users(data, chan->channel);
1649 >
1650 </span>
1651 </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
1652 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
1653 ref="urn:uuid:4b4b1161-c4f3-5b7a-f4fd-b9a8d5e4d864"
1654 href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-0-3011aa04622f@baylibre.com/"/><content
1655 type="xhtml"><div
1656 xmlns="http://www.w3.org/1999/xhtml"><pre
1657 style="white-space:pre-wrap">When a device supports IO daisy-chain wakeups, it uses a dedicated
1658 wake IRQ. Devices with IO daisy-chain wakeups enabled should not set
1659 wakeup constraints since these can happen even from deep power states,
1660 so should not prevent the DM from picking deep power states.
1661
1662 Wake IRQs are set with dev_pm_set_wake_irq() or
1663 dev_pm_set_dedicated_wake_irq(). The latter is used by the serial
1664 driver used on K3 platforms (drivers/tty/serial/8250/8250_omap.c)
1665 when the interrupts-extended property is used to describe the
1666 dedicated wakeup interrupt.
1667
1668 Detect these wake IRQs in the suspend path, and if set, skip sending
1669 constraint.
1670
1671 Tested-by: Dhruva Gole <d-gole@ti.com>
1672 Signed-off-by: Kevin Hilman <khilman@baylibre.com>
1673 ---
1674 drivers/pmdomain/ti/ti_sci_pm_domains.c | 9 +++++++++
1675 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(+)
1676
1677 <span
1678 class="head">diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
1679 index ff529fa2d6135cc2fb32ae8a3ca26ac055f66cf5..8c46ca428f60b3d42a5a43488538f16b7ffaa3ac 100644
1680 --- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
1681 +++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
1682 </span><span
1683 class="hunk">@@ -82,6 +82,15 @@ static inline void ti_sci_pd_set_wkup_constraint(struct device *dev)
1684 </span> int ret;
1685
1686 if (device_may_wakeup(dev)) {
1687 <span
1688 class="add">+ /*
1689 + * If device can wakeup using IO daisy chain wakeups,
1690 + * we do not want to set a constraint.
1691 + */
1692 + if (dev->power.wakeirq) {
1693 + dev_dbg(dev, "%s: has wake IRQ, not setting constraints\n", __func__);
1694 + return;
1695 + }
1696 +
1697 </span> ret = ti_sci->ops.pm_ops.set_device_constraint(ti_sci, pd->idx,
1698 TISCI_MSG_CONSTRAINT_SET);
1699 if (!ret)
1700
1701 --
1702 2.46.2
1703
1704 </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
1705 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
1706 ref="urn:uuid:4b4b1161-c4f3-5b7a-f4fd-b9a8d5e4d864"
1707 href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-0-3011aa04622f@baylibre.com/"/><content
1708 type="xhtml"><div
1709 xmlns="http://www.w3.org/1999/xhtml"><pre
1710 style="white-space:pre-wrap">During system-wide suspend, check all devices connected to PM domain
1711 to see if they are wakeup-enabled. If so, set a TI SCI device
1712 constraint.
1713
1714 Note: DM firmware clears all constraints on resume.
1715
1716 Co-developed-by: Vibhore Vardhan <vibhore@ti.com>
1717 Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
1718 Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
1719 Tested-by: Dhruva Gole <d-gole@ti.com>
1720 Signed-off-by: Kevin Hilman <khilman@baylibre.com>
1721 ---
1722 drivers/pmdomain/ti/ti_sci_pm_domains.c | 17 +++++++++++++++++
1723 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(+)
1724
1725 <span
1726 class="head">diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
1727 index c976a382d64c807daea72fa1ea9d6c11c8773762..ff529fa2d6135cc2fb32ae8a3ca26ac055f66cf5 100644
1728 --- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
1729 +++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
1730 </span><span
1731 class="hunk">@@ -74,6 +74,21 @@ static void ti_sci_pd_set_lat_constraint(struct device *dev, s32 val)
1732 </span> pd->idx, val);
1733 }
1734
1735 <span
1736 class="add">+static inline void ti_sci_pd_set_wkup_constraint(struct device *dev)
1737 +{
1738 + struct generic_pm_domain *genpd = pd_to_genpd(dev->pm_domain);
1739 + struct ti_sci_pm_domain *pd = genpd_to_ti_sci_pd(genpd);
1740 + const struct ti_sci_handle *ti_sci = pd->parent->ti_sci;
1741 + int ret;
1742 +
1743 + if (device_may_wakeup(dev)) {
1744 + ret = ti_sci->ops.pm_ops.set_device_constraint(ti_sci, pd->idx,
1745 + TISCI_MSG_CONSTRAINT_SET);
1746 + if (!ret)
1747 + dev_dbg(dev, "ti_sci_pd: ID:%d set device constraint.\n", pd->idx);
1748 + }
1749 +}
1750 +
1751 </span> /*
1752 * ti_sci_pd_power_off(): genpd power down hook
1753 * @domain: pointer to the powerdomain to power off
1754 <span
1755 class="hunk">@@ -116,6 +131,8 @@ static int ti_sci_pd_suspend(struct device *dev)
1756 </span> if (ti_sci_pd_is_valid_constraint(val))
1757 ti_sci_pd_set_lat_constraint(dev, val);
1758
1759 <span
1760 class="add">+ ti_sci_pd_set_wkup_constraint(dev);
1761 +
1762 </span> return 0;
1763 }
1764 #else
1765
1766 --
1767 2.46.2
1768
1769 </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
1770 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
1771 ref="urn:uuid:4b4b1161-c4f3-5b7a-f4fd-b9a8d5e4d864"
1772 href="http://lore.kernel.org/lkml/20241101-lpm-v6-10-constraints-pmdomain-v5-0-3011aa04622f@baylibre.com/"/><content
1773 type="xhtml"><div
1774 xmlns="http://www.w3.org/1999/xhtml"><pre
1775 style="white-space:pre-wrap">For each device in a TI SCI PM domain, check whether the device has
1776 any resume latency constraints set via per-device PM QoS. If
1777 constraints are set, send them to DM via the new SCI constraints API.
1778
1779 Checking for constraints happen for each device before system-wide
1780 suspend (via ->suspend() hook.)
1781
1782 An important detail here is that the PM domain driver inserts itself
1783 into the path of both the ->suspend() and ->resume() hook path
1784 of *all* devices in the PM domain. This allows generic PM domain code
1785 to handle the constraint management and communication with TI SCI.
1786
1787 Further, this allows device drivers to use existing PM QoS APIs to
1788 add/update constraints.
1789
1790 DM firmware clears constraints during its resume, so Linux has
1791 to check/update/send constraints each time system suspends.
1792
1793 Co-developed-by: Vibhore Vardhan <vibhore@ti.com>
1794 Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
1795 Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>
1796 Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
1797 Tested-by: Dhruva Gole <d-gole@ti.com>
1798 Signed-off-by: Kevin Hilman <khilman@baylibre.com>
1799 ---
1800 drivers/pmdomain/ti/ti_sci_pm_domains.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
1801 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(+)
1802
1803 <span
1804 class="head">diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
1805 index 1510d5ddae3decd5b70f835338ed4e0b2a3c9373..c976a382d64c807daea72fa1ea9d6c11c8773762 100644
1806 --- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
1807 +++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
1808 </span><span
1809 class="hunk">@@ -13,6 +13,8 @@
1810 </span> #include <linux/platform_device.h>
1811 #include <linux/pm_domain.h>
1812 #include <linux/slab.h>
1813 <span
1814 class="add">+#include <linux/pm_qos.h>
1815 +#include <linux/pm_runtime.h>
1816 </span> #include <linux/soc/ti/ti_sci_protocol.h>
1817 #include <dt-bindings/soc/ti,sci_pm_domain.h>
1818
1819 <span
1820 class="hunk">@@ -51,6 +53,27 @@ struct ti_sci_pm_domain {
1821 </span>
1822 #define genpd_to_ti_sci_pd(gpd) container_of(gpd, struct ti_sci_pm_domain, pd)
1823
1824 <span
1825 class="add">+static inline bool ti_sci_pd_is_valid_constraint(s32 val)
1826 +{
1827 + return val != PM_QOS_RESUME_LATENCY_NO_CONSTRAINT;
1828 +}
1829 +
1830 +static void ti_sci_pd_set_lat_constraint(struct device *dev, s32 val)
1831 +{
1832 + struct generic_pm_domain *genpd = pd_to_genpd(dev->pm_domain);
1833 + struct ti_sci_pm_domain *pd = genpd_to_ti_sci_pd(genpd);
1834 + const struct ti_sci_handle *ti_sci = pd->parent->ti_sci;
1835 + int ret;
1836 +
1837 + ret = ti_sci->ops.pm_ops.set_latency_constraint(ti_sci, val, TISCI_MSG_CONSTRAINT_SET);
1838 + if (ret)
1839 + dev_err(dev, "ti_sci_pd: set latency constraint failed: ret=%d\n",
1840 + ret);
1841 + else
1842 + dev_dbg(dev, "ti_sci_pd: ID:%d set latency constraint %d\n",
1843 + pd->idx, val);
1844 +}
1845 +
1846 </span> /*
1847 * ti_sci_pd_power_off(): genpd power down hook
1848 * @domain: pointer to the powerdomain to power off
1849 <span
1850 class="hunk">@@ -79,6 +102,26 @@ static int ti_sci_pd_power_on(struct generic_pm_domain *domain)
1851 </span> return ti_sci->ops.dev_ops.get_device(ti_sci, pd->idx);
1852 }
1853
1854 <span
1855 class="add">+#ifdef CONFIG_PM_SLEEP
1856 +static int ti_sci_pd_suspend(struct device *dev)
1857 +{
1858 + int ret;
1859 + s32 val;
1860 +
1861 + ret = pm_generic_suspend(dev);
1862 + if (ret)
1863 + return ret;
1864 +
1865 + val = dev_pm_qos_read_value(dev, DEV_PM_QOS_RESUME_LATENCY);
1866 + if (ti_sci_pd_is_valid_constraint(val))
1867 + ti_sci_pd_set_lat_constraint(dev, val);
1868 +
1869 + return 0;
1870 +}
1871 +#else
1872 +#define ti_sci_pd_suspend NULL
1873 +#endif
1874 +
1875 </span> /*
1876 * ti_sci_pd_xlate(): translation service for TI SCI genpds
1877 * @genpdspec: DT identification data for the genpd
1878 <span
1879 class="hunk">@@ -188,6 +231,13 @@ static int ti_sci_pm_domain_probe(struct platform_device *pdev)
1880 </span> pd->pd.power_on = ti_sci_pd_power_on;
1881 pd->idx = args.args[0];
1882 pd->parent = pd_provider;
1883 <span
1884 class="add">+ /*
1885 + * If SCI constraint functions are present, then firmware
1886 + * supports the constraints API.
1887 + */
1888 + if (pd_provider->ti_sci->ops.pm_ops.set_device_constraint &&
1889 + pd_provider->ti_sci->ops.pm_ops.set_latency_constraint)
1890 + pd->pd.domain.ops.suspend = ti_sci_pd_suspend;
1891 </span>
1892 pm_genpd_init(&pd->pd, NULL, true);
1893
1894
1895 --
1896 2.46.2
1897
1898 </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
1899 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
1900 type="xhtml"><div
1901 xmlns="http://www.w3.org/1999/xhtml"><pre
1902 style="white-space:pre-wrap">The latest (10.x) version of the firmware for the PM co-processor (aka
1903 device manager, or DM) adds support for a "managed" mode, where the DM
1904 firmware will select the specific low power state which is entered
1905 when Linux requests a system-wide suspend.
1906
1907 In this mode, the DM will always attempt the deepest low-power state
1908 available for the SoC.
1909
1910 However, Linux (or OSes running on other cores) may want to constrain
1911 the DM for certain use cases. For example, the deepest state may have
1912 a wakeup/resume latency that is too long for certain use cases. Or,
1913 some wakeup-capable devices may potentially be powered off in deep
1914 low-power states, but if one of those devices is enabled as a wakeup
1915 source, it should not be powered off.
1916
1917 These kinds of constraints are are already known in Linux by the use
1918 of existing APIs such as per-device PM QoS and device wakeup APIs, but
1919 now we need to communicate these constraints to the DM.
1920
1921 For TI SoCs with TI SCI support, all DM-managed devices will be
1922 connected to a TI SCI PM domain. So the goal of this series is to use
1923 the PM domain driver for TI SCI devices to collect constraints, and
1924 communicate them to the DM via the new TI SCI APIs.
1925
1926 This is all managed by TI SCI PM domain code. No new APIs are needed
1927 by Linux drivers. Any device that is managed by TI SCI will be
1928 checked for QoS constraints or wakeup capability and the constraints
1929 will be collected and sent to the DM.
1930
1931 This series depends on the support for the new TI SCI APIs (v10) and
1932 was also tested with this series to update 8250_omap serial support
1933 for AM62x[2].
1934
1935 [1] <a
1936 href="https://lore.kernel.org/all/20240801195422.2296347-1-msp@baylibre.com">https://lore.kernel.org/all/20240801195422.2296347-1-msp@baylibre.com</a>
1937 [2] <a
1938 href="https://lore.kernel.org/all/20240807141227.1093006-1-msp@baylibre.com/">https://lore.kernel.org/all/20240807141227.1093006-1-msp@baylibre.com/</a>
1939
1940 Signed-off-by: Kevin Hilman <khilman@baylibre.com>
1941 ---
1942 Changes in v5:
1943 - fix build-error when CONFIG_PM_SLEEP not defined
1944 - Link to v4: <a
1945 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>
1946
1947 Changes in v4:
1948 - fixed missing return in wakeirq error path
1949 - updated trailers with reviewed & tested tags
1950 - Link to v3: <a
1951 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>
1952
1953 Changes in v3:
1954 - change latency set functions to static void
1955 - Link to v2: <a
1956 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>
1957
1958 Changes in v2:
1959 - To simplify this version a bit, drop the pmdomain ->power_off()
1960 changes. Constraints only sent during ->suspend() path. The pmdomain
1961 path was an optimization that may be added back later.
1962 - With the above simplification, drop the extra state variables that
1963 had been added to keep track of constraint status.
1964 - Link to v1: <a
1965 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>
1966
1967 ---
1968 Kevin Hilman (3):
1969 pmdomain: ti_sci: add per-device latency constraint management
1970 pmdomain: ti_sci: add wakeup constraint management
1971 pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups
1972
1973 drivers/pmdomain/ti/ti_sci_pm_domains.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1974 1 file changed, 76 insertions(+)
1975 ---
1976 base-commit: ad7eb1b6b92ee0c959a0a6ae846ddadd7a79ea64
1977 change-id: 20240802-lpm-v6-10-constraints-pmdomain-f33df5aef449
1978 prerequisite-change-id: 20241006-tisci-syssuspendresume-e6550720a50f:v13
1979 prerequisite-patch-id: 945b15416a011cb40007c5d95561786c1776bb98
1980 prerequisite-patch-id: 69a741b9c81d7990937483fc481aafa70e67669d
1981 prerequisite-patch-id: 15e97947da8cb7055745151990c756d81fded804
1982 prerequisite-patch-id: a0efbf22e69d23dba8bb96db4032ca644935709b
1983 prerequisite-patch-id: 2999da190c1ba63aabecc55fae501d442e4e0d7b
1984
1985 Best regards,
1986 --
1987 Kevin Hilman <khilman@baylibre.com>
1988
1989 </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
1990 href="http://lore.kernel.org/lkml/20241101153608.23a9c6f1@jic23-huawei/"/><id>urn:uuid:74f09b13-8157-93a6-328b-90d18d2afd4b</id><thr:in-reply-to
1991 ref="urn:uuid:447a8057-432d-a0a9-a141-fc5025a1a9a0"
1992 href="http://lore.kernel.org/lkml/20241031-iio-fix-write-event-config-signature-v2-4-2bcacbb517a2@baylibre.com/"/><content
1993 type="xhtml"><div
1994 xmlns="http://www.w3.org/1999/xhtml"><pre
1995 style="white-space:pre-wrap">On Thu, 31 Oct 2024 16:26:59 +0100
1996 Julien Stephan <jstephan@baylibre.com> wrote:
1997
1998 <span
1999 class="q">> iio_ev_state_store is actually using kstrtobool to check user
2000 > input, then gives the converted boolean value to the write_event_config
2001 > callback.
2002 >
2003 > Remove useless code in write_event_config callback.
2004 >
2005 > Signed-off-by: Julien Stephan <jstephan@baylibre.com>
2006 </span>Applied and pushed out as testing. If anyone has time to review
2007 I can still add tags (or pull the patches if there is something I missed!)
2008
2009 Thanks,
2010
2011 Jonathan
2012
2013 <span
2014 class="q">> ---
2015 > drivers/iio/proximity/irsd200.c | 2 +-
2016 > 1 file changed, 1 insertion(+), 1 deletion(-)
2017 >
2018 > diff --git a/drivers/iio/proximity/irsd200.c b/drivers/iio/proximity/irsd200.c
2019 > index 6e96b764fed8b577d71c3146210679b0b61d4c38..fb0691da99ee621e19013a64d122f097e793efd9 100644
2020 > --- a/drivers/iio/proximity/irsd200.c
2021 > +++ b/drivers/iio/proximity/irsd200.c
2022 > @@ -662,7 +662,7 @@ static int irsd200_write_event_config(struct iio_dev *indio_dev,
2023 > return ret;
2024 >
2025 > return regmap_field_write(
2026 > - data->regfields[IRS_REGF_INTR_COUNT_THR_OR], !!state);
2027 > + data->regfields[IRS_REGF_INTR_COUNT_THR_OR], state);
2028 > default:
2029 > return -EINVAL;
2030 > }
2031 >
2032 </span>
2033 </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
2034 href="http://lore.kernel.org/lkml/7hwmhnnf0f.fsf@baylibre.com/"/><id>urn:uuid:c61ea5b1-48e8-c3d0-eac6-5fc9154ec730</id><thr:in-reply-to
2035 ref="urn:uuid:cc2c9c2c-260b-f814-2876-26305aeca478"
2036 href="http://lore.kernel.org/lkml/20241101144445.56ejnuoxshqwns37@boots/"/><content
2037 type="xhtml"><div
2038 xmlns="http://www.w3.org/1999/xhtml"><pre
2039 style="white-space:pre-wrap">Nishanth Menon <nm@ti.com> writes:
2040
2041 <span
2042 class="q">> On 11:11-20241031, Ulf Hansson wrote:
2043 >> On Wed, 30 Oct 2024 at 20:43, Kevin Hilman <khilman@baylibre.com> wrote:
2044 >> >
2045 >> > Ulf Hansson <ulf.hansson@linaro.org> writes:
2046 >> >
2047 >> > > On Wed, 30 Oct 2024 at 14:01, Nishanth Menon <nm@ti.com> wrote:
2048 >> > >>
2049 >> > >> Hi Kevin Hilman,
2050 >> > >>
2051 >> > >> On Fri, 06 Sep 2024 09:14:48 -0700, Kevin Hilman wrote:
2052 >> > >> > The latest (10.x) version of the firmware for the PM co-processor (aka
2053 >> > >> > device manager, or DM) adds support for a "managed" mode, where the DM
2054 >> > >> > firmware will select the specific low power state which is entered
2055 >> > >> > when Linux requests a system-wide suspend.
2056 >> > >> >
2057 >> > >> > In this mode, the DM will always attempt the deepest low-power state
2058 >> > >> > available for the SoC.
2059 >> > >> >
2060 >> > >> > [...]
2061 >> > >>
2062 >> > >> I have applied the following to branch ti-drivers-soc-next on [1].
2063 >> > >> Thank you!
2064 >> > >>
2065 >> > >> Ulf, based on your ack[2], I have assumed that you want me to pick
2066 >> > >> this series up. Let me know if that is not the case and I can drop the
2067 >> > >> series.
2068 >> > >
2069 >> > > Well, that was a while ago. The reason was because there was a
2070 >> > > dependency to another series [2], when this was posted.
2071 >> > >
2072 >> > > If that's not the case anymore, I think it's better to funnel this via
2073 >> > > my pmdomain tree. Please let me know how to proceed.
2074 >> >
2075 >> > The build-time dependency on [2] still exists, and since that was just
2076 >> > queued up by Nishanth, I think this series should (still) go along with
2077 >> > it to keep things simple.
2078 >> >
2079 >> > Kevin
2080 >>
2081 >> Right, that makes perfect sense to me too. If we discover conflicts,
2082 >> let's deal with them then.
2083 >
2084 >
2085 > oops.. I missed this response. OK, I will let things be.
2086 >
2087 </span>
2088 Oops, 0day bot found a build error in linux-next when CONFIG_PM_SLEEP is
2089 not defined[1]. Need to respin to fix this.
2090
2091 v5 coming right up....
2092
2093 Kevin
2094
2095 [1] <a
2096 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>
2097 </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
2098 href="http://lore.kernel.org/lkml/20241101153509.11ae74b9@jic23-huawei/"/><id>urn:uuid:ba78cdbf-6561-c6ef-f0fd-10f343557c18</id><thr:in-reply-to
2099 ref="urn:uuid:c9c12e36-c944-62c0-f373-d6c3c51e217e"
2100 href="http://lore.kernel.org/lkml/20241031-iio-fix-write-event-config-signature-v2-3-2bcacbb517a2@baylibre.com/"/><content
2101 type="xhtml"><div
2102 xmlns="http://www.w3.org/1999/xhtml"><pre
2103 style="white-space:pre-wrap">On Thu, 31 Oct 2024 16:26:58 +0100
2104 Julien Stephan <jstephan@baylibre.com> wrote:
2105
2106 <span
2107 class="q">> iio_ev_state_store is actually using kstrtobool to check user
2108 > input, then gives the converted boolean value to the write_event_config
2109 > callback.
2110 >
2111 > Remove useless code in write_event_config callback.
2112 >
2113 > Signed-off-by: Julien Stephan <jstephan@baylibre.com>
2114 </span>Applied.
2115 <span
2116 class="q">> ---
2117 > drivers/iio/light/tsl2772.c | 4 ++--
2118 > 1 file changed, 2 insertions(+), 2 deletions(-)
2119 >
2120 > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
2121 > index cab468a82b616a23394977da1d8822d29d8941d3..26082f239c4c3aeabfe73ed100d6e885f5266329 100644
2122 > --- a/drivers/iio/light/tsl2772.c
2123 > +++ b/drivers/iio/light/tsl2772.c
2124 > @@ -1086,9 +1086,9 @@ static int tsl2772_write_interrupt_config(struct iio_dev *indio_dev,
2125 > struct tsl2772_chip *chip = iio_priv(indio_dev);
2126 >
2127 > if (chan->type == IIO_INTENSITY)
2128 > - chip->settings.als_interrupt_en = val ? true : false;
2129 > + chip->settings.als_interrupt_en = val;
2130 > else
2131 > - chip->settings.prox_interrupt_en = val ? true : false;
2132 > + chip->settings.prox_interrupt_en = val;
2133 >
2134 > return tsl2772_invoke_change(indio_dev);
2135 > }
2136 >
2137 </span>
2138 </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
2139 href="http://lore.kernel.org/lkml/20241101153434.11d85f8b@jic23-huawei/"/><id>urn:uuid:c8a9619e-10eb-3a16-1f56-21cbfa9dc5e5</id><thr:in-reply-to
2140 ref="urn:uuid:86f1d001-2b45-a3aa-44a1-1b4b99f208db"
2141 href="http://lore.kernel.org/lkml/20241031-iio-fix-write-event-config-signature-v2-2-2bcacbb517a2@baylibre.com/"/><content
2142 type="xhtml"><div
2143 xmlns="http://www.w3.org/1999/xhtml"><pre
2144 style="white-space:pre-wrap">On Thu, 31 Oct 2024 16:26:57 +0100
2145 Julien Stephan <jstephan@baylibre.com> wrote:
2146
2147 <span
2148 class="q">> iio_ev_state_store is actually using kstrtobool to check user
2149 > input, then gives the converted boolean value to the write_event_config
2150 > callback.
2151 >
2152 > Remove useless code in write_event_config callback.
2153 >
2154 > Signed-off-by: Julien Stephan <jstephan@baylibre.com>
2155 </span>Applied to the togreg branch of iio.git and pushed out as testing.
2156 Note if anyone else has time to review, I can still add tags for now.
2157
2158 I'll probably push it out as an (in theory) not rebasing tree early
2159 next week to give a bit of time in next before a pull request.
2160
2161 Jonathan
2162
2163 <span
2164 class="q">> ---
2165 > drivers/iio/proximity/hx9023s.c | 2 +-
2166 > 1 file changed, 1 insertion(+), 1 deletion(-)
2167 >
2168 > diff --git a/drivers/iio/proximity/hx9023s.c b/drivers/iio/proximity/hx9023s.c
2169 > index d8fb34060d3db88a3ba5ecdc209b14be8e42e8b9..38441b1ee040c7c26047b0cb2ac443ecb8396df3 100644
2170 > --- a/drivers/iio/proximity/hx9023s.c
2171 > +++ b/drivers/iio/proximity/hx9023s.c
2172 > @@ -879,7 +879,7 @@ static int hx9023s_write_event_config(struct iio_dev *indio_dev,
2173 > struct hx9023s_data *data = iio_priv(indio_dev);
2174 >
2175 > if (test_bit(chan->channel, &data->chan_in_use)) {
2176 > - hx9023s_ch_en(data, chan->channel, !!state);
2177 > + hx9023s_ch_en(data, chan->channel, state);
2178 > __assign_bit(chan->channel, &data->chan_event,
2179 > data->ch_data[chan->channel].enable);
2180 > }
2181 >
2182 </span>
2183