Hi Alan,
On 05/10/2011 08:35 PM, Jan Andersson wrote:
> On 10/05/11 18:27, Alan Stern wrote:
>> On Tue, 10 May 2011, Jan Andersson wrote:
>>
>>>> Shouldn't these things already be defined in an arch-specific header
>>>> file? Just like readl(), __raw_readl(), ... ?
>>>>
>>>
>>> If there is call to make a big endian access that works on all
>>> architectures that would be a better choice.
>>>
>>> I could have used __raw_readl() directly but I didn't since the above is
>>> what is done in ehci.h. IMHO it makes sense to have it like this because
>>> (again assuming that read/write() always is defined to work with LE
>>> memory) a read/write*_be is what we need to do and then people can
>>> define the appropriate function/macro for their arch here locally.
>>>
....
>>>
>>> I propose that the current solution is kept. If that is not acceptable I
>>> suggest that the calls are changed to use the __raw versions of
>>> read/write (but that could break in case the __raw versions are defined
>>> to be native endian and someone wants to use a BE controller together
>>> with a LE processor).
>>
>> Yes, keeping the current solution is easiest. But the whole situation
>> is a mess; some architectures define readl_be() and others don't. It
>> needs to be solved at a higher level.
>>
>
> I agree. I will send V3 of this series with fixes for all other comments
> now. Then I try to add {read,write}*_be for this architecture. When/if
> that patch accepted I will follow up with patches to remove the
> LEON_SPARC-specific fixes for read/write in ehci.h and uhci-hcd.h
> (assuming that V3 is accepted).
>
A patch to add {read,write}*_be has now been accepted for SPARC. Should
I wait and resubmit this patch series when those additions have
propagated to mainline or could V3 go in? I would then follow up with
patches to remove the #ifdef:s for SPARC_LEON in uhci-hcd.h and (the
ones currently present in) ehci.h?
Best regards,
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
