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:
Yep. I also do not clearly understand the use case and why we need to haveMaybe the scenario was not properly described in the commit message, orTrue, 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.
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.
a board file, because the swnodes all are about board files that we must not
use for the new platforms.