Skip to contentSkip to conversation

List of offending drivers

U-Boot Marek Vasut 7 participants 18 messages Jul 26, 2012 – Aug 1, 2012

lore
Share & tools
lore
#0 lore raw

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/blackfin/cpu/serial.c
arch/m68k/cpu/mcf5445x/pci.c
arch/m68k/cpu/mcf547x_8x/pci.c
arch/mips/cpu/mips32/au1x00/au1x00_eth.c
arch/mips/cpu/mips32/au1x00/au1x00_serial.c
arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c
arch/mips/cpu/mips32/incaip/asc_serial.c
arch/mips/cpu/xburst/jz_serial.c
arch/powerpc/cpu/mpc512x/i2c.c
arch/powerpc/cpu/mpc512x/ide.c
arch/powerpc/cpu/mpc512x/pci.c
arch/powerpc/cpu/mpc512x/serial.c
arch/powerpc/cpu/mpc5xx/serial.c
arch/powerpc/cpu/mpc5xx/spi.c
arch/powerpc/cpu/mpc5xxx/i2c.c
arch/powerpc/cpu/mpc5xxx/ide.c
arch/powerpc/cpu/mpc5xxx/pci_mpc5200.c
arch/powerpc/cpu/mpc5xxx/serial.c
arch/powerpc/cpu/mpc5xxx/usb.c
arch/powerpc/cpu/mpc5xxx/usb_ohci.c
arch/powerpc/cpu/mpc8220/fec.c
arch/powerpc/cpu/mpc8220/i2c.c
arch/powerpc/cpu/mpc8220/pci.c
arch/powerpc/cpu/mpc8220/uart.c
arch/powerpc/cpu/mpc824x/pci.c
arch/powerpc/cpu/mpc824x/drivers/i2c/i2c.c
arch/powerpc/cpu/mpc8260/ether_fcc.c
arch/powerpc/cpu/mpc8260/ether_scc.c
arch/powerpc/cpu/mpc8260/i2c.c
arch/powerpc/cpu/mpc8260/pci.c
arch/powerpc/cpu/mpc8260/serial_scc.c
arch/powerpc/cpu/mpc8260/serial_smc.c
arch/powerpc/cpu/mpc8260/spi.c
arch/powerpc/cpu/mpc83xx/pci.c
arch/powerpc/cpu/mpc83xx/pcie.c
arch/powerpc/cpu/mpc85xx/ether_fcc.c
arch/powerpc/cpu/mpc85xx/pci.c
arch/powerpc/cpu/mpc85xx/serial_scc.c
arch/powerpc/cpu/mpc8xx/fec.c
arch/powerpc/cpu/mpc8xx/i2c.c
arch/powerpc/cpu/mpc8xx/lcd.c
arch/powerpc/cpu/mpc8xx/serial.c
arch/powerpc/cpu/mpc8xx/spi.c
arch/powerpc/cpu/mpc8xx/video.c
arch/powerpc/cpu/mpc8xx/wlkbd.c
arch/powerpc/cpu/ppc4xx/4xx_pci.c
arch/powerpc/cpu/ppc4xx/4xx_pcie.c
arch/powerpc/cpu/ppc4xx/4xx_uart.c
arch/powerpc/cpu/ppc4xx/gpio.c
arch/powerpc/cpu/ppc4xx/miiphy.c
arch/powerpc/cpu/ppc4xx/usb.c
arch/powerpc/cpu/ppc4xx/usb_ohci.c
arch/sh/cpu/sh2/watchdog.c
arch/sh/cpu/sh3/watchdog.c
arch/sh/cpu/sh4/watchdog.c
arch/sparc/cpu/leon2/serial.c
arch/sparc/cpu/leon3/serial.c
arch/sparc/cpu/leon3/usb_uhci.c
arch/x86/cpu/sc520/sc520_pci.c

board/BuS/EB+MCF-EV123/cfm_flash.c
board/BuS/EB+MCF-EV123/flash.c
board/LEOX/elpt860/flash.c
board/Marvell/common/flash.c
board/Marvell/common/i2c.c
board/Marvell/common/intel_flash.c
board/Marvell/common/ns16550.c
board/Marvell/common/serial.c
board/Marvell/db64360/mv_eth.c
board/Marvell/db64360/pci.c
board/Marvell/db64460/mv_eth.c
board/Marvell/db64460/pci.c
board/RPXClassic/flash.c
board/RPXlite/flash.c
board/RPXlite_dw/flash.c
board/RRvision/flash.c
board/a3000/flash.c
board/alaska/flash.c
board/altera/common/AMDLV065D.c
board/altera/common/cfide.c
board/altera/common/epled.c
board/altera/common/flash.c
board/altera/common/sevenseg.c
board/amcc/bamboo/flash.c
board/amcc/bubinga/flash.c
board/amcc/common/flash.c
board/amcc/ebony/flash.c
board/amcc/luan/flash.c
board/amcc/ocotea/flash.c
board/amcc/taihu/flash.c
board/amcc/taihu/lcd.c
board/amcc/taishan/lcd.c
board/amcc/walnut/flash.c
board/amcc/yucca/flash.c
board/amirix/ap1000/flash.c
board/amirix/ap1000/pci.c
board/amirix/ap1000/serial.c
board/armltd/integrator/pci.c
board/atc/flash.c
board/atmel/at91rm9200ek/led.c
board/atmel/at91sam9260ek/led.c
board/atmel/at91sam9261ek/led.c
board/atmel/at91sam9263ek/led.c
board/atmel/at91sam9m10g45ek/led.c
board/atmel/at91sam9rlek/led.c
board/bct-brettl2/cled.c
board/bct-brettl2/gpio_cfi_flash.c
board/bct-brettl2/smsc9303.c
board/bf527-ezkit/video.c
board/bf533-ezkit/flash.c
board/bf533-stamp/ide-cf.c
board/bf533-stamp/video.c
board/bf537-stamp/ide-cf.c
board/bf548-ezkit/video.c
board/bmw/flash.c
board/bmw/m48t59y.c
board/bmw/ns16550.c
board/bmw/serial.c
board/c2mon/flash.c
board/c2mon/pcmcia.c
board/calao/sbc35_a9g20/spi.c
board/calao/tny_a9260/spi.c
board/cm-bf527/gpio_cfi_flash.c
board/cm-bf537e/gpio_cfi_flash.c
board/cm-bf537u/gpio_cfi_flash.c
board/cm-bf548/video.c
board/cm4008/flash.c
board/cm41xx/flash.c
board/cm_t35/eeprom.c
board/cm_t35/leds.c
board/cmi/flash.c
board/cobra5272/flash.c
board/cogent/flash.c
board/cogent/lcd.c
board/cogent/pci.c
board/cogent/rtc.c
board/cogent/serial.c
board/cpc45/flash.c
board/cpc45/pd67290.c
board/cpc45/plx9030.c
board/cpu86/flash.c
board/cpu87/flash.c
board/cray/L1/flash.c
board/cu824/flash.c
board/dave/PPChameleonEVB/flash.c
board/dave/PPChameleonEVB/nand.c
board/dave/common/flash.c
board/dave/common/fpga.c
board/dave/common/pci.c
board/davedenx/qong/fpga.c
board/dvlhost/watchdog.c
board/eNET/eNET_pci.c
board/earthlcd/favr-32-ezkit/flash.c
board/eltec/elppc/eepro100_srom.c
board/eltec/elppc/flash.c
board/eltec/elppc/mpc107_i2c.c
board/eltec/elppc/pci.c
board/eltec/mhpc/flash.c
board/emk/common/am79c874.c
board/emk/common/flash.c
board/emk/top9000/spi.c
board/ep8260/flash.c
board/ep8260/mii_phy.c
board/esd/adciop/flash.c
board/esd/ar405/flash.c
board/esd/ash405/flash.c
board/esd/canbt/canbt.c
board/esd/canbt/flash.c
board/esd/cms700/flash.c
board/esd/common/esd405ep_nand.c
board/esd/common/flash.c
board/esd/common/fpga.c
board/esd/common/lcd.c
board/esd/common/pci.c
board/esd/common/xilinx_jtag/
board/esd/cpci2dp/flash.c
board/esd/cpci405/flash.c
board/esd/cpci5200/strataflash.c
board/esd/cpci750/i2c.c
board/esd/cpci750/ide.c
board/esd/cpci750/mv_eth.c
board/esd/cpci750/pci.c
board/esd/cpci750/serial.c
board/esd/cpciiser4/flash.c
board/esd/dasa_sim/eeprom.c
board/esd/dasa_sim/flash.c
board/esd/dp405/flash.c
board/esd/du405/flash.c
board/esd/hh405/flash.c
board/esd/hub405/flash.c
board/esd/ocrtc/flash.c
board/esd/pci405/flash.c
board/esd/pci405/pci405.c
board/esd/pf5200/flash.c
board/esd/plu405/flash.c
board/esd/pmc440/fpga.c
board/esd/tasreg/flash.c
board/esd/vme8349/caddy.c
board/esd/vme8349/pci.c
board/esd/voh405/flash.c
board/esd/vom405/flash.c
board/esd/wuh405/flash.c
board/esteem192e/flash.c
board/etin/debris/flash.c
board/etin/debris/phantom.c
board/etx094/flash.c
board/eukrea/cpu9260/led.c
board/evb64260/eth_addrtbl.c
board/evb64260/eth.c
board/evb64260/flash.c
board/evb64260/i2c.c
board/evb64260/intel_flash.c
board/evb64260/pci.c
board/evb64260/serial.c
board/fads/flash.c
board/fads/lamp.c
board/fads/pcmcia.c
board/flagadm/flash.c
board/freescale/m5253demo/flash.c
board/freescale/m5329evb/nand.c
board/freescale/m5373evb/nand.c
board/freescale/mpc8260ads/flash.c
board/freescale/mpc8266ads/flash.c
board/freescale/mpc832xemds/pci.c
board/freescale/mpc8349emds/pci.c
board/freescale/mpc8349itx/pci.c
board/freescale/mpc8360emds/pci.c
board/freescale/mpc8360erdk/nand.c
board/freescale/mpc837xemds/pci.c
board/freescale/mpc837xerdb/pci.c
board/freescale/p1_p2_rdb/pci.c
board/freescale/p2041rdb/eth.c
board/freescale/p3060qds/eth.c
board/funkwerk/vovpn-gw/flash.c
board/funkwerk/vovpn-gw/m88e6060.c
board/g2000/strataflash.c
board/gdsys/common/miiphybb.c
board/gen860t/beeper.c
board/gen860t/flash.c
board/gen860t/fpga.c
board/genietv/flash.c
board/gth2/ee_access.c
board/gth2/flash.c
board/gw8260/flash.c
board/hermes/flash.c
board/hidden_dragon/flash.c
board/hymod/eeprom.c
board/hymod/env.c
board/hymod/flash.c
board/hymod/input.c
board/icecube/flash.c
board/icu862/flash.c
board/icu862/pcmcia.c
board/idmr/flash.c
board/incaip/flash.c
ard/ip860/flash.c
board/iphase4539/flash.c
board/ivm/flash.c
board/jse/flash.c
board/jse/host_bridge.c
board/keymile/km83xx/km83xx_i2c.c
board/kup/common/flash.c
board/kup/common/pcmcia.c
board/lantec/flash.c
board/linkstation/ide.c
board/logicpd/zoom2/led.c
board/lubbock/flash.c
board/lwmon/flash.c
board/lwmon/pcmcia.c
board/lwmon5/kbd.c
board/manroland/uc100/pcmcia.c
board/matrix_vision/mergerbox/fpga.c
board/matrix_vision/mergerbox/pci.c
board/matrix_vision/mvbc_p/fpga.c
board/matrix_vision/mvblm7/fpga.c
board/matrix_vision/mvblm7/pci.c
board/matrix_vision/mvblx/fpga.c
board/matrix_vision/mvblx/sys_eeprom.c
board/matrix_vision/mvsmr/fpga.c
board/mbx8xx/flash.c
board/mbx8xx/pcmcia.c
board/mcc200/lcd.c
board/micronas/vct/ebi.c
board/micronas/vct/ebi_nor_flash.c
board/micronas/vct/ebi_onenand.c
board/micronas/vct/ebi_smc911x.c
board/micronas/vct/ehci.c
board/micronas/vct/gpio.c
board/micronas/vct/smc_eeprom.c
board/ml2/flash.c
board/ml2/serial.c
board/mousse/flash.c
board/mousse/m48t59y.c
board/mousse/pci.c
board/mpl/common/isa.c
board/mpl/common/kbd.c
board/mpl/common/pci.c
board/mpl/common/usb_uhci.c
board/musenki/flash.c
board/mvblue/flash.c
board/mx1ads/syncflash.c
board/netphone/phone_console.c
board/netphone/flash.c
board/netta/codec.c
board/netta/dsp.c
board/netta/flash.c
board/netta/pcmcia.c
board/netta2/flash.c
board/netvia/flash.c
board/ns9750dev/flash.c
board/ns9750dev/led.c
board/nx823/flash.c
board/o2dnt/flash.c
board/pb1x00/flash.c
board/pcippc2/cpc710_pci.c
board/pcippc2/flash.c
board/pcippc2/fpga_serial.c
board/pcippc2/i2c.c
board/pcippc2/pcippc2_fpga.c
board/pcippc2/sconsole.c
board/pcs440ep/flash.c
board/pm520/flash.c
board/pm826/flash.c
board/pm828/flash.c
board/ppmc7xx/flash.c
board/ppmc7xx/pci.c
board/ppmc8260/strataflash.c
board/prodrive/alpr/fpga.c
board/prodrive/alpr/nand.c
board/prodrive/common/flash.c
board/prodrive/common/fpga.c
board/prodrive/p3mx/mv_eth.c
board/prodrive/p3mx/pci.c
board/prodrive/p3mx/serial.c
board/prodrive/pdnb3/flash.c
board/prodrive/pdnb3/nand.c
board/psyent/pk1c20/led.c
board/quad100hd/nand.c
board/quantum/fpga.c
board/r360mpi/flash.c
board/r360mpi/pcmcia.c
board/rbc823/flash.c
board/rbc823/kbd.c
board/renesas/ap325rxa/cpld-ap325rxa.c
board/renesas/sh7785lcr/rtl8169_mac.c
board/ronetix/pm9261/led.c
board/ronetix/pm9263/led.c
board/rpxsuper/flash.c
board/rpxsuper/mii_phy.c
board/rsdproto/flash.c
board/sacsng/flash.c
board/samsung/goni/onenand.c
board/samsung/smdkc100/onenand.c
board/samsung/universal_c210/onenand.c
board/sandburst/common/flash.c
board/sandburst/common/ppc440gx_i2c.c
board/sandpoint/flash.c
board/sbc405/strataflash.c
board/sbc8349/pci.c
board/scb9328/flash.c
board/siemens/IAD210/flash.c
board/siemens/SCM/flash.c
board/siemens/SCM/fpga_scm.c
board/siemens/common/fpga.c
board/sixnet/flash.c
board/snmc/qs850/flash.c
board/snmc/qs860t/flash.c
board/socrates/nand.c
board/spd8xx/flash.c
board/st-ericsson/u8500/gpio.c
board/stx/stxgp3/flash.c
board/svm_sc8xx/flash.c
board/tcm-bf537/gpio_cfi_flash.c
board/ti/beagle/led.c
board/ti/omap730p2/flash.c
board/tqc/tqm5200/cam5200_flash.c
board/tqc/tqm8272/nand.c
board/tqc/tqm834x/pci.c
board/tqc/tqm85xx/nand.c
board/trizepsiv/eeprom.c
board/utx8245/flash.c
board/v37/flash.c
board/v38b/ethaddr.c
board/vpac270/onenand.c
board/w7o/flash.c
board/w7o/fpga.c
board/westel/amx860/flash.c
board/xaeniax/flash.c
board/xes/common/actl_nand.c
board/xes/common/fsl_8xxx_pci.c

Best regards,
Marek Vasut

#1 lore raw

Hi Marek,

Quoted 8 lines · Marek Vasut

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? How was this list generated?

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

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)

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?

Regards,

Graeme

#2 lore raw

Dear Graeme Russ,

Quoted 9 lines

Hi Marek,

Quoted 6 lines · Marek Vasut

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:

Quoted 5 lines
Quoted 2 lines

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.

Quoted 1 line

How was this list generated?

By hard manual labor (=slavework).

Quoted 1 line

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/ ?

Quoted 6 lines

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.

Quoted 6 lines

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

Quoted 8 lines

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?

Quoted 3 lines

Regards,

Graeme

Best regards,
Marek Vasut

#3 lore raw

Hi Marek,

Quoted 8 lines · Marek Vasut

Dear Graeme Russ,

Quoted 3 lines

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?

In which case you have a board/arch specific function to intialise the pointer :) Hmm, or are we now looking at a variation of my INIT_FUNC architecture where this gets done at compile time?

Regards,

Graeme

#4 lore raw

Dear Graeme Russ,

Quoted 9 lines

Hi Marek,

Quoted 6 lines · Marek Vasut

Dear Graeme Russ,

Quoted 3 lines

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?

Quoted 5 lines
Quoted 2 lines

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

In which case you have a board/arch specific function to intialise the pointer :)

No, you have static platform data which contain the pointer.

Quoted 2 lines

Hmm, or are we now looking at a variation of my INIT_FUNC architecture where this gets done at compile time?

I think you missed the point here

Quoted 3 lines

Regards,

Graeme

Best regards,
Marek Vasut

#5 lore raw

Hi Marek,

Quoted 11 lines · Marek Vasut

Dear Graeme Russ,

Quoted 9 lines

Hi Marek,

Quoted 6 lines · Marek Vasut

Dear Graeme Russ,

Quoted 3 lines

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?

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

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

In which case you have a board/arch specific function to intialise the pointer :)

No, you have static platform data which contain the pointer.

Ah, of course

Quoted 4 lines
Quoted 2 lines

Hmm, or are we now looking at a variation of my INIT_FUNC architecture where this gets done at compile time?

I think you missed the point here

Yes, by --->| |<--- that much :)

Oh, unless of course it has to be done dynamically due to a single U-Boot image supporting multiple board hardware configurations...

Regards

Graeme

#6 lore raw

Dear Graeme Russ,

Quoted 27 lines

Hi Marek,

Quoted 11 lines · Marek Vasut

Dear Graeme Russ,

Quoted 9 lines

Hi Marek,

Quoted 6 lines · Marek Vasut

Dear Graeme Russ,

Quoted 3 lines

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?

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

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

In which case you have a board/arch specific function to intialise the pointer :)

No, you have static platform data which contain the pointer.

Ah, of course

Quoted 3 lines
Quoted 2 lines

Hmm, or are we now looking at a variation of my INIT_FUNC architecture where this gets done at compile time?

Quoted 6 lines
Quoted 1 line

I think you missed the point here

Yes, by --->| |<--- that much :)

Oh, unless of course it has to be done dynamically due to a single U-Boot image supporting multiple board hardware configurations...

Which is not yet happening, let's take small steps, ok?

Quoted 3 lines

Regards

Graeme

Best regards,
Marek Vasut

#7 lore raw
In reply to Marek Vasut

Dear Marek Vasut,

Quoted 147 lines · In message <[email protected]> you wrote:

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:

board/BuS/EB+MCF-EV123/cfm_flash.c
board/BuS/EB+MCF-EV123/flash.c
board/LEOX/elpt860/flash.c
board/Marvell/common/flash.c
board/Marvell/common/intel_flash.c
board/RPXClassic/flash.c
board/RPXlite/flash.c
board/RPXlite_dw/flash.c
board/RRvision/flash.c
board/a3000/flash.c
board/alaska/flash.c
board/altera/common/flash.c
board/amcc/bamboo/flash.c
board/amcc/bubinga/flash.c
board/amcc/common/flash.c
board/amcc/ebony/flash.c
board/amcc/luan/flash.c
board/amcc/ocotea/flash.c
board/amcc/taihu/flash.c
board/amcc/walnut/flash.c
board/amcc/yucca/flash.c
board/amirix/ap1000/flash.c
board/atc/flash.c
board/bct-brettl2/gpio_cfi_flash.c
board/bf533-ezkit/flash.c
board/bmw/flash.c
board/c2mon/flash.c
board/cm-bf527/gpio_cfi_flash.c
board/cm-bf537e/gpio_cfi_flash.c
board/cm-bf537u/gpio_cfi_flash.c
board/cm4008/flash.c
board/cm41xx/flash.c
board/cmi/flash.c
board/cobra5272/flash.c
board/cogent/flash.c
board/cpc45/flash.c
board/cpu86/flash.c
board/cpu87/flash.c
board/cray/L1/flash.c
board/cu824/flash.c
board/dave/PPChameleonEVB/flash.c
board/dave/common/flash.c
board/earthlcd/favr-32-ezkit/flash.c
board/eltec/elppc/flash.c
board/eltec/mhpc/flash.c
board/emk/common/flash.c
board/ep8260/flash.c
board/esd/adciop/flash.c
board/esd/ar405/flash.c
board/esd/ash405/flash.c
board/esd/canbt/flash.c
board/esd/cms700/flash.c
board/esd/common/flash.c
board/esd/cpci2dp/flash.c
board/esd/cpci405/flash.c
board/esd/cpci5200/strataflash.c
board/esd/cpciiser4/flash.c
board/esd/dasa_sim/flash.c
board/esd/dp405/flash.c
board/esd/du405/flash.c
board/esd/hh405/flash.c
board/esd/hub405/flash.c
board/esd/ocrtc/flash.c
board/esd/pci405/flash.c
board/esd/pf5200/flash.c
board/esd/plu405/flash.c
board/esd/tasreg/flash.c
board/esd/voh405/flash.c
board/esd/vom405/flash.c
board/esd/wuh405/flash.c
board/esteem192e/flash.c
board/etin/debris/flash.c
board/etx094/flash.c
board/evb64260/flash.c
board/evb64260/intel_flash.c
board/fads/flash.c
board/flagadm/flash.c
board/freescale/m5253demo/flash.c
board/freescale/mpc8260ads/flash.c
board/freescale/mpc8266ads/flash.c
board/funkwerk/vovpn-gw/flash.c
board/g2000/strataflash.c
board/gen860t/flash.c
board/genietv/flash.c
board/gth2/flash.c
board/gw8260/flash.c
board/hermes/flash.c
board/hidden_dragon/flash.c
board/hymod/flash.c
board/icecube/flash.c
board/icu862/flash.c
board/idmr/flash.c
board/incaip/flash.c
ard/ip860/flash.c
board/iphase4539/flash.c
board/ivm/flash.c
board/jse/flash.c
board/kup/common/flash.c
board/lantec/flash.c
board/lubbock/flash.c
board/lwmon/flash.c
board/mbx8xx/flash.c
board/micronas/vct/ebi_nor_flash.c
board/ml2/flash.c
board/mousse/flash.c
board/musenki/flash.c
board/mvblue/flash.c
board/mx1ads/syncflash.c
board/netphone/flash.c
board/netta/flash.c
board/netta2/flash.c
board/netvia/flash.c
board/ns9750dev/flash.c
board/nx823/flash.c
board/o2dnt/flash.c
board/pb1x00/flash.c
board/pcippc2/flash.c
board/pcs440ep/flash.c
board/pm520/flash.c
board/pm826/flash.c
board/pm828/flash.c
board/ppmc7xx/flash.c
board/ppmc8260/strataflash.c
board/prodrive/common/flash.c
board/prodrive/pdnb3/flash.c
board/r360mpi/flash.c
board/rbc823/flash.c
board/rpxsuper/flash.c
board/rsdproto/flash.c
board/sacsng/flash.c
board/sandburst/common/flash.c
board/sandpoint/flash.c
board/sbc405/strataflash.c
board/scb9328/flash.c
board/siemens/IAD210/flash.c
board/siemens/SCM/flash.c
board/sixnet/flash.c
board/snmc/qs850/flash.c
board/snmc/qs860t/flash.c
board/spd8xx/flash.c
board/stx/stxgp3/flash.c
board/svm_sc8xx/flash.c

Quoted 8 lines

board/tcm-bf537/gpio_cfi_flash.c
board/ti/omap730p2/flash.c
board/tqc/tqm5200/cam5200_flash.c
board/utx8245/flash.c
board/v37/flash.c
board/w7o/flash.c
board/westel/amx860/flash.c
board/xaeniax/flash.c

All these are either

1) old versions of flash drivers that predate the cfi flash implementation, so they could be replaced by the CFI driver (if there was someone to test this)

or

2) very special versions of flash drivers dealing with board specific details that prevent the use of the CFI flash driver, in which case they should remain in the board directories.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of course there's no reason for it, it's just our policy.
#8 lore raw

Dear Wolfgang Denk,

Quoted 6 lines

Dear Marek Vasut,

Quoted 3 lines · In message <[email protected]> you wrote:

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:

[...]

Quoted 5 lines

All these are either

1) old versions of flash drivers that predate the cfi flash implementation, so they could be replaced by the CFI driver (if there was someone to test this)

Well, can they not be replaced either way? Someone will eventually complain if they care enough.

Quoted 5 lines

or

2) very special versions of flash drivers dealing with board specific details that prevent the use of the CFI flash driver, in which case they should remain in the board directories.

Can these not be unified (read stuffed with #ifdef-#endif blocks for now, later replaced with platform data) ?

Quoted 3 lines

Best regards,

Wolfgang Denk

Best regards,
Marek Vasut

#9 lore raw

Dear Marek Vasut,

Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 6 lines

All these are either

1) old versions of flash drivers that predate the cfi flash implementation, so they could be replaced by the CFI driver (if there was someone to test this)

Well, can they not be replaced either way? Someone will eventually complain if they care enough.

No. I will not accept moving reduindant crap into the drivers/ hierarchy. If this is code that can be replaced by using the CFI driver, this reorganization is the point to do it.

If the boards are uinmaintained, then so be it, we will remove broken stuff.

Quoted 6 lines
Quoted 3 lines

2) very special versions of flash drivers dealing with board specific details that prevent the use of the CFI flash driver, in which case they should remain in the board directories.

Can these not be unified (read stuffed with #ifdef-#endif blocks for now, later replaced with platform data) ?

I don't see how this could be done, and it seems not worth the effort to me. I smell most of these are unmaintained boards, and it's easier to clean this up once for all.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of course there's no reason for it, it's just our policy.
#10 lore raw
In reply to Wolfgang Denk
Quoted 10 lines · On Friday 27 July 2012 00:41:45 Wolfgang Denk wrote:
Quoted 5 lines · Marek Vasut

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:

board/bf533-ezkit/flash.c

1) old versions of flash drivers that predate the cfi flash implementation, so they could be replaced by the CFI driver (if there was someone to test this)

yep. this driver is wicked old, and has since languished for a few reasons:
- the people who wrote it originally were (are) not exactly great
programmers. in fact, they were pretty terrible.
- this particular board is one of the first Blackfins to see a real open source
port, but the board itself isn't terribly developer friendly, so no one pays too much attention to it.
- the flash does not support the CFI query command which means none of the
stock CFI code would work out of the box (it does use the AMD CFI commandset though).
- the flash is funky -- it's two chips in a single package which leads to
quite a bit of confusion, and it also has SRAM areas on it !
- the Blackfin maintainers who took over weren't terribly familiar with the
CFI spec (i would say i only have a little familiarity at a higher level).

at any rate, i was able to figure out the JEDEC probe logic in Linux somewhat recently to make it work there, and so i ported that to u-boot which means we can drop this old driver (patches already posted). seems to probe/read/erase/write just fine, so ship it ;).

Quoted 9 lines
Quoted 5 lines

board/bct-brettl2/gpio_cfi_flash.c
board/cm-bf527/gpio_cfi_flash.c
board/cm-bf537e/gpio_cfi_flash.c
board/cm-bf537u/gpio_cfi_flash.c
board/tcm-bf537/gpio_cfi_flash.c

2) very special versions of flash drivers dealing with board specific details that prevent the use of the CFI flash driver, in which case they should remain in the board directories.

yep. these are merely glue to support the flashes on these boards that use GPIO's for additional address lines. they actually use the common CFI code already.

there is a thread from a while ago discussing how to make these work better in the larger u-boot framework (NOR flashes which are not fully directly mapped), but i honestly don't think i'll ever get around to implementing that idea. i have no job that requires it, and only had a passing interest in implementing it ;).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120731/6d6cff13/attachment.pgp>

#11 lore raw
In reply to Marek Vasut

Dear Marek Vasut,

Quoted 3 lines

board/samsung/goni/onenand.c
board/samsung/smdkc100/onenand.c
board/samsung/universal_c210/onenand.c

Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.

Signature · 5 lines
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group
#12 lore raw

Dear Lukasz Majewski,

Quoted 8 lines

Dear Marek Vasut,

Quoted 3 lines

board/samsung/goni/onenand.c
board/samsung/smdkc100/onenand.c
board/samsung/universal_c210/onenand.c

Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.

That's fairy possible, I did only quick inspection and I'll be taking further look this weekend.

Best regards,
Marek Vasut

#13 lore raw

Hi Marek,

Quoted 8 lines · Marek Vasut

Dear Lukasz Majewski,

Quoted 6 lines

Dear Marek Vasut,

Quoted 3 lines

board/samsung/goni/onenand.c
board/samsung/smdkc100/onenand.c
board/samsung/universal_c210/onenand.c

Quoted 5 lines
Quoted 2 lines

Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.

That's fairy possible, I did only quick inspection and I'll be taking further look this weekend.

May be you should do a further look before sending a heads up about everything you see...

Signature · 2 lines
Regards,
Igor.
#14 lore raw

Dear Igor Grinberg,

Quoted 11 lines

Hi Marek,

Quoted 8 lines · Marek Vasut

Dear Lukasz Majewski,

Quoted 6 lines

Dear Marek Vasut,

Quoted 3 lines

board/samsung/goni/onenand.c
board/samsung/smdkc100/onenand.c
board/samsung/universal_c210/onenand.c

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.

That's fairy possible, I did only quick inspection and I'll be taking further look this weekend.

May be you should do a further look before sending a heads up about everything you see...

Where are you aiming with this exactly? I clearly stated I didn't do deep inspection of these and that there might be mishits

Best regards,
Marek Vasut

#15 lore raw
Quoted 16 lines · Marek Vasut

Dear Igor Grinberg,

Quoted 14 lines

Hi Marek,

Quoted 11 lines · Marek Vasut

Dear Lukasz Majewski,

Quoted 8 lines

Dear Marek Vasut,

Quoted 3 lines

board/samsung/goni/onenand.c
board/samsung/smdkc100/onenand.c
board/samsung/universal_c210/onenand.c

Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

That's fairy possible, I did only quick inspection and I'll be taking further look this weekend.

May be you should do a further look before sending a heads up about everything you see...

Where are you aiming with this exactly? I clearly stated I didn't do deep inspection of these and that there might be mishits

Probably, if you send the heads up email after taking a further look, the list would be shorter and hit the right people? Don't you think? Because, if you are going to look into this deeper,
then what the point in sending the "quick look" list?

Signature · 2 lines
Regards,
Igor.
#16 lore raw

Dear Igor Grinberg,

Quoted 23 lines · Marek Vasut
Quoted 22 lines

Dear Igor Grinberg,

Quoted 19 lines

Hi Marek,

Quoted 8 lines · Marek Vasut

Dear Lukasz Majewski,

Quoted 6 lines

Dear Marek Vasut,

Quoted 3 lines

board/samsung/goni/onenand.c
board/samsung/smdkc100/onenand.c
board/samsung/universal_c210/onenand.c

Quoted 5 lines
Quoted 2 lines

Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are.

That's fairy possible, I did only quick inspection and I'll be taking further look this weekend.

May be you should do a further look before sending a heads up about everything you see...

Quoted 7 lines
Quoted 2 lines

Where are you aiming with this exactly? I clearly stated I didn't do deep inspection of these and that there might be mishits

Probably, if you send the heads up email after taking a further look, the list would be shorter and hit the right people? Don't you think? Because, if you are going to look into this deeper,
then what the point in sending the "quick look" list?

http://en.wikipedia.org/wiki/Release_early,_release_often ;-)

Best regards,
Marek Vasut

#17 lore raw
In reply to Marek Vasut

Dear Marek Vasut,

Quoted 7 lines · Marek Vasut

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:

Quoted 6 lines

board/atmel/at91rm9200ek/led.c
board/atmel/at91sam9260ek/led.c
board/atmel/at91sam9261ek/led.c
board/atmel/at91sam9263ek/led.c
board/atmel/at91sam9m10g45ek/led.c
board/atmel/at91sam9rlek/led.c

these atmel specific led stuff is basically for very early debug (switching a LED after relocation, another one after board init, ..). It also provides possibility to use it in assembler code sections e.g. lowlevel_init.

I do not really care about that cause I normally use JTAG to debug early code. The led switching at a specific stage could be done by one of the other generic led drivers.

Beside that, I think for debugging early stage code without JTAG the serial line is much better than a LED which can only provide two states. Has anyone thought about that? Has anyone tried to add some 'early_printf' feature?

Best regards

Andreas Bie?mann