public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick Gefre <pfg@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, matthew@wil.cx
Subject: Re: [PATCH] 2.6.10 Altix : ioc4 serial driver support
Date: Wed, 22 Dec 2004 13:53:28 -0600	[thread overview]
Message-ID: <41C9D0B8.9000208@sgi.com> (raw)
In-Reply-To: <20041222134423.GA11750@infradead.org>

Christoph Hellwig wrote:

> So both claim the same PCI ID?  In this case you need to creat a small
> shim driver that exports a pseudo-bus to the serial and ide driver using
> the driver model.  You must never return an error from ->probe if you
> actually use that particular device.
> 

Has this been done before ? Any example I can use ??


> 
> +/* defining this will force the driver to run in polled mode */
> +//#define POLLING_FOR_CHARACTERS
> 
> Again, what's the need for these conditionals?
> 

Most of these are compile options to use/not use particular things/"features". Some were
used during debugging. It's a small thing, I'll delete.


> 
> +/* a table to keep the card names as passed to request_region */
> +static struct {
> +	char c_name[20];
> +} Table_o_cards[IOC4_NUM_CARDS];
> 
> Completely superflous.  Just pass "ioc4_serial" as argument to request_region.
> 

WHAT ?!?!?!?  Then I get nice output that actually identifies each card when I have >1. 8^) Not a 
big thing, I'll delete.


> +
> +	switch (type) {
> +	case IOC4_SIO_INTR_TYPE:
> +		switch (which) {
> +		case IOC4_W_IES:
> +			writel(val, (void *)&mem->sio_ies_ro);
> 
> The second argumnet to writeX (and readX) is actually void __iomem *,
> but to see the difference you need to run sparse (from sparse.bkbits.net)
> over the driver.  Please store all I/O addresses in void __iomem * pointers
> in your structures and avoid the cast here and in all the other places.
> 

So then I'd have to declare the end elements as:
void __iomem foo;

They are 32 bit values, so it's OK to assume that void __iomem is 32bits ?

FWIW I did run sparse and it didn't complain about the readX/writeX.....


> no need to cast the return value from kmalloc (dito for the other places)
> 

Why is that ? Seems if kmalloc returns a void * and the left side is not, a casting is appropriate ?

-- Pat

  parent reply	other threads:[~2004-12-22 19:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-22  0:28 [PATCH] 2.6.10 Altix : ioc4 serial driver support Pat Gefre
2004-12-22 13:44 ` Christoph Hellwig
2004-12-22 14:03   ` Russell King
2004-12-22 15:20     ` Patrick Gefre
2004-12-22 18:49       ` Russell King
2004-12-22 19:53   ` Patrick Gefre [this message]
2004-12-22 20:33     ` Matthew Wilcox
2005-01-03 14:09     ` Christoph Hellwig
2005-01-31 22:45       ` [PATCH] " Pat Gefre
2005-02-01  9:23         ` Christoph Hellwig
2005-02-02 20:36           ` Patrick Gefre
2005-02-02 21:37             ` Bartlomiej Zolnierkiewicz
2005-02-02 21:57             ` Christoph Hellwig
2005-02-07 15:58               ` Patrick Gefre
2005-02-07 16:25                 ` Christoph Hellwig
2005-02-08 16:52                   ` Patrick Gefre
2005-02-08 19:32                     ` Patrick Gefre
2005-02-10 19:09                     ` Jesse Barnes
2005-02-10 19:15                       ` Christoph Hellwig
2005-02-10 21:07                         ` Patrick Gefre
2005-02-17 21:55                           ` Patrick Gefre
  -- strict thread matches above, loose matches on Subject: below --
2004-12-16 22:24 [PATCH] 2.6.10 " Pat Gefre
2004-12-16 22:43 ` Matthew Wilcox
2004-12-16 23:15 ` Christoph Hellwig
2004-12-17 16:24   ` Matthew Wilcox
2004-12-17 22:14   ` Patrick Gefre
2004-12-18 14:51     ` Christoph Hellwig

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=41C9D0B8.9000208@sgi.com \
    --to=pfg@sgi.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox