Re: [PATCH 5/6] spi/bcm63xx: move register definitions into the driver

[Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]

On Fri, Sep 11, 2015 at 12:27:02PM +0200, Jonas Gorski wrote:
> On Thu, Sep 10, 2015 at 9:10 PM, Florian Fainelli <florian-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:

> > This is a little fragile, I would rather create more specialized
> > platform_id names, like "bcm6348-spi" and "bcm6358-spi", very much like
> > what the FEC driver does, such that:

> Can we even associate more than one name with a driver? Else I would
> need to split this driver into two, and that sounds like a lot more
> work for IMHO not much gain, and a lot more opportunities to
> accidentially break things ;-)

Yes, of course - like Florian says look at the FEC driver for one
example.  Just set id_table.

> I'm also trying to not touch arch stuff, to keep the changes local to
> spi (easier merging). Apart from that, this is the legacy platform
> device registration route where we know exactly which values to
> expect, and the device tree path won't go there, so I would think this
> is okay for devices where we have full control over this (i.e. within
> the kernel).

Making the code more obscure and fragile to avoid such a minor issue
with integrating changes sounds like it's going in the wrong direction -
it creates long term complexity for a short term gain.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]