| Message ID | 1486758216-23140-1-git-send-email-abrodkin@synopsys.com |
|---|---|
| State | Accepted, archived |
| Commit | 9000eddbae0d292331ef403b0a1ff7ec7a983a79 |
| Delegated to: | Marek Vasut |
| Headers | show |
On 02/10/2017 09:23 PM, Alexey Brodkin wrote: > Current implementation doesn't allow utilization of platform-specific > reads and writes. > > But some arches or platforms may want to use their accessors that do > some extra work like adding barriers for data serialization etc. > > Interesting enough OHCI accessors already do that so just aligning > EHCI to it now. > > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> > Cc: Marek Vasut <marex@denx.de> > Cc: Simon Glass <sjg@chromium.org> > Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> IMO looks OK, Acked-by: Marek Vasut <marex@denx.de> I'd like to have a few more reviews of this before applying it for 2017.05 . Also CCing Wills, it'd be great to get a test on atheros MIPS . Thanks! > --- > drivers/usb/host/ehci.h | 10 ++++------ > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h > index 734d7f036278..2ab830df5155 100644 > --- a/drivers/usb/host/ehci.h > +++ b/drivers/usb/host/ehci.h > @@ -102,13 +102,11 @@ struct usb_linux_config_descriptor { > } __attribute__ ((packed)); > > #if defined CONFIG_EHCI_DESC_BIG_ENDIAN > -#define ehci_readl(x) cpu_to_be32((*((volatile u32 *)(x)))) > -#define ehci_writel(a, b) (*((volatile u32 *)(a)) = \ > - cpu_to_be32(((volatile u32)b))) > +#define ehci_readl(x) cpu_to_be32(readl(x)) > +#define ehci_writel(a, b) writel(cpu_to_be32(b), a) > #else > -#define ehci_readl(x) cpu_to_le32((*((volatile u32 *)(x)))) > -#define ehci_writel(a, b) (*((volatile u32 *)(a)) = \ > - cpu_to_le32(((volatile u32)b))) > +#define ehci_readl(x) cpu_to_le32(readl(x)) > +#define ehci_writel(a, b) writel(cpu_to_le32(b), a) > #endif > > #if defined CONFIG_EHCI_MMIO_BIG_ENDIAN >
Hi Marek, On Fri, 2017-02-10 at 21:33 +0100, Marek Vasut wrote: > On 02/10/2017 09:23 PM, Alexey Brodkin wrote: > > > > Current implementation doesn't allow utilization of platform-specific > > reads and writes. > > > > But some arches or platforms may want to use their accessors that do > > some extra work like adding barriers for data serialization etc. > > > > Interesting enough OHCI accessors already do that so just aligning > > EHCI to it now. > > > > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> > > Cc: Marek Vasut <marex@denx.de> > > Cc: Simon Glass <sjg@chromium.org> > > Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> > > IMO looks OK, > > Acked-by: Marek Vasut <marex@denx.de> > > I'd like to have a few more reviews of this before applying it for > 2017.05 . Also CCing Wills, it'd be great to get a test on atheros > MIPS . It's been quite some time since your request to try the patch on other systems and so far nobody answered. May we consider that one for application then? Essentially I'm not talking about current Tom's master branch but would be good if the patch lands somewhere and once 2017.03 gets cut is merged in the main branch? -Alexey
On 03/01/2017 01:52 PM, Alexey Brodkin wrote: > Hi Marek, > > On Fri, 2017-02-10 at 21:33 +0100, Marek Vasut wrote: >> On 02/10/2017 09:23 PM, Alexey Brodkin wrote: >>> >>> Current implementation doesn't allow utilization of platform-specific >>> reads and writes. >>> >>> But some arches or platforms may want to use their accessors that do >>> some extra work like adding barriers for data serialization etc. >>> >>> Interesting enough OHCI accessors already do that so just aligning >>> EHCI to it now. >>> >>> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> >>> Cc: Marek Vasut <marex@denx.de> >>> Cc: Simon Glass <sjg@chromium.org> >>> Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> >> >> IMO looks OK, >> >> Acked-by: Marek Vasut <marex@denx.de> >> >> I'd like to have a few more reviews of this before applying it for >> 2017.05 . Also CCing Wills, it'd be great to get a test on atheros >> MIPS . > > It's been quite some time since your request to try the patch > on other systems and so far nobody answered. May we consider that > one for application then? > > Essentially I'm not talking about current Tom's master branch > but would be good if the patch lands somewhere and once 2017.03 > gets cut is merged in the main branch? Yeah, it's not happening for 2017.03, it'll go into the next one. Can you just rebase and repost the patch please ? I'll get to it next week, I'm traveling until the 10th. > -Alexey >
Hi Marek, On Fri, 2017-03-03 at 00:57 +0100, Marek Vasut wrote: > On 03/01/2017 01:52 PM, Alexey Brodkin wrote: > > > > Hi Marek, > > > > On Fri, 2017-02-10 at 21:33 +0100, Marek Vasut wrote: > > > > > > On 02/10/2017 09:23 PM, Alexey Brodkin wrote: > > > > > > > > > > > > Current implementation doesn't allow utilization of platform-specific > > > > reads and writes. > > > > > > > > But some arches or platforms may want to use their accessors that do > > > > some extra work like adding barriers for data serialization etc. > > > > > > > > Interesting enough OHCI accessors already do that so just aligning > > > > EHCI to it now. > > > > > > > > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> > > > > Cc: Marek Vasut <marex@denx.de> > > > > Cc: Simon Glass <sjg@chromium.org> > > > > Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> > > > > > > IMO looks OK, > > > > > > Acked-by: Marek Vasut <marex@denx.de> > > > > > > I'd like to have a few more reviews of this before applying it for > > > 2017.05 . Also CCing Wills, it'd be great to get a test on atheros > > > MIPS . > > > > It's been quite some time since your request to try the patch > > on other systems and so far nobody answered. May we consider that > > one for application then? > > > > Essentially I'm not talking about current Tom's master branch > > but would be good if the patch lands somewhere and once 2017.03 > > gets cut is merged in the main branch? > > Yeah, it's not happening for 2017.03, it'll go into the next one. > > Can you just rebase and repost the patch please ? I'll get to it next > week, I'm traveling until the 10th. I just tried and the same .mbox applies cleanly on top of today's U-Boot master so I believe there's no point in resending it. Are you OK to just grab existing one? -Alexey
On 03/03/2017 02:22 PM, Alexey Brodkin wrote: > Hi Marek, > > On Fri, 2017-03-03 at 00:57 +0100, Marek Vasut wrote: >> On 03/01/2017 01:52 PM, Alexey Brodkin wrote: >>> >>> Hi Marek, >>> >>> On Fri, 2017-02-10 at 21:33 +0100, Marek Vasut wrote: >>>> >>>> On 02/10/2017 09:23 PM, Alexey Brodkin wrote: >>>>> >>>>> >>>>> Current implementation doesn't allow utilization of platform-specific >>>>> reads and writes. >>>>> >>>>> But some arches or platforms may want to use their accessors that do >>>>> some extra work like adding barriers for data serialization etc. >>>>> >>>>> Interesting enough OHCI accessors already do that so just aligning >>>>> EHCI to it now. >>>>> >>>>> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> >>>>> Cc: Marek Vasut <marex@denx.de> >>>>> Cc: Simon Glass <sjg@chromium.org> >>>>> Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> >>>> >>>> IMO looks OK, >>>> >>>> Acked-by: Marek Vasut <marex@denx.de> >>>> >>>> I'd like to have a few more reviews of this before applying it for >>>> 2017.05 . Also CCing Wills, it'd be great to get a test on atheros >>>> MIPS . >>> >>> It's been quite some time since your request to try the patch >>> on other systems and so far nobody answered. May we consider that >>> one for application then? >>> >>> Essentially I'm not talking about current Tom's master branch >>> but would be good if the patch lands somewhere and once 2017.03 >>> gets cut is merged in the main branch? >> >> Yeah, it's not happening for 2017.03, it'll go into the next one. >> >> Can you just rebase and repost the patch please ? I'll get to it next >> week, I'm traveling until the 10th. > > I just tried and the same .mbox applies cleanly on top of today's > U-Boot master so I believe there's no point in resending it. > > Are you OK to just grab existing one? I no longer have the patch in my mailbox, which is why I asked you to resend it. Moreover, did you just test that it applies or did you actually build-test and retest the patch on real hardware too ?
Hi Marek, On Sun, 2017-03-05 at 02:09 +0100, Marek Vasut wrote: > On 03/03/2017 02:22 PM, Alexey Brodkin wrote: > > > > Hi Marek, > > > > On Fri, 2017-03-03 at 00:57 +0100, Marek Vasut wrote: > > > > > > On 03/01/2017 01:52 PM, Alexey Brodkin wrote: > > > > > > > > > > > > Hi Marek, > > > > > > > > On Fri, 2017-02-10 at 21:33 +0100, Marek Vasut wrote: > > > > > > > > > > > > > > > On 02/10/2017 09:23 PM, Alexey Brodkin wrote: > > > > > > > > > > > > > > > > > > > > > > > > Current implementation doesn't allow utilization of platform-specific > > > > > > reads and writes. > > > > > > > > > > > > But some arches or platforms may want to use their accessors that do > > > > > > some extra work like adding barriers for data serialization etc. > > > > > > > > > > > > Interesting enough OHCI accessors already do that so just aligning > > > > > > EHCI to it now. > > > > > > > > > > > > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> > > > > > > Cc: Marek Vasut <marex@denx.de> > > > > > > Cc: Simon Glass <sjg@chromium.org> > > > > > > Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> > > > > > > > > > > IMO looks OK, > > > > > > > > > > Acked-by: Marek Vasut <marex@denx.de> > > > > > > > > > > I'd like to have a few more reviews of this before applying it for > > > > > 2017.05 . Also CCing Wills, it'd be great to get a test on atheros > > > > > MIPS . > > > > > > > > It's been quite some time since your request to try the patch > > > > on other systems and so far nobody answered. May we consider that > > > > one for application then? > > > > > > > > Essentially I'm not talking about current Tom's master branch > > > > but would be good if the patch lands somewhere and once 2017.03 > > > > gets cut is merged in the main branch? > > > > > > Yeah, it's not happening for 2017.03, it'll go into the next one. > > > > > > Can you just rebase and repost the patch please ? I'll get to it next > > > week, I'm traveling until the 10th. > > > > I just tried and the same .mbox applies cleanly on top of today's > > U-Boot master so I believe there's no point in resending it. > > > > Are you OK to just grab existing one? > > I no longer have the patch in my mailbox, which is why I asked you to > resend it. Moreover, did you just test that it applies or did you > actually build-test and retest the patch on real hardware too ? I did test it on my boards again on top of today's master branch and everything seem to work perfectly fine so please consider applying this one. You may use mbox from here http://patchwork.ozlabs.org/patch/726714/mbox/ Al least it worked for me this way: --------------------->8----------------------- curl http://patchwork.ozlabs.org/patch/726714/mbox/ | git am --------------------->8----------------------- Regards, Alexey
On 03/24/2017 12:08 PM, Alexey Brodkin wrote: > Hi Marek, > > On Sun, 2017-03-05 at 02:09 +0100, Marek Vasut wrote: >> On 03/03/2017 02:22 PM, Alexey Brodkin wrote: >>> >>> Hi Marek, >>> >>> On Fri, 2017-03-03 at 00:57 +0100, Marek Vasut wrote: >>>> >>>> On 03/01/2017 01:52 PM, Alexey Brodkin wrote: >>>>> >>>>> >>>>> Hi Marek, >>>>> >>>>> On Fri, 2017-02-10 at 21:33 +0100, Marek Vasut wrote: >>>>>> >>>>>> >>>>>> On 02/10/2017 09:23 PM, Alexey Brodkin wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Current implementation doesn't allow utilization of platform-specific >>>>>>> reads and writes. >>>>>>> >>>>>>> But some arches or platforms may want to use their accessors that do >>>>>>> some extra work like adding barriers for data serialization etc. >>>>>>> >>>>>>> Interesting enough OHCI accessors already do that so just aligning >>>>>>> EHCI to it now. >>>>>>> >>>>>>> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> >>>>>>> Cc: Marek Vasut <marex@denx.de> >>>>>>> Cc: Simon Glass <sjg@chromium.org> >>>>>>> Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> >>>>>> >>>>>> IMO looks OK, >>>>>> >>>>>> Acked-by: Marek Vasut <marex@denx.de> >>>>>> >>>>>> I'd like to have a few more reviews of this before applying it for >>>>>> 2017.05 . Also CCing Wills, it'd be great to get a test on atheros >>>>>> MIPS . >>>>> >>>>> It's been quite some time since your request to try the patch >>>>> on other systems and so far nobody answered. May we consider that >>>>> one for application then? >>>>> >>>>> Essentially I'm not talking about current Tom's master branch >>>>> but would be good if the patch lands somewhere and once 2017.03 >>>>> gets cut is merged in the main branch? >>>> >>>> Yeah, it's not happening for 2017.03, it'll go into the next one. >>>> >>>> Can you just rebase and repost the patch please ? I'll get to it next >>>> week, I'm traveling until the 10th. >>> >>> I just tried and the same .mbox applies cleanly on top of today's >>> U-Boot master so I believe there's no point in resending it. >>> >>> Are you OK to just grab existing one? >> >> I no longer have the patch in my mailbox, which is why I asked you to >> resend it. Moreover, did you just test that it applies or did you >> actually build-test and retest the patch on real hardware too ? > > I did test it on my boards again on top of today's master branch and > everything seem to work perfectly fine so please consider applying this one. > > You may use mbox from here http://patchwork.ozlabs.org/patch/726714/mbox/ > Al least it worked for me this way: > --------------------->8----------------------- > curl http://patchwork.ozlabs.org/patch/726714/mbox/ | git am > --------------------->8----------------------- Thank you for NOT resending the patch and making my life harder. Applied.
On 03/24/2017 01:56 PM, Marek Vasut wrote: > On 03/24/2017 12:08 PM, Alexey Brodkin wrote: >> Hi Marek, >> >> On Sun, 2017-03-05 at 02:09 +0100, Marek Vasut wrote: >>> On 03/03/2017 02:22 PM, Alexey Brodkin wrote: >>>> >>>> Hi Marek, >>>> >>>> On Fri, 2017-03-03 at 00:57 +0100, Marek Vasut wrote: >>>>> >>>>> On 03/01/2017 01:52 PM, Alexey Brodkin wrote: >>>>>> >>>>>> >>>>>> Hi Marek, >>>>>> >>>>>> On Fri, 2017-02-10 at 21:33 +0100, Marek Vasut wrote: >>>>>>> >>>>>>> >>>>>>> On 02/10/2017 09:23 PM, Alexey Brodkin wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Current implementation doesn't allow utilization of platform-specific >>>>>>>> reads and writes. >>>>>>>> >>>>>>>> But some arches or platforms may want to use their accessors that do >>>>>>>> some extra work like adding barriers for data serialization etc. >>>>>>>> >>>>>>>> Interesting enough OHCI accessors already do that so just aligning >>>>>>>> EHCI to it now. >>>>>>>> >>>>>>>> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> >>>>>>>> Cc: Marek Vasut <marex@denx.de> >>>>>>>> Cc: Simon Glass <sjg@chromium.org> >>>>>>>> Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> >>>>>>> >>>>>>> IMO looks OK, >>>>>>> >>>>>>> Acked-by: Marek Vasut <marex@denx.de> >>>>>>> >>>>>>> I'd like to have a few more reviews of this before applying it for >>>>>>> 2017.05 . Also CCing Wills, it'd be great to get a test on atheros >>>>>>> MIPS . >>>>>> >>>>>> It's been quite some time since your request to try the patch >>>>>> on other systems and so far nobody answered. May we consider that >>>>>> one for application then? >>>>>> >>>>>> Essentially I'm not talking about current Tom's master branch >>>>>> but would be good if the patch lands somewhere and once 2017.03 >>>>>> gets cut is merged in the main branch? >>>>> >>>>> Yeah, it's not happening for 2017.03, it'll go into the next one. >>>>> >>>>> Can you just rebase and repost the patch please ? I'll get to it next >>>>> week, I'm traveling until the 10th. >>>> >>>> I just tried and the same .mbox applies cleanly on top of today's >>>> U-Boot master so I believe there's no point in resending it. >>>> >>>> Are you OK to just grab existing one? >>> >>> I no longer have the patch in my mailbox, which is why I asked you to >>> resend it. Moreover, did you just test that it applies or did you >>> actually build-test and retest the patch on real hardware too ? >> >> I did test it on my boards again on top of today's master branch and >> everything seem to work perfectly fine so please consider applying this one. >> >> You may use mbox from here http://patchwork.ozlabs.org/patch/726714/mbox/ >> Al least it worked for me this way: >> --------------------->8----------------------- >> curl http://patchwork.ozlabs.org/patch/726714/mbox/ | git am >> --------------------->8----------------------- > > Thank you for NOT resending the patch and making my life harder. Applied. > Even better, this patch breaks powerpc board lwmon5, so dropped.
Hi Marek, On Fri, 2017-04-14 at 16:44 +0200, Marek Vasut wrote: > On 03/24/2017 01:56 PM, Marek Vasut wrote: > > > Even better, this patch breaks powerpc board lwmon5, so dropped. Are you sure the problem is in my patch? Maybe this PPC board just needs to UNdefine CONFIG_EHCI_DESC_BIG_ENDIAN or there's a problem in its either cpu_to_XXX() or readl()/writel()? Stefan, could you please look at what's wrong here if you have the board handy? -Alexey
On 04/14/2017 07:16 PM, Alexey Brodkin wrote: > Hi Marek, Hi, > On Fri, 2017-04-14 at 16:44 +0200, Marek Vasut wrote: >> On 03/24/2017 01:56 PM, Marek Vasut wrote: >>> >> Even better, this patch breaks powerpc board lwmon5, so dropped. > > Are you sure the problem is in my patch? Builds without the patch, does not build with the patch. Patch which modifies common code which affects a lot of different architectures should be at least compile-tested . We already have buildman for that. Clearly it was not, otherwise this would have popped up. > Maybe this PPC board just needs to UNdefine > CONFIG_EHCI_DESC_BIG_ENDIAN or there's a problem in its either > cpu_to_XXX() or readl()/writel()? > > Stefan, could you please look at what's wrong here > if you have the board handy? The board is pretty ancient. I'd rather appreciate if you could look into this and fix the issue, then re-submit. Thanks > -Alexey >
On Fri, Apr 14, 2017 at 05:16:11PM +0000, Alexey Brodkin wrote: > Hi Marek, > > On Fri, 2017-04-14 at 16:44 +0200, Marek Vasut wrote: > > On 03/24/2017 01:56 PM, Marek Vasut wrote: > > > > > Even better, this patch breaks powerpc board lwmon5, so dropped. > > Are you sure the problem is in my patch? Yes, it is. Dropping this from the USB PR gets everything going again. > Maybe this PPC board just needs to UNdefine > CONFIG_EHCI_DESC_BIG_ENDIAN or there's a problem in its either > cpu_to_XXX() or readl()/writel()? > > Stefan, could you please look at what's wrong here > if you have the board handy? Well, since this is your set of changes, you should have some idea what's right/wrong here given what things are before/after. Also, for wide changes like this, please give things a build either in travis-ci (so that most of the world is built) or do most of the world locally before posting, thanks!
Hi Tom, Marek, On Fri, 2017-04-14 at 16:06 -0400, Tom Rini wrote: > On Fri, Apr 14, 2017 at 05:16:11PM +0000, Alexey Brodkin wrote: > > > > Hi Marek, > > > > On Fri, 2017-04-14 at 16:44 +0200, Marek Vasut wrote: > > > > > > On 03/24/2017 01:56 PM, Marek Vasut wrote: > > > > > > > > > > > Even better, this patch breaks powerpc board lwmon5, so dropped. > > > > Are you sure the problem is in my patch? > > Yes, it is. Dropping this from the USB PR gets everything going again. Ok the problem was obvious missing inclusion f "asm/io.h". Fix is submitted here http://patchwork.ozlabs.org/patch/751397/ Please consider for applying. > > Maybe this PPC board just needs to UNdefine > > CONFIG_EHCI_DESC_BIG_ENDIAN or there's a problem in its either > > cpu_to_XXX() or readl()/writel()? > > > > Stefan, could you please look at what's wrong here > > if you have the board handy? > > Well, since this is your set of changes, you should have some idea > what's right/wrong here given what things are before/after. Also, for > wide changes like this, please give things a build either in travis-ci > (so that most of the world is built) or do most of the world locally > before posting, thanks! Well I tried to run a buildman locally (thanks to machine resources I have) but out of 1243 boards 154 have fatal problems if I use toolchains obtained via buildbot. Which is barely useful for capturing issues introduced by incremental patches :( -Alexey
On Mon, Apr 17, 2017 at 04:19:17PM +0000, Alexey Brodkin wrote: > Hi Tom, Marek, > > On Fri, 2017-04-14 at 16:06 -0400, Tom Rini wrote: > > On Fri, Apr 14, 2017 at 05:16:11PM +0000, Alexey Brodkin wrote: > > > > > > Hi Marek, > > > > > > On Fri, 2017-04-14 at 16:44 +0200, Marek Vasut wrote: > > > > > > > > On 03/24/2017 01:56 PM, Marek Vasut wrote: > > > > > > > > > > > > > > Even better, this patch breaks powerpc board lwmon5, so dropped. > > > > > > Are you sure the problem is in my patch? > > > > Yes, it is. Dropping this from the USB PR gets everything going again. > > Ok the problem was obvious missing inclusion f "asm/io.h". > Fix is submitted here http://patchwork.ozlabs.org/patch/751397/ > > Please consider for applying. Thanks. > > > Maybe this PPC board just needs to UNdefine > > > CONFIG_EHCI_DESC_BIG_ENDIAN or there's a problem in its either > > > cpu_to_XXX() or readl()/writel()? > > > > > > Stefan, could you please look at what's wrong here > > > if you have the board handy? > > > > Well, since this is your set of changes, you should have some idea > > what's right/wrong here given what things are before/after. Also, for > > wide changes like this, please give things a build either in travis-ci > > (so that most of the world is built) or do most of the world locally > > before posting, thanks! > > Well I tried to run a buildman locally (thanks to machine resources I have) > but out of 1243 boards 154 have fatal problems if I use toolchains obtained > via buildbot. Which is barely useful for capturing issues introduced by > incremental patches :( Did you mean buildman? If you look at .travis.yml that builds all of those boards (well, with the exception of some we need gcc-6 in order to have small enough binaries for) and that's pretty close to 1200 I think.
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h index 734d7f036278..2ab830df5155 100644 --- a/drivers/usb/host/ehci.h +++ b/drivers/usb/host/ehci.h @@ -102,13 +102,11 @@ struct usb_linux_config_descriptor { } __attribute__ ((packed)); #if defined CONFIG_EHCI_DESC_BIG_ENDIAN -#define ehci_readl(x) cpu_to_be32((*((volatile u32 *)(x)))) -#define ehci_writel(a, b) (*((volatile u32 *)(a)) = \ - cpu_to_be32(((volatile u32)b))) +#define ehci_readl(x) cpu_to_be32(readl(x)) +#define ehci_writel(a, b) writel(cpu_to_be32(b), a) #else -#define ehci_readl(x) cpu_to_le32((*((volatile u32 *)(x)))) -#define ehci_writel(a, b) (*((volatile u32 *)(a)) = \ - cpu_to_le32(((volatile u32)b))) +#define ehci_readl(x) cpu_to_le32(readl(x)) +#define ehci_writel(a, b) writel(cpu_to_le32(b), a) #endif #if defined CONFIG_EHCI_MMIO_BIG_ENDIAN
Current implementation doesn't allow utilization of platform-specific reads and writes. But some arches or platforms may want to use their accessors that do some extra work like adding barriers for data serialization etc. Interesting enough OHCI accessors already do that so just aligning EHCI to it now. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Marek Vasut <marex@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com> --- drivers/usb/host/ehci.h | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)