All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: [PATCH] libata: fix class handling in ata_bus_probe()
Date: Mon, 13 Mar 2006 03:34:00 +0900	[thread overview]
Message-ID: <44146998.6070203@gmail.com> (raw)
In-Reply-To: <44146758.6090006@garzik.org>

Jeff Garzik wrote:
> Tejun Heo wrote:
> 
>> ata_bus_probe() didn't set classes[] properly for port disabled case
>> of ->phy_reset() compatibility path.  This patch moves classes[]
>> initialization and normalization out of ->probe_reset block such that
>> it applies to both ->probe_reset and ->phy_reset paths.
>>
>> Signed-off-by: Tejun Heo <htejun@gmail.com>
>>
>> ---
>>
>> Jeff, the sata_nv case is similar bug as what Jiri reported, except
>> that this one is affecting ->phy_reset path.
>>
>> This patch should fix sata_nv.  For sata_mv, I have no idea at all.
> 
> 
> 
> Yep, that solves that bug.  I spotted another minor one:
> 
>> libata version 1.20 loaded.
>> sata_nv 0000:00:07.0: version 0.8
>> ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
>> GSI 18 sharing vector 0xC1 and IRQ 18
>> ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [LSA0] -> GSI 23 (level, 
>> high) -> IRQ 193
>> PCI: Setting latency timer of device 0000:00:07.0 to 64
>> ata1: SATA max UDMA/133 cmd 0x28D0 ctl 0x28FA bmdma 0x28B0 irq 193
>> ata2: SATA max UDMA/133 cmd 0x28D8 ctl 0x28FE bmdma 0x28B8 irq 193
>> ata1: SATA link up 1.5 Gbps (SStatus 113)
>> ata1: dev 0 cfg 49:2f00 82:3469 83:7f61 84:4003 85:3469 86:3e41 
>> 87:4003 88:407f
>> ata1: dev 0 ATA-6, max UDMA/133, 488281250 sectors: LBA48
>> nv_sata: Primary device added
>> nv_sata: Primary device removed
>> nv_sata: Secondary device added
>> nv_sata: Secondary device removed
>> ata1: dev 0 cfg 49:2f00 82:3469 83:7f61 84:4003 85:3469 86:3e41 
>> 87:4003 88:407f
>> ata1: dev 0 configured for UDMA/133
> 
> 
> The dev 0 id words are printed twice, but should not be.  Or, the second 
> one should only be printed if something relevant changed.
> 

The duplicated messages are KERN_DEBUG messages which usually won't show 
up on the console. Still, yeah, annonying. I'll send a patch which 
changes the code such that the message isn't printed the second time 
(during revalidation) tomorrow. I gotta sleep now.

Good night.

-- 
tejun

  reply	other threads:[~2006-03-12 18:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-12 15:42 current #upstream bug? Jeff Garzik
2006-03-12 16:57 ` [PATCH] libata: fix class handling in ata_bus_probe() Tejun Heo
2006-03-12 17:50   ` Jeff Garzik
2006-03-12 18:24   ` Jeff Garzik
2006-03-12 18:34     ` Tejun Heo [this message]
2006-03-13  5:33     ` [PATCH] libata: clean up IDENTIFY printing Tejun Heo
2006-03-13  5:48       ` Tejun Heo
2006-03-13  5:52         ` Jeff Garzik
     [not found]           ` <20060313064016.GA26732@htj.dyndns.org>
2006-03-13  7:42             ` Jeff Garzik
2006-03-13 10:51               ` [PATCH 2/2] libata: move IDENTIFY info printing from ata_dev_read_id() to ata_dev_configure() Tejun Heo
     [not found]               ` <20060313104804.GA29996@htj.dyndns.org>
2006-03-17  0:23                 ` [PATCH 1/2] libata: use local *id instead of dev->id in ata_dev_configure() Jeff Garzik
2006-03-13  5:51       ` [PATCH] libata: clean up IDENTIFY printing Jeff Garzik

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=44146998.6070203@gmail.com \
    --to=htejun@gmail.com \
    --cc=jeff@garzik.org \
    --cc=linux-ide@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.