All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerald Champagne <gerald.champagne@esstech.com>
To: Andre Hedrick <andre@linux-ide.org>, linux-kernel@vger.kernel.org
Subject: Re: Promise 20268 PCI register decoding
Date: Wed, 16 Jan 2002 19:52:30 -0600	[thread overview]
Message-ID: <3C462E5E.4020802@esstech.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10201161713080.30663-100000@master.linux-ide.org>

I just checked 2.5.3-pre1 and it still makes references to
registers above 0x0f.   I see many references to registers
at  0x11, 0x1b, 0x1f.  For example, the following:

unsigned long atapi_reg	= high_16 + (hwif->channel ? 0x24 : 0x00);

That assumes atapi_reg will be 0x24 beyond the base of bar4 (high_16).
Is my PCI code showing me an incorrect size for bar4, or is this
accessing registers beyond its limits?

Thanks.

Gerald

Andre Hedrick wrote:

> I fixed that problem after it was discovered.
> It is in the newest drivers.
> 
> 
> On Wed, 16 Jan 2002, Gerald Champagne wrote:
> 
> 
>>I thought I understood the way PCI devices are accessed in Linux,
>>but the code for the Promise PCI controllers has me confused.  To
>>me it looks like the code is accessing registers outside the area
>>allocated to the PCI device during initialization.
>>
>>The device is configured with the following resources (on a Mips-based
>>platform):
>>
>>00:08.0 Class 0180: 105a:4d68 (rev 01)
>>         I/O at 0x00000080 [size=0x8]
>>         I/O at 0x00000088 [size=0x4]
>>         I/O at 0x00000090 [size=0x8]
>>         I/O at 0x00000098 [size=0x4]
>>         I/O at 0x000000a0 [size=0x10]
>>         Mem at 0x08004000 [size=0x4000]
>>
>>The Promise code uses registers specified using bar4 but it uses offsets
>>above 0x0f.  Here's an example of the code in drivers/ide/pdc202xx.c:
>>
>>void pdc202xx_reset (ide_drive_t *drive)
>>{
>>         unsigned long high_16   = pci_resource_start(HWIF(drive)->pci_dev, 4);
>>         byte udma_speed_flag    = inb(high_16 + 0x001f);
>>
>>         OUT_BYTE(udma_speed_flag | 0x10, high_16 + 0x001f);
>>         mdelay(100);
>>         OUT_BYTE(udma_speed_flag & ~0x10, high_16 + 0x001f);
>>         mdelay(2000);           /* 2 seconds ?! */
>>}
>>
>>How can the code above try to write to a register 0x1f into a region with
>>a size of 0x10?  Wouldn't that stomp on the registers of some other PCI device?
>>
>>Thanks.
>>
>>Gerald
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at  http://www.tux.org/lkml/
>>
>>
> 
> 
> 
> 



  reply	other threads:[~2002-01-17  1:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-17  1:11 Promise 20268 PCI register decoding Gerald Champagne
2002-01-17  1:14 ` Andre Hedrick
2002-01-17  1:52   ` Gerald Champagne [this message]
2002-01-17 11:49     ` Andre Hedrick

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=3C462E5E.4020802@esstech.com \
    --to=gerald.champagne@esstech.com \
    --cc=andre@linux-ide.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.