Hi,
On 2024/4/25 00:34, 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,
No thecommit message is very clear, just you don't clear. Can't you see that
only you are out of scope here and complaining with wrong hypothesis?
or
maybe I missed something.
No, you miss and mess everything.
The usecase that I understood from the commit
message was to use instatiated i2c / spi devices, which means
i2c_device_id / spi_device_id.
It can also be platform device with manually assigned software node.
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.
Yes, I admit it, its not the first time you do such a thing. I know you might
good at debating and directing blindly. But those skills are not really helpful.
As it brings ZERO benefits to the developers and end user of Linux kernel. What
the end user need is a good DRM driver and infrastructure like i915, amdgpu,
radeon, vc4, ast, X server or wayland etc.
Its fine to keep quite if you don't understand something very well, especially,
the for the things that not directly maintained by you. As you don't have to
responsible for it and you don't need to pay for the obligation. You might
deceive yourself to believe that you are reviewing, actually, you are just
wasting your time as well as other people's time.
If the the commit message is really matters to you, then do you thing about
the following series [1][2][3] ?
[1] https://patchwork.freedesktop.org/series/123812/
[2] https://patchwork.freedesktop.org/patch/579730/?series=130021&rev=2
[3] https://patchwork.freedesktop.org/series/123737/
How about the witting of its commit message, very well, right?
Think before you type, and type with the brain not with the emotion.
--
Best regards,
Sui
