devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>, Kevin Cernekee <cernekee@gmail.com>
Cc: tglx@linutronix.de, jason@lakedaemon.net, ralf@linux-mips.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	mbizon@freebox.fr, jogo@openwrt.org, linux-mips@linux-mips.org
Subject: Re: [PATCH 01/11] irqchip: Allow irq_reg_{readl,writel} to use __raw_{readl_writel}
Date: Wed, 29 Oct 2014 10:36:25 -0700	[thread overview]
Message-ID: <54512599.4080500@gmail.com> (raw)
In-Reply-To: <11255905.1JsQYcArO7@wuerfel>

On 10/29/2014 12:43 AM, Arnd Bergmann wrote:
> On Tuesday 28 October 2014 20:58:48 Kevin Cernekee wrote:
>>
>> +#ifdef CONFIG_RAW_IRQ_ACCESSORS
>> +
>> +#ifndef irq_reg_writel
>> +# define irq_reg_writel(val, addr)     __raw_writel(val, addr)
>> +#endif
>> +#ifndef irq_reg_readl
>> +# define irq_reg_readl(addr)           __raw_readl(addr)
>> +#endif
>> +
>> +#else
>> +
> 
> No, this is just wrong: registers almost always have a fixed endianess
> indenpent of CPU endianess, so if you use __raw_writel, it will be
> broken on one or the other.

Our brcmstb platforms had an endian strap settings for MIPS-based
platforms, and for most peripherals this would be just completely
transparent, as the HW always will do the internal swapping, such that
host CPU does read/writes in its native endianess regardless of the
actual strap settings.

AFAICT bcm3384, a MIPS-based Cable Modem platform has only one endianess
setting: BE, and the HW only supports that specific endianess.

> 
> If you have a machine that uses big-endian registers in the interrupt
> controller, you need to find a way to use the correct accessors
> (e.g. iowrite32be) and use them independent of what endianess the CPU
> is running.
> 
> As this code is being used on all sorts of platforms, you can't assume
> that they all use the same endianess, which makes it rather tricky.

I think the more general problem with the use of readl_*() I/O accessors
is that they just happen to work fine on most platforms out there: ARM
Little-endian, because this nicely matches the endianess expected by the
HW and that does not enforce an audit of whether your actual peripheral
expects little-endian writes to be done.

The other problem is that readl() on ARM implies a barrier, which is not
necesarily true/necessary for some other platforms such as some MIPS
processors.

> 
> As the first step, you can probably introduce a new Kconfig symbol
> GENERIC_IRQ_CHIP_BE, and then make that mutually exclusive with the
> existing users that all use little-endian registers:
> 
> #if defined(CONFIG_GENERIC_IRQ_CHIP) && !defined(CONFIG_GENERIC_IRQ_CHIP_BE)
> #define irq_reg_writel(val, addr)     writel(val, addr)
> #else if defined(CONFIG_GENERIC_IRQ_CHIP_BE) && !defined(CONFIG_GENERIC_IRQ_CHIP)
> #define irq_reg_writel(val, addr)     iowrite32be(val, addr)
> #else
> /* provoke a compile error when this is used */
> #define irq_reg_writel(val, addr)	irq_reg_writel_unknown_endian(val, addr)
> #endif
> 
> and
> 
> --- a/kernel/irq/Makefile
> +++ b/kernel/irq/Makefile
> @@ -1,5 +1,6 @@
>  
>  obj-y := irqdesc.o handle.o manage.o spurious.o resend.o chip.o dummychip.o devres.o
> +obj-$(CONFIG_GENERIC_IRQ_CHIP_BE) += generic-chip.o
>  obj-$(CONFIG_GENERIC_IRQ_CHIP) += generic-chip.o
>  obj-$(CONFIG_GENERIC_IRQ_PROBE) += autoprobe.o
>  obj-$(CONFIG_IRQ_DOMAIN) += irqdomain.o
> 
> Note that you might also have a case where you have more than
> one generic irqchip driver built into the kernel, which require
> different endianess. We can't really support that case without
> changing the generic-chip implementation.
> 
> 	Arnd
> 

  reply	other threads:[~2014-10-29 17:36 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-29  3:58 [PATCH 01/11] irqchip: Allow irq_reg_{readl,writel} to use __raw_{readl_writel} Kevin Cernekee
2014-10-29  3:58 ` [PATCH 02/11] irqchip: brcmstb-l2: Eliminate dependency on ARM code Kevin Cernekee
     [not found]   ` <1414555138-6500-2-git-send-email-cernekee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-10-29  7:29     ` Arnd Bergmann
2014-10-29 16:53   ` Florian Fainelli
2014-10-29  3:58 ` [PATCH 03/11] irqchip: bcm7120-l2: Eliminate bad IRQ check Kevin Cernekee
2014-10-29 16:53   ` Florian Fainelli
2014-10-29  3:58 ` [PATCH 04/11] irqchip: Remove ARM dependency for bcm7120-l2 and brcmstb-l2 Kevin Cernekee
2014-10-29  7:44   ` Arnd Bergmann
2014-10-29 16:53   ` Florian Fainelli
2014-10-29  3:58 ` [PATCH 05/11] irqchip: bcm7120-l2: Make sure all register accesses use base+offset Kevin Cernekee
2014-10-29  7:46   ` Arnd Bergmann
2014-10-29  7:56     ` Arnd Bergmann
2014-10-29 16:53   ` Florian Fainelli
2014-10-29  3:58 ` [PATCH 06/11] irqchip: bcm7120-l2: Use irq_reg_* accessors Kevin Cernekee
2014-10-29  7:46   ` Arnd Bergmann
2014-10-29 16:54   ` Florian Fainelli
2014-10-29  3:58 ` [PATCH 07/11] irqchip: brcmstb-l2: " Kevin Cernekee
     [not found]   ` <1414555138-6500-7-git-send-email-cernekee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-10-29  7:46     ` Arnd Bergmann
2014-10-29 16:54   ` Florian Fainelli
2014-10-29  3:58 ` [PATCH 08/11] irqchip: bcm7120-l2: Fix missing nibble in gc->unused mask Kevin Cernekee
2014-10-29  7:47   ` Arnd Bergmann
2014-10-29 16:55   ` Florian Fainelli
2014-10-29  3:58 ` [PATCH 09/11] irqchip: bcm7120-l2: Use gc->mask_cache to simplify suspend/resume functions Kevin Cernekee
     [not found]   ` <1414555138-6500-9-git-send-email-cernekee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-10-29 16:55     ` Florian Fainelli
2014-10-29  3:58 ` [PATCH 10/11] irqchip: bcm7120-l2: Extend driver to support 64+ bit controllers Kevin Cernekee
2014-10-29  7:53   ` Arnd Bergmann
2014-10-29 23:22     ` Kevin Cernekee
2014-10-30  9:10       ` Arnd Bergmann
2014-10-29  3:58 ` [PATCH 11/11] irqchip: Decouple bcm7120-l2 from brcmstb-l2 Kevin Cernekee
2014-10-29  7:55   ` Arnd Bergmann
2014-10-29 16:56   ` Florian Fainelli
2014-10-29  7:43 ` [PATCH 01/11] irqchip: Allow irq_reg_{readl,writel} to use __raw_{readl_writel} Arnd Bergmann
2014-10-29 17:36   ` Florian Fainelli [this message]
     [not found]     ` <54512599.4080500-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-10-29 19:14       ` Arnd Bergmann
2014-10-29 18:48   ` Kevin Cernekee
2014-10-29 19:10     ` Thomas Gleixner
2014-10-29 19:14     ` Arnd Bergmann
2014-10-29 20:09       ` Kevin Cernekee
2014-10-29 21:13         ` Arnd Bergmann
2014-10-29 21:31           ` Thomas Gleixner
2014-10-29 21:41             ` Arnd Bergmann
2014-10-29 21:50               ` Thomas Gleixner
2014-10-29 23:05           ` Kevin Cernekee
2014-10-30  9:58             ` Arnd Bergmann
2014-10-30 19:03               ` Kevin Cernekee
2014-10-30 19:52                 ` Arnd Bergmann
2014-10-30 20:54                   ` Kevin Cernekee
     [not found]                     ` <CAJiQ=7C+r80Jt51NXLCk-0D2nRezBfMN9pGBVT9V8ncefGhBnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-30 21:18                       ` Arnd Bergmann
2014-10-29 10:12 ` Thomas Gleixner

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=54512599.4080500@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=arnd@arndb.de \
    --cc=cernekee@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jason@lakedaemon.net \
    --cc=jogo@openwrt.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=mbizon@freebox.fr \
    --cc=ralf@linux-mips.org \
    --cc=tglx@linutronix.de \
    /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).