Patchwork [U-Boot] USB:host: Attribute packed removed from usb structures

login
register
mail settings
Submitter Amit Virdi
Date Feb. 24, 2012, 11:58 a.m.
Message ID <1330084720-16878-1-git-send-email-amit.virdi@st.com>
Download mbox | patch
Permalink /patch/142820/
State Changes Requested
Delegated to: Marek Vasut
Headers show

Comments

Amit Virdi - Feb. 24, 2012, 11:58 a.m.
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

Signed-off-by: Vipin Kumar <vipin.kumar@st.com>
Signed-off-by: Amit Virdi <amit.virdi@st.com>
---
 drivers/usb/host/ehci.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
Mike Frysinger - Feb. 24, 2012, 7:18 p.m.
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
Albert ARIBAUD - Feb. 25, 2012, 10:12 a.m.
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,
Vipin Kumar - Feb. 27, 2012, 7:16 a.m.
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,
Amit Virdi - Feb. 27, 2012, 10:02 a.m.
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
Marek Vasut - Feb. 27, 2012, 1:14 p.m.
> 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
Mike Frysinger - Feb. 27, 2012, 6:25 p.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
Mike Frysinger - Feb. 27, 2012, 6:26 p.m.
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
Marek Vasut - Feb. 27, 2012, 8:53 p.m.
> 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 
?
Mike Frysinger - Feb. 28, 2012, 12:56 a.m.
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
Amit Virdi - Feb. 29, 2012, 10:25 a.m.
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
Amit Virdi - March 6, 2012, 12:06 p.m.
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
Marek Vasut - March 6, 2012, 12:51 p.m.
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
Mike Frysinger - March 6, 2012, 4:11 p.m.
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
Amit Virdi - March 7, 2012, 8:23 a.m.
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
Amit Virdi - March 7, 2012, 8:30 a.m.
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
Marek Vasut - March 7, 2012, 11:38 a.m.
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
Amit Virdi - March 7, 2012, 12:12 p.m.
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
Mike Frysinger - March 7, 2012, 1:33 p.m.
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
Amit Virdi - March 7, 2012, 1:49 p.m.
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

Patch

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 */