public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Stephen Boyd <sboyd@codeaurora.org>, Kay Sievers <kay@vrfy.org>
Subject: Re: [PATCH] drivers: base: add cpu_device_create to support per-cpu devices
Date: Fri, 22 Aug 2014 13:33:52 +0100	[thread overview]
Message-ID: <53F738B0.5080806@arm.com> (raw)
In-Reply-To: <CANq1E4Snx_n3XDWXU5PtmLtt31sRqnkKrSRsx2_b=i+6GTLnxw@mail.gmail.com>



On 22/08/14 12:41, David Herrmann wrote:
> Hi
>
> On Fri, Aug 22, 2014 at 1:37 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Hi
>>
>> On Fri, Aug 22, 2014 at 1:29 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> From: Sudeep Holla <sudeep.holla@arm.com>
>>>
>>> This patch adds a new function to create per-cpu devices.
>>> This helps in:
>>> 1. reusing the device infrastructure to create any cpu related
>>>     attributes and corresponding sysfs instead of creating and
>>>     dealing with raw kobjects directly
>>> 2. retaining the legacy path(/sys/devices/system/cpu/..) to support
>>>     existing sysfs ABI
>>> 3. avoiding to create links in the bus directory pointing to the
>>>     device as there would be per-cpu instance of these devices with
>>>     the same name since dev->bus is not populated to cpu_sysbus on
>>>     purpose
>>>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> ---
>>>   drivers/base/cpu.c  | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>   include/linux/cpu.h |  4 ++++
>>>   2 files changed, 58 insertions(+)
>>>
>>> Hi Greg,
>>>
>>> Here is the alternate solution I could come up with instead of
>>> creating cpu class. cpu_device_create is very similar to
>>> device_create_groups_vargs w/o class support, but I could not
>>> reuse anything else to avoid creating similar function.
>>>
>>> Let me know your thoughts/suggestions on this.
>>>
>>> Regards,
>>> Sudeep
>>>
>>>
>>> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
>>> index 277a9cfa9040..53f0c4141d05 100644
>>> --- a/drivers/base/cpu.c
>>> +++ b/drivers/base/cpu.c
>>> @@ -363,6 +363,60 @@ struct device *get_cpu_device(unsigned cpu)
>>>   }
>>>   EXPORT_SYMBOL_GPL(get_cpu_device);
>>>
>>> +static void device_create_release(struct device *dev)
>>> +{
>>> +       kfree(dev);
>>> +}
>>> +
>>> +static struct device *
>>> +__cpu_device_create(struct device *parent, void *drvdata,
>>> +                   const struct attribute_group **groups,
>>> +                   const char *fmt, va_list args)
>>> +{
>>> +       struct device *dev = NULL;
>>> +       int retval = -ENODEV;
>>> +
>>> +       dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>>> +       if (!dev) {
>>> +               retval = -ENOMEM;
>>> +               goto error;
>>> +       }
>>> +
>>> +       device_initialize(dev);
>>> +       dev->parent = parent;
>>> +       dev->groups = groups;
>>> +       dev->release = device_create_release;
>>> +       dev_set_drvdata(dev, drvdata);
>>> +
>>> +       retval = kobject_set_name_vargs(&dev->kobj, fmt, args);
>>> +       if (retval)
>>> +               goto error;
>>> +
>>> +       retval = device_add(dev);
>>> +       if (retval)
>>> +               goto error;
>>
>> Exactly! As I said, simply setting dev->groups before calling device_add().
>>
>> However, I really don't understand why we need this as global API.
>> Skimming over the other patches, you use cpu_device_create() only in
>> one place. Why not hard-code this all there? It is totally OK to do
>> device initialization in drivers. All the helpers (like
>> device_create(), device_create_with_groups(), and so on) are just
>> convenience functions. The driver-core API explicitly allows drivers
>> to initialize devices manually.
>>
>> Nevertheless, this patch looks fine.
>
> Wait, no. Why don't you set dev->bus to cpu_subsys? Is this thing
> supposed to create child-devices of CPUs? Can you describe what your
> topology is supposed to look like?
>

Yes, it's not done on purpose as mentioned in the commit log.
E.g.: cacheinfo topology will be as below

/sys/devices/system/cpu/cpuX/cache/index0/<attributes>
/sys/devices/system/cpu/cpuX/cache/index1/<attributes>
..
/sys/devices/system/cpu/cpuX/cache/index<Y/<attributes>

In this case 'cache' is cpuX's child and index<0..Y> are children of
cache in cpuX. The main problem with per-cpu device is that they have
same name for each cpu's instance and when the bus is set to this
devices, the driver model tries to create symlink to each of these
devices in /sys/bus/cpu/... which fails.

Regards,
Sudeep


  reply	other threads:[~2014-08-22 12:33 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25 17:30 [PATCH 0/9] drivers: cacheinfo support Sudeep Holla
2014-06-25 17:30 ` [PATCH 1/9] drivers: base: add new class "cpu" to group cpu devices Sudeep Holla
2014-06-25 17:30 ` [PATCH 2/9] drivers: base: support cpu cache information interface to userspace via sysfs Sudeep Holla
2014-06-25 22:23   ` Russell King - ARM Linux
2014-06-26 18:41     ` Sudeep Holla
2014-06-26 18:50       ` Russell King - ARM Linux
2014-06-26 19:03         ` Sudeep Holla
2014-07-10  0:09   ` Greg Kroah-Hartman
2014-07-10 13:37     ` Sudeep Holla
2014-06-25 17:30 ` [PATCH 3/9] ia64: move cacheinfo sysfs to generic cacheinfo infrastructure Sudeep Holla
2014-06-25 17:30 ` [PATCH 4/9] s390: " Sudeep Holla
2014-06-25 17:30 ` [PATCH 5/9] x86: " Sudeep Holla
2014-06-25 17:30 ` [PATCH 6/9] powerpc: " Sudeep Holla
2014-06-25 17:30 ` [PATCH 7/9] ARM64: kernel: add support for cpu cache information Sudeep Holla
2014-06-27 10:36   ` Mark Rutland
2014-06-27 11:22     ` Sudeep Holla
2014-06-27 11:34       ` Mark Rutland
2014-06-25 17:30 ` [PATCH 8/9] ARM: " Sudeep Holla
2014-06-25 22:33   ` Russell King - ARM Linux
2014-06-26 11:33     ` Sudeep Holla
2014-06-26  0:19   ` Stephen Boyd
2014-06-26 11:36     ` Sudeep Holla
2014-06-26 18:45       ` Stephen Boyd
2014-06-27  9:38         ` Sudeep Holla
2014-06-25 17:30 ` [PATCH 9/9] ARM: kernel: add outer cache support for cacheinfo implementation Sudeep Holla
2014-06-25 22:37   ` Russell King - ARM Linux
2014-06-26 13:02     ` Sudeep Holla
2014-07-25 16:44 ` [PATCH v2 0/9] drivers: cacheinfo support Sudeep Holla
2014-07-25 16:44   ` [PATCH v2 1/9] drivers: base: add new class "cpu" to group cpu devices Sudeep Holla
2014-07-25 19:09     ` Stephen Boyd
2014-07-28 13:37       ` Sudeep Holla
2014-07-25 16:44   ` [PATCH v2 2/9] drivers: base: support cpu cache information interface to userspace via sysfs Sudeep Holla
2014-07-29 23:09     ` Stephen Boyd
2014-07-30 16:23       ` Sudeep Holla
2014-07-31 19:46         ` Stephen Boyd
2014-08-05 18:15           ` Sudeep Holla
2014-07-25 16:44   ` [PATCH v2 3/9] ia64: move cacheinfo sysfs to generic cacheinfo infrastructure Sudeep Holla
2014-07-25 16:44   ` [PATCH v2 4/9] s390: " Sudeep Holla
2014-07-25 16:44   ` [PATCH v2 5/9] x86: " Sudeep Holla
2014-07-25 16:44   ` [PATCH v2 6/9] powerpc: " Sudeep Holla
2014-07-25 16:44   ` [PATCH v2 7/9] ARM64: kernel: add support for cpu cache information Sudeep Holla
2014-07-25 16:44   ` [PATCH v2 8/9] ARM: " Sudeep Holla
2014-07-25 16:44   ` [PATCH v2 9/9] ARM: kernel: add outer cache support for cacheinfo implementation Sudeep Holla
2014-08-21 10:59   ` [PATCH v3 00/11] drivers: cacheinfo support Sudeep Holla
2014-08-21 10:59     ` [PATCH v3 01/11] cpumask: factor out show_cpumap into separate helper function Sudeep Holla
2014-08-21 10:59     ` [PATCH v3 02/11] topology: replace custom attribute macros with standard DEVICE_ATTR* Sudeep Holla
2014-08-21 10:59     ` [PATCH v3 03/11] drivers: base: add new class "cpu" to group cpu devices Sudeep Holla
2014-08-21 11:20       ` David Herrmann
2014-08-21 12:30         ` Sudeep Holla
2014-08-21 12:37           ` David Herrmann
2014-08-21 14:54             ` Sudeep Holla
2014-08-22  9:12           ` Kay Sievers
2014-08-22 11:29             ` [PATCH] drivers: base: add cpu_device_create to support per-cpu devices Sudeep Holla
2014-08-22 11:37               ` David Herrmann
2014-08-22 11:41                 ` David Herrmann
2014-08-22 12:33                   ` Sudeep Holla [this message]
2014-08-26 16:54                     ` Sudeep Holla
2014-08-26 17:08                       ` David Herrmann
2014-08-22 12:17                 ` Sudeep Holla
2014-09-02 17:22               ` Sudeep Holla
2014-09-02 17:26                 ` Greg Kroah-Hartman
2014-09-02 17:40                   ` Sudeep Holla
2014-09-02 17:55                     ` Greg Kroah-Hartman
2014-08-21 10:59     ` [PATCH v3 04/11] drivers: base: support cpu cache information interface to userspace via sysfs Sudeep Holla
2014-08-21 10:59     ` [PATCH v3 05/11] ia64: move cacheinfo sysfs to generic cacheinfo infrastructure Sudeep Holla
2014-08-21 10:59     ` [PATCH v3 06/11] s390: " Sudeep Holla
2014-08-21 10:59     ` [PATCH v3 07/11] x86: " Sudeep Holla
2014-08-21 10:59     ` [PATCH v3 08/11] powerpc: " Sudeep Holla
2014-08-21 10:59     ` [PATCH v3 09/11] ARM64: kernel: add support for cpu cache information Sudeep Holla
2014-08-21 10:59     ` [PATCH v3 10/11] ARM: " Sudeep Holla
2014-08-21 10:59     ` [PATCH v3 11/11] ARM: kernel: add outer cache support for cacheinfo implementation Sudeep Holla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53F738B0.5080806@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=dh.herrmann@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kay@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sboyd@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox