linux-kernel - Re: [PATCH] drivers/char/moxa.c, kernel 2.6.23.14

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

Message-ID: <Pine.LNX.4.64.0801250013410.3424@dbs1.uni-c.dtu.dk>
Date:	Fri, 25 Jan 2008 00:34:36 +0100 (CET)
From:	"Oyvind Aabling" <Oyvind.Aabling@...-c.dk>
To:	Jiri Slaby <jirislaby@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers/char/moxa.c, kernel 2.6.23.14

On Wed, 23 Jan 2008, Jiri Slaby wrote:

> On 01/22/2008 11:23 AM, Oyvind Aabling wrote:
>> On Mon, 21 Jan 2008, Jiri Slaby wrote:
>>> Would you be willing to test such a patch for point no. 3?
>> 
>> Yes, I could do that.
>> 
>> I can see your point about the non-portability of it, but
>> how about this scenario, to provide backwards compatibility:
>> 
>> * We keep the (ugly and non-compatible) MOXA_GET_CONF
>>   ioctl, to avoid breaking the old moxaload.
>>   Let's rename it to MOXA_GET_CONF_OLD or MOXA_GET_CONF_BAD in the driver.
>> * Create a new MOXA_GET_CONF ioctl (with a new
>>   number, of course), that does it "the right way".
>>   If you don't like renaming ioctl's, we need a new name for this one.
>> * Rewrite moxaload to either do a kernel version check
>>   and use the new ioctl if available or the old if not.
>>   Or skip that and let it call the new ioctl first.
>>   If it succeeds (system running a newer kernel): fine, and
>>   if not (system running an older kernel), use the old ioctl.
>> 
>> The MOXA Intellio driver and moxaload have been "broken" ever since they
>> were written in 1999, and this way, we don't break anything - you can
>> use old or new kernel, and old or new moxaload in any combination.
>> 
>> Whaddaya think ?
>
> We won't need anything from that. I'm almost done with firmware support. The 
> only thing you'll need to do is to copy the .cod file(s) into /lib/firmware 
> or wherever your firmware loader (probably udev nowadays) finds such files.
>
> Could you post me lspci -vvxxx output of your moxa card?
>
> thanks,
> --js

Ah, I see, you want to get rid of moxaload altogether ...

I'll test your patch series as soon as I get a chance - need to put a
MOXA card into a non-production machine first, so it'll be a few days.

We have a few MOXA Intellio C320 Turbo PCI
cards, here's lspci -vvxxx for one of them:

02:02.0 Serial controller: Moxa Technologies Co Ltd Intellio C320 Turbo PCI (rev 02) (prog-if 80)
         Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
         Interrupt: pin A routed to IRQ 16
         Region 1: I/O ports at 9400 [size=128]
         Region 2: Memory at fb200000 (32-bit, non-prefetchable) [size=16K]
00: 93 13 00 32 03 00 80 02 02 80 00 07 08 00 00 00
10: 00 00 00 00 01 94 00 00 00 00 20 fb 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The other cards looks identical, except for unimportant differences
in region mapping and IRQ allocation due to system differences.

Øyvind.

**************************************************************************
* Øyvind Aabling     E-mail : Oyvind.Aabling@...-c.dk    /~\ The ASCII   *
* UNI-C Lyngby       Phone  : +45 35 87 88 89            \ / Ribbon      *
* DTU Building 304   Phone  : +45 35 87 89 51 (direct)    X  Campaign    *
* DK-2800 LYNGBY     Fax    : +45 35 87 89 90            / \ Against     *
* Denmark                                                    HTML Email! *
**************************************************************************