[U-Boot] [U-Boot-DM] List of offending drivers

[Marek Vasut <marex@denx.de>]

Dear Graeme Russ,

> Hi Marek,
> 
> On Fri, Jul 27, 2012 at 9:18 AM, Marek Vasut <marex@denx.de> wrote:
> > Hello,
> > 
> > Check the following list, it's the list of drivers scattered (misplaced)
> > across the tree. The list is not complete and might be inaccurate. But
> > it should give a good impression of what I'm going to break soon:
> > 
> > arch/x86/cpu/sc520/sc520_pci.c
> > board/eNET/eNET_pci.c
> 
> Hmm, I'm wondering what where the line between 'driver' and 'arch/board
> specific driver glue' is?

That's why I said the list isn't exactly precise.

> How was this list generated?

By hard manual labor (=slavework).

> You seem to have missed sc520_ssi.c and sc520_timer.c

I wonder if we should move the timer drivers ... maybe to drivers/timer/ ?

> board/eNET/eNET_pci.c only contains:
> 
> pci_enet_fixup_irq() - Board specific configuration of PCI interrupt lines.
> This is a platform function which is specified when the board initialises
> the PCI driver. Note that this function calls pci_sc520_set_irq() which is
> located on arch/x86/cpu/sc520/sc520_pci.c (see below)

Ok, so this one should be left out, I didn't properly examine them all. Just 
wanted to share the list, the examination will follow this weekend, when I start 
moving them.

> pci_init_board() - One line wrapper for pci_sc520_init() which should get
> dropped once the driver model and init sequence (if that gets looked at
> again) refactoring
> 
> pci_set_regions() - Configure the board-specific PCI memory and I/O regions
> 
> arch/x86/cpu/sc520/sc520_pci.c contains:
> pci_sc520_set_irq() - A support function for board-specific PCI interrupt
> line configuration
> pci_sc520_init() - SC520 specific PCI driver initialisation
> 
> So neither of these files are 'drivers' per-se. They are really just
> initialisation and platform specific support functions. How do these fit
> into the new driver model?

You can supply a pointer to that function to some "pci" driver I guess ... 
Pavel?

> Regards,
> 
> Graeme

Best regards,
Marek Vasut