On Fri, 01 Dec 2006 09:57:59 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Yeah, I saw that. The problem with the driver is that it doesn't
contain any license notice. I'm not sure if it would be okay to read
the driver and use the acquired info to implement GPL driver. I asked
sunix about it
Hello.
Alan wrote:
I believe this is completely the wrong thing to do. Adding a ton of
changes to the existing (and stable) life expired drivers/ide driver
rather than keeping new and risky stuff in the new libata code is bad.
The new and risky stuff is long agon in there.
The existing
Ok I noiw have a copy of the driver which is clearly marked as GPL and
since it credits me anyway makes it clear enough for anyone I'd think
libata driver will follow, just needs a test victim...
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to
Hi All,
Can someone please check if the changes for sata_promise.c - Promise
SATA
mentioned under the following link would make sense to be implemented in
vanilla ?
http://www.linuxquestions.org/linux/answers/Hardware/Promise_FastTrack_P
DC20378_PATA_or_RAID
I've tried the changes in 2.6.18
Alan wrote:
Ok I noiw have a copy of the driver which is clearly marked as GPL and
since it credits me anyway makes it clear enough for anyone I'd think
libata driver will follow, just needs a test victim...
Alan, I have the hardware and I have half-finished driver lying around
somewhere.
Testing the new libata ICH PATA drivers. There's one PATA port on this
chip, and I've got two optical drives connected to it. The master drive
fails to detect. The slave detects and works properly.
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE
Controller (rev 01) (prog-if
On Fri, 1 Dec 2006 19:34:16 +0100 (MET)
Olaf Hering [EMAIL PROTECTED] wrote:
The printk in pci_request_region has 'bar + 1', so 6 should be possible
if i becomes 5.
Does the IO region of the last bar look correct?
I've no idea. That really depends upon the platform.
-
To unsubscribe from
Olaf Hering wrote:
The printk in pci_request_region has 'bar + 1', so 6 should be possible
if i becomes 5.
Does the IO region of the last bar look correct?
I'd say it looks suspicious since it's not adjacent to all the other
regions... In fact, after looking at your /proc/ioports/ I
On Wed, 29 Nov 2006 13:25:18 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Mmmm.. Tejun, here's a clue for what Linus saw on his system:
Right now I'm implementing support for READ/WRITE LONG commands via libata.
And the ata_piix driver gets into a non-recoverable state after successfully
On Fri, 2006-12-01 at 22:05 +0300, Sergei Shtylyov wrote:
Olaf Hering wrote:
The printk in pci_request_region has 'bar + 1', so 6 should be possible
if i becomes 5.
Does the IO region of the last bar look correct?
I think BAR 5 is unassigned by the firmware, though when OF does that,
it
On Sat, 02 Dec 2006 08:53:49 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
In fact, the driver doesn't actually use that BAR 5... Only 0 to 4
afaik.
I think the libata code shouldn't request the BARs it doesn't need or
that problem will hit us in other circumstances. It should only
I don't think that is the problem. pci_request_regions() handles all
this internally. It is incorrect for me to not request BAR 5
if present as nobody else should use that resource with my driver loaded.
The underlying problem appears to be that PPC64 isn't setting up the
resources properly
This patch adds code to fix up the PHYMODE4 align timing
register value on second-generation Promise SATA chips.
Failure to correct this value on non-x86 machines makes
drive detection prone to failure due to timeouts. (I've
observed about 50% detection failure rates on SPARC64.)
The HW boots
This patch performs two simple cleanups of sata_promise.
* Remove board_20771 and map device id 0x3577 to board_2057x.
After the recent corrections for SATAII chips, board_20771 and
board_2057x were equivalent in the driver.
* Remove hp-hotplug_offset and use hp-flags PDC_FLAG_GEN_II
to
On Tue, Nov 28, 2006 at 03:39:29AM -0500, Jeff Garzik wrote:
...
In the future, please use --- not -- as the separator your .sig, so
that it is not copied into the kernel changelog by git-applymbox.
...
-- is the standard separator most MUAs can interpret - --- would
therefore be wrong.
I just rebased all branches of libata-dev.git, and there was a bit of
fallout:
1) Dan, I'll have to ask you to resend your sata_vsc MSI patch yet
again, this time against 2.6.19. Since it was against
drivers/scsi/sata_vsc.c, that caused some cross-directory-move related
problems.
2)
16 matches
Mail list logo
