On Tue, Apr 30, 2019 at 09:32:20AM -0400, Sven Van Asbroeck wrote:
> On Tue, Apr 30, 2019 at 12:19 AM Al Viro wrote:
> >
> > ... not that there's much sense keeping ->fieldbus_type in host-endian,
> > while we are at it.
>
> Interesting! Suppose we make device->fieldbus_type bus-endian.
> Then
On Tue, Apr 30, 2019 at 10:22 AM Sven Van Asbroeck wrote:
>
> Ah ok, it's like a standard way of implementing a bus. Sounds good, I'll
> spin a patch to conform to it. And while I'm at it, I'll rename fieldbus_type
> because it can be confused with another fieldbus_type within the
> fieldbus_dev
On Tue, Apr 30, 2019 at 10:03 AM Greg Kroah-Hartman
wrote:
>
> Keep it bus-endian, as that's the "normal" way bus structures work (like
> PCI and USB for example), and that should be in a documented, and
> consistent, form, right?
>
> Then do the conversion when you access the field from within
On Tue, Apr 30, 2019 at 09:32:20AM -0400, Sven Van Asbroeck wrote:
> On Tue, Apr 30, 2019 at 12:19 AM Al Viro wrote:
> >
> > ... not that there's much sense keeping ->fieldbus_type in host-endian,
> > while we are at it.
>
> Interesting! Suppose we make device->fieldbus_type bus-endian.
Keep it
On Tue, Apr 30, 2019 at 12:19 AM Al Viro wrote:
>
> ... not that there's much sense keeping ->fieldbus_type in host-endian,
> while we are at it.
Interesting! Suppose we make device->fieldbus_type bus-endian.
Then the endinan-ness conversion either needs to happen in
bus_match() (and we'd have
On Tue, Apr 30, 2019 at 05:33:10AM +0200, Nicholas Mc Guire wrote:
> ok - my bad thn - I had assumed that using __force is reasonable
> if the handling is correct and its a localized conversoin only
> like var = be16_to_cpu(var) which evaded introducing additinal
> variables just to have
On Tue, Apr 30, 2019 at 04:02:23AM +0100, Al Viro wrote:
> On Tue, Apr 30, 2019 at 04:22:38AM +0200, Nicholas Mc Guire wrote:
> > On Mon, Apr 29, 2019 at 10:03:36AM -0400, Sven Van Asbroeck wrote:
> > > On Mon, Apr 29, 2019 at 2:11 AM Nicholas Mc Guire
> > > wrote:
> > > >
> > > > V2: As
On Tue, Apr 30, 2019 at 04:22:38AM +0200, Nicholas Mc Guire wrote:
> On Mon, Apr 29, 2019 at 10:03:36AM -0400, Sven Van Asbroeck wrote:
> > On Mon, Apr 29, 2019 at 2:11 AM Nicholas Mc Guire wrote:
> > >
> > > V2: As requested by Sven Van Asbroeck make the
> > > impact of the patch clear in
On Mon, Apr 29, 2019 at 10:03:36AM -0400, Sven Van Asbroeck wrote:
> On Mon, Apr 29, 2019 at 2:11 AM Nicholas Mc Guire wrote:
> >
> > V2: As requested by Sven Van Asbroeck make the
> > impact of the patch clear in the commit message.
>
> Thank you, but did you miss my comment about creating
On Mon, Apr 29, 2019 at 2:11 AM Nicholas Mc Guire wrote:
>
> V2: As requested by Sven Van Asbroeck make the
> impact of the patch clear in the commit message.
Thank you, but did you miss my comment about creating a local variable
instead? See:
https://lkml.org/lkml/2019/4/28/97
While the endiannes is being handled correctly sparse was unhappy with
the missing annotation as be16_to_cpu() expects a __be16. The __force
cast to __be16 makes sparse happy but has no impact on the generated
binary.
Signed-off-by: Nicholas Mc Guire
---
Problem reported by sparse
V2: As
11 matches
Mail list logo
