All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
To: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Cc: me-uiRdBs8odbtmTBlB0Cgj/Q@public.gmane.org,
	Felipe Balbi
	<felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: drivers/usb/musb/musb_io.h
Date: Fri, 15 Aug 2008 12:53:08 +0100	[thread overview]
Message-ID: <20080815115308.GA24513@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20080815021131.dfab416a.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>

On Fri, Aug 15, 2008 at 02:11:31AM -0700, Andrew Morton wrote:
> On Fri, 15 Aug 2008 11:52:48 +0300 Felipe Balbi <me-uiRdBs8odbtmTBlB0Cgj/Q@public.gmane.org> wrote:
> 
> > Wonder if it's possible to have the above patch applied so I can get rid
> > of those stubs in musb_io.h
> 
> Someone would need to take care of it and document it and repair all
> those driver which broke because they went and created private copies.
> 
> I could do some of that but I'm stuck at step #1.  What the heck _are_
> these things?  Why do they exist?  What are their semantics?
> 
> The arm implementation says
> 
>  * Generic IO read/write.  These perform native-endian accesses.  Note
>  * that some architectures will want to re-define __raw_{read,write}w.
> 
> which is somewhat clear as mud.  I'd guess that these are the MMIO
> partners to insl and friends?

Yes.

> And then it has
> 
> extern void __raw_writesb(void __iomem *addr, const void *data, int bytelen);
> extern void __raw_writesw(void __iomem *addr, const void *data, int wordlen);
> extern void __raw_writesl(void __iomem *addr, const void *data, int longlen);
> 
> which is a bit odd.

Shrug.  Everything is not a PC.  I don't see anything odd about the above.

We basically implement a standard set of IO macros (the __raw_*) stuff
which is used to implement the standard set of IO support (inl, insl)
and provide a set of extensions for our platforms (readsl to complement
insl - named precisely the same way because that's what they are) because
the generic stuff doesn't cover all our needs.

> I assume that "bytelen" should have been "bytecount" or similar.

bytelen and bytecount mean the same thing to me.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Russell King <rmk@arm.linux.org.uk>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: me@felipebalbi.com, Felipe Balbi <felipe.balbi@nokia.com>,
	linux-usb@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: drivers/usb/musb/musb_io.h
Date: Fri, 15 Aug 2008 12:53:08 +0100	[thread overview]
Message-ID: <20080815115308.GA24513@flint.arm.linux.org.uk> (raw)
Message-ID: <20080815115308.3jLSC_wuJ4-DfY1WVXGMn3pbE-s4kZxK0Y3TxagG_fg@z> (raw)
In-Reply-To: <20080815021131.dfab416a.akpm@linux-foundation.org>

On Fri, Aug 15, 2008 at 02:11:31AM -0700, Andrew Morton wrote:
> On Fri, 15 Aug 2008 11:52:48 +0300 Felipe Balbi <me@felipebalbi.com> wrote:
> 
> > Wonder if it's possible to have the above patch applied so I can get rid
> > of those stubs in musb_io.h
> 
> Someone would need to take care of it and document it and repair all
> those driver which broke because they went and created private copies.
> 
> I could do some of that but I'm stuck at step #1.  What the heck _are_
> these things?  Why do they exist?  What are their semantics?
> 
> The arm implementation says
> 
>  * Generic IO read/write.  These perform native-endian accesses.  Note
>  * that some architectures will want to re-define __raw_{read,write}w.
> 
> which is somewhat clear as mud.  I'd guess that these are the MMIO
> partners to insl and friends?

Yes.

> And then it has
> 
> extern void __raw_writesb(void __iomem *addr, const void *data, int bytelen);
> extern void __raw_writesw(void __iomem *addr, const void *data, int wordlen);
> extern void __raw_writesl(void __iomem *addr, const void *data, int longlen);
> 
> which is a bit odd.

Shrug.  Everything is not a PC.  I don't see anything odd about the above.

We basically implement a standard set of IO macros (the __raw_*) stuff
which is used to implement the standard set of IO support (inl, insl)
and provide a set of extensions for our platforms (readsl to complement
insl - named precisely the same way because that's what they are) because
the generic stuff doesn't cover all our needs.

> I assume that "bytelen" should have been "bytecount" or similar.

bytelen and bytecount mean the same thing to me.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

  parent reply	other threads:[~2008-08-15 11:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080814215200.27f79a59.akpm@linux-foundation.org>
     [not found] ` <20080815073750.GG16231@frodo>
     [not found]   ` <20080815074318.GH16231@frodo>
     [not found]     ` <20080815010227.121e5e4b.akpm@linux-foundation.org>
     [not found]       ` <20080815081154.GJ16231@frodo>
2008-08-15  8:31         ` drivers/usb/musb/musb_io.h Andrew Morton
     [not found]           ` <20080815013148.b9dfc7ad.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2008-08-15  8:52             ` drivers/usb/musb/musb_io.h Felipe Balbi
2008-08-15  8:52               ` drivers/usb/musb/musb_io.h Felipe Balbi
2008-08-15  9:11               ` drivers/usb/musb/musb_io.h Andrew Morton
2008-08-15  9:11                 ` drivers/usb/musb/musb_io.h Andrew Morton
2008-08-15  9:23                 ` drivers/usb/musb/musb_io.h Felipe Balbi
     [not found]                 ` <20080815021131.dfab416a.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2008-08-15 11:53                   ` Russell King [this message]
2008-08-15 11:53                     ` drivers/usb/musb/musb_io.h Russell King
     [not found]                     ` <20080815115308.GA24513-f404yB8NqCZvn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2008-08-15 12:38                       ` drivers/usb/musb/musb_io.h Felipe Balbi
2008-08-15 12:38                         ` drivers/usb/musb/musb_io.h Felipe Balbi
2008-08-15 13:17                         ` drivers/usb/musb/musb_io.h Felipe Balbi
2008-08-15 13:17                           ` drivers/usb/musb/musb_io.h Felipe Balbi
2008-08-18  6:40                           ` drivers/usb/musb/musb_io.h Geert Uytterhoeven
2008-08-15 21:46                         ` drivers/usb/musb/musb_io.h David Brownell
2008-08-15 22:22                           ` drivers/usb/musb/musb_io.h Felipe Balbi
2008-08-16  1:53                             ` drivers/usb/musb/musb_io.h David Brownell
2008-08-16  1:53                               ` drivers/usb/musb/musb_io.h David Brownell
2008-08-16  2:05                               ` drivers/usb/musb/musb_io.h David Brownell
2008-08-16  9:29                                 ` drivers/usb/musb/musb_io.h Felipe Balbi

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=20080815115308.GA24513@flint.arm.linux.org.uk \
    --to=rmk-lfz/pmaqli7xmaaqvzeohq@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org \
    --cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=me-uiRdBs8odbtmTBlB0Cgj/Q@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.