On Sun, Jun 23, 2024 at 03:38:23PM +0800, Sui Jingfeng wrote: > Hi, > > On 6/23/24 03:29, Dmitry Torokhov wrote: > > > In case of non-OF match (which > > > > includes the case where you use software nodes) the match data is coming > > > > from matching spi_device_id entry in the driver. > > > > > > We don't care about much how it is probed now, rather, after the driver > > > probed by a non-OF way, how does the additional devices properties > > > can be get? > > > > > > > > > Say: > > > > > > 1) "device_property_read_u32(dev, "rotation", &rotation);" and > > > 2) "!device_property_read_string(dev, "pervasive,thermal-zone", > > > &thermal_zone))" > > > > > > > > > For those spi/i2c/platform devices, what we argues are that > > > those drivers really should just depend on "OF" before we have > > > a reliable fwnode API backend to redirect to. > > They are working fine without such restriction now, > > > You still *NOT* answer where the additional devices properties[1][2] > can be acquire. > > [1] device_property_read_u32(dev, "rotation", &rotation) > > [2] device_property_read_string(dev, "pervasive,thermal-zone", > &thermal_zone)) > > > > so I see absolutely no reason imposing this restriction. > > The reason is rigorous. > > You are acclaiming that works by hardcode or by ignoring the flaws > is fine, then all driver are working fine by *your* standard. > > Your personal standard has nothing to do with this patch. > > > > Where the additional device_property_read_xxxx() calls redirect to? > > > > > > What if users want to invoke more device_property_read_xxxx() function? > > They are being directed to first the primary FW node instance, which may > > be either OF, ACPI, or SW node, and then, if property is not present > > there, to the secondary FW node, which can be either again. > > > What I'm asking is, on the non-OF and no-ACPI cases, where's those > device_property_read_xxx() calls can be directed to? > > > At no point ->device_get_match_data() callback in involved in this > > process. > > > > The patch is written for people who need it, not for people who don't. > > It will be involved if the device is associated with software node. > Its for fwnode API user to get a consistent experience, that is > to get a matching data without introduce extra/duplicated match > mechanism. > > The patch is focus on fixing the undefined behavior, is discussing > the correct way to consolidate the fwnode API. Its not going to > discuss how does the those *old" and/or how does those non-fwnode > systems works. > > Its NOT discussing how does the driver itself can be probed, a driver > can be probed multiple way and is another question. Being probed and > extract matching data can two different thing and is perfectly valid. > > Your problem is that you are not fully understand what other people > does before you rush into the discussion. You are putting restrictions > onto other people, while leaving the problem itself there unsolved. > > Its not a place to express your personal value or you personal status, > such as, you are "ready" or "not ready" for something. Or persuading > somebody should get used to what or teaching people to talks with a > whatever tone like a God. > > None of those junk words are technical, I can not see constructive > ideas. Yes, indeed, it appears that further discussion is pointless at this point. Andy, Heikki, Greg, and others: FWIW this is a NAK from me. Thanks. -- Dmitry
