| Message ID | 20190522105113.11153-1-heikki.krogerus@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Software fwnode references | expand |
On Wed, May 22, 2019 at 1:51 PM Heikki Krogerus <heikki.krogerus@linux.intel.com> wrote: > > Hi, > > I'm not splitting this series in two after all. After thinking about > this for some time, I decided to add support for static software > nodes. I did not want to support them because I don't want to make it > easy to maintain board files, but in end they make the use of the > software nodes so much more easier compared to if we always had to > dynamically allocate them that it's a no-brainer. The references can > now be also described statically. Actually, those can now only be > described statically. > > Hans! I applied (hopefully) all of the fixes you proposed in v3. I > hope you have time to test these. > > Here's the cover letter from v3: > > This is the third version of my proposal to add reference handling to > the software node code. In this version I renamed ACPI_NAME_SIZE to > ACPI_NAMESEG_SIZE in 6/13, and slit patch 9/13 in two separate patches > (9/13 and 10/13) as suggested by Andy. Patch 9/13 will now only move > the registration of max17047 out of probe, and 10/13 will introduce > the software nodes. > > v2 cover letter: > > This is the second version of this series. In this version I'm > introducing a new helper device_find_child_by_name() as proposed > by Andy. Andy requested also another helper that could be used for > chaining the fwnodes, but I decided not to add that now. I would like > to still think about how we should handle exceptions like if there > already is a secondary node assigned for a node. > > v1 cover letter: > > This series adds support for software fwnode reference handling. In > practice it means making fwnode_property_get_reference_args() function > usable in the drivers also with software nodes. I send the series > originally as RFC [1]. > > As the first user for the software node references, I'm converting > intel_cht_int33fe.c to use them as part of the series. > > [1] https://lkml.org/lkml/2019/3/15/457 > For PDx86 bits, Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Assuming it will go thru some other tree. > thanks, > > Heikki Krogerus (16): > software node: Allow node creation without properties > software node: Simplify software_node_release() function > software node: Add support for static node descriptors > software node: Use kobject name when finding child nodes by name > software node: Add software_node_get_reference_args() > driver core: Add helper device_find_child_by_name() > ACPI / property: Don't limit named child node matching to data nodes > device property: Introduce fwnode_find_reference() > device connection: Find connections also by checking the references > usb: typec: Registering real device entries for the muxes > platform/x86: intel_cht_int33fe: Register max17047 in its own function > platform/x86: intel_cht_int33fe: Remove unused fusb302 device property > platform/x86: intel_cht_int33fe: Provide software nodes for the > devices > platform/x86: intel_cht_int33fe: Provide fwnode for the USB connector > platform/x86: intel_cht_int33fe: Supply fwnodes for the external > dependencies > platform/x86: intel_cht_int33fe: Replacing the old connections with > references > > drivers/acpi/property.c | 26 +- > drivers/base/core.c | 28 ++ > drivers/base/devcon.c | 26 ++ > drivers/base/property.c | 24 ++ > drivers/base/swnode.c | 324 +++++++++++++++++------ > drivers/platform/x86/intel_cht_int33fe.c | 290 ++++++++++++++++---- > drivers/usb/roles/class.c | 2 +- > drivers/usb/typec/bus.h | 15 ++ > drivers/usb/typec/class.c | 17 +- > drivers/usb/typec/mux.c | 238 ++++++++++++----- > drivers/usb/typec/mux/pi3usb30532.c | 46 ++-- > include/linux/device.h | 2 + > include/linux/property.h | 51 ++++ > include/linux/usb/typec_mux.h | 62 ++--- > 14 files changed, 902 insertions(+), 249 deletions(-) > > -- > 2.20.1 >
Hi, On 5/22/19 12:50 PM, Heikki Krogerus wrote: > Hi, > > I'm not splitting this series in two after all. After thinking about > this for some time, I decided to add support for static software > nodes. I did not want to support them because I don't want to make it > easy to maintain board files, but in end they make the use of the > software nodes so much more easier compared to if we always had to > dynamically allocate them that it's a no-brainer. The references can > now be also described statically. Actually, those can now only be > described statically. > > Hans! I applied (hopefully) all of the fixes you proposed in v3. I > hope you have time to test these. I've just ran various tests with the entire series applied and everything (superspeed host, superspeed device, DP over Type-C, PD charging) seems to work fin, so you can add my: Tested-by: Hans de Goede <hdegoede@redhat.com> To the entire series. I've 2 very minor nitpicks about the intel_cht_int33fe patches, with those fixed, you can also add my: Reviewed-by: Hans de Goede <hdegoede@redhat.com> To the intel_cht_int33fe patches. I will reply to the 2 individual patches for which I've some remarks separately. Regards, Hans
On Wed, May 29, 2019 at 11:29:10AM +0200, Hans de Goede wrote: > Hi, > > On 5/22/19 12:50 PM, Heikki Krogerus wrote: > > Hi, > > > > I'm not splitting this series in two after all. After thinking about > > this for some time, I decided to add support for static software > > nodes. I did not want to support them because I don't want to make it > > easy to maintain board files, but in end they make the use of the > > software nodes so much more easier compared to if we always had to > > dynamically allocate them that it's a no-brainer. The references can > > now be also described statically. Actually, those can now only be > > described statically. > > > > Hans! I applied (hopefully) all of the fixes you proposed in v3. I > > hope you have time to test these. > > I've just ran various tests with the entire series applied and > everything (superspeed host, superspeed device, DP over Type-C, > PD charging) seems to work fin, so you can add my: > > Tested-by: Hans de Goede <hdegoede@redhat.com> > > To the entire series. > > I've 2 very minor nitpicks about the intel_cht_int33fe patches, > with those fixed, you can also add my: > > Reviewed-by: Hans de Goede <hdegoede@redhat.com> > > To the intel_cht_int33fe patches. I will reply to the > 2 individual patches for which I've some remarks > separately. Thanks Hans! I'll fix those. Cheers,
Hi, I'm not splitting this series in two after all. After thinking about this for some time, I decided to add support for static software nodes. I did not want to support them because I don't want to make it easy to maintain board files, but in end they make the use of the software nodes so much more easier compared to if we always had to dynamically allocate them that it's a no-brainer. The references can now be also described statically. Actually, those can now only be described statically. Hans! I applied (hopefully) all of the fixes you proposed in v3. I hope you have time to test these. Here's the cover letter from v3: This is the third version of my proposal to add reference handling to the software node code. In this version I renamed ACPI_NAME_SIZE to ACPI_NAMESEG_SIZE in 6/13, and slit patch 9/13 in two separate patches (9/13 and 10/13) as suggested by Andy. Patch 9/13 will now only move the registration of max17047 out of probe, and 10/13 will introduce the software nodes. v2 cover letter: This is the second version of this series. In this version I'm introducing a new helper device_find_child_by_name() as proposed by Andy. Andy requested also another helper that could be used for chaining the fwnodes, but I decided not to add that now. I would like to still think about how we should handle exceptions like if there already is a secondary node assigned for a node. v1 cover letter: This series adds support for software fwnode reference handling. In practice it means making fwnode_property_get_reference_args() function usable in the drivers also with software nodes. I send the series originally as RFC [1]. As the first user for the software node references, I'm converting intel_cht_int33fe.c to use them as part of the series. [1] https://lkml.org/lkml/2019/3/15/457 thanks, Heikki Krogerus (16): software node: Allow node creation without properties software node: Simplify software_node_release() function software node: Add support for static node descriptors software node: Use kobject name when finding child nodes by name software node: Add software_node_get_reference_args() driver core: Add helper device_find_child_by_name() ACPI / property: Don't limit named child node matching to data nodes device property: Introduce fwnode_find_reference() device connection: Find connections also by checking the references usb: typec: Registering real device entries for the muxes platform/x86: intel_cht_int33fe: Register max17047 in its own function platform/x86: intel_cht_int33fe: Remove unused fusb302 device property platform/x86: intel_cht_int33fe: Provide software nodes for the devices platform/x86: intel_cht_int33fe: Provide fwnode for the USB connector platform/x86: intel_cht_int33fe: Supply fwnodes for the external dependencies platform/x86: intel_cht_int33fe: Replacing the old connections with references drivers/acpi/property.c | 26 +- drivers/base/core.c | 28 ++ drivers/base/devcon.c | 26 ++ drivers/base/property.c | 24 ++ drivers/base/swnode.c | 324 +++++++++++++++++------ drivers/platform/x86/intel_cht_int33fe.c | 290 ++++++++++++++++---- drivers/usb/roles/class.c | 2 +- drivers/usb/typec/bus.h | 15 ++ drivers/usb/typec/class.c | 17 +- drivers/usb/typec/mux.c | 238 ++++++++++++----- drivers/usb/typec/mux/pi3usb30532.c | 46 ++-- include/linux/device.h | 2 + include/linux/property.h | 51 ++++ include/linux/usb/typec_mux.h | 62 ++--- 14 files changed, 902 insertions(+), 249 deletions(-)