• Tero Roponen's avatar
    libata: init ata_print_id to 0 · a78f57af
    Tero Roponen authored
    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 85d6725b ("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: default avatarTero Roponen <tero.roponen@gmail.com>
    Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
    Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
    a78f57af
libata-core.c 173 KB