Re: [PATCH v3] software node: Implement device_get_match_data fwnode callback

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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