public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: dtor_core@ameritech.net, Pavel Machek <pavel@suse.cz>,
	rpurdie@rpsys.net, lenz@cs.wisc.edu,
	kernel list <linux-kernel@vger.kernel.org>,
	vojtech@suse.cz
Subject: Re: [patch 1/2] Touchscreen support for sharp sl-5500
Date: Mon, 25 Jul 2005 11:02:43 -0500	[thread overview]
Message-ID: <d120d50005072509022ccbdd0a@mail.gmail.com> (raw)
In-Reply-To: <20050725165014.B7629@flint.arm.linux.org.uk>

On 7/25/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote:
> > If the problem is that you have a single piece of hardware you need to
> > bind several drivers to - I guess you will have to create a new
> > sub-device bus for that. Or just register sub-devices on the same bus
> > the parent device is registered on - I am not sure what is best in
> > this particular case - I am not familiar with the arch.
> 
> That is exactly the problem - these kinds of devices do _not_ fit
> well into the device model.  A struct device for every different
> possible sub-unit is completely overkill.
> 
> For instance, you may logically use one ADC and some GPIO lines
> on the device for X and something else for Y and they logically
> end up in different drivers.
> 
> The problem is that the parent doesn't actually know how many
> devices to create nor what to call them, and they're logically
> indistinguishable from each other so there's no logical naming
> system.
> 

Then we should probably not try to force them into driver model. Have
parent device register struct device and when sub-drivers register
they could attach class devices (like input devices) directly to the
"main" device thus hiding presence of sub-sections of the chip from
sysfs completely. My point is that we should not be using
class_interface here - its purpose is diferent.

-- 
Dmitry

  reply	other threads:[~2005-07-25 16:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-22 18:01 [patch 1/2] Touchscreen support for sharp sl-5500 Pavel Machek
2005-07-24 16:47 ` Russell King
2005-07-24 17:01   ` Richard Purdie
2005-07-24 17:07   ` randy_dunlap
2005-07-25  4:56   ` Pavel Machek
2005-07-25 15:16     ` Dmitry Torokhov
2005-07-25 15:50       ` Russell King
2005-07-25 16:02         ` Dmitry Torokhov [this message]
2005-07-25 16:13           ` Russell King
2005-07-25 16:47             ` Dmitry Torokhov
2005-07-25 16:57               ` Russell King
2005-07-25 22:07             ` Pavel Machek
2005-07-25 21:39         ` Pavel Machek
2005-07-25 21:36       ` Pavel Machek
2005-07-25 16:04     ` Russell King
2005-07-25 22:06       ` Pavel Machek
2005-07-25 23:03         ` Russell King
2005-07-26  6:28           ` Pavel Machek

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=d120d50005072509022ccbdd0a@mail.gmail.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=dtor_core@ameritech.net \
    --cc=lenz@cs.wisc.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=rpurdie@rpsys.net \
    --cc=vojtech@suse.cz \
    /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