Hi,
2011/2/15 Marcel Janssen korgull@home.nl:
On Tuesday, February 15, 2011 07:43:34 pm Remy Bohmer wrote:
Hi,
2011/2/13 Marcel Janssen korgull@home.nl:
From: Marcel korgull@home.nl
Signed-off-by: Marcel korgull@home.nl
arch/arm/cpu/arm926ejs/at91/led.c | 119 +++++++++++++++++++++++++++++++++-
Why is this part if this patch? It does not seem to be related to USB stuff. Please make it a seperate patch.
I optionally use the LED's in DFU mode so that there's interaction while upgrading the board.
U-boot has a terminal/monitor. It is not up to the driver to control LEDs that might or might not be on a board.
You might believe the host could handle this, but I like the device to indicate activity as well. Somehow I couldn't get it working without changing led.c I think, but I may have missed something.
The problem is here that you mix up sub-systems. Modifying LED code should be independent from USB driver code, and really not in the same patch.
common/Makefile | 1 + common/update_dfu.c | 2 - drivers/usb/gadget/usbdfu.c | 14 +++--
These files should be completely generic code, that even would work on X86, PowerPC and so on.
drivers/usb/gadget/atmel_usba_udc.c | 8 +-
Only this driver file should be Atmel USBA specific, but NOT SoC specific, and absolutely not board or board config related.
Please, only make a patch series with only USB-DFU stuff in it, drop the add-board code from this series. The board code is not acceptable for mainstream since it does not follow the new u-boot-atmel->rework110202 tree style of adding at91 boards. It will take you a huge amount of effort to make it suitable. Further, both parts of the patch series are not related and you are now creating a link between the Atmel tree and the USB tree, which makes it even more difficult.
I'm actually busy fixing the board code for u-boot-atmel->rework110202
Most of it is working so I hope I can create the patches as you like them.
Hmm, Let's make it even more black/white: I do not have to like the board code. ;-) Reinhard is the Atmel maintainer. He needs to pull in the Board code. I only care about generic USB code... ;-)))
Please make 2 unrelated patch series (1 series for USB DFU support, 1 series for board support), or it will never hit mainline... AND: I would really recommend to build a decent USB/DFU patch series first. Forget the board for now. The board seems to depend on DFU support, not the other way around. If generic DFU code is really generic and acceptable, I will pull it in my tree. I am willing to fix small issues in the series to assist you, but I will not do major redesigns...
Kind regards,
Remy