From: hdegoede@redhat.com (Hans de Goede)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ohci-platform: Add support for controllers with big-endian regs / descriptors
Date: Tue, 21 Jan 2014 18:01:01 +0100 [thread overview]
Message-ID: <52DEA7CD.5070107@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1401211116370.1272-100000@iolanthe.rowland.org>
Hi,
On 01/21/2014 05:40 PM, Alan Stern wrote:
> On Tue, 21 Jan 2014, Hans de Goede wrote:
>
>> Note this commit uses the same devicetree booleans for this as the ones
>> already existing in the usb-ehci bindings.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -512,6 +512,10 @@ config USB_CNS3XXX_OHCI
>>
>> config USB_OHCI_HCD_PLATFORM
>> tristate "Generic OHCI driver for a platform device"
>> + # Always support LE, support BE on architectures which have readl_be
>> + select USB_OHCI_LITTLE_ENDIAN
>> + select USB_OHCI_BIG_ENDIAN_DESC if (AVR32 || MIPS || MICROBLAZE || SPARC || PPC32 || PPC64)
>> + select USB_OHCI_BIG_ENDIAN_MMIO if (AVR32 || MIPS || MICROBLAZE || SPARC || PPC32 || PPC64)
>> default n
>
> The comment line above is slightly misleading. USB_OHCI_LITTLE_ENDIAN
> doesn't exactly mean to include support for little-endian controllers;
> it means include mixed-endian support if either
> USB_OHCI_BIG_ENDIAN_DESC or USB_OHCI_BIG_ENDIAN_MMIO is set. That is,
> the driver determines at runtime whether a particular controller is
> big-endian or little-endian, rather than choosing to support one or the
> other at compile time.
Right I already knew that, that is what the "Always" tried to summarize.
> In any case, the style we have adopted is that these select lines go in
> the arch-specific defconfig, not here.
Ok, so I should drop the Kconfig parts of both patches ?
> For example, check out the
> occurrences of EHCI in arch/mips/Kconfig. Also, I'm not sure how you
> came up with that list of architectures for the two selects; it's hard
> to say if they are right. For instance, why did you include AVR32?
I included all archs which defines readl_be in asm/io.h
Regards,
Hans
next prev parent reply other threads:[~2014-01-21 17:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-21 15:48 [PATCH 1/2] ohci-platform: Add support for controllers with big-endian regs / descriptors Hans de Goede
2014-01-21 15:48 ` [PATCH 2/2] ehci-platform: " Hans de Goede
2014-01-21 19:39 ` Florian Fainelli
2014-01-22 19:28 ` Hans de Goede
2014-01-22 20:34 ` Jonas Gorski
2014-01-22 20:52 ` Hans de Goede
2014-01-22 21:02 ` Hans de Goede
2014-01-22 21:17 ` Alan Stern
2014-01-22 23:03 ` Jonas Gorski
2014-01-23 15:46 ` Alan Stern
2014-01-21 16:40 ` [PATCH 1/2] ohci-platform: " Alan Stern
2014-01-21 17:01 ` Hans de Goede [this message]
2014-01-21 18:09 ` Alan Stern
2014-01-21 19:48 ` Florian Fainelli
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=52DEA7CD.5070107@redhat.com \
--to=hdegoede@redhat.com \
--cc=linux-arm-kernel@lists.infradead.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 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).