linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 01:31:48 -0700	[thread overview]
Message-ID: <20080815013148.b9dfc7ad.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080815081154.GJ16231@frodo>

(cc linux-arch)

On Fri, 15 Aug 2008 11:11:55 +0300 Felipe Balbi <me@felipebalbi.com> wrote:

> On Fri, Aug 15, 2008 at 01:02:27AM -0700, Andrew Morton wrote:
> > > SH also defines read/write friends.
> > 
> > That's an unilluminating changelog.
> > What's actually going on in here?
> 
> Those functions are used for fifo reading/writing operations. Some
> architectures provide them and some don't. For those who don't, we add
> the definition to the driver.
> 
> > Why is a driver implementing what appear to be core architecture helper
> > functions?
> 
> Just because the core architecture doesn't provide them.
> 
> > What is a proper fix?
> 
> The proper fix is that we always have, at least, stubs for read/write
> friends even if the arch doesn't provide them.

That is absolutely not the proper fix.  Far from it.  This way we end
up with multiple (and of course, different) implementations of these
things in an arbitrary number of drivers.

A proper fix would be to a) define the semantics of these operations,
b) document them then c) implement them on each architecture.

One possible implementation might be


--- a/include/linux/io.h~a
+++ a/include/linux/io.h
@@ -67,4 +67,41 @@ int check_signature(const volatile void 
 			const unsigned char *signature, int length);
 void devm_ioremap_release(struct device *dev, void *res);
 
+#ifndef readsl
+
+/*
+ * description goes here
+ */
+static inline void readsl(const void __iomem *addr, void *buf, int len)
+{
+	insl((unsigned long)addr, buf, len);
+}
+
+static inline void readsw(const void __iomem *addr, void *buf, int len)
+{
+	insw((unsigned long)addr, buf, len);
+}
+
+static inline void readsb(const void __iomem *addr, void *buf, int len)
+{
+	insb((unsigned long)addr, buf, len);
+}
+
+static inline void writesl(const void __iomem *addr, const void *buf, int len)
+{
+	outsl((unsigned long)addr, buf, len);
+}
+
+static inline void writesw(const void __iomem *addr, const void *buf, int len)
+{
+	outsw((unsigned long)addr, buf, len);
+}
+
+static inline void writesb(const void __iomem *addr, const void *buf, int len)
+{
+	outsb((unsigned long)addr, buf, len);
+}
+
+#endif		/* readsl */
+
 #endif /* _LINUX_IO_H */


But just saying "oh look, the arch layer is all screwed up, let's hack
around it in our driver" is plain irresponsible.

> > avr32 and powerpc might also have conflicts.  Now, or in the future.

Did you review these architectures?

       reply	other threads:[~2008-08-15  8:31 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         ` Andrew Morton [this message]
     [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                   ` 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=20080815013148.b9dfc7ad.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=felipe.balbi@nokia.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=me@felipebalbi.com \
    /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;
as well as URLs for NNTP newsgroup(s).