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] [day] [month] [year] [list]

Date:	Tue, 15 May 2012 17:13:04 +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 Tue, 2012-05-15 at 16:11 +0200, Samuel Iglesias Gonsálvez wrote:
[snip]
> 
> 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?

Thinking again about it, I think I don't win anything interesting
registering a new device in case of an ipack bus device.

It is just needed to establish the parent of the ipack device to the
"real" device of the bus (i.e, the PCI, USB device...), like the
aforementioned VME bridge in the drivers/staging/vme driver.

So, I will rewrite the patch keeping it simple: maintaining the change
in ipack_device_release function and ipack_device_register with some
little modifications. This is actually the important stuff.

And delaying the change in ipack_bus_register to whenever it is really
necessary, if it is.

Sorry for the inconveniences,

Sam

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)