All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
To: me-uiRdBs8odbtmTBlB0Cgj/Q@public.gmane.org
Cc: 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 02:11:31 -0700	[thread overview]
Message-ID: <20080815021131.dfab416a.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080815085247.GK16231@frodo>

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?

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.  I assume that "bytelen" should have been
"bytecount" or similar.


--
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: Andrew Morton <akpm@linux-foundation.org>
To: me@felipebalbi.com
Cc: 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 02:11:31 -0700	[thread overview]
Message-ID: <20080815021131.dfab416a.akpm@linux-foundation.org> (raw)
Message-ID: <20080815091131.lyVeeLzQHUwcJ5X0eVk5rdcPAF6UBlOOlYexPX4FcGM@z> (raw)
In-Reply-To: <20080815085247.GK16231@frodo>

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?

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.  I assume that "bytelen" should have been
"bytecount" or similar.



  reply	other threads:[~2008-08-15  9:11 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               ` Andrew Morton [this message]
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                   ` drivers/usb/musb/musb_io.h Russell King
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=20080815021131.dfab416a.akpm@linux-foundation.org \
    --to=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.