linux-kernel.vger.kernel.org archive mirror
 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>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Kay Sievers <kay.sievers@vrfy.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Stephen Boyd <sboyd@codeaurora.org>
Subject: Re: [PATCH v3 03/11] drivers: base: add new class "cpu" to group cpu devices
Date: Thu, 21 Aug 2014 15:54:00 +0100	[thread overview]
Message-ID: <53F60808.10707@arm.com> (raw)
In-Reply-To: <CANq1E4S-PJvJeORnf-GZxHQZxPLOZ-R+hv9mu0w2g2O6zdfuVw@mail.gmail.com>



On 21/08/14 13:37, David Herrmann wrote:
> Hi
>
> On Thu, Aug 21, 2014 at 2:30 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 21/08/14 12:20, David Herrmann wrote:
>>> Why do we need a cpu-class if the same set of information is already
>>> available on the cpu-bus? Furthermore, classes are deprecated anyway.
>>> Everything you can do with a class can be solved with a bus. And we
>>> already have a bus for cpus.
>>>

Sorry I wasn't aware that classes are deprecated. IIUC its class_device
struct and related APIs that are deprecated not struct class. I may be
wrong but Greg would not have suggested to use class if it was deprecated.

>>
>> This was suggested[1] by GregKH. The main reason it was added is to
>> reuse the device attributes rather than creating the raw kobjects.
>>
>> It helps to move few other cpu related subsystems using raw kobjects to
>> the device attribute groups.
>
> So the only reason to add a class is to get attributes registered
> properly with the device? Just set dev->groups before calling
> device_add()? This works just fine on buses, too.
>

Do you mean to say create bus for each cpu and add cpu devices like
cache under that ? We can't reuse the cpu bus i.e cpu_subsys as we can't
add per-cpu devices with same name under /sys/bus/cpu/devices/

Also adding bus for each cpu device might be more complex than creating
cpu class.

That's the reason why I added checks to avoid creating link in the class
directory pointing to the device. It would be difficult to do
that with bus as it can't be unconditional.

Regards,
Sudeep



  reply	other threads:[~2014-08-21 14:53 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 [this message]
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
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=53F60808.10707@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.sievers@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;
as well as URLs for NNTP newsgroup(s).