On Thu, May 18, 2023 at 11:47:12AM -0500, Pierre-Louis Bossart wrote: > On 5/18/23 11:15, Richard Fitzgerald wrote: > > On 18/05/2023 16:16, Pierre-Louis Bossart wrote: > >>>>> + ret = devm_mfd_add_devices(cs42l43->dev, PLATFORM_DEVID_NONE, > >>>>> + cs42l43_devs, ARRAY_SIZE(cs42l43_devs), > >>>> > >>>> I don't why adding devices is not in probe. They use the same regmap > >>>> right? So there will be no problem in probing them from MFD probe. > >>> > >>> Well except SoundWire is a bit of a special boy, the hardware is > >>> not necessarily available in probe, the hardware is only available > >>> at some point later when the device attaches. Doing it this way all > >>> of the attaching (and various detach/attach cycles the device needs > >>> during configuration) are over by the time the child drivers bind, so > >>> they don't all need special code to handle that. > >> > >> if the devices are added in the probe, then the regmap needs to be moved > >> to cache-only and another special API would be needed to tell the MFD > >> framework to turn the regmap cache-only off. > >> > >> But if it's the same regmap, the regmap cache is handled in the > >> SoundWire update_status callback so maybe Krzysztof's proposal does > >> work? > > > > But you still can't access the hardware in probe(). So you'd have all > > the child drivers probing but not able to talk to the hardware. The > > child drivers would have to hook into the update_status() somehow so > > they know when the peripheral has enumerated. > > It's simpler to add them after the hardware has enumerated - they will > > be able to access the hardware in their probe(). > > It depends on what you mean by 'access the hardware'. If the only > interface is regmap and regmap is in cache-only, then the child drivers > could "access the hardware" without anything happening until after > regmap is no longer cache-only. > > But yeah, I realize it's a long shot. Yeah, its never just the regmap. Take the sound driver for example, when the sound driver binds all the components will be inplace and a soundcard will be created. This means the user could then start an audio stream before any hardware is actually available, various bits of the audio bring up rely on timing or reading state so won't work in cache-only. Yeah you could add work arounds for these problems as they arise, but you will end up with a lot of them. I would flip this around and ask, what is the problem with adding the child devices once the device has completed initialisation? As far as I can see it looks like a choice between moving one function call with no obvious downside, against loads lines of various work arounds in each of the child drivers for whatever subsystem specific problems are caused by the device not actually being available. Thanks, Charles
