From: Martin Dalecki <dalecki@evision-ventures.com>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [patch] New driver for Artop [Acard] controllers.
Date: Fri, 24 May 2002 16:07:01 +0200 [thread overview]
Message-ID: <3CEE4905.5010503@evision-ventures.com> (raw)
In-Reply-To: <Pine.SOL.4.30.0205241620440.16894-100000@mion.elka.pw.edu.pl> <20020524165021.B10656@ucw.cz>
Uz.ytkownik Vojtech Pavlik napisa?:
> On Fri, May 24, 2002 at 04:29:39PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
>>Hi!
>>
>>I have a very quick look over patch/driver... looks quite ok...
>>
>>But it doesn't support multiple controllers.
>
>
> Yes, right! That's a bug. Ahh, that's why all the drivers use the PCI
> device id over and over and over in the sources ...
>
>
>>We should add 'unsigned long private' to 'ata_channel struct' and
>>store index in the chipset table there.
>
>
> That'd be great. Though I prefer void*. Looks like "drive_data" is
> intended for that purpose. Martin: How about renaming this to "private"
> and a comment "solely for use by chip-specific drivers"?
Indeed strcut ata_channel should be virtualized this way.
However you can't reuse drive_data for this purpose - that
get's consumed by ide-scsi already if I remember correctly.
(Will have to double check.)
>
> A private member in the ata_pci_device[] struct would be also very
> useful. Or is the "extra" field for that?
extra is it already for host chip driver specific flags.
pdc202xx is the only one using it. Indeed this should be moved
to a void *private as well.
But anyway principally I agree with all the suggestions.
BTW.> Please note that right now we have a bit
of dichotomy about where the actual driver
methods get stored, after I have generalized the registration
of the driver. This should be unified at some point in time as well.
(xxxproc and udma_xxx method famili is what I have in mind here.)
>>You can remove duplicate entries from module data table.
>
>
> I wonder how they got there ...
Already gone in nr. 70.
>>BTW: please don't touch pdc202xx.c I am playing with it...
>
>
> Ok, I won't. Send it to me for comments later.
You guys are reducing me more and more to a spinnlock for
synchronization ;-).
next prev parent reply other threads:[~2002-05-24 15:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-24 14:29 [patch] New driver for Artop [Acard] controllers Bartlomiej Zolnierkiewicz
2002-05-24 13:33 ` Martin Dalecki
2002-05-24 14:50 ` Vojtech Pavlik
2002-05-24 14:07 ` Martin Dalecki [this message]
2002-05-24 15:17 ` Vojtech Pavlik
2002-05-24 15:29 ` Vojtech Pavlik
2002-05-24 15:57 ` Vojtech Pavlik
2002-05-25 5:07 ` Andre Hedrick
2002-05-26 9:50 ` Andre Hedrick
2002-05-26 11:08 ` Vojtech Pavlik
2002-05-26 11:05 ` Vojtech Pavlik
2002-05-26 12:42 ` Ruth Ivimey-Cook
2002-05-26 12:48 ` Vojtech Pavlik
2002-05-26 23:08 ` Andre Hedrick
2002-05-27 0:42 ` Alan Cox
2002-05-27 0:17 ` Andre Hedrick
2002-05-28 14:09 ` Rob Landley
2002-05-29 8:15 ` Vojtech Pavlik
2002-05-27 3:57 ` Copyright Violation (Re: [patch] New driver for Artop [Acard] controllers.) Andre Hedrick
2002-05-27 15:04 ` Pavel Machek
2002-05-27 14:58 ` [patch] New driver for Artop [Acard] controllers Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2002-05-24 13:46 Vojtech Pavlik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CEE4905.5010503@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.