linux-kernel - Re: CSR ARM SoC Subarchitecture preview

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 26 May 2011 17:40:05 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Barry Song <21cnbao@...il.com>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Russell King <linux@....linux.org.uk>,
	Nicolas Pitre <nico@...xnic.net>,
	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: CSR ARM SoC Subarchitecture preview

On Thursday 26 May 2011, Barry Song wrote:
> 2011/5/25 Arnd Bergmann <arnd@...db.de>:
> > On Wednesday 25 May 2011 04:15:12 Barry Song wrote:
> >
> > Regarding platform data, the ideal case would be to not pass any,
> > and have the driver itself enquire the settings by looking at device
> > tree properties. There may be a few cases where that is not possible,
> > or where a callback into platform code ends up simplifying things
> > significantly, but that should stay the exception.
> really. some hardware-related callbacks are now in arch and make
> driver codes simpler and better to cross platform without considering
> trivial hardware details.
> if they are moved to drivers, the drivers will be very ugly with things like:
> #ifdef BOARD_X
> ....
> #elif defined(BOARD_Y)
> ...
> #endif
> that is not what people want.
> 
> so a temp way is maybe providing funtions in arch as exported symbols
> which will be called by drivers. different boards implement them in
> different codes.

We really need to look at this case-by-case. The #ifdef mess you cited
is of course not acceptable, but that my feeling is that in most cases
we can find a much nicer solution. It depends of course on what code
gets run in the board specific fixup.

> > From the little I know about GPS, the controllers have a fairly standardized
> > serial port interface even across vendors. It would be good to be
> > compatible with the existing ones there, e.g. bluetooth or serial GPS that
> > all provide a tty interface. If your's is very different and has a
> > high-level API, you might want to create a new drivers/gps/ subsystem
> > with an architected user interface that works with both your own
> > implementation and the serial ones.
> > Turning a tty into a high-level interface is normally done using a new tty
> > line discipline, similar to how PPP or CAN work over serial lines.
> 
> yes. gps generally is an external module connected to SoC's uart.
> actually, the char device we are talking is more like firmware inside
> a common gps module. it is in lower level than an external interface.
> anyway, csr is a company with gps technology. i'd like to figure out
> whether we can provide a generic framework.

Great! I think many people would appreciate that.

This may actually be as easy as providing a new line discipline with
very simple ioctls (e.g. GPSIO_GET_CURRENT_POSSITION).

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