summaryrefslogtreecommitdiff
path: root/drivers/base
diff options
context:
space:
mode:
authorKrishna Kurapati <quic_kriskura@quicinc.com>2022-08-27 06:15:10 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-09-08 12:11:40 +0300
commit6202637fdef0745a20b68675c4b08e08aa0a6297 (patch)
treebc57a79cb238105a9931741a64076a75eceae557 /drivers/base
parentabe3cfb7a7c8e907b312c7dbd7bf4d142b745aa8 (diff)
downloadlinux-6202637fdef0745a20b68675c4b08e08aa0a6297.tar.xz
usb: gadget: mass_storage: Fix cdrom data transfers on MAC-OS
commit 9d4dc16ec71bd6368548e9743223e449b4377fc7 upstream. During cdrom emulation, the response to read_toc command must contain the cdrom address as the number of sectors (2048 byte sized blocks) represented either as an absolute value (when MSF bit is '0') or in terms of PMin/PSec/PFrame (when MSF bit is set to '1'). Incase of cdrom, the fsg_lun_open call sets the sector size to 2048 bytes. When MAC OS sends a read_toc request with MSF set to '1', the store_cdrom_address assumes that the address being provided is the LUN size represented in 512 byte sized blocks instead of 2048. It tries to modify the address further to convert it to 2048 byte sized blocks and store it in MSF format. This results in data transfer failures as the cdrom address being provided in the read_toc response is incorrect. Fixes: 3f565a363cee ("usb: gadget: storage: adapt logic block size to bound block devices") Cc: stable@vger.kernel.org Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Link: https://lore.kernel.org/r/1661570110-19127-1-git-send-email-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/base')
0 files changed, 0 insertions, 0 deletions