[PATCH] ARM: mach-moxart: platform port for MOXA ART SoC
zonque at gmail.com
Wed Mar 13 14:34:26 EDT 2013
On 13.03.2013 16:37, Jonas Jensen wrote:
> I ask for feedback and to submit (if possible) a new ARM SoC platform
> port. This is now near complete (I think) (tested on UC-7112-LX Plus)
> and applies to 126.96.36.199.
First of all - thanks for submitting to the upstream kernel!
However, your patch has many severe problems which you need to address.
* please rebase your work. 2.6.34 is almost three years old now. 3.9 is
in it's stabilisation phase, and all new support has to be done for 3.10.
* all new platforms must be written with device-tree support
* all drivers must have device-tree support as well
> The patch contains the following drivers and platform specific
> * ARCH_MOXART (FA526 processor)
> * 100Hz interrupt timer
> * UART
> * MTD map driver
> * Ethernet driver (RTL8201CP)
> * MMC driver
> * MOXA Smartio/Industio family multiport serial driver
> * RTC driver
> * Watchdog driver
> * GPIO driver
Never send one big patch but series of smaller ones, so the individual
subsystem maintainers can review and approve their bits.
Please also read Documentation/SubmittingPatches for a lot more
information about this subject.
> Predicted patch rejects below (in need of a solution, feedback is much
> appreciated) because they are critical in areas of boot, MMC and TTY.
> A valid (and unique) architecture ID is not loaded to r1. Looks like
> the bootloader is broken, it should be doing this!
> Omitted (do not edit manually / add a new machine using
> http://www.arm.linux.org.uk/developer/machines/?action=new). A fix to
> this and above is not feasible as long as MOXA withholds bootloader
> sources (requested without success).
> drivers/char/mxser.c drivers/char/mxser.h: MOXA
> SMARTIO/INDUSTIO/INTELLIO SERIAL CARD (Jiří Slabý):
> Force board setup for CONFIG_ARCH_MOXART.
> ASYNCB_CLOSING is avoided because of a lockup (infinite wait after
> tty_wait_until_sent). Why this happens is unknown (to me) I'm hoping
> someone (Jiří?) can shed light. SysRq trace @ http://ideone.com/e845mr
> What significance does ASYNCB_CLOSING have?
> Obviously, automatic detection is better but "mxser_read_register" is
> pointless on this hardware. What to do instead? Is it better to make a
> copy and submit a new driver?
> The MMC controller is "special"? "UNSTUFF_BITS" is redefined here
> . Without the new macro it'll report the wrong geometry and prod_name.
> I'm thinking a driver should never have to redefine UNSTUFF_BITS.
> Possible workaround: modify bits (in driver) to line up as expected
> before returning the response (mmc_request_done).
> For reference, this is my previous post from a few months back:
> Gitweb: http://repo.or.cz/w/linux-188.8.131.52-moxart.git/commitdiff/?h=3bc2e98ebb92961e1c5992736186920cd070f4ee&hp=b7f1d43323eceb02fd663a71eb2f8be9c17e6740
> Download link (size: 193K):
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
More information about the linux-arm-kernel