[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120605131337.GA15432@mail.gnudd.com>
Date: Tue, 5 Jun 2012 15:13:37 +0200
From: Alessandro Rubini <rubini@...dd.com>
To: bhupesh.sharma@...com
Cc: federico.vaga@...il.com, alan@...rguk.ukuu.org.uk,
wg@...ndegger.com, mkl@...gutronix.de, giancarlo.asnaghi@...com,
alan@...ux.intel.com, linux-can@...r.kernel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] c_can_pci: generic module for c_can on PCI
>> My implementation is align to 32, but I'm trying to make a generic PCI
>> wrapper (some other could be aligned to 16)
> So it means your implementation is also flaky and you are probably
> wasting HW memory space while integrating the Bosch C_CAN module in
> your SoC :)
Then I may say _your_ implementation is flaky because it wastes one
bit in the address decoder and a lot of logic gates in the data
bus. It's normal to align registers at 32 bits, as it's simpler and
faster. Most SoCs have only 32-bit aligned registers, for a reason.
> I am not a big fan of adding platform specific flakes in any core
> file, that why we keep the platform file separate from the core
> ones.
A number of other drivers have a shift parameter, because it's very
common for the hardware integrator to feel free to choose the easiest
wiring for the device. The choice to keep the platform driver
separate from the core driver only adds complication in my opinion:
you need to export 4 symbols and yhen every user must duplicate code
(like federico is replicating theplatform driver in the pci driver).
I'd really prefer to have the core driver be a platform driver, and
the others just add platform data to describe how it is wired. That's
actually the reason why the platform bus exists.
> But I will left Marc and Wolfgang to further comment on the same.
I agree: let them decide.
/alessandro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists