Hi,
On 2024/4/24 16:39, Dmitry Baryshkov wrote:
Sui, if that fits your purpose,
That doesn't fits my purpose, please stop the recommendation, thanks.
please make sure that with your patch
(or the next iteration of it) you can get driver_data from the matched
platform_device_id.
No, that's a another problem.
The 'platform_get_device_id(pdev)->driver_data' you mentioned is completely
off the domain of fwnode API framework. You are completely deviate what we
are currently talking about.
What we are talking about is something within the fwnode API framework.
You can hack the device_get_match_data() function to call
platform_get_device_id()
as a fallback code path when the fwnode subsystem couldn't return a match data
to
you. But this is another problem.
No. I was using this as a pointer for having non-DT driver data.
Whatever.
Whatever how does it going to be used by you, or whatever data the pointer you
use to point to.
Just remember one thing, it is not relevant to my patch itself.
As I
wrote several paragraphs above, other subsystems use their own
driver-specific match structures.
Fine, but on the DT systems, they mostly probed via DT.
Thus, the so-called driver-specific match structures won't be used.
Reworking subsystems one-by-one to
be able to use generic codepath sounds to me like a way to go.
Fine, you are encouraged to do whatever you like, you don't have to told me.
Adding
"compatible" property doesn't.
As I have told you several times, software node is kind of complement to ACPI,
it's
definitely need to follow the style of ACPI counterpart. Software node can be
secondary
node of the primary ACPI device node. With this understood, please read the
implementation
of acpi_of_match_device() before express objection. Or you can read several
relevant commit
such as 4222f38ca3b7a ('ACPI / bus: Do not traverse through non-existed device
table')
for knowing some extra background.
Beside, users of the software node backend itself can do whatever they like.
The value of the "compatible" property is *just* string, programmers
are free to name their string property in their driver. It is not you to say no
though.
No offensive here, I means that both of us are not good at this domain.
Especially me,
but at the very least, I'm willing to listen to what expects in ACPI/swnode
domain say.
One day, you become the top maintainer of specific domain, and when I go to
contribute
then, I will also read to you reviews message carefully.
Back to the technical itself, the "compatible" property is a standard property
of ACPI _DSD object. This is written into the ACPI Spec. The value of the
"compatible"
property is just string, store it at
'platform_get_device_id(pdev)->driver_data' or in
'of_device_id->compatible' or some other places doesn't really changes much in
semantic.
A device driver can be platform probed, DT probed, ACPI probed, I2C probed, SPI
probed...
Take the driver of I2C slave display bridge as an example, it can platform
probed, DT probed,
I2C probed, in the future, there may have programmers want to add
acpi_device_id, then, it will
gain the 'ACPI probed'.
If each of them introduce a driver-specific match structure. Then, that going
to introduce
very heavy maintain overhead to the maintainers, not to mention to achieve your
cheap slogan:
"Unifying DT and non-DT paths via generic property / fwnode code".
--
Best regards,
Sui
