From: Bart Van Assche <bvanassche@acm.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-scsi@vger.kernel.org,
Adrian Hunter <adrian.hunter@intel.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
Bean Huo <beanhuo@micron.com>, Avri Altman <avri.altman@wdc.com>,
Jinyoung Choi <j-young.choi@samsung.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
Stanley Chu <stanley.chu@mediatek.com>,
Keoseong Park <keosung.park@samsung.com>,
Kiwoong Kim <kwmad.kim@samsung.com>
Subject: Re: [PATCH v3 5/5] scsi: ufs: Allow UFS host drivers to override the sg entry size
Date: Wed, 9 Nov 2022 10:35:18 -0800 [thread overview]
Message-ID: <435bb076-644d-599c-b7ba-cfa630696221@acm.org> (raw)
In-Reply-To: <Y2vwX3XlibvDi70/@sol.localdomain>
On 11/9/22 10:24, Eric Biggers wrote:
> On Tue, Nov 08, 2022 at 03:33:39PM -0800, Bart Van Assche wrote:
>> +config SCSI_UFS_VARIABLE_SG_ENTRY_SIZE
>> + bool "Variable size UTP physical region descriptor"
>> + help
>> + In the UFSHCI 3.0 standard the Physical Region Descriptor (PRD) is a
>> + data structure used for transferring data between host and UFS
>> + device. This data structure describes a single region in physical
>> + memory. Although the standard requires that this data structure has a
>> + size of 16 bytes, for some controllers this data structure has a
>> + different size. Enable this option for UFS controllers that need it.
>
> This shouldn't be a user-selectable option. Just make it be enabled
> automatically when it is needed. Like this:
>
> config SCSI_UFS_VARIABLE_SG_ENTRY_SIZE
> bool
> default y if SCSI_UFS_EXYNOS && SCSI_UFS_CRYPTO
Thanks Eric for having taken a look. I will include the above change in
this patch when I repost it.
> Also, this patch doesn't make sense without the code that actually needs it, so
> I hope you plan to send that upstream too. I haven't been able to do so yet,
> because no platform with this hardware actually can run the upstream kernel at
> all, as far as I know. Maybe commit 06874015327 ("arm64: dts: exynos: Add
> initial device tree support for Exynos7885 SoC") changed that? Any suggestions
> would be greatly appreciated... How are you testing this?
My approach for maintaining the UFS driver in the Android kernel tree is
to keep the diffs between the upstream UFS driver and the driver in the
Android kernel tree as small as possible. This patch has been tested in
the same way as my other UFS driver patches, namely by applying it on
the Android kernel tree and by testing the Android kernel tree. For this
patch in particular "applying" came down to integrating the changes from
this patch that are not yet in the Android kernel tree.
Thanks,
Bart.
prev parent reply other threads:[~2022-11-09 18:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-08 23:33 [PATCH v3 0/5] Prepare for upstreaming Pixel 6 and 7 UFS support Bart Van Assche
2022-11-08 23:33 ` [PATCH v3 1/5] scsi: ufs: Reduce the clock scaling latency Bart Van Assche
2022-11-08 23:33 ` [PATCH v3 2/5] scsi: ufs: Move a clock scaling check Bart Van Assche
2022-11-08 23:33 ` [PATCH v3 3/5] scsi: ufs: Pass the clock scaling timeout as an argument Bart Van Assche
2022-11-08 23:33 ` [PATCH v3 4/5] scsi: ufs: Add suspend/resume SCSI command processing support Bart Van Assche
2022-11-10 11:07 ` Avri Altman
2022-11-22 22:10 ` Bart Van Assche
2022-11-08 23:33 ` [PATCH v3 5/5] scsi: ufs: Allow UFS host drivers to override the sg entry size Bart Van Assche
2022-11-09 8:56 ` Avri Altman
2022-11-09 12:34 ` Christoph Hellwig
2022-11-09 17:29 ` Bart Van Assche
2022-11-15 7:48 ` Christoph Hellwig
2022-11-15 8:56 ` Avri Altman
2022-11-15 19:36 ` Bart Van Assche
2022-11-16 7:06 ` Avri Altman
2022-11-15 19:04 ` Bart Van Assche
2022-11-09 18:24 ` Eric Biggers
2022-11-09 18:35 ` Bart Van Assche [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=435bb076-644d-599c-b7ba-cfa630696221@acm.org \
--to=bvanassche@acm.org \
--cc=adrian.hunter@intel.com \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=ebiggers@kernel.org \
--cc=geert@linux-m68k.org \
--cc=j-young.choi@samsung.com \
--cc=jaegeuk@kernel.org \
--cc=jejb@linux.ibm.com \
--cc=keosung.park@samsung.com \
--cc=kwmad.kim@samsung.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=stanley.chu@mediatek.com \
--cc=yoshihiro.shimoda.uh@renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox