On 12/2/20 1:20 PM, Greg KH wrote:
On Wed, Dec 02, 2020 at 01:02:06PM -0500, Andrey Grodzovsky wrote:
On 12/2/20 12:34 PM, Greg KH wrote:
On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:
On 11/11/20 10:34 AM, Greg KH wrote:
On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
On 11/10/20 12:59 PM, Greg KH wrote:
On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:
Hi, back to this after a long context switch for some higher priority stuff.
So here I was able eventually to drop all this code and this change here
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedesktop.org%2F~agrodzov%2Flinux%2Fcommit%2F%3Fh%3Damd-staging-drm-next-device-unplug%26id%3D61852c8a59b4dd89d637693552c73175b9f2ccd6&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C13040ab9b50947a95acc08d896eec15d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637425299507092187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CIXEl9hWHTAdo7t9yrdtu0OdEIZ3X2GQmJRhDUj28mw%3D&reserved=0
was enough for me. Seems like while device_remove_file can handle the use
case where the file and the parent directory already gone,
sysfs_remove_group goes down in flames in that case
due to kobj->sd being unset on device removal.
A driver shouldn't ever have to remove individual sysfs groups, the
driver core/bus logic should do it for them automatically.
And whenever a driver calls a sysfs_* call, that's a hint that something
is not working properly.
Do you mean that while the driver creates the groups and files explicitly
from it's different subsystems it should not explicitly remove each
one of them because all of them should be removed at once (and
recursively) when the device is being removed ?
Individual drivers should never add groups/files in sysfs, the driver
core should do it properly for you if you have everything set up
properly. And yes, the driver core will automatically remove them as
well.
Please use the default groups attribute for your bus/subsystem and this
will happen automagically.
Hi Greg, I tried your suggestion to hang amdgpu's sysfs
attributes on default attributes in struct device.groups but turns out it's
not usable since by the
time i have access to struct device from amdgpu code it has already been
initialized by pci core
(i.e. past the point where device_add->device_add_attrs->device_add_groups
with dev->groups is called)
and so i can't really use it.
That's odd, why can't you just set the groups pointer in your pci_driver
structure? That's what it is there for, right?
I am probably missing something but amdgpu sysfs attrs are per device not
per driver
Oops, you are right, you want the 'dev_groups' field. Looks like pci
doesn't export that directly, so you can do:
.driver {
.dev_groups = my_device_groups;
},
in your pci_driver structure.
Or I'm sure the PCI driver maintainer would take a patch like
7d9c1d2f7aca ("USB: add support for dev_groups to struct
usb_device_driver") was done for the USB subsystem, as diving into the
"raw" .driver pointer isn't really that clean or nice in my opinion.
Looks like what I need exactly. I will probably start with assigning raw pointer
just
to push ahead my work and in parallel will probably submit same patch as yours
for PCI subsystem review as the rework to switch to this is really minimal.
Andrey
thanks,
greg k-h
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
