Date: Thu, 23 Jan 2025 11:42:07 +0900 From: Jaeyoon Choi <j_yoon.choi@samsung.com> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-hackers@FreeBSD.org" <freebsd-hackers@freebsd.org> Subject: Re: Universal Flash Storage Driver Proposal Message-ID: <20250123024207epcms2p1782d2ff74077c1f215fbdb0ae5f3aa09@epcms2p1> In-Reply-To: <CANCZdfpVZhQ7dO5qzm9XDTA4qirOmoA-NLx-V5QmEpm_-9g43g@mail.gmail.com> References: <CANCZdfpVZhQ7dO5qzm9XDTA4qirOmoA-NLx-V5QmEpm_-9g43g@mail.gmail.com> <20250117045346epcms2p61099ea651d3ca3f00e3134dd00e6a9ac@epcms2p6> <CANCZdfotpi0W8ivsShzvWqgaCQhCOU0enb_RrPn7QdMEvvXpnw@mail.gmail.com> <20250121002602epcms2p6067990e98b8143ff596d90af0ec54492@epcms2p6> <CGME20250117045346epcms2p61099ea651d3ca3f00e3134dd00e6a9ac@epcms2p1>
next in thread | previous in thread | raw e-mail | index | archive | help
=20 > Generally, yes. However, looking at umass, you'll see that different kind= s of USB > thumb drives have different subsets of SCSI that are supported. For examp= le, RBC > is a reduced subset of commands, and umass filters things so that we have= the right > length (only READ(10) and WRITE(10) are supported for RBC, for example). = I'd image > there'd be a similar list for UFS and you'd need to arrange for scsi_da t= o only generate > those. It looks like some kind of quirk info is going on to force this, b= ut I've not puzzled > through all the layers to find it. umass also does some minor CDB rewriti= ng for things > like ATAPI that are close. UFI also has a different subset that's support= ed. Thanks for letting me know, I will study the scsi_da code more. > Right now that's all handled by the SIM setting cpi.hba_misc =7C=3D PIM_N= O_6_BYTE for > the CAM_PATH_INQ xpt request. You may need to create a PIM_NO_10_BYTE if > only the 12 byte variants are supported, or find some other way to signal= to scsi_da that > it must choose a different way to generate commands (if say a single bit = isn't enough, > or it turns into too much of a specialty quirk flag) There are three restrictions that I found in UFS spec (MODE SENSE(6), READ(= 12) and WRITE(12)), I think adding the following two flags to cpi.hba_misc should be enough: - PIM_NO_12_BYTE - PIM_NO_6_BYTE_MODE_SENSE But I'll take a look at the UFS spec documentation to see if there are more restrictions needed. > Though having said that, I kinda think > we can retire all the 6-byte command support: we don't need it on anythin= g modern and > it really is there for the pre-scsi-1 SASI drives that we don't support= =5B*=5D. We may also want > to rework the number of special cases we have in scsi_da.c as well. There= 's a number > of quirks that either go away with no-6-byte commands, or that can be gue= ssed w/o a loud > message to the user (which is why we avoid sending them with the quirk, t= hough some > of that avoidance is because some early drives hung).=C2=A0=0D=0A=0D=0AI= =20don't=20know=20if=20this=20helps,=20but=20Fuchsia=20OS=20has=20decided= =20not=20to=20support=0D=0AREAD(6)/WRITE(6)=20commands.=0D=0A(Fuchsia's=20S= CSI=20layer=20is=20still=20in=20the=20early=20stages=20of=20development)=0D= =0A-=20https://fuchsia-review.googlesource.com/c/fuchsia/+/932832/comments/= 72826c28_c48b071d?tab=3Dcomments=0D=0A=0D=0A>=20So=20the=20SCSI=20protocol= =20likely=20can=20still=20be=20used,=20but=20some=20adjustments=20might=20b= e=20needed=0D=0A>=20to=20the=20SCSI=20transport=20(though=20the=20distincti= on=20between=20the=20two=20can=20get=20rather=20confused=20at=0D=0A>=20time= s).=20=20Eg,=20I=20think=20eventually=20you'll=20find=20you'll=20want=20a= =20XPORT_UFS=20to=20sit=20along=20side=0D=0A>=20XPORT_FC,=20XPORT_SPI,=20XP= ORT_SAS,=20etc.=20I=20think=20the=20protocol=20will=20be=20PROTO_SCSI=0D=0A= >=20for=20everything.=20Each=20of=20the=20transports=20can=20and=20do=20rep= ort=20slightly=20different=20things=20in=20handled=0D=0A>=20by=20XPT_GET_TR= AN_SETTINGS=20and=20XPT_SET_TRAN_SETTINGS=20messages.=0D=0A=0D=0AI=20was=20= confusing=20SCSI=20protocol=20and=20SCSI=20transport.=20Thanks=20for=20the= =20clarification.=0D=0AI=20agree=20with=20you=20that=20we=20should=20add=20= XPORT_UFS.=20I=20will=20study=20it=20more=20and=20share=0D=0Amy=20design.= =0D=0A=0D=0A>=20I=20hope=20my=20advice=20is=20useful.=20Also,=20although=20= I've=20given=20talks=20on=20this=20topic,=20you=20should=20double=0D=0A>=20= check=20anything=20I=20said=20in=20those=20talks=20or=20that=20I=20say=20he= re.=20(a)=20It=20will=20help=20you=20learn=20CAM=20better=0D=0A>=20and=20(b= )=20some=20of=20these=20details=20I=20only=20think=20I=20know=20and=20under= stand,=20but=20I'm=20missing=20something=0D=0A>=20subtle=20(if=20I=20knew= =20which=20points,=20I'd=20say=20:).=0D=0A>=20=0D=0A>=20Good=20luck=20with= =20everything,=20and=20don't=20hesitate=20to=20ask=20if=20you=20have=20ques= tions,=20want=20some=20early=0D=0A>=20code=20review,=20design=20advice,=20e= tc.=0D=0A=0D=0AI=20was=20confused=20and=20your=20advice=20cleared=20up=20a= =20lot=20of=20my=20questions.=0D=0AI=20will=20definitely=20check=20out=20yo= ur=20talks=20again.=0D=0A=0D=0AHere=20are=20a=20few=20questions=20that=20co= me=20to=20mind:=0D=0A1.=20i'm=20trying=20to=20take=20the=20overall=20struct= ure=20similar=20to=20NVMe,=20is=20that=20okay?=0D=0A=20=20=20(nvme_controll= er,=20nvme_namespace,=20nvme_qpair,=20nvme_request,=20nvme_tracker,=0D=0A= =20=20=20etc.)=0D=0A2.=20is=20there=20any=20tool=20or=20test=20I=20can=20tr= y=20to=20test=20the=20block=20device=20while=20I'm=0D=0A=20=20=20developing= ,=20I'm=20curious=20to=20know=20how=20you=20are=20testing=20it.=0D=0A=0D=0A= FYI,=20I'll=20be=20out=20of=20the=20office=20for=205=20weeks=20starting=20i= n=20February,=20so=20I'll=0D=0Aprobably=20start=20development=20in=20mid-Ma= rch.=0D=0APerhaps=20I=20can=20ask=20more=20detailed=20questions=20at=20that= =20time.=0D=0A=0D=0AThank=20you,=0D=0AJaeyoon=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250123024207epcms2p1782d2ff74077c1f215fbdb0ae5f3aa09>