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] [day] [month] [year] [list]

Message-ID: <BANLkTikN+y4XXr2nk8OCF477a3JmJbvizQ@mail.gmail.com>
Date:	Mon, 30 May 2011 22:56:15 +0800
From:	Barry Song <21cnbao@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
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

2011/5/26 Arnd Bergmann <arnd@...db.de>:
> 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).

yes. i believe that makes more senses than a simple char-based device
or misc device. the internal gps can still show as a /dev/ttyGPS or
something with a new ldisc.

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