On Thu, Aug 21, 2014 at 2:30 PM, Sudeep Holla <sudeep.ho...@arm.com> wrote: > On 21/08/14 12:20, David Herrmann wrote: >> On Thu, Aug 21, 2014 at 12:59 PM, Sudeep Holla <sudeep.ho...@arm.com> >> wrote: >>> >>> From: Sudeep Holla <sudeep.ho...@arm.com> >>> >>> This patch creates a new class called "cpu" and assigns it to all the >>> cpu devices. This helps in grouping all the cpu devices and associated >>> child devices under the same class. >>> >>> This patch also: >>> 1. modifies the get_parent_device to return the legacy path >>> (/sys/devices/system/cpu/..) for the cpu class devices to support >>> existing sysfs ABI >>> 2. avoids creating link in the class directory pointing to the device as >>> there would be per-cpu instance of these devices with the same name >>> 3. makes sure subsystem symlink continues pointing to cpu bus instead of >>> cpu class for cpu devices >> >> >> This patch lacks any explanation _why_ you add a class for CPUs. With >> this patch applied, these directories are effectively the same: >> /sys/bus/cpu/devices/ >> /sys/class/cpu/ >> > > Yes that's the intention, so that we don't break any existing sysfs/ABI > > >> 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. >> > > 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.
No, nothing should ever create a bus and a class with the same name. This is not supported by userspace tools. Your problem needs to be addressed by adding things to the existing "cpu" bus, not by adding a new class. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/