Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1476063 > unrolled thread

linux-next: manual merge of the arm-soc tree with Linus' tree

Back to article view | Back to linux.kernel

Contents

  linux-next: manual merge of the arm-soc tree with Linus' tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-09-05 03:00 +0200
    Re: linux-next: manual merge of the arm-soc tree with Linus' tree Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-09-06 09:30 +0200
      Re: linux-next: manual merge of the arm-soc tree with Linus' tree Arnd Bergmann <arnd@arndb.de> - 2016-09-06 12:20 +0200
        Re: linux-next: manual merge of the arm-soc tree with Linus' tree Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-09-06 12:50 +0200

#1476063 — linux-next: manual merge of the arm-soc tree with Linus' tree

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in:

  arch/arm/mach-realview/core.c

between commit:

  2fb04fdf3019 ("net: smc91x: fix SMC accesses")

from Linus' tree and commit:

  7484c727b636 ("ARM: realview: delete the RealView board files")

from the arm-soc tree.

I fixed it up (I deleted the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[toc] | [next] | [standalone]

#1477119

On Mon, Sep 05, 2016 at 10:58:03AM +1000, Stephen Rothwell wrote:
> I fixed it up (I deleted the file) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

That's the "simple" way of making the conflict go away, but I'm afraid
it's really not that simple.

Having just looked at the SMC91x definition for realview, it shows that
the SMC91x binding, like many of the conversions that the patch in my
tree fixes, has been created without a proper understanding of the
hardware.  To put it simply, it is broken.

The binding only allows _one_ register width to be specified, which is
completely incorrect: the binding _must_ allow multiple register widths
to be specified.  This is what SMC91x has always expected: to be told
which register access widths it is permitted to make.

That must include at least one of 8 or 16 bit accesses, but 32-bit
access is optional.

The result will be that - despite I've fixed up all the static platform
data to be correct, there's no way to fix up the DT binding without
inventing a new one.

So, deleting the Realview (and other) board files results in platforms
that can't use networking - it's worse than that, because the smc91x
driver will BUG() as a result of this at boot time.

Since the patch in my tree is fixing a regression caused by the broken
conversions, I'm not mindful to drop it from the merge window - I
actually want to push it into -rc kernels.  We _do_ need to fix the
DT regressions, and quickly though, and push those with this patch.

Since I don't use the SMC91x with DT, that's outside of what I can
test, so consider this a call for help on that subject.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1477243

On Monday, September 5, 2016 7:26:03 PM CEST Russell King - ARM Linux wrote:
> On Mon, Sep 05, 2016 at 10:58:03AM +1000, Stephen Rothwell wrote:
> > I fixed it up (I deleted the file) and can carry the fix as
> > necessary. This is now fixed as far as linux-next is concerned, but any
> > non trivial conflicts should be mentioned to your upstream maintainer
> > when your tree is submitted for merging.  You may also want to consider
> > cooperating with the maintainer of the conflicting tree to minimise any
> > particularly complex conflicts.
> 
> That's the "simple" way of making the conflict go away, but I'm afraid
> it's really not that simple.
> 
> Having just looked at the SMC91x definition for realview, it shows that
> the SMC91x binding, like many of the conversions that the patch in my
> tree fixes, has been created without a proper understanding of the
> hardware.  To put it simply, it is broken.
> 
> The binding only allows _one_ register width to be specified, which is
> completely incorrect: the binding _must_ allow multiple register widths
> to be specified.  This is what SMC91x has always expected: to be told
> which register access widths it is permitted to make.

This is what is documented:

Documentation/devicetree/bindings/net/smsc-lan91c111.txt
- reg-io-width : Mask of sizes (in bytes) of the IO accesses that
  are supported on the device.  Valid value for SMSC LAN91c111 are
  1, 2 or 4.  If it's omitted or invalid, the size would be 2 meaning
  16-bit access only.

and this appears to match what the driver does, although it is a
rather unconventional definition (I would have expected an array
of widths in bytes).

Almost all of the users leave out the property, so they get 16-bit
access, nomadik-nhk15 is the only one that actually specifies
the width explicitly, and it also requests 16-bit only. I don't
think your patch changes anything for these cases.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1477274

On Tue, Sep 06, 2016 at 12:17:48PM +0200, Arnd Bergmann wrote:
> On Monday, September 5, 2016 7:26:03 PM CEST Russell King - ARM Linux wrote:
> > On Mon, Sep 05, 2016 at 10:58:03AM +1000, Stephen Rothwell wrote:
> > > I fixed it up (I deleted the file) and can carry the fix as
> > > necessary. This is now fixed as far as linux-next is concerned, but any
> > > non trivial conflicts should be mentioned to your upstream maintainer
> > > when your tree is submitted for merging.  You may also want to consider
> > > cooperating with the maintainer of the conflicting tree to minimise any
> > > particularly complex conflicts.
> > 
> > That's the "simple" way of making the conflict go away, but I'm afraid
> > it's really not that simple.
> > 
> > Having just looked at the SMC91x definition for realview, it shows that
> > the SMC91x binding, like many of the conversions that the patch in my
> > tree fixes, has been created without a proper understanding of the
> > hardware.  To put it simply, it is broken.
> > 
> > The binding only allows _one_ register width to be specified, which is
> > completely incorrect: the binding _must_ allow multiple register widths
> > to be specified.  This is what SMC91x has always expected: to be told
> > which register access widths it is permitted to make.
> 
> This is what is documented:
> 
> Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> - reg-io-width : Mask of sizes (in bytes) of the IO accesses that
>   are supported on the device.  Valid value for SMSC LAN91c111 are
>   1, 2 or 4.  If it's omitted or invalid, the size would be 2 meaning
>   16-bit access only.
> 
> and this appears to match what the driver does, although it is a
> rather unconventional definition (I would have expected an array
> of widths in bytes).

It doesn't match what the driver does - have you not been following the
discussion on the breakage caused by your commit b70661c70830 ?

> Almost all of the users leave out the property, so they get 16-bit
> access, nomadik-nhk15 is the only one that actually specifies
> the width explicitly, and it also requests 16-bit only. I don't
> think your patch changes anything for these cases.

Okay, so all the DT users _only_ use 16-bit accesses, and end up
_emulating_ 8-bit accesses through a 16-bit read-modify-write
sequence, even when they may be perfectly capable of 8-bit accesses,
because this fine detail of the SMC91x driver hasn't been understood.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web