| Message ID | 20210329105047.51033-6-heikki.krogerus@linux.intel.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | i2c: Adding support for software nodes | expand |
On 29/03/2021 12:50, Heikki Krogerus wrote: > Additional device properties are always just a part of a > software fwnode. If the device properties are constant, the > software node can also be constant. > Hi, Thanks for your work. I did not get the cover letter nor other patches from this set and I don't see how the i2c uses the swnode. This makes difficult to judge whether this looks reasonable. At least without the context the title looks misleading - you add software_node or change to use software_node instead of constifying it. Best regards, Krzysztof
On Mon, Mar 29, 2021 at 12:58:41PM +0200, Krzysztof Kozlowski wrote: > On 29/03/2021 12:50, Heikki Krogerus wrote: > > Additional device properties are always just a part of a > > software fwnode. If the device properties are constant, the > > software node can also be constant. > > > Hi, > > Thanks for your work. > > I did not get the cover letter nor other patches from this set and I > don't see how the i2c uses the swnode. This makes difficult to judge > whether this looks reasonable. At least without the context the title > looks misleading - you add software_node or change to use software_node > instead of constifying it. OK, I'll try to open this up somehow... Whenever additional device properties are added to devices by using the old device property API (device_add_properties()) that also i2c core code uses, in reality a software node is always created to hold those properties. It's just always dynamically allocated. The goal of this series is to prepare the i2c subsystem and drivers for the removal of that old device property API, but I did not see that as relevant info for this patch, because even if we did not in the end remove that old API, this change is still useful. The patch does exactly what the subject says. After this we supply the device a constant software node instead of a dynamically allocated one. thanks,
On 29/03/2021 14:32, Heikki Krogerus wrote: > On Mon, Mar 29, 2021 at 12:58:41PM +0200, Krzysztof Kozlowski wrote: >> On 29/03/2021 12:50, Heikki Krogerus wrote: >>> Additional device properties are always just a part of a >>> software fwnode. If the device properties are constant, the >>> software node can also be constant. >>> >> Hi, >> >> Thanks for your work. >> >> I did not get the cover letter nor other patches from this set and I >> don't see how the i2c uses the swnode. This makes difficult to judge >> whether this looks reasonable. At least without the context the title >> looks misleading - you add software_node or change to use software_node >> instead of constifying it. > > OK, I'll try to open this up somehow... > > Whenever additional device properties are added to devices by using > the old device property API (device_add_properties()) that also i2c > core code uses, in reality a software node is always created to hold > those properties. It's just always dynamically allocated. > > The goal of this series is to prepare the i2c subsystem and drivers > for the removal of that old device property API, but I did not see > that as relevant info for this patch, because even if we did not in > the end remove that old API, this change is still useful. > > The patch does exactly what the subject says. After this we supply the > device a constant software node instead of a dynamically allocated one. Thanks for explanation. The follow up question is - can I take it independently via ARM Samsung/S3C tree? Best regards, Krzysztof
> Thanks for explanation. The follow up question is - can I take it > independently via ARM Samsung/S3C tree? Is it possible to just ack it, so I can take this all via I2C? Or will there be merge conflicts. I can provide an immutable branch, of course.
On 06/04/2021 21:40, Wolfram Sang wrote: > >> Thanks for explanation. The follow up question is - can I take it >> independently via ARM Samsung/S3C tree? > > Is it possible to just ack it, so I can take this all via I2C? Or will > there be merge conflicts. I can provide an immutable branch, of course. > Sure, ack is possible (from my currently used email): Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Best regards, Krzysztof
diff --git a/arch/arm/mach-s3c/mach-mini2440.c b/arch/arm/mach-s3c/mach-mini2440.c index 4100905dfbd0c..551ec660ab599 100644 --- a/arch/arm/mach-s3c/mach-mini2440.c +++ b/arch/arm/mach-s3c/mach-mini2440.c @@ -542,10 +542,14 @@ static const struct property_entry mini2440_at24_properties[] = { { } }; +static const struct software_node mini2440_at24_node = { + .properties = mini2440_at24_properties, +}; + static struct i2c_board_info mini2440_i2c_devs[] __initdata = { { I2C_BOARD_INFO("24c08", 0x50), - .properties = mini2440_at24_properties, + .swnode = &mini2440_at24_node, }, };
Additional device properties are always just a part of a software fwnode. If the device properties are constant, the software node can also be constant. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> --- arch/arm/mach-s3c/mach-mini2440.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)