08:14 <lag> Dear hive-mind, does -EPROBE_DEFER loop forever? (I would usually look these kinds of things up, but I am exceptionally over-loaded ATM - TIA)

08:38 <geertu> lag: See driver_deferred_probe_timeout in drivers/base/dd.c (defaults to 10 if CONFIG_MODULES, else 0)

08:38 <lag> geertu: Thank you buddy! :thumb

08:39 <lag> geertu: Odd that someone on the list is insisting that it loops forever - I knew this shouldn't be the case

08:39 <lag> geertu: :)

08:41 <lag> geertu: MFD is great for certain use-cases, but for the purists, having the ability to trivially convert a class driver into a platform driver is not a good thing - each to their own! :)

10:11 <javierm> lag, geertu: I don't think driver_deferred_probe_timeout is used by all subsytems, but only the ones that opt-in

10:11 <bjdooks> lag: it'll keep going every time a new device or such happens

10:12 <javierm> git grep driver_deferred_probe_check_state | grep -v "drivers/base"

10:12 <javierm> drivers/iommu/of_iommu.c: return driver_deferred_probe_check_state(dev);

10:12 <javierm> drivers/net/mdio/fwnode_mdio.c: rc = driver_deferred_probe_check_state(&phy->mdio.dev);

10:12 <javierm> include/linux/device/driver.h:int driver_deferred_probe_check_state(struct device *dev);

10:12 <javierm> geertu, lag ^

10:13 <javierm> bjdooks: indeed. If the subsystems doesn't check for driver_deferred_probe_check_state(), I believe that will always be -EPROBE_DEFER

10:24 <lag> bjdooks: That would suit too - so long as it's finite

10:26 <lag> javierm: geertu: bjdooks: So what's the default? What happens without special handling?

10:32 <bjdooks> it'll just keep trying deffered devices each time there's a device added, iirc

10:33 <lag> bjdooks: I guess I need to figure out why that is not the case for this particular contributor

10:34 <javierm> lag: do you have a reference to the thread ?

10:35 <lag> javierm: Sure, let me dig it up

10:35 <javierm> lag: but what bjdooks said, maybe you can refer the contributor to https://blog.dowhile0.org/2022/06/21/how-to-troubleshoot-deferred-probe-issues-in-linux/

10:36 <lag> javierm: I shouldn't do that until I am certain that it's not our (LED subsystem's) fault!

10:37 <javierm> lag: right, but regardless I wrote that to help people troubleshoot probe deferral issues :)

10:42 <geertu> javierm: I must be unlucky when I have a deferred probe issue, as usually I don't get sufficiently far in the boot to look at /sys/kernel/debug/devices_deferred :-(

10:42 <lag> https://lore.kernel.org/all/20230102162227.523d2a73@md1za8fc.ad001.siemens.net/

10:44 <javierm> geertu: yeah, I also had issues with driver_deferred_probe_timeout (because was timing out with some IOMMU driver on QC platforms)

10:44 <javierm> geertu: and proposed to disable it by default but got nacked: https://lore.kernel.org/lkml/20221116115348.517599-1-javierm@redhat.com/

10:49 <javierm> lag: the contributor is correct, there's no way for user-space to know when the probe deferral finished, it's basically the halting problem

10:49 <javierm> lag: because it may be that the dependency could be registered only when a linux module is loaded for example

10:50 <javierm> lag: if you want led-gpios to time out, then you should call driver_deferred_probe_check_state()

10:50 <lag> javierm: So what is looping and filling up the buffer if the deferred devices are only re-executed when new devices are added?

10:50 <javierm> lag: that seems to be some user-space daemon that they have?

10:51 <lag> javierm: ... what would happen if we used driver_deferred_probe_check_state() and the pinctrl driver was insmoded at a later date?

10:51 <lag> javierm: Egh!

10:52 <javierm> lag: because they talk about poll(2) ? or did I misunderstood what they meant?

10:53 <javierm> lag: if the pinctrl is insmoded / probe callback called after the 10 secs default timeout, it will fail with -ENODEV

10:53 <lag> javierm: As I say, I need to carve out some time to spend on it I think :|

10:54 <javierm> lag: yeah, basically you need to decide what would be the behaviour for your subsystem. Either never timeout (the default) or timeout after driver_deferred_probe_timeout (the subsystems I shared in my grep output)

10:54 <javierm> lag: IMO the correct thing here would be to not have a timeout but have a syscall or something for user-space to specify that no more modules are expected to be loaded

10:55 <javierm> so that the probe deferral mechanism is disabled from there

10:57 <javierm> lag: but I don't think the patch they are proposing is the correct thing to do, it is yet again a workaround

10:59 <javierm> lag: if the problem is logs, then they should not log on the probe deferral path

11:01 <javierm> lag: ah, they already have these kind of stuff in their driver: https://elixir.bootlin.com/linux/latest/source/drivers/leds/simple/simatic-ipc-leds-gpio.c#L82

11:02 <javierm> ugh, and request_module("gpio-f7188x")

11:03 <javierm> lag: why they are not using module alias instead for https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpio-f7188x.c ?

11:06 <javierm> lag: too many workarounds in that driver... If I were you, I would probably just merge that and move on. IMO the probe deferral mechanism is just hacks on top of hacks

11:08 <javierm> lag: specially since the driver is already using that pattern of returning -ENODEV if !IS_ENABLED(CONFIG_FOO_BAR), so at least what is proposing is consistent

11:16 <bjdooks> hmm, if the driver is checking for a config, sounds like one of the drivers is not doing the right thing

11:34 <lag> bjdooks: That was my initial issue - however, there is already a precedent for it in the lines below (before my time) /facepalm

11:34 <javierm> lag, bjdooks: yeah, agreed but as mentioned the driver is already doing that so not sure if is worth to push back in this case

11:35 <javierm> anyways, not a hill I would be willing to die on at least :)

11:39 <lag> javierm: ... and with 600 mails in my back-log, I don't have time to waste on 49:51 issues

11:40 <lag> Path of least resistance, here we come ...

11:42 <bjdooks> it's a hill i'd quitely back away from and then pretend to have never seen it in the first place

13:51 <mwalle> The general rule seem to be not to rely on the bootloader, but I'm not sure how to fix the following in linux. The problem is that on one of our boards, the PHY reset is broken. The reset line is driven by the CPLD and the SoC. Until now, both will drive the output (the reset line doesn't work, the io cell seems to be to weak to compete against the CPLD output cell). The intended use is that the

13:51 <mwalle> SoC drives another gpio connected to the CPLD which then drives the PHY reset. The fix seems easy, that is just change the phy reset GPIO in the device tree. *But* if the bootloader isn't updated, it will leave the old gpio as output. And in this case, the CPLD now drives against the SoC output. So linux would need to change the old gpio to input mode.

13:52 <mwalle> just requesting that pin via the pinmux, doesn't work as it wont change the gpio direction. Maybe someone has another idea?

14:26 <jn> mwalle: i'd try using the gpio-hog mechanism, see Documentation/devicetree/bindings/gpio/gpio.txt

14:32 <mwalle> jn: ah that one. yeah, but it has one major drawback. the order in which that one is probed isn't always in favor. And I guess it could change over time (?)

14:32 <mwalle> *in my favor

14:33 <jn> hmm

14:34 <mwalle> (i've tried to use that one on another board to set some obscure gpios I need for some devices to work. sometimes it worked, sometimes the gpio hog was activated after the driver was probed)

14:34 <jn> in that case, i'd try to change the bootloader or CPLD design to avoid booting in an unusable state

14:37 <mwalle> jn: sure. for new boards that is doabale (and maybe boards in the field if customer wants to do bootloader updates). But there seems to be something missing in linux to fix up such situations.

14:37 <jn> hmm, i see

14:38 <jn> early board code is always a (somewhat dirty) option

14:39 <mwalle> and making the gpio hog code probe early isn't possible because the gpio controller might be a module and there is just no link between a device and an assicated gpio.

14:40 <mwalle> or - for dt platforms at least - the gpio hog could be a child of a device

14:43 <jn> modules are a good point. in your specific case you could use them to influence the probe order in your favor

14:52 <mwalle> jn: yeah but that is rather fragile. we are an OEM. We can't really tell someone how to use our bsp

22:48 <ukleinek> linusw_: Do you know details about drivers/mfd/ab8500*?

22:49 <ukleinek> linusw_: background of my question is: I looked at the matching PWM driver (i.e. drivers/pwm/pwm-ab8500.c) and there is something strange.

22:51 <ukleinek> The driver doesn't handle struct pwm_state::period, I guess the period is fixed at 0x300 ns, but a confirmation from someone who has the documentation handy would be great.

23:02 <ukleinek> s/0x300/0x400/