All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	gregkh-l3A5Bk7waGM@public.gmane.org,
	linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH 1/2] serial: 8250: Add a notifier chain for driver registration.
Date: Thu, 17 Mar 2011 13:13:06 -0700	[thread overview]
Message-ID: <4D826B52.3060304@caviumnetworks.com> (raw)
In-Reply-To: <20110317193149.GD12824-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>

On 03/17/2011 12:31 PM, Grant Likely wrote:
> On Thu, Mar 17, 2011 at 07:24:41PM +0000, Alan Cox wrote:
>>>> If we did that, serial8250_probe() would automatically do the right thing.
>>>
>>> Take a look at the way arch/powerpc/platforms/512x/pdm360ng.c uses a
>>> notifier for amending a platform_device with additional data..
>>
>> I tend to view arch specific embedded code as rather like very dubious
>> parties. What goes on in other peoples' house out of sight is none of my
>> business.
>>
>> The 8250 however is core code so it should keep its clothers on and behave
>> in a manner befitting its status.
>>
>> What part of the problem can't be solved by doing it properly using the
>> device registration interfaces we have today ?
>
> Device registration isn't the problem.  The problem is supplying
> machine-specific callbacks from the board support code to the
> drivers.  When devices are sourced from a device tree, it is easy to
> get data about the device out of the tree, but it is really hard to
> get callback pointers.  To make it all work without this fiddling
> about, the octeon serial_{in,out} implementation would need to be
> rolled into of_serial.c (which FWIW, I have absolutely no problem
> with).
>

The only problem I have with that is that it ends up moving chip 
specific erratum workarounds into drivers/tty/serial instead of 
arch/mips/cavium-octeon.

I will think about this more.

David Daney

WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney@caviumnetworks.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-serial@vger.kernel.org, gregkh@suse.de,
	linux-kernel@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org
Subject: Re: [RFC PATCH 1/2] serial: 8250: Add a notifier chain for driver registration.
Date: Thu, 17 Mar 2011 13:13:06 -0700	[thread overview]
Message-ID: <4D826B52.3060304@caviumnetworks.com> (raw)
In-Reply-To: <20110317193149.GD12824@angua.secretlab.ca>

On 03/17/2011 12:31 PM, Grant Likely wrote:
> On Thu, Mar 17, 2011 at 07:24:41PM +0000, Alan Cox wrote:
>>>> If we did that, serial8250_probe() would automatically do the right thing.
>>>
>>> Take a look at the way arch/powerpc/platforms/512x/pdm360ng.c uses a
>>> notifier for amending a platform_device with additional data..
>>
>> I tend to view arch specific embedded code as rather like very dubious
>> parties. What goes on in other peoples' house out of sight is none of my
>> business.
>>
>> The 8250 however is core code so it should keep its clothers on and behave
>> in a manner befitting its status.
>>
>> What part of the problem can't be solved by doing it properly using the
>> device registration interfaces we have today ?
>
> Device registration isn't the problem.  The problem is supplying
> machine-specific callbacks from the board support code to the
> drivers.  When devices are sourced from a device tree, it is easy to
> get data about the device out of the tree, but it is really hard to
> get callback pointers.  To make it all work without this fiddling
> about, the octeon serial_{in,out} implementation would need to be
> rolled into of_serial.c (which FWIW, I have absolutely no problem
> with).
>

The only problem I have with that is that it ends up moving chip 
specific erratum workarounds into drivers/tty/serial instead of 
arch/mips/cavium-octeon.

I will think about this more.

David Daney

  parent reply	other threads:[~2011-03-17 20:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-17  1:26 [RFC PATCH 0/2] serial: Hack up 8520.c for evil device tree hookin David Daney
2011-03-17  1:26 ` David Daney
     [not found] ` <1300325167-26433-1-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2011-03-17  1:26   ` [RFC PATCH 1/2] serial: 8250: Add a notifier chain for driver registration David Daney
2011-03-17  1:26     ` David Daney
     [not found]     ` <1300325167-26433-2-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2011-03-17 12:18       ` Alan Cox
2011-03-17 12:18         ` Alan Cox
2011-03-17 16:42         ` David Daney
2011-03-17 18:25         ` Grant Likely
     [not found]           ` <20110317182510.GN9597-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2011-03-17 18:42             ` David Daney
2011-03-17 18:42               ` David Daney
2011-03-17 18:47               ` Grant Likely
     [not found]                 ` <20110317184723.GQ9597-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2011-03-17 19:24                   ` Alan Cox
2011-03-17 19:24                     ` Alan Cox
2011-03-17 19:31                     ` Grant Likely
     [not found]                       ` <20110317193149.GD12824-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2011-03-17 20:13                         ` David Daney [this message]
2011-03-17 20:13                           ` David Daney
2011-03-17 20:31                           ` Grant Likely
2011-03-17 23:48                         ` Alan Cox
2011-03-17 23:48                           ` Alan Cox
2011-03-18  5:18                           ` Grant Likely
2011-03-17  1:26   ` [RFC PATCH 2/2] MIPS: Octeon: Use device tree to register serial ports David Daney
2011-03-17  1:26     ` David Daney
2011-03-17 18:28     ` Grant Likely
2011-03-17 18:35       ` David Daney
2011-03-17  1:46 ` [RFC PATCH 0/2] serial: Hack up 8520.c for evil device tree hookin Alan Cox

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=4D826B52.3060304@caviumnetworks.com \
    --to=ddaney-m3mlkvoiwjvv6pq1l3v1odbpr1lh4cv8@public.gmane.org \
    --cc=alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
    --cc=gregkh-l3A5Bk7waGM@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.