Skip site navigation (1)Skip section navigation (2)
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>