09:05 <mwalle> linusw__: any chance you can give https://lore.kernel.org/r/20240610074809.2180535-1-mwalle@kernel.org/ a quick test?

09:13 <linusw__> mwalle: I've been planning to do so, just didn't have time & equipment at the same moment!

09:27 <mwalle> linusw__: ok, great :)

12:35 <marc|gonzalez> Consider a probe function for a platform device, foo_probe(struct platform_device *pdev). If we do platform_set_drvdata(pdev, drvdata); in the function, but the probe fails, and drvdata is devm_freed, pdev will have a dangling pointer. Is there any risk some code will try accessing this memory?

12:43 <pinchartl> marc|gonzalez: not in core code

12:43 <broonie> marc|gonzalez: The driver would have to try to access drvdata before setting it in probe().

12:43 <marc|gonzalez> pinchartl: thanks!

12:43 <pinchartl> and device_unbind_cleanup() sets it back to NULL

12:44 <pinchartl> device_unbind_cleanup() is called in the failure patch of really_probe()

12:44 <pinchartl> so I think you're safe

12:44 <marc|gonzalez> I was concerned about the following code pattern:

12:45 <marc|gonzalez> p = devm_kzalloc(...); platform_set_drvdata(pdev, p); other_stuff() if (err) return err;

12:46 <marc|gonzalez> actually, same thing for i2c_client, with s/platform_set_drvdata/i2c_set_clientdata/

12:46 <marc|gonzalez> But it seems like a fairly common code pattern

12:49 <pinchartl> marc|gonzalez: core code doesn't dereference the drvdata pointer. furthermore, if the probe function fails, really_probe() will call device_unbind_cleanup(), which will set the pointer to NULL

12:50 <marc|gonzalez> thanks for the definitive answer!

12:50 <pinchartl> you have the source code, you can check too :-)

12:53 <javierm_> pinchartl: in fairness, the dd core / probe deferral path is not that easy to follow :)

12:54 <pinchartl> true

12:55 <javierm_> :D

13:05 <mripard> pinchartl: tbf, I'm not sure anyone does

13:19 <javierm_> mripard: I *thought* that did at least as a 3rd lang but then realized that probe deferrals timeout now for some subsystems... so agree with you that probably is hard to claim that

15:14 <marc|gonzalez> pinchartl: I don't understand simple-bridge.yaml (the compatible prop's definition)

15:15 <marc|gonzalez> First option is: either ti,ths8134a OR ti,ths8134b, followed by mandatory ti,ths8134

15:15 <marc|gonzalez> second option is foo or bar

15:16 <marc|gonzalez> how is 3rd option different semantically from option 2?

15:17 <marc|gonzalez> I'll take my question to #device-tree

15:43 <marc|gonzalez> animesh explained, option 2 was foo AND bar