On 2024/4/25 00:44, Andy Shevchenko wrote:
On Wed, Apr 24, 2024 at 07:34:54PM +0300, Dmitry Baryshkov wrote:
On Wed, Apr 24, 2024 at 05:52:03PM +0300, Andy Shevchenko wrote:
On Wed, Apr 24, 2024 at 04:34:39PM +0300, Dmitry Baryshkov wrote:
On Wed, 24 Apr 2024 at 16:11, Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
On Wed, Apr 24, 2024 at 12:37:16AM +0300, Dmitry Baryshkov wrote:
On Wed, Apr 24, 2024 at 12:49:18AM +0800, Sui Jingfeng wrote:
On 2024/4/23 21:28, Andy Shevchenko wrote:
On Tue, Apr 23, 2024 at 12:46:58AM +0800, Sui Jingfeng wrote:
...
But let me throw an argument why this patch (or something similar) looks
to be necessary.
Both on DT and non-DT systems the kernel allows using the non-OF based
matching. For the platform devices there is platform_device_id-based
matching.
Currently handling the data coming from such device_ids requires using
special bits of code, e.g. platform_get_device_id(pdev)->driver_data to
get the data from the platform_device_id. Having such codepaths goes
against the goal of unifying DT and non-DT paths via generic property /
fwnode code.
As such, I support Sui's idea of being able to use device_get_match_data
for non-DT, non-ACPI platform devices.
I'm not sure I buy this. We have a special helpers based on the bus type to
combine device_get_match_data() with the respective ID table crawling, see
the SPI and I²C cases as the examples.
I was thinking that we might be able to deprecate these helpers and
always use device_get_match_data().
True, but that is orthogonal to swnode match_data support, right?
There even was (still is?) a patch series to do something like a new
member to struct device_driver (? don't remember) to achieve that.
Maybe the scenario was not properly described in the commit message, or
maybe I missed something. The usecase that I understood from the commit
message was to use instatiated i2c / spi devices, which means
i2c_device_id / spi_device_id. The commit message should describe why
the usecase requires using 'compatible' property and swnode. Ideally it
should describe how these devices are instantiated at the first place.
Yep. I also do not clearly understand the use case and why we need to have
a board file, because the swnodes all are about board files that we must not
use for the new platforms.
Would you like to tell us what's the 'board file'?
I am asking because I can not understand those two words at all.
I'm really don't know what's the meanings of 'board file'.
Do you means that board file is something like the dts, or
somethings describe the stuff on the motherboard but outside
the CPU?
Does the hardware IP core belong to the "board file"?
Can we using more concrete vocabulary instead of the vague
vocabulary to communicate?
--
Best regards,
Sui
