Re: libata: init ata_print_id to 0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Apr 22, 2012 at 1:38 AM, Tero Roponen <tero.roponen@xxxxxxxxx> wrote:
>
> 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@xxxxxxxxx>

Acked-by: Dan Williams <dan.j.williams@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux