mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Samuel Iglesias Gonsálvez" <siglesias@igalia.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] Staging: ipack: add proper device model into ipack_bus_register.
Date: Tue, 15 May 2012 17:13:04 +0200	[thread overview]
Message-ID: <1337094784.3472.69.camel@fourier.local.igalia.com> (raw)
In-Reply-To: <1337091098.3472.58.camel@fourier.local.igalia.com>

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2012-05-15 15:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-14 10:41 [PATCH 0/5] Staging ipack: device model and clean-up Samuel Iglesias Gonsalvez
2012-05-14 10:41 ` [PATCH 1/5] Staging ipack: fix a few sparse warnings Samuel Iglesias Gonsalvez
2012-05-14 12:26   ` Dan Carpenter
2012-05-14 12:53     ` Samuel Iglesias Gonsálvez
2012-05-14 10:41 ` [PATCH 2/5] Staging: ipack: add proper device model into ipack_bus_register Samuel Iglesias Gonsalvez
2012-05-14 20:46   ` Greg Kroah-Hartman
2012-05-15 14:11     ` Samuel Iglesias Gonsálvez
2012-05-15 15:13       ` Samuel Iglesias Gonsálvez [this message]
2012-05-14 10:41 ` [PATCH 3/5] Staging: ipack: remove board_name and bus_name fields from struct ipack_device Samuel Iglesias Gonsalvez
2012-05-14 10:41 ` [PATCH 4/5] Staging ipack/bridges/tpci200: remove TPCI200_SHORTNAME constant Samuel Iglesias Gonsalvez
2012-05-14 10:41 ` [PATCH 5/5] Staging: ipack/devices/ipoctal: check for availability of helper functions in ipoctal_match() Samuel Iglesias Gonsalvez

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=1337094784.3472.69.camel@fourier.local.igalia.com \
    --to=siglesias@igalia.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.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

Powered by JetHome