| Message ID | 1330084720-16878-1-git-send-email-amit.virdi@st.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Marek Vasut |
| Headers | show |
On Friday 24 February 2012 06:58:40 Amit Virdi wrote: > Packed attribute is forcing a bytewise write on device registers, > there by, resulting in a misbehavior on gcc-4.4.1. so use a compiler that isn't broken ? -mike
Hi Amit, Le 24/02/2012 12:58, Amit Virdi a écrit : > From: Vipin Kumar<vipin.kumar@st.com> > > Packed attribute is forcing a bytewise write on device registers, > there by, resulting in a misbehavior on gcc-4.4.1. > Reverting the structures to non-packed If (just asking, not asserting) the issue is caused by fields being u8 where u8 access is not possible, then should you not make the fields u16 / u32 according to access requirements? Amicalement,
On 2/25/2012 3:42 PM, Albert ARIBAUD wrote: > Hi Amit, > Hello Albert, > Le 24/02/2012 12:58, Amit Virdi a écrit : >> From: Vipin Kumar<vipin.kumar@st.com> >> >> Packed attribute is forcing a bytewise write on device registers, >> there by, resulting in a misbehavior on gcc-4.4.1. >> Reverting the structures to non-packed > > If (just asking, not asserting) the issue is caused by fields being u8 > where u8 access is not possible, then should you not make the fields u16 > / u32 according to access requirements? > The problem is not with the fields being of a different width. AFAIK, the packed attribute changes the generated code to access even the word field elements in a byte by byte manner Infact, there is a discussion on lkml that I can point https://lkml.org/lkml/2011/4/27/278 It seems that the discussion did not lead to a conclusion but it was sensible (at least for ARM) to remove the packed attribute from this structure Regards Vipin > Amicalement,
Hello Mike, On 2/25/2012 12:48 AM, Mike Frysinger wrote: > On Friday 24 February 2012 06:58:40 Amit Virdi wrote: >> Packed attribute is forcing a bytewise write on device registers, >> there by, resulting in a misbehavior on gcc-4.4.1. > > so use a compiler that isn't broken ? It doesn't seem like compiler issue (on ARM). Thanks Amit Virdi
> On 2/25/2012 3:42 PM, Albert ARIBAUD wrote: > > Hi Amit, > > Hello Albert, > > > Le 24/02/2012 12:58, Amit Virdi a écrit : > >> From: Vipin Kumar<vipin.kumar@st.com> > >> > >> Packed attribute is forcing a bytewise write on device registers, > >> there by, resulting in a misbehavior on gcc-4.4.1. > >> Reverting the structures to non-packed > > > > If (just asking, not asserting) the issue is caused by fields being u8 > > where u8 access is not possible, then should you not make the fields u16 > > / u32 according to access requirements? > > The problem is not with the fields being of a different width. AFAIK, > the packed attribute changes the generated code to access even the word > field elements in a byte by byte manner > > Infact, there is a discussion on lkml that I can point > https://lkml.org/lkml/2011/4/27/278 > > It seems that the discussion did not lead to a conclusion but it was > sensible (at least for ARM) to remove the packed attribute from this > structure > What does the USB spec say ? It might be a HW bug? M
On Monday 27 February 2012 05:02:14 Amit Virdi wrote: > On 2/25/2012 12:48 AM, Mike Frysinger wrote: > > On Friday 24 February 2012 06:58:40 Amit Virdi wrote: > >> Packed attribute is forcing a bytewise write on device registers, > >> there by, resulting in a misbehavior on gcc-4.4.1. > > > > so use a compiler that isn't broken ? > > It doesn't seem like compiler issue (on ARM). i think it is ... you don't see this behavior on other architectures. the recent thread indicates that ARM has been broken for a long time though. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/85629 -mike
On Monday 27 February 2012 08:14:26 Marek Vasut wrote: > > On 2/25/2012 3:42 PM, Albert ARIBAUD wrote: > > > Le 24/02/2012 12:58, Amit Virdi a écrit : > > >> Packed attribute is forcing a bytewise write on device registers, > > >> there by, resulting in a misbehavior on gcc-4.4.1. > > >> Reverting the structures to non-packed > > > > > > If (just asking, not asserting) the issue is caused by fields being u8 > > > where u8 access is not possible, then should you not make the fields > > > u16 / u32 according to access requirements? > > > > The problem is not with the fields being of a different width. AFAIK, > > the packed attribute changes the generated code to access even the word > > field elements in a byte by byte manner > > > > Infact, there is a discussion on lkml that I can point > > https://lkml.org/lkml/2011/4/27/278 > > > > It seems that the discussion did not lead to a conclusion but it was > > sensible (at least for ARM) to remove the packed attribute from this > > structure > > What does the USB spec say ? It might be a HW bug? it isn't covered by the USB spec. these are structs for hardware registers in the EHCI usb host controller. -mike
> On Monday 27 February 2012 08:14:26 Marek Vasut wrote: > > > On 2/25/2012 3:42 PM, Albert ARIBAUD wrote: > > > > Le 24/02/2012 12:58, Amit Virdi a écrit : > > > >> Packed attribute is forcing a bytewise write on device registers, > > > >> there by, resulting in a misbehavior on gcc-4.4.1. > > > >> Reverting the structures to non-packed > > > > > > > > If (just asking, not asserting) the issue is caused by fields being > > > > u8 where u8 access is not possible, then should you not make the > > > > fields u16 / u32 according to access requirements? > > > > > > The problem is not with the fields being of a different width. AFAIK, > > > the packed attribute changes the generated code to access even the word > > > field elements in a byte by byte manner > > > > > > Infact, there is a discussion on lkml that I can point > > > https://lkml.org/lkml/2011/4/27/278 > > > > > > It seems that the discussion did not lead to a conclusion but it was > > > sensible (at least for ARM) to remove the packed attribute from this > > > structure > > > > What does the USB spec say ? It might be a HW bug? > > it isn't covered by the USB spec. these are structs for hardware registers > in the EHCI usb host controller. > -mike I see ... so replacing them with unions of accessors where it colides might work ?
On Monday 27 February 2012 15:53:29 Marek Vasut wrote: > > On Monday 27 February 2012 08:14:26 Marek Vasut wrote: > > > > On 2/25/2012 3:42 PM, Albert ARIBAUD wrote: > > > > > Le 24/02/2012 12:58, Amit Virdi a écrit : > > > > >> Packed attribute is forcing a bytewise write on device registers, > > > > >> there by, resulting in a misbehavior on gcc-4.4.1. > > > > >> Reverting the structures to non-packed > > > > > > > > > > If (just asking, not asserting) the issue is caused by fields being > > > > > u8 where u8 access is not possible, then should you not make the > > > > > fields u16 / u32 according to access requirements? > > > > > > > > The problem is not with the fields being of a different width. AFAIK, > > > > the packed attribute changes the generated code to access even the > > > > word field elements in a byte by byte manner > > > > > > > > Infact, there is a discussion on lkml that I can point > > > > https://lkml.org/lkml/2011/4/27/278 > > > > > > > > It seems that the discussion did not lead to a conclusion but it was > > > > sensible (at least for ARM) to remove the packed attribute from this > > > > structure > > > > > > What does the USB spec say ? It might be a HW bug? > > > > it isn't covered by the USB spec. these are structs for hardware > > registers in the EHCI usb host controller. > > I see ... so replacing them with unions of accessors where it colides might > work ? i'm not entirely sure what you're asking, but i think you're pointing to the right answer: drivers/usb/host/ehci.h:ehci_{read,write}l() should *not* be casting/derferencing the pointers directly. they should instead be using standard {read,write}l() funcs from asm/io.h. Amit: can you post a new patch that does that instead ? don't touch the packed attribute, but change ehci_readl() to use readl() and ehci_writel() to use writel() ? -mike
Hello Mike, On 2/28/2012 6:26 AM, Mike Frysinger wrote: > On Monday 27 February 2012 15:53:29 Marek Vasut wrote: >>> On Monday 27 February 2012 08:14:26 Marek Vasut wrote: >>>>> On 2/25/2012 3:42 PM, Albert ARIBAUD wrote: >>>>>> Le 24/02/2012 12:58, Amit Virdi a écrit : >>>>>>> Packed attribute is forcing a bytewise write on device registers, >>>>>>> there by, resulting in a misbehavior on gcc-4.4.1. >>>>>>> Reverting the structures to non-packed >>>>>> >>>>>> If (just asking, not asserting) the issue is caused by fields being >>>>>> u8 where u8 access is not possible, then should you not make the >>>>>> fields u16 / u32 according to access requirements? >>>>> >>>>> The problem is not with the fields being of a different width. AFAIK, >>>>> the packed attribute changes the generated code to access even the >>>>> word field elements in a byte by byte manner >>>>> >>>>> Infact, there is a discussion on lkml that I can point >>>>> https://lkml.org/lkml/2011/4/27/278 >>>>> >>>>> It seems that the discussion did not lead to a conclusion but it was >>>>> sensible (at least for ARM) to remove the packed attribute from this >>>>> structure >>>> >>>> What does the USB spec say ? It might be a HW bug? >>> >>> it isn't covered by the USB spec. these are structs for hardware >>> registers in the EHCI usb host controller. >> >> I see ... so replacing them with unions of accessors where it colides might >> work ? > > i'm not entirely sure what you're asking, but i think you're pointing to the > right answer: drivers/usb/host/ehci.h:ehci_{read,write}l() should *not* be > casting/derferencing the pointers directly. they should instead be using > standard {read,write}l() funcs from asm/io.h. > > Amit: can you post a new patch that does that instead ? don't touch the > packed attribute, but change ehci_readl() to use readl() and ehci_writel() to > use writel() ? I'll make the changes and post the patch after testing successfully. Thanks Amit Virdi
Hello Mike and Marek, On 2/29/2012 3:55 PM, Amit Virdi wrote: > Hello Mike, > > On 2/28/2012 6:26 AM, Mike Frysinger wrote: >> On Monday 27 February 2012 15:53:29 Marek Vasut wrote: >>>> On Monday 27 February 2012 08:14:26 Marek Vasut wrote: >>>>>> On 2/25/2012 3:42 PM, Albert ARIBAUD wrote: >>>>>>> Le 24/02/2012 12:58, Amit Virdi a écrit : >>>>>>>> Packed attribute is forcing a bytewise write on device registers, >>>>>>>> there by, resulting in a misbehavior on gcc-4.4.1. >>>>>>>> Reverting the structures to non-packed >>>>>>> >>>>>>> If (just asking, not asserting) the issue is caused by fields being >>>>>>> u8 where u8 access is not possible, then should you not make the >>>>>>> fields u16 / u32 according to access requirements? >>>>>> >>>>>> The problem is not with the fields being of a different width. AFAIK, >>>>>> the packed attribute changes the generated code to access even the >>>>>> word field elements in a byte by byte manner >>>>>> >>>>>> Infact, there is a discussion on lkml that I can point >>>>>> https://lkml.org/lkml/2011/4/27/278 >>>>>> >>>>>> It seems that the discussion did not lead to a conclusion but it was >>>>>> sensible (at least for ARM) to remove the packed attribute from this >>>>>> structure >>>>> >>>>> What does the USB spec say ? It might be a HW bug? >>>> >>>> it isn't covered by the USB spec. these are structs for hardware >>>> registers in the EHCI usb host controller. >>> >>> I see ... so replacing them with unions of accessors where it colides >>> might >>> work ? >> >> i'm not entirely sure what you're asking, but i think you're pointing >> to the >> right answer: drivers/usb/host/ehci.h:ehci_{read,write}l() should >> *not* be >> casting/derferencing the pointers directly. they should instead be using >> standard {read,write}l() funcs from asm/io.h. >> >> Amit: can you post a new patch that does that instead ? don't touch the >> packed attribute, but change ehci_readl() to use readl() and >> ehci_writel() to >> use writel() ? > > I'll make the changes and post the patch after testing successfully. > I did the changes suggested by you and tested the build. The issue didn't come up. Then I reverted the code to the original (attributes retained and ehci directly de-referencing the pointers. The issue didn't come here too. Today, I used armv7-linux-gcc (GCC) v4.6.2 So I suspect there has been some fix done in the GCC. Now, even with the packed attributes, the word fields are accessed word-by-word in contrast to the earlier observed behavior (byte-by-byte). I could see ldr and str in the disassembly. May be, we can discard this patch and keep drivers/usb/host/ehci.h intact. Thanks Amit Virdi
Dear Amit Virdi, > Hello Mike and Marek, > > On 2/29/2012 3:55 PM, Amit Virdi wrote: > > Hello Mike, > > > > On 2/28/2012 6:26 AM, Mike Frysinger wrote: > >> On Monday 27 February 2012 15:53:29 Marek Vasut wrote: > >>>> On Monday 27 February 2012 08:14:26 Marek Vasut wrote: > >>>>>> On 2/25/2012 3:42 PM, Albert ARIBAUD wrote: > >>>>>>> Le 24/02/2012 12:58, Amit Virdi a écrit : > >>>>>>>> Packed attribute is forcing a bytewise write on device registers, > >>>>>>>> there by, resulting in a misbehavior on gcc-4.4.1. > >>>>>>>> Reverting the structures to non-packed > >>>>>>> > >>>>>>> If (just asking, not asserting) the issue is caused by fields being > >>>>>>> u8 where u8 access is not possible, then should you not make the > >>>>>>> fields u16 / u32 according to access requirements? > >>>>>> > >>>>>> The problem is not with the fields being of a different width. > >>>>>> AFAIK, the packed attribute changes the generated code to access > >>>>>> even the word field elements in a byte by byte manner > >>>>>> > >>>>>> Infact, there is a discussion on lkml that I can point > >>>>>> https://lkml.org/lkml/2011/4/27/278 > >>>>>> > >>>>>> It seems that the discussion did not lead to a conclusion but it was > >>>>>> sensible (at least for ARM) to remove the packed attribute from this > >>>>>> structure > >>>>> > >>>>> What does the USB spec say ? It might be a HW bug? > >>>> > >>>> it isn't covered by the USB spec. these are structs for hardware > >>>> registers in the EHCI usb host controller. > >>> > >>> I see ... so replacing them with unions of accessors where it colides > >>> might > >>> work ? > >> > >> i'm not entirely sure what you're asking, but i think you're pointing > >> to the > >> right answer: drivers/usb/host/ehci.h:ehci_{read,write}l() should > >> *not* be > >> casting/derferencing the pointers directly. they should instead be using > >> standard {read,write}l() funcs from asm/io.h. > >> > >> Amit: can you post a new patch that does that instead ? don't touch the > >> packed attribute, but change ehci_readl() to use readl() and > >> ehci_writel() to > >> use writel() ? > > > > I'll make the changes and post the patch after testing successfully. > > I did the changes suggested by you and tested the build. The issue > didn't come up. Then I reverted the code to the original (attributes > retained and ehci directly de-referencing the pointers. The issue didn't > come here too. > > Today, I used armv7-linux-gcc (GCC) v4.6.2 > So I suspect there has been some fix done in the GCC. > > Now, even with the packed attributes, the word fields are accessed > word-by-word in contrast to the earlier observed behavior > (byte-by-byte). I could see ldr and str in the disassembly. > > May be, we can discard this patch and keep drivers/usb/host/ehci.h intact. Can you check with different toolchain please? Best regards, Marek Vasut
On Tuesday 06 March 2012 07:06:22 Amit Virdi wrote: > On 2/29/2012 3:55 PM, Amit Virdi wrote: > > On 2/28/2012 6:26 AM, Mike Frysinger wrote: > >> On Monday 27 February 2012 15:53:29 Marek Vasut wrote: > >>>> On Monday 27 February 2012 08:14:26 Marek Vasut wrote: > >>>>>> On 2/25/2012 3:42 PM, Albert ARIBAUD wrote: > >>>>>>> Le 24/02/2012 12:58, Amit Virdi a écrit : > >>>>>>>> Packed attribute is forcing a bytewise write on device registers, > >>>>>>>> there by, resulting in a misbehavior on gcc-4.4.1. > >>>>>>>> Reverting the structures to non-packed > >>>>>>> > >>>>>>> If (just asking, not asserting) the issue is caused by fields being > >>>>>>> u8 where u8 access is not possible, then should you not make the > >>>>>>> fields u16 / u32 according to access requirements? > >>>>>> > >>>>>> The problem is not with the fields being of a different width. > >>>>>> AFAIK, the packed attribute changes the generated code to access > >>>>>> even the word field elements in a byte by byte manner > >>>>>> > >>>>>> Infact, there is a discussion on lkml that I can point > >>>>>> https://lkml.org/lkml/2011/4/27/278 > >>>>>> > >>>>>> It seems that the discussion did not lead to a conclusion but it was > >>>>>> sensible (at least for ARM) to remove the packed attribute from this > >>>>>> structure > >>>>> > >>>>> What does the USB spec say ? It might be a HW bug? > >>>> > >>>> it isn't covered by the USB spec. these are structs for hardware > >>>> registers in the EHCI usb host controller. > >>> > >>> I see ... so replacing them with unions of accessors where it colides > >>> might > >>> work ? > >> > >> i'm not entirely sure what you're asking, but i think you're pointing > >> to the > >> right answer: drivers/usb/host/ehci.h:ehci_{read,write}l() should > >> *not* be > >> casting/derferencing the pointers directly. they should instead be using > >> standard {read,write}l() funcs from asm/io.h. > >> > >> Amit: can you post a new patch that does that instead ? don't touch the > >> packed attribute, but change ehci_readl() to use readl() and > >> ehci_writel() to > >> use writel() ? > > > > I'll make the changes and post the patch after testing successfully. > > I did the changes suggested by you and tested the build. The issue > didn't come up. Then I reverted the code to the original (attributes > retained and ehci directly de-referencing the pointers. The issue didn't > come here too. > > Today, I used armv7-linux-gcc (GCC) v4.6.2 > So I suspect there has been some fix done in the GCC. > > Now, even with the packed attributes, the word fields are accessed > word-by-word in contrast to the earlier observed behavior > (byte-by-byte). I could see ldr and str in the disassembly. > > May be, we can discard this patch and keep drivers/usb/host/ehci.h intact. not sure ... in general, device registers should be accessed with io.h helpers instead of dereferenced by volatile pointers. i can think of cases on Blackfin where the io.h helpers would be required, and even using volatile pointers could result in misbehavior. -mike
Mike, >> >> I did the changes suggested by you and tested the build. The issue >> didn't come up. Then I reverted the code to the original (attributes >> retained and ehci directly de-referencing the pointers. The issue didn't >> come here too. >> >> Today, I used armv7-linux-gcc (GCC) v4.6.2 >> So I suspect there has been some fix done in the GCC. >> >> Now, even with the packed attributes, the word fields are accessed >> word-by-word in contrast to the earlier observed behavior >> (byte-by-byte). I could see ldr and str in the disassembly. >> >> May be, we can discard this patch and keep drivers/usb/host/ehci.h intact. > > not sure ... in general, device registers should be accessed with io.h helpers > instead of dereferenced by volatile pointers. i can think of cases on Blackfin > where the io.h helpers would be required, and even using volatile pointers > could result in misbehavior. If you guys agree, I can float the patch but how can we distribute the responsibility for testing on other architectures? Thanks Amit Virdi
Dear Marek, >> I did the changes suggested by you and tested the build. The issue >> didn't come up. Then I reverted the code to the original (attributes >> retained and ehci directly de-referencing the pointers. The issue didn't >> come here too. >> >> Today, I used armv7-linux-gcc (GCC) v4.6.2 >> So I suspect there has been some fix done in the GCC. >> >> Now, even with the packed attributes, the word fields are accessed >> word-by-word in contrast to the earlier observed behavior >> (byte-by-byte). I could see ldr and str in the disassembly. >> >> May be, we can discard this patch and keep drivers/usb/host/ehci.h intact. > > Can you check with different toolchain please? > Do you mean different toolchains for ARM? I can surely check if you can help me. I have used ST's internal distribution till date and I guess I need to download and install other ARM toolchains in order to verify this issue. Or, we can work this way that my source code is compiled by someone already installed/using other tool chains. I can test it on my board and report the results? Thanks Amit Virdi
Dear Amit Virdi, > Dear Marek, > > >> I did the changes suggested by you and tested the build. The issue > >> didn't come up. Then I reverted the code to the original (attributes > >> retained and ehci directly de-referencing the pointers. The issue didn't > >> come here too. > >> > >> Today, I used armv7-linux-gcc (GCC) v4.6.2 > >> So I suspect there has been some fix done in the GCC. > >> > >> Now, even with the packed attributes, the word fields are accessed > >> word-by-word in contrast to the earlier observed behavior > >> (byte-by-byte). I could see ldr and str in the disassembly. > >> > >> May be, we can discard this patch and keep drivers/usb/host/ehci.h > >> intact. > > > > Can you check with different toolchain please? > > Do you mean different toolchains for ARM? I can surely check if you can > help me. I have used ST's internal distribution till date and I guess I > need to download and install other ARM toolchains in order to verify > this issue. Sure, you can download the ELDK installer for ELDK 5.1 :-) > > Or, we can work this way that my source code is compiled by someone > already installed/using other tool chains. I can test it on my board and > report the results? Yes please. I'll most likely apply your other patchset, but let's keep an eye on this patch, it might come handy later if the issue reappears. > > Thanks > Amit Virdi Best regards, Marek Vasut
Dear Marek, On 3/7/2012 5:08 PM, Marek Vasut wrote: > Dear Amit Virdi, > >> Dear Marek, >> >>>> I did the changes suggested by you and tested the build. The issue >>>> didn't come up. Then I reverted the code to the original (attributes >>>> retained and ehci directly de-referencing the pointers. The issue didn't >>>> come here too. >>>> >>>> Today, I used armv7-linux-gcc (GCC) v4.6.2 >>>> So I suspect there has been some fix done in the GCC. >>>> >>>> Now, even with the packed attributes, the word fields are accessed >>>> word-by-word in contrast to the earlier observed behavior >>>> (byte-by-byte). I could see ldr and str in the disassembly. >>>> >>>> May be, we can discard this patch and keep drivers/usb/host/ehci.h >>>> intact. >>> >>> Can you check with different toolchain please? >> >> Do you mean different toolchains for ARM? I can surely check if you can >> help me. I have used ST's internal distribution till date and I guess I >> need to download and install other ARM toolchains in order to verify >> this issue. > > Sure, you can download the ELDK installer for ELDK 5.1 :-) Ok. I keep this in my "To do" list. As soon as I get some spare time, I'll install the toolchain and test the build on my SPEAr320 eval board. >> >> Or, we can work this way that my source code is compiled by someone >> already installed/using other tool chains. I can test it on my board and >> report the results? > > Yes please. I'll most likely apply your other patchset, but let's keep an eye on > this patch, it might come handy later if the issue reappears. > Ok, thanks. Regards Amit Virdi
On Wednesday 07 March 2012 03:23:42 Amit Virdi wrote: > >> I did the changes suggested by you and tested the build. The issue > >> didn't come up. Then I reverted the code to the original (attributes > >> retained and ehci directly de-referencing the pointers. The issue didn't > >> come here too. > >> > >> Today, I used armv7-linux-gcc (GCC) v4.6.2 > >> So I suspect there has been some fix done in the GCC. > >> > >> Now, even with the packed attributes, the word fields are accessed > >> word-by-word in contrast to the earlier observed behavior > >> (byte-by-byte). I could see ldr and str in the disassembly. > >> > >> May be, we can discard this patch and keep drivers/usb/host/ehci.h > >> intact. > > > > not sure ... in general, device registers should be accessed with io.h > > helpers instead of dereferenced by volatile pointers. i can think of > > cases on Blackfin where the io.h helpers would be required, and even > > using volatile pointers could result in misbehavior. > > If you guys agree, I can float the patch but how can we distribute the > responsibility for testing on other architectures? if it works on your platform, and you compile it test it for others, and we agree it looks correct, and no one else wants to runtime test it to verify, i think it's fine to merge. if there's a problem, someone will notice and let us know ;). -mike
On Wed, Mar 7, 2012 at 7:03 PM, Mike Frysinger <vapier@gentoo.org> wrote: > On Wednesday 07 March 2012 03:23:42 Amit Virdi wrote: >> >> I did the changes suggested by you and tested the build. The issue >> >> didn't come up. Then I reverted the code to the original (attributes >> >> retained and ehci directly de-referencing the pointers. The issue didn't >> >> come here too. >> >> >> >> Today, I used armv7-linux-gcc (GCC) v4.6.2 >> >> So I suspect there has been some fix done in the GCC. >> >> >> >> Now, even with the packed attributes, the word fields are accessed >> >> word-by-word in contrast to the earlier observed behavior >> >> (byte-by-byte). I could see ldr and str in the disassembly. >> >> >> >> May be, we can discard this patch and keep drivers/usb/host/ehci.h >> >> intact. >> > >> > not sure ... in general, device registers should be accessed with io.h >> > helpers instead of dereferenced by volatile pointers. i can think of >> > cases on Blackfin where the io.h helpers would be required, and even >> > using volatile pointers could result in misbehavior. >> >> If you guys agree, I can float the patch but how can we distribute the >> responsibility for testing on other architectures? > > if it works on your platform, and you compile it test it for others, and we > agree it looks correct, and no one else wants to runtime test it to verify, i > think it's fine to merge. if there's a problem, someone will notice and let us > know ;). Ok Mike, agreed. Once I test it with ELDK 5.1, i'll inform you guys. Thanks Amit Virdi
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h index 3d0ad0c..df9f055 100644 --- a/drivers/usb/host/ehci.h +++ b/drivers/usb/host/ehci.h @@ -55,7 +55,7 @@ struct ehci_hccr { #define HCS_N_PORTS(p) (((p) >> 0) & 0xf) uint32_t cr_hccparams; uint8_t cr_hcsp_portrt[8]; -} __attribute__ ((packed, aligned(4))); +}; struct ehci_hcor { uint32_t or_usbcmd; @@ -85,7 +85,7 @@ struct ehci_hcor { #define FLAG_CF (1 << 0) /* true: we'll support "high speed" */ uint32_t or_portsc[CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS]; uint32_t or_systune; -} __attribute__ ((packed, aligned(4))); +}; #define USBMODE 0x68 /* USB Device mode */ #define USBMODE_SDIS (1 << 3) /* Stream disable */