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:Maybe the scenario was not properly described in the commit message,
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:
True, but that is orthogonal to swnode match_data support, right?I was thinking that we might be able to deprecate these helpers andBut let me throw an argument why this patch (or something similar) looksI'm not sure I buy this. We have a special helpers based on the bus type to
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.
combine device_get_match_data() with the respective ID table crawling, see
the SPI and I²C cases as the examples.
always use device_get_match_data().
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.
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 whyYes, I admit it, its not the first time you do such a thing. I know you might
the usecase requires using 'compatible' property and swnode. Ideally it
should describe how these devices are instantiated at the first place.