libata: init ata_print_id to 0
authorTero Roponen <tero.roponen@gmail.com>
Sun, 22 Apr 2012 08:38:00 +0000 (11:38 +0300)
committerJeff Garzik <jgarzik@redhat.com>
Thu, 3 May 2012 18:07:59 +0000 (14:07 -0400)
When comparing the dmesg between 3.4-rc3 and 3.4-rc4 I found the
following differences:

 -ata1: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff100 irq 47
 -ata2: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff180 irq 47
 -ata3: DUMMY
 +ata2: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff100 irq 47
 +ata3: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff180 irq 47
  ata4: DUMMY
  ata5: DUMMY
 -ata6: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff380 irq 47
 +ata6: DUMMY
 +ata7: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff380 irq 47

The change of numbering comes from commit 85d6725b7c0d7e3f ("libata:
make ata_print_id atomic") that changed lines like

ap->print_id = ata_print_id++;
to
ap->print_id = atomic_inc_return(&ata_print_id);

As the latter behaves like ++ata_print_id, we must initialize
it to zero to start the numbering from one.

Signed-off-by: Tero Roponen <tero.roponen@gmail.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
drivers/ata/libata-core.c

index 28db50b..23763a1 100644 (file)
@@ -95,7 +95,7 @@ static unsigned int ata_dev_set_xfermode(struct ata_device *dev);
 static void ata_dev_xfermask(struct ata_device *dev);
 static unsigned long ata_dev_blacklisted(const struct ata_device *dev);
 
-atomic_t ata_print_id = ATOMIC_INIT(1);
+atomic_t ata_print_id = ATOMIC_INIT(0);
 
 struct ata_force_param {
        const char      *name;