Question about combining a PCI driver with an OF driver
benh at kernel.crashing.org
Wed Jan 5 08:05:57 EST 2011
On Tue, 2011-01-04 at 13:23 -0600, Scott Wood wrote:
> On Tue, 4 Jan 2011 10:58:35 -0800
> <Bruce_Leonard at selinc.com> wrote:
> > Hi all,
> > I'm working on a project with an MPC8347 and three ethernet ports. Because
> > of end of life issues we've had to replace the part we're using for the
> > third ethernet port and we decided rather than rely on a vendor who would
> > pull a part out from under us every two to three years we would do our own
> > MAC in an FPGA. In order to reduce driver work it was decided that we
> > would use the same hardware interface as the TSEC in the 8347 so we could
> > reuse the gianfar driver.
> Making a faithful clone of any reasonably complex device strikes me as
> more work than writing a new ethernet driver.
> The last thing you want to end up doing is...
> > And for speed sake it would go on the PCI bus.
> > (So much for letting HW make decisions regarding SW :) )
> ...hacking up the existing driver to deal with the quirks of the clone,
> and having to maintain those hacks. :-)
I definitely agree. You're up for more work and problems than just doing
a new design or getting an existing one off opencores or even buying an
IP block with its own driver.
> > So now I'm stuck with hacking the gianfar driver to work on PCI. However,
> > I think it would be a lot more elegant if I could wrap the gianfar driver
> > with a PCI interface. After all the idea is sound, with a HW interface
> > that looks like the TSEC I should be able to reuse the gianfar driver. But
> > the gianfar driver is an open firmware driver registered with a call to
> > of_register_platform_driver() and depending on the order in which the
> > busses are walked the PCI bus may not be enumerated and available when the
> > onboard TSECS are detected and the gianfar driver claims them.
> It shouldn't matter -- the way buses work in Linux, you should be able
> to add a platform device at any time, and the driver will receive a
> probe() callback. The driver never actively searches for devices to
> Linuxppc-dev mailing list
> Linuxppc-dev at lists.ozlabs.org
More information about the Linuxppc-dev