On Friday 05 February 2016 19:11:06 Grygorii Strashko wrote:
> On 02/05/2016 06:18 PM, Arnd Bergmann wrote:
> > On Thursday 04 February 2016 18:25:08 Grygorii Strashko wrote:
> > @@ -1173,7 +1189,8 @@ static int netcp_tx_submit_skb(struct netcp_intf
> > *netcp,
> > }
> >
> > set_words(&tmp, 1, &desc->packet_info);
> > - set_words((u32 *)&skb, 1, &desc->pad[0]);
> > + tmp = (uintptr_t)&skb;
> > + set_words(&tmp, 1, &desc->pad[0]);
>
> &skb is virt address and its size is 32bit even when LPAE=y (phys/dma 64 bit)
> so this is excess conversion to/from u64 ;)
> This is from the first look.
My original patch attempted to fix support for 64-bit CPUs, as no driver
should be written to support only 32-bit CPUs even if you think at this
point that there can never be a 64-bit keystone system.
The half-reverted patch above no longer works correctly for 64-bit CPUs
but it should not actually be wrong on 32-bit CPUs either, unless I'm
missing your point.
> >
> > if (tx_pipe->flags & SWITCH_TO_PORT_IN_TAGINFO) {
> > tmp = tx_pipe->switch_to_port;
> >
> >
> > I'm sure it's something obvious and stupid in there, but I just can't
> > see it and that is very unsatisfying. Do you see where I am going wrong?
> > Most of all, I want to know it so I don't make the same mistake again
> > when I patch another driver.
> >
>
> I'm very sorry, but I'll not be able to test it in the nearest future :(
> What I could do now is update your/my patch as i mentioned in [1]
> and re-send it at the weekend (with your authorship and my signoff).
> Do you agree?
>
>
> [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg95831.html
Yes, let's do that in the meantime. I can also make sure that that
the driver doesn't build on 64-bit, just in case.
Arnd
