linux-kernel - Re: [PATCH 2/5] Staging: ipack: add proper device model into ipack_bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1337091098.3472.58.camel@fourier.local.igalia.com>
Date:	Tue, 15 May 2012 16:11:38 +0200
From:	Samuel Iglesias Gonsálvez 
	<siglesias@...lia.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] Staging: ipack: add proper device model into
 ipack_bus_register.

On Mon, 2012-05-14 at 13:46 -0700, Greg Kroah-Hartman wrote:
> On Mon, May 14, 2012 at 12:41:26PM +0200, Samuel Iglesias Gonsalvez wrote:
> > This patch adds a proper device model to the driver. The carrier boards are
> > managed like other ipack device, the way to recognize them is using the
> > platform data field from struct device.
> 
> Wait, what?  Why would you use the platform data field?  Why is that
> needed at all?  You can specify the "type" of the device, but it seems
> that you really want two different things here, busses and devices,
> right?  So use two different devices and manage them differently, don't
> make them the "same but different" by looking at the platform data
> field.  That's not what the platform data field is for at all, sorry.

I don't use platform_data to tell apart the devices from buses.
Although they don't have auto-discovery, the buses drivers do the
matching. I am not avoiding this step.

The "real" bus devices are already registered in PCI, USB, VME, etc, as
their interface with the rest of the system is through one of these
buses. The problem is to make a relation between a ipack bus device and
its driver, if we want it to be a registered device in ipack, as this
patch does.

Platform_data field is filled with the driver that the device belongs
to, facilitating the task.

There is a similar example in the VME bus with the devices that don't
support auto-discovery, as shown in drivers/staging/vme/vme.c in the
vme_bus_match() function.

Another option is what you say: use two different devices and manage
them differently. It will be needed to add new match/probe functions and
do similar stuff due to the lack of auto-discovery at this case.

A third option is use bus devices like VME bridges in the vme bus
driver, i.e, they are not devices, just an abstraction that provides
some functionality to the mezzanine devices.

I prefer the first option because it reuses the code of the probe/match
functions inside the ipack bus driver and it shows the hierarchy through
sysfs as everything is a registered device.

What do you think?

Sam

--
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/