On Thu, Nov 04, 2021 at 11:10:48AM -0600, Jens Axboe wrote: > On 11/4/21 11:07 AM, Luis Chamberlain wrote: > > On Thu, Nov 04, 2021 at 06:53:34AM -0600, Jens Axboe wrote: > >> On 11/4/21 5:49 AM, Jens Axboe wrote: > >>> On Wed, 3 Nov 2021 16:04:23 -0700, Luis Chamberlain wrote: > >>>> Jens, > >>>> > >>>> as requested, I've folded all pending changes into this series. This > >>>> v5 pegs on Christoph's reviewed-by tags and since I was respinning I > >>>> modified the ataprobe and floppy driver changes as he suggested. > >>>> > >>>> I think this is it. The world of floppy has been exciting for v5.16. > >>>> > >>>> [...] > >>> > >>> Applied, thanks! > >>> > >>> [01/14] nvdimm/btt: use goto error labels on btt_blk_init() > >>> commit: 2762ff06aa49e3a13fb4b779120f4f8c12c39fd1 > >>> [02/14] nvdimm/btt: add error handling support for add_disk() > >>> commit: 16be7974ff5d0a5cd9f345571c3eac1c3f6ba6de > >>> [03/14] nvdimm/blk: avoid calling del_gendisk() on early failures > >>> commit: b7421afcec0c77ab58633587ddc29d53e6eb95af > >>> [04/14] nvdimm/blk: add error handling support for add_disk() > >>> commit: dc104f4bb2d0a652dee010e47bc89c1ad2ab37c9 > >>> [05/14] nvdimm/pmem: cleanup the disk if pmem_release_disk() is yet assigned > >>> commit: accf58afb689f81daadde24080ea1164ad2db75f > >>> [06/14] nvdimm/pmem: use add_disk() error handling > >>> commit: 5a192ccc32e2981f721343c750b8cfb4c3f41007 > >>> [07/14] z2ram: add error handling support for add_disk() > >>> commit: 15733754ccf35c49d2f36a7ac51adc8b975c1c78 > >>> [08/14] block/sunvdc: add error handling support for add_disk() > >>> commit: f583eaef0af39b792d74e39721b5ba4b6948a270 > >>> [09/14] mtd/ubi/block: add error handling support for add_disk() > >>> commit: ed73919124b2e48490adbbe48ffe885a2a4c6fee > >>> [10/14] ataflop: remove ataflop_probe_lock mutex > >>> commit: 4ddb85d36613c45bde00d368bf9f357bd0708a0c > >>> [11/14] block: update __register_blkdev() probe documentation > >>> commit: 26e06f5b13671d194d67ae8e2b66f524ab174153 > >>> [12/14] ataflop: address add_disk() error handling on probe > >>> commit: 46a7db492e7a27408bc164cbe6424683e79529b0 > >>> [13/14] floppy: address add_disk() error handling on probe > >>> commit: ec28fcc6cfcd418d20038ad2c492e87bf3a9f026 > >>> [14/14] block: add __must_check for *add_disk*() callers > >>> commit: 1698712d85ec2f128fc7e7c5dc2018b5ed2b7cf6 > >> > >> rivers/scsi/sd.c: In function ‘sd_probe’: > >> drivers/scsi/sd.c:3573:9: warning: ignoring return value of ‘device_add_disk’ declared with attribute ‘warn_unused_result’ [-Wunused-result] > >> 3573 | device_add_disk(dev, gd, NULL); > >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> drivers/scsi/sr.c: In function ‘sr_probe’: > >> drivers/scsi/sr.c:731:9: warning: ignoring return value of ‘device_add_disk’ declared with attribute ‘warn_unused_result’ [-Wunused-result] > >> 731 | device_add_disk(&sdev->sdev_gendev, disk, NULL); > >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> > >> > >> Dropping the last two patches... > > > > Martin K Peterson has the respective patches needed queued up on his tree > > for v5.16: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?h=5.16/scsi-staging&id=e9d658c2175b95a8f091b12ddefb271683aeacd9 > > https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?h=5.16/scsi-staging&id=2a7a891f4c406822801ecd676b076c64de072c9e > > > > Would the last patch be sent once that gets to Linus? > > But that dependency wasn't clear in the patches posted, Sorry my mistake. > and it leaves me > wondering if there are others? There should not be, becauase at least my patches on top of linux-next compiles fine as per 0-day builds on tons of configs. > I obviously can't queue up a patch that > adds a must_check to a function, when we still have callers that don't > properly check it. Absolutely. > That should have been made clear, and that last patch never should've > been part of the series. Please send it once Linus's tree has all > callers checking the result. Indeed. Will track and will do. > > Also curious why drop the last two patches instead just the last one for > > now? > > Sorry, meant just the last one. Ah ok! Luis