All of lore.kernel.org
 help / color / mirror / Atom feed
From: yanok@emcraft.com (Ilya Yanok)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers?
Date: Fri, 06 May 2011 03:41:29 +0400	[thread overview]
Message-ID: <4DC335A9.6000709@emcraft.com> (raw)
In-Reply-To: <20110425052512.GB484@kurt.e-circ.dyndns.org>

Hello Kurt,

On 25.04.2011 09:25, Kurt Van Dijck wrote:
>> So, to add both input and hwmon drivers we need to serialize the
>> register accesses.
> 
> 1 physical device may contain several 'class_device's, even if they're of
> different types.  So in a single platform_device probe function, you can do
> both 'input_register_device' and 'hwmon_register_device'.
> This way of working actually puts 2 drivers in 1 file, and let those
> share 1 lock (mutex or so). A peripheral with 2 functions mixed together
> should IMHO be addressed this way. Your driver is the coupling
> between hardware (mixed functions) and Linux device model (clean seperation).

Yes, I know this is possible. Still, I think it's not desired. I should
ask my customer...
My concern is pushing these changes upstream. Is such two-in-one driver
going to be easily accepted?

Anyway, thanks for the idea.

>> I was thinking about adding some middle-layer to
>> perform the actual conversion. The question is what is the preferred way
>> to add such a middle layer?
> 
> IMHO a middle layer for this type of problem is a bit overkill.

Still I can see that at least S3C does this.

>> Should we use a multi-function device driver
>> for this or just some platform-specific code (as S3C does)? Or maybe
>> there is another way?
> 
> AFAIK MFD is a solution when multiple devices have sequential register maps.
> MFD does no locking.

Well, yes. MFD was just another idea where to put custom API piece...

Thanks!

Regards, Ilya.

  reply	other threads:[~2011-05-05 23:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-25  0:37 [RFC] What is the preferred way to share ADC unit between hwmon and input(ts) drivers? Ilya Yanok
2011-04-25  5:25 ` Kurt Van Dijck
2011-05-05 23:41   ` Ilya Yanok [this message]
2011-04-25 11:02 ` Mark Brown
2011-05-05 23:43   ` Ilya Yanok
2011-05-06 13:43   ` Jonathan Cameron
2011-05-06 14:13     ` Ithamar R. Adema
2011-05-06 14:23       ` Mark Brown
2011-05-06 15:15         ` Jonathan Cameron
2011-05-06 15:56           ` Mark Brown
2011-05-06 16:29             ` Jonathan Cameron
2011-05-06 17:20               ` Mark Brown
2011-05-09 13:25                 ` Jonathan Cameron
2011-05-09 14:39                   ` Mark Brown
2011-05-09 16:35                     ` Jonathan Cameron
2011-05-09 16:35                       ` Jonathan Cameron
2011-05-09 19:54                       ` Mark Brown
2011-05-09 19:54                         ` Mark Brown
2011-05-10  9:51                         ` Jonathan Cameron
2011-05-10  9:51                           ` Jonathan Cameron
2011-05-06 15:21         ` Ithamar R. Adema
2011-05-07 18:11 ` Linus Walleij

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=4DC335A9.6000709@emcraft.com \
    --to=yanok@emcraft.com \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.