From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Can Guo <cang@codeaurora.org>
Cc: Avri Altman <Avri.Altman@wdc.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
kernel-team@android.com, alim.akhtar@samsung.com,
bvanassche@acm.org, martin.petersen@oracle.com,
stanley.chu@mediatek.com
Subject: Re: [PATCH] scsi: ufs: should not override buffer lengh
Date: Mon, 11 Jan 2021 00:46:43 -0800 [thread overview]
Message-ID: <X/wQcwkdSOTkuFBV@google.com> (raw)
In-Reply-To: <f4f633617ce91628b251b6ba668df820@codeaurora.org>
On 01/11, Can Guo wrote:
> On 2021-01-11 16:15, Avri Altman wrote:
> > >
> > > Sorry, typo corrected.
> > >
> > > Hi Jaegeuk,
> > >
> > > I think the problem is that func ufshcd_read_desc_param() is not
> > > expecting
> > > one access unsupported descriptors on RPMB LU.
> > Correct.
> > This is about wb introducing a new constraint: wb buffer is only
> > allowed in lu 0..7.
> > And this is why, IMHO, the fix should be in ufs_is_valid_unit_desc_lun,
> > To include param offset, as it is only called in contingency of
> > ufshcd_read_desc_param.
> >
> > Thanks,
> > Avri
>
> Yeah... Fixing it in ufs-sysfs.c also works. Anyways, the math in
> ufshcd_read_desc_param is already complex. Let's fix it somewhere
> close to the source/initiator.
Thank you, Can and Avri.
I think fixing the lun check makese sense. Let me post v2. :)
>
> Thanks,
> Can Guo.
prev parent reply other threads:[~2021-01-11 8:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 4:44 [PATCH] scsi: ufs: should not override buffer lengh Jaegeuk Kim
2021-01-11 5:53 ` Can Guo
2021-01-11 6:02 ` Can Guo
2021-01-11 8:15 ` Avri Altman
2021-01-11 8:19 ` Can Guo
2021-01-11 8:46 ` Jaegeuk Kim [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=X/wQcwkdSOTkuFBV@google.com \
--to=jaegeuk@kernel.org \
--cc=Avri.Altman@wdc.com \
--cc=alim.akhtar@samsung.com \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=stanley.chu@mediatek.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