| Message ID | 2024013025-spoiling-exact-ad20@gregkh |
|---|---|
| Headers | show |
| Series | Soundwire: clean up sysfs group creation | expand |
Greg Kroah-Hartman wrote: > Now that sdw_slave_sysfs_init() only calls sdw_slave_sysfs_dpn_init(), > just do that instead and remove sdw_slave_sysfs_init() to get it out of > the way to save a bit of logic and code size. > > Cc: Vinod Koul <vkoul@kernel.org> > Cc: Bard Liao <yung-chuan.liao@linux.intel.com> > Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > Cc: Sanyog Kale <sanyog.r.kale@intel.com> > Cc: alsa-devel@alsa-project.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Looks correct. Reviewed-by: Dan Williams <dan.j.williams@intel.com>
On 1/30/24 19:46, Greg Kroah-Hartman wrote: > From: Dan Williams <dan.j.williams@intel.com> > > Add a mechanism for named attribute_groups to hide their directory at > sysfs_update_group() time, or otherwise skip emitting the group > directory when the group is first registered. It piggybacks on > is_visible() in a similar manner as SYSFS_PREALLOC, i.e. special flags > in the upper bits of the returned mode. To use it, specify a symbol > prefix to DEFINE_SYSFS_GROUP_VISIBLE(), and then pass that same prefix > to SYSFS_GROUP_VISIBLE() when assigning the @is_visible() callback: > > DEFINE_SYSFS_GROUP_VISIBLE($prefix) > > struct attribute_group $prefix_group = { > .name = $name, > .is_visible = SYSFS_GROUP_VISIBLE($prefix), > }; > > SYSFS_GROUP_VISIBLE() expects a definition of $prefix_group_visible() > and $prefix_attr_visible(), where $prefix_group_visible() just returns > true / false and $prefix_attr_visible() behaves as normal. > > The motivation for this capability is to centralize PCI device > authentication in the PCI core with a named sysfs group while keeping > that group hidden for devices and platforms that do not meet the > requirements. In a PCI topology, most devices will not support > authentication, a small subset will support just PCI CMA (Component > Measurement and Authentication), a smaller subset will support PCI CMA + > PCIe IDE (Link Integrity and Encryption), and only next generation > server hosts will start to include a platform TSM (TEE Security > Manager). > > Without this capability the alternatives are: > > * Check if all attributes are invisible and if so, hide the directory. > Beyond trouble getting this to work [1], this is an ABI change for > scenarios if userspace happens to depend on group visibility absent any > attributes. I.e. this new capability avoids regression since it does > not retroactively apply to existing cases. > > * Publish an empty /sys/bus/pci/devices/$pdev/tsm/ directory for all PCI > devices (i.e. for the case when TSM platform support is present, but > device support is absent). Unfortunate that this will be a vestigial > empty directory in the vast majority of cases. > > * Reintroduce usage of runtime calls to sysfs_{create,remove}_group() > in the PCI core. Bjorn has already indicated that he does not want to > see any growth of pci_sysfs_init() [2]. > > * Drop the named group and simulate a directory by prefixing all > TSM-related attributes with "tsm_". Unfortunate to not use the naming > capability of a sysfs group as intended. > > In comparison, there is a small potential for regression if for some > reason an @is_visible() callback had dependencies on how many times it > was called. Additionally, it is no longer an error to update a group > that does not have its directory already present, and it is no longer a > WARN() to remove a group that was never visible. > > Link: https://lore.kernel.org/all/2024012321-envious-procedure-4a58@gregkh/ [1] > Link: https://lore.kernel.org/linux-pci/20231019200110.GA1410324@bhelgaas/ [2] > Signed-off-by: Dan Williams <dan.j.williams@intel.com> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> This patch seems to introduce a regression on our Lunar Lake test devices, where we can't boot to an ssh shell. No issues on older devices [1]. Bard Liao and I reproduced the same results on different boards. We'll need to find someone with direct device access to provide more information on the problem, remote testing without ssh is a self-negating proposition. Is there a dependency on other patches? Our tests are still based on 6.7.0-rc3 due to other upstream issues we're currently working through. [1] https://github.com/thesofproject/linux/pull/4799
On Wed, Jan 31, 2024 at 02:05:04PM +0100, Pierre-Louis Bossart wrote: > > > On 1/30/24 19:46, Greg Kroah-Hartman wrote: > > From: Dan Williams <dan.j.williams@intel.com> > > > > Add a mechanism for named attribute_groups to hide their directory at > > sysfs_update_group() time, or otherwise skip emitting the group > > directory when the group is first registered. It piggybacks on > > is_visible() in a similar manner as SYSFS_PREALLOC, i.e. special flags > > in the upper bits of the returned mode. To use it, specify a symbol > > prefix to DEFINE_SYSFS_GROUP_VISIBLE(), and then pass that same prefix > > to SYSFS_GROUP_VISIBLE() when assigning the @is_visible() callback: > > > > DEFINE_SYSFS_GROUP_VISIBLE($prefix) > > > > struct attribute_group $prefix_group = { > > .name = $name, > > .is_visible = SYSFS_GROUP_VISIBLE($prefix), > > }; > > > > SYSFS_GROUP_VISIBLE() expects a definition of $prefix_group_visible() > > and $prefix_attr_visible(), where $prefix_group_visible() just returns > > true / false and $prefix_attr_visible() behaves as normal. > > > > The motivation for this capability is to centralize PCI device > > authentication in the PCI core with a named sysfs group while keeping > > that group hidden for devices and platforms that do not meet the > > requirements. In a PCI topology, most devices will not support > > authentication, a small subset will support just PCI CMA (Component > > Measurement and Authentication), a smaller subset will support PCI CMA + > > PCIe IDE (Link Integrity and Encryption), and only next generation > > server hosts will start to include a platform TSM (TEE Security > > Manager). > > > > Without this capability the alternatives are: > > > > * Check if all attributes are invisible and if so, hide the directory. > > Beyond trouble getting this to work [1], this is an ABI change for > > scenarios if userspace happens to depend on group visibility absent any > > attributes. I.e. this new capability avoids regression since it does > > not retroactively apply to existing cases. > > > > * Publish an empty /sys/bus/pci/devices/$pdev/tsm/ directory for all PCI > > devices (i.e. for the case when TSM platform support is present, but > > device support is absent). Unfortunate that this will be a vestigial > > empty directory in the vast majority of cases. > > > > * Reintroduce usage of runtime calls to sysfs_{create,remove}_group() > > in the PCI core. Bjorn has already indicated that he does not want to > > see any growth of pci_sysfs_init() [2]. > > > > * Drop the named group and simulate a directory by prefixing all > > TSM-related attributes with "tsm_". Unfortunate to not use the naming > > capability of a sysfs group as intended. > > > > In comparison, there is a small potential for regression if for some > > reason an @is_visible() callback had dependencies on how many times it > > was called. Additionally, it is no longer an error to update a group > > that does not have its directory already present, and it is no longer a > > WARN() to remove a group that was never visible. > > > > Link: https://lore.kernel.org/all/2024012321-envious-procedure-4a58@gregkh/ [1] > > Link: https://lore.kernel.org/linux-pci/20231019200110.GA1410324@bhelgaas/ [2] > > Signed-off-by: Dan Williams <dan.j.williams@intel.com> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > This patch seems to introduce a regression on our Lunar Lake test > devices, where we can't boot to an ssh shell. No issues on older devices > [1]. Bard Liao and I reproduced the same results on different boards. > > We'll need to find someone with direct device access to provide more > information on the problem, remote testing without ssh is a > self-negating proposition. > > Is there a dependency on other patches? Our tests are still based on > 6.7.0-rc3 due to other upstream issues we're currently working through. This should be totally stand-alone and not cause any problems, especially if you don't have any other patches applied. I did make this against 6.8-rc2, perhaps that's the issue? thanks, greg k-h
Dan Williams wrote: > Pierre-Louis Bossart wrote: > > > > > > On 1/30/24 19:46, Greg Kroah-Hartman wrote: > > > From: Dan Williams <dan.j.williams@intel.com> > > > > > > Add a mechanism for named attribute_groups to hide their directory at > > > sysfs_update_group() time, or otherwise skip emitting the group > > > directory when the group is first registered. It piggybacks on > > > is_visible() in a similar manner as SYSFS_PREALLOC, i.e. special flags > > > in the upper bits of the returned mode. To use it, specify a symbol > > > prefix to DEFINE_SYSFS_GROUP_VISIBLE(), and then pass that same prefix > > > to SYSFS_GROUP_VISIBLE() when assigning the @is_visible() callback: > > > > > > DEFINE_SYSFS_GROUP_VISIBLE($prefix) > > > > > > struct attribute_group $prefix_group = { > > > .name = $name, > > > .is_visible = SYSFS_GROUP_VISIBLE($prefix), > > > }; > > > > > > SYSFS_GROUP_VISIBLE() expects a definition of $prefix_group_visible() > > > and $prefix_attr_visible(), where $prefix_group_visible() just returns > > > true / false and $prefix_attr_visible() behaves as normal. > > > > > > The motivation for this capability is to centralize PCI device > > > authentication in the PCI core with a named sysfs group while keeping > > > that group hidden for devices and platforms that do not meet the > > > requirements. In a PCI topology, most devices will not support > > > authentication, a small subset will support just PCI CMA (Component > > > Measurement and Authentication), a smaller subset will support PCI CMA + > > > PCIe IDE (Link Integrity and Encryption), and only next generation > > > server hosts will start to include a platform TSM (TEE Security > > > Manager). > > > > > > Without this capability the alternatives are: > > > > > > * Check if all attributes are invisible and if so, hide the directory. > > > Beyond trouble getting this to work [1], this is an ABI change for > > > scenarios if userspace happens to depend on group visibility absent any > > > attributes. I.e. this new capability avoids regression since it does > > > not retroactively apply to existing cases. > > > > > > * Publish an empty /sys/bus/pci/devices/$pdev/tsm/ directory for all PCI > > > devices (i.e. for the case when TSM platform support is present, but > > > device support is absent). Unfortunate that this will be a vestigial > > > empty directory in the vast majority of cases. > > > > > > * Reintroduce usage of runtime calls to sysfs_{create,remove}_group() > > > in the PCI core. Bjorn has already indicated that he does not want to > > > see any growth of pci_sysfs_init() [2]. > > > > > > * Drop the named group and simulate a directory by prefixing all > > > TSM-related attributes with "tsm_". Unfortunate to not use the naming > > > capability of a sysfs group as intended. > > > > > > In comparison, there is a small potential for regression if for some > > > reason an @is_visible() callback had dependencies on how many times it > > > was called. Additionally, it is no longer an error to update a group > > > that does not have its directory already present, and it is no longer a > > > WARN() to remove a group that was never visible. > > > > > > Link: https://lore.kernel.org/all/2024012321-envious-procedure-4a58@gregkh/ [1] > > > Link: https://lore.kernel.org/linux-pci/20231019200110.GA1410324@bhelgaas/ [2] > > > Signed-off-by: Dan Williams <dan.j.williams@intel.com> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > This patch seems to introduce a regression on our Lunar Lake test > > devices, where we can't boot to an ssh shell. No issues on older devices > > [1]. Bard Liao and I reproduced the same results on different boards. > > > > We'll need to find someone with direct device access to provide more > > information on the problem, remote testing without ssh is a > > self-negating proposition. > > > > Is there a dependency on other patches? Our tests are still based on > > 6.7.0-rc3 due to other upstream issues we're currently working through. > > The only behavior change I can imagine with this patch is that > ->is_visble() callbacks get called extra times for named attribute > groups. > > ...or if an is_visible() callback was inadvertantly already using the > SYSFS_GROUP_INVISIBLE flag in umode_t result. Are you able to get kernel logs? A before and after with this patch applied might highlight which attribute does not appreciate the extra callback... diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c index ccb275cdabcb..683c0b10990b 100644 --- a/fs/sysfs/group.c +++ b/fs/sysfs/group.c @@ -33,11 +33,17 @@ static void remove_files(struct kernfs_node *parent, static umode_t __first_visible(const struct attribute_group *grp, struct kobject *kobj) { - if (grp->attrs && grp->is_visible) + if (grp->attrs && grp->is_visible) { + pr_info("kobj: %s is_visible: %pS\n", kobj->name, + grp->is_visible); return grp->is_visible(kobj, grp->attrs[0], 0); + } - if (grp->bin_attrs && grp->is_bin_visible) + if (grp->bin_attrs && grp->is_bin_visible) { + pr_info("kobj: %s is_bin_visible: %pS\n", kobj->name, + grp->is_bin_visible); return grp->is_bin_visible(kobj, grp->bin_attrs[0], 0); + } return 0; } @@ -62,6 +68,8 @@ static int create_files(struct kernfs_node *parent, struct kobject *kobj, if (update) kernfs_remove_by_name(parent, (*attr)->name); if (grp->is_visible) { + pr_info("kobj: %s is_visible: %pS\n", + kobj->name, grp->is_visible); mode = grp->is_visible(kobj, *attr, i); mode &= ~SYSFS_GROUP_INVISIBLE; if (!mode) @@ -92,6 +100,8 @@ static int create_files(struct kernfs_node *parent, struct kobject *kobj, kernfs_remove_by_name(parent, (*bin_attr)->attr.name); if (grp->is_bin_visible) { + pr_info("kobj: %s is_bin_visible: %pS\n", + kobj->name, grp->is_bin_visible); mode = grp->is_bin_visible(kobj, *bin_attr, i); mode &= ~SYSFS_GROUP_INVISIBLE; if (!mode)
On Wed, Jan 31, 2024 at 06:34:15PM +0530, Vinod Koul wrote: > On 30-01-24, 10:46, Greg Kroah-Hartman wrote: > > Note, this is a redone version of a very old series I wrote back in > > 2022: > > https://lore.kernel.org/r/20220824135951.3604059-1-gregkh@linuxfoundation.org > > but everyone has forgotten about it now, and I've reworked it, so I'm > > considering it a "new" version, and not v2. > > > > Here's a series that adds the functionality to the driver core to hide > > entire attribute groups, in a much saner way than we have attempted in > > the past (i.e. dynamically figuring it out.) Many thanks to Dan for > > this patch. I'll also be taking this into my driver-core branch and > > creating a stable tag for anyone else to pull from to get it into their > > trees, as I think it will want to be in many for this development cycle. > > > > After the driver core change, there's cleanups to the soundwire core for > > how the attribute groups are created, to remove the "manual" creation of > > them, and allow the driver core to create them correctly, as needed, > > when needed, which makes things much smaller for the soundwire code to > > manage. > > The series lgtm, having the core handle these would be good. I will wait > couple of days for people to test this and give a t-b and apply. > I hope it is okay if patch1 goes thru sdw tree? patch 1 is now in Linus's tree, so the remaining ones can go through the your tree now if you want. Or I can resend them if needed, just let me know. thanks, greg k-h
On 27-03-24, 09:13, Greg Kroah-Hartman wrote: > On Wed, Jan 31, 2024 at 06:34:15PM +0530, Vinod Koul wrote: > > On 30-01-24, 10:46, Greg Kroah-Hartman wrote: > > > Note, this is a redone version of a very old series I wrote back in > > > 2022: > > > https://lore.kernel.org/r/20220824135951.3604059-1-gregkh@linuxfoundation.org > > > but everyone has forgotten about it now, and I've reworked it, so I'm > > > considering it a "new" version, and not v2. > > > > > > Here's a series that adds the functionality to the driver core to hide > > > entire attribute groups, in a much saner way than we have attempted in > > > the past (i.e. dynamically figuring it out.) Many thanks to Dan for > > > this patch. I'll also be taking this into my driver-core branch and > > > creating a stable tag for anyone else to pull from to get it into their > > > trees, as I think it will want to be in many for this development cycle. > > > > > > After the driver core change, there's cleanups to the soundwire core for > > > how the attribute groups are created, to remove the "manual" creation of > > > them, and allow the driver core to create them correctly, as needed, > > > when needed, which makes things much smaller for the soundwire code to > > > manage. > > > > The series lgtm, having the core handle these would be good. I will wait > > couple of days for people to test this and give a t-b and apply. > > I hope it is okay if patch1 goes thru sdw tree? > > patch 1 is now in Linus's tree, so the remaining ones can go through the > your tree now if you want. Or I can resend them if needed, just let me > know. Great, I was about to ask about this. If there is no conflicts I can pick this series (looking at folks for giving me a t-b)
On 27/03/24 18:21, Vinod Koul wrote: > On 27-03-24, 09:13, Greg Kroah-Hartman wrote: >> On Wed, Jan 31, 2024 at 06:34:15PM +0530, Vinod Koul wrote: >>> On 30-01-24, 10:46, Greg Kroah-Hartman wrote: >>>> Note, this is a redone version of a very old series I wrote back in >>>> 2022: >>>> https://lore.kernel.org/r/20220824135951.3604059-1-gregkh@linuxfoundation.org >>>> but everyone has forgotten about it now, and I've reworked it, so I'm >>>> considering it a "new" version, and not v2. >>>> >>>> Here's a series that adds the functionality to the driver core to hide >>>> entire attribute groups, in a much saner way than we have attempted in >>>> the past (i.e. dynamically figuring it out.) Many thanks to Dan for >>>> this patch. I'll also be taking this into my driver-core branch and >>>> creating a stable tag for anyone else to pull from to get it into their >>>> trees, as I think it will want to be in many for this development cycle. >>>> >>>> After the driver core change, there's cleanups to the soundwire core for >>>> how the attribute groups are created, to remove the "manual" creation of >>>> them, and allow the driver core to create them correctly, as needed, >>>> when needed, which makes things much smaller for the soundwire code to >>>> manage. >>> The series lgtm, having the core handle these would be good. I will wait >>> couple of days for people to test this and give a t-b and apply. >>> I hope it is okay if patch1 goes thru sdw tree? >> patch 1 is now in Linus's tree, so the remaining ones can go through the >> your tree now if you want. Or I can resend them if needed, just let me >> know. > Great, I was about to ask about this. If there is no conflicts I can > pick this series (looking at folks for giving me a t-b) Applied this patch series on top of soundwire git tree and validated SoundWire stack on AMD platform using command line alsa utils. All use cases are working fine. Tested-By: Vijendar Mukunda <Vijendar.Mukunda@amd.com> >
On Tue, 30 Jan 2024 10:46:26 -0800, Greg Kroah-Hartman wrote: > Note, this is a redone version of a very old series I wrote back in > 2022: > https://lore.kernel.org/r/20220824135951.3604059-1-gregkh@linuxfoundation.org > but everyone has forgotten about it now, and I've reworked it, so I'm > considering it a "new" version, and not v2. > > Here's a series that adds the functionality to the driver core to hide > entire attribute groups, in a much saner way than we have attempted in > the past (i.e. dynamically figuring it out.) Many thanks to Dan for > this patch. I'll also be taking this into my driver-core branch and > creating a stable tag for anyone else to pull from to get it into their > trees, as I think it will want to be in many for this development cycle. > > [...] Applied, thanks! [2/6] soundwire: sysfs: move sdw_slave_dev_attr_group into the existing list of groups commit: b1b11bb07898b7e0313438734c310100219e676f [3/6] soundwire: sysfs: cleanup the logic for creating the dp0 sysfs attributes commit: 3ee43f7cc9841cdf3f2bec2de4b1e729fd17e303 [4/6] soundwire: sysfs: have the driver core handle the creation of the device groups commit: fc7e56017b51482f1b9da2e778eedb4bd1deb6b3 [5/6] soundwire: sysfs: remove sdw_slave_sysfs_init() commit: f88c1afe338edbcbfd23743742c45581075fb86c [6/6] soundwire: sysfs: remove unneeded ATTRIBUTE_GROUPS() comments commit: 91c4dd2e5c9066577960c7eef7dd8e699220c85e Best regards,
Note, this is a redone version of a very old series I wrote back in 2022: https://lore.kernel.org/r/20220824135951.3604059-1-gregkh@linuxfoundation.org but everyone has forgotten about it now, and I've reworked it, so I'm considering it a "new" version, and not v2. Here's a series that adds the functionality to the driver core to hide entire attribute groups, in a much saner way than we have attempted in the past (i.e. dynamically figuring it out.) Many thanks to Dan for this patch. I'll also be taking this into my driver-core branch and creating a stable tag for anyone else to pull from to get it into their trees, as I think it will want to be in many for this development cycle. After the driver core change, there's cleanups to the soundwire core for how the attribute groups are created, to remove the "manual" creation of them, and allow the driver core to create them correctly, as needed, when needed, which makes things much smaller for the soundwire code to manage. Comments appreciated! thanks, greg k-h Dan Williams (1): sysfs: Introduce a mechanism to hide static attribute_groups Greg Kroah-Hartman (5): soundwire: sysfs: move sdw_slave_dev_attr_group into the existing list of groups soundwire: sysfs: cleanup the logic for creating the dp0 sysfs attributes soundwire: sysfs: have the driver core handle the creation of the device groups soundwire: sysfs: remove sdw_slave_sysfs_init() soundwire: sysfs: remove unneeded ATTRIBUTE_GROUPS() comments drivers/soundwire/bus_type.c | 5 ++- drivers/soundwire/sysfs_local.h | 4 +- drivers/soundwire/sysfs_slave.c | 64 ++++++++++++++--------------- drivers/soundwire/sysfs_slave_dpn.c | 3 ++ fs/sysfs/group.c | 45 ++++++++++++++++---- include/linux/sysfs.h | 63 ++++++++++++++++++++++------ 6 files changed, 126 insertions(+), 58 deletions(-)