[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1383635784.11383.2.camel@oc7383187364.ibm.com>
Date: Tue, 05 Nov 2013 08:16:24 +0100
From: Frank Haverkamp <haver@...ux.vnet.ibm.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, arnd@...db.de,
cody@...ux.vnet.ibm.com, schwidefsky@...ibm.com,
utz.bacher@...ibm.com, mmarek@...e.cz, rmallon@...il.com,
jsvogt@...ibm.com, MIJUNG@...ibm.com, cascardo@...ux.vnet.ibm.com,
michael@...ra.de, Frank Haverkamp <haver@...t.ibm.com>
Subject: Re: [PATCH] Generic WorkQueue Engine (GenWQE) device driver (v4)
Hi Greg,
Am Montag, den 04.11.2013, 14:15 -0800 schrieb Greg KH:
> > I am using sysfs_create_group() now, but do I understand you
> correctly
> > that setting the const struct attribute_group **groups; in my device
> > (where in my struct pci_device.dev?) is an even better way to
> establish
> > my sysfs attributes? Is there a function which I could call rather
> than
> > trying to find the right pointer?
>
> Ugh, this is still a problem, I'm trying to work through how to have
> individual drivers implement groups and sysfs files in a non-racy way.
> The issue is your device was announced to userspace _before_ it was
> bound to the driver, so there's no way to get the sysfs files to apply
> before then.
>
> You should just have the attributes on the sysfs device you create
> yourself, not your pci device, as that's where they make more sense,
> and
> there you should be able to use the attribute group easily, right?
>
The current version works well for me and I did not get any complaints
about the possible race-condition you mentioned so far. So I am happy.
> thanks,
>
> greg k-h
Greetings
Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists