linux-kernel - [PATCH] ARM: mach-moxart: platform port for MOXA ART SoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACmBeS05cyT8N9nZeqbJUPMSGeZYLWjL0Tu1GSZ-ms+Hjc0UoQ@mail.gmail.com>
Date:	Wed, 13 Mar 2013 16:37:16 +0100
From:	Jonas Jensen <jonas.jensen@...il.com>
To:	linux-arm-kernel@...ts.infradead.org, linux-mmc@...r.kernel.org,
	jirislaby@...il.com, linux@....linux.org.uk
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH] ARM: mach-moxart: platform port for MOXA ART SoC

Hi,

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 2.6.34.14.

The patch contains the following drivers and platform specific implementations:

* 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

Predicted patch rejects below (in need of a solution, feedback is much
appreciated) because they are critical in areas of boot, MMC and TTY.

arch/arm/boot/compressed/head.S:
A valid (and unique) architecture ID is not loaded to r1. Looks like
the bootloader is broken, it should be doing this!
http://gicl.cs.drexel.edu/people/sevy/linux/ARM_Linux_boot_sequence.html

arch/arm/tools/mach-types:
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?

drivers/mmc/core/sd.c:
The MMC controller is "special"? "UNSTUFF_BITS" is redefined here
http://repo.or.cz/w/linux-2.6.19-moxart.git/blob/50cdf2c57662f9f69c5615976412f76bfd73311a:/drivers/mmc/mmc.c
. 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:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137130.html

Gitweb: http://repo.or.cz/w/linux-2.6.34.14-moxart.git/commitdiff/?h=3bc2e98ebb92961e1c5992736186920cd070f4ee&hp=b7f1d43323eceb02fd663a71eb2f8be9c17e6740

Download link (size: 193K):
https://linux-2-6-34-14-moxart.googlecode.com/files/linux-2.6.34.14-moxart.patch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/