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.
Thanks.
