Re: [PATCH] scsi: ufs: Consider device limitations for dma_mask
Hi,
On Fri, Jan 11, 2019 at 2:54 PM Bjorn Andersson
wrote:
>
> On Qualcomm SDM845 the capabilities of the UFS MEM controller states
> that it's capable of dealing with 64 bit addresses, but DMA addresses
> are truncated causing IOMMU faults when trying to issue operations.
>
> Limit the DMA mask to that of the device, so that DMA allocations
> is limited to the range supported by the bus and device and not just
> following what the controller's capabilities states.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/scsi/ufs/ufshcd.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 9ba7671b84f8..dc0eb59dd46f 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -8151,11 +8151,14 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
> */
> static int ufshcd_set_dma_mask(struct ufs_hba *hba)
> {
> - if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
> - if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
> - return 0;
> - }
> - return dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(32));
> + u64 dma_mask = dma_get_mask(hba->dev);
> +
> + if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT)
> + dma_mask &= DMA_BIT_MASK(64);
> + else
> + dma_mask &= DMA_BIT_MASK(32);
Just because I'm annoying like that, I'll point out that the above is
a bit on the silly side. Instead I'd do:
if (!(hba->capabilities & MASK_64_ADDRESSING_SUPPORT))
dma_mask &= DMA_BIT_MASK(32);
AKA: your code is masking a 64-bit variable with a value that is known
to be 0x, which is kinda a no-op.
...other than the nit, this seems sane to me.
Reviewed-by: Douglas Anderson
Tested-by: Douglas Anderson
Re: [PATCH] scsi: ufs: Remove select of phy-qcom-ufs from ufs-qcom
Hi, On Fri, Jan 11, 2019 at 7:37 PM Martin K. Petersen wrote: > > > Evan, > > > CONFIG_SCSI_UFS_QCOM selects CONFIG_PHY_QCOM_UFS, assuming that > > this was the only possible PHY driver Qualcomm's UFS controller > > would use. But in SDM845, the UFS driver is bundled into phy-qcom-qmp, > > and phy-qcom-ufs is unused. > > > > Remove the select, since for SDM845 it adds useless drivers to the > > build. > > Applied to 5.1/scsi-queue. Should this be accompanied by a change to arch/arm64/configs/defconfig that sets 'CONFIG_PHY_QCOM_UFS=m'? I don't personally have any non-SDM845 devices to test on, but I'm sorta assuming they will all break without the defconfig update? Added a few more people (and linux-arm-msm list) to this thread in case this matters to anyone. -Doug
Re: [PATCH v4] scsi: ufs: Make sysfs attributes writable
Hi, On Tue, Sep 4, 2018 at 3:29 AM Adrian Hunter wrote: > > On 22/08/18 14:00, Adrian Hunter wrote: > > On 09/08/18 01:44, Evan Green wrote: > >> This change makes the UFS controller's sysfs attributes writable, which > >> will enable users to provision unprovisioned UFS devices, or > >> re-provision unlocked UFS devices. > >> > >> Signed-off-by: Evan Green > > > > Acked-by: Adrian Hunter > > > > This patch has my Ack and Reviewed-by: Stanislav Nijnikov, so can it be > queued for v4.20? There is also Evan's "[PATCH] scsi: ufs: Make sysfs flags > writable" Ping? I came across this patch and Evan's other one and noticed that they haven't been applied though a batch of other SCSI patches for 4.20 were applied about a week ago. Martin: is there something about these patches that needs to change before they can land? We're about to land the two patches into the Chrome OS kernel tree which will remove any built-in reminders we'll have to keep track of upstream progress, so this is probably the final ping from this end until the next major Chrome OS kernel rebase. ;-) -Doug
Re: [PATCH v4] scsi: ufs: Make sysfs attributes writable
Martin, On Tue, Sep 25, 2018 at 6:08 PM Martin K. Petersen wrote: > > Doug, > > > I came across this patch and Evan's other one and noticed that they > > haven't been applied though a batch of other SCSI patches for 4.20 > > were applied about a week ago. Martin: is there something about these > > patches that needs to change before they can land? > > I have simply been awaiting some sort of consensus on the various > competing approaches. Lots of patches posted with tiny incremental fixes > but very little discussion about the merits of one over the other. Ah, perfect information! Thank you! I was just confused because I didn't understand all the status and it just looked like silence here. Maybe someone on this thread can start a discussion with all the stakeholders (people who have been involved in competing patches or other tiny bits and pieces) and summarize their view of the current status? Maybe that would help get the ball rolling again? Thanks again! :) -Doug
Re: [PATCH 1/1] scsi: ufs: make UFS Tx lane1 clock optional
Hi,
On Sun, Oct 7, 2018 at 9:34 PM Can Guo wrote:
>
> From: Venkat Gopalakrishnan
>
> The UFS Tx lane1 clock could be muxed, hence keep it optional by ignoring
> it if it is not provided in device tree.
Thanks for the updated commit message. This makes much more sense now! :-)
> @@ -113,10 +110,10 @@ static void ufs_qcom_disable_lane_clks(struct
> ufs_qcom_host *host)
> if (!host->is_lane_clks_enabled)
> return;
>
> - if (host->hba->lanes_per_direction > 1)
> + if (host->tx_l1_sync_clk)
> clk_disable_unprepare(host->tx_l1_sync_clk);
I don't believe you need the "if". A NULL clock is by definition OK
to enable / disable which is designed to make optional clocks easier
to deal with.
> clk_disable_unprepare(host->tx_l0_sync_clk);
> - if (host->hba->lanes_per_direction > 1)
> + if (host->rx_l1_sync_clk)
> clk_disable_unprepare(host->rx_l1_sync_clk);
optional: Technically this part of the patch wasn't actually needed,
right? "rx_l1_sync_clk" is not optional so that means that
"rx_l1_sync_clk" should be non-NULL exactly when lanes_per_direction >
1.
...but actually I'm fine with keeping this part of your patch for
symmetry. Especially since you can leverage the
clk_disable_unprepare(NULL) to simplify your code. Please mention in
your commit message that this is a cleanup and just for symmetry.
Probably also remove the "if" tests that are guarding
ufs_qcom_host_clk_enable().
> clk_disable_unprepare(host->rx_l0_sync_clk);
>
> @@ -141,24 +138,21 @@ static int ufs_qcom_enable_lane_clks(struct
> ufs_qcom_host *host)
> if (err)
> goto disable_rx_l0;
>
> - if (host->hba->lanes_per_direction > 1) {
> + if (host->rx_l1_sync_clk) {
Similar: the above change isn't required but I'm OK if you want to
make this change for symmetry / to cleanup clock handling. Please
mention in your commit message.
> + /* The tx lane1 clk could be muxed, hence keep this optional */
> + if (host->tx_l1_sync_clk)
> + ufs_qcom_host_clk_enable(dev, "tx_lane1_sync_clk",
> +host->tx_l1_sync_clk);
If "host->tx_l1_sync_clk" is provided then you should still check the
return value of ufs_qcom_host_clk_enable(), right? ...so please leave
the error path here.
> @@ -174,23 +168,33 @@ static int ufs_qcom_init_lane_clks(struct ufs_qcom_host
> *host)
>
> err = ufs_qcom_host_clk_get(dev,
> "rx_lane0_sync_clk", &host->rx_l0_sync_clk);
> - if (err)
> + if (err) {
> + dev_err(dev, "%s: failed to get rx_lane0_sync_clk, err %d",
> + __func__, err);
nit: including "__func__" in dev_xxx() calls is discouraged. The
"dev_xxx" calls already print the device name and the string within a
given device driver should be unique enough so __func__ just adds crap
to the logs. If you really feel that __func__ adds something for you,
try posting up a patch to make all "dev_err" functions include
__func__. ...but I think you'd probably be rejected.
suggestion: you'd save a few lines of code and simplify your probe if
you just passed an "optional" bool to the ufs_qcom_host_clk_get() that
controlled the printout.
> - err = ufs_qcom_host_clk_get(dev, "tx_lane1_sync_clk",
> - &host->tx_l1_sync_clk);
> + /* The tx lane1 clk could be muxed, hence keep this optional
> */
> + ufs_qcom_host_clk_get(dev, "tx_lane1_sync_clk",
> + &host->tx_l1_sync_clk);
To be technically correct you should actually check the error value
returned by ufs_qcom_host_clk_get(). Specifically figure out what the
error value is when "tx_lane1_sync_clk" isn't specified and check for
that.
...one reason this matters is -EPROBE_DEFER. In theory devm_clk_get()
could return -EPROBE_DEFER. In such a case you'd want to exit the
probe, not continue on. It's also just good coding practice to handle
just the error you want though so that if the function returned some
other failing case you'd propagate it down instead of eating it.
If you passed "optional" to ufs_qcom_host_clk_get() as suggested above
you could put this error-code checking in ufs_qcom_host_clk_get() and
return 0 from that function if an optional clock was found to not
exist.
-Doug
Re: [PATCH v2 1/1] scsi: ufs: make UFS Tx lane1 clock optional for QCOM platforms
Hi,
On Thu, Oct 11, 2018 at 5:33 AM Can Guo wrote:
> static int ufs_qcom_host_clk_get(struct device *dev,
> - const char *name, struct clk **clk_out)
> + const char *name, struct clk **clk_out, bool optional)
> {
> struct clk *clk;
> int err = 0;
>
> clk = devm_clk_get(dev, name);
> - if (IS_ERR(clk)) {
> + if (clk == ERR_PTR(-EPROBE_DEFER)) {
> + err = -EPROBE_DEFER;
> + dev_warn(dev, "required clock %s hasn't probed yet, err %d\n",
> + name, err);
> + } else if (IS_ERR(clk)) {
> + if (optional)
> + return 0;
Change this function to:
static int ufs_qcom_host_clk_get(struct device *dev,
const char *name, struct clk **clk_out, bool optional)
{
struct clk *clk;
int err;
clk = devm_clk_get(dev, name);
if (!IS_ERR(clk)) {
*clk_out = clk;
return 0;
}
err = PTR_ERR(clk);
if (optional && err == -ENOENT) {
*clk_out = NULL;
return 0;
}
if (err != -EPROBE_DEFER)
dev_err(dev, "failed to get %s err %d",
name, err);
return err;
}
Specifically:
* Typically it just spams the log to print something when you see an
-EPROBE_DEFER.
* If a clock is optional you should only consider things a success
only if "-ENOENT" was returned. All other errors should be considered
fatal.
* If a clock is optional it's slightly cleaner to set *clk_out to
NULL. I know you're initting global data that happened to already be
NULL by default, but it still feels nice for the abstraction of the
function to do this.
* Please don't pass __func__ to your error messages.
> err = PTR_ERR(clk);
> dev_err(dev, "%s: failed to get %s err %d",
> __func__, name, err);
> @@ -113,10 +119,10 @@ static void ufs_qcom_disable_lane_clks(struct
> ufs_qcom_host *host)
> if (!host->is_lane_clks_enabled)
> return;
>
> - if (host->hba->lanes_per_direction > 1)
> + if (host->tx_l1_sync_clk)
Remove this "if". Always call clk_disable_unprepare() which will be a
no-op if "host->tx_l1_sync_clk" is NULL. clk_disable_unprepare() is a
no-op for NULL clocks by design specifically to make code like this
cleaner.
> clk_disable_unprepare(host->tx_l1_sync_clk);
> clk_disable_unprepare(host->tx_l0_sync_clk);
> - if (host->hba->lanes_per_direction > 1)
> + if (host->rx_l1_sync_clk)
Remove this "if". Always call clk_disable_unprepare() which will be a
no-op if "host->rx_l1_sync_clk" is NULL. clk_disable_unprepare() is a
no-op for NULL clocks by design specifically to make code like this
cleaner.
> clk_disable_unprepare(host->rx_l1_sync_clk);
> clk_disable_unprepare(host->rx_l0_sync_clk);
>
> @@ -141,12 +147,14 @@ static int ufs_qcom_enable_lane_clks(struct
> ufs_qcom_host *host)
> if (err)
> goto disable_rx_l0;
>
> - if (host->hba->lanes_per_direction > 1) {
> + if (host->rx_l1_sync_clk) {
Remove this "if". Always call ufs_qcom_host_clk_enable(). The
clk_prepare_enable() inside ufs_qcom_host_clk_enable() will be a no-op
if "host->rx_l1_sync_clk" is NULL and will return 0 (no error).
> err = ufs_qcom_host_clk_enable(dev, "rx_lane1_sync_clk",
> host->rx_l1_sync_clk);
> if (err)
> goto disable_tx_l0;
> + }
>
> + if (host->tx_l1_sync_clk) {
Remove this "if". Always call ufs_qcom_host_clk_enable(). The
clk_prepare_enable() inside ufs_qcom_host_clk_enable() will be a no-op
if "host->tx_l1_sync_clk" is NULL and will return 0 (no error).
-Doug
Re: [PATCH v3 1/1] scsi: ufs: make UFS Tx lane1 clock optional for QCOM platforms
Hi, On Thu, Oct 11, 2018 at 6:12 PM Can Guo wrote: > + if (err != -EPROBE_DEFER) > + dev_err(dev, "failed to get %s err %d", > + name, err); I wouldn't spin just for this, but if you spin for some other reason you could move the above "dev_err" onto one line now. Sorry: I should have noticed that / done that on my patch... > @@ -141,24 +147,21 @@ static int ufs_qcom_enable_lane_clks(struct > ufs_qcom_host *host) Idea for a future patch: now that I look at what's left of this function you're basically re-implementing clk_bulk_prepare_enable() and clk_bulk_disable_unprepare() now. I bet your code would be cleaner / nicer by switching to that. ...possibly you might need to improve the clk_bulk_get() API to allow for some clock to be optional, but that would be a pretty easy patch to post up. In any case I think it's better to do the clk_bulk switch in a future / separate patch, so: Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson -Doug
Re: [PATCH V14 1/2] scsi: ufs: set the device reference clock setting
Hi,
On Sun, Sep 23, 2018 at 11:29 PM Sayali Lokhande wrote:
> +static struct ufs_ref_clk ufs_ref_clk_freqs[] = {
> + {1920, REF_CLK_FREQ_19_2_MHZ},
> + {2600, REF_CLK_FREQ_26_MHZ},
> + {3840, REF_CLK_FREQ_38_4_MHZ},
> + {5200, REF_CLK_FREQ_52_MHZ},
> + {0, REF_CLK_FREQ_INVAL},
> +};
> +
> +static inline enum ufs_ref_clk_freq
Please don't specify inline. Let the compiler decide whether inline is better.
> +ufs_get_bref_clk_from_hz(u32 freq)
> +{
> + int i = 0;
> +
> + while (ufs_ref_clk_freqs[i].freq_hz != freq) {
> + if (!ufs_ref_clk_freqs[i].freq_hz)
> + return REF_CLK_FREQ_INVAL;
> + i++;
> + }
> +
> + return ufs_ref_clk_freqs[i].val;
I think you'll have less confusion if you write the above as this (untested):
for (i = 0; ufs_ref_clk_freqs[i].freq_hz; i++) {
if (ufs_ref_clk_freqs[i].freq_hz == freq)
return ufs_ref_clk_freqs[i].val;
}
return REF_CLK_FREQ_INVAL;
Now it looks like a normal iteration till a normal stop condition
(NULL term array).
> +void ufshcd_parse_dev_ref_clk_freq(struct ufs_hba *hba)
Shouldn't this return an error code so that if there's a problem it
can return back to the caller? Right now you print error messages but
ufshcd_pltfrm_init() will plow merrily along after.
> +{
> + struct device *dev = hba->dev;
> + struct device_node *np = dev->of_node;
> + struct clk *refclk = NULL;
> + u32 freq = 0;
"freq" should be "unsigned long" to match clk_get_rate(), not u32.
Similarly all the places you pass it to and store it in should be
"unsigned long" too. Save "u32" for values which are being programmed
into 32-bit hardware registers.
> + if (!np)
> + return;
You don't need to check for (!np). If you do clk_get() and there's no
np you'll get get an error back. Handle it there.
> +
> + refclk = of_clk_get_by_name(np, "ref_clk");
> + if (!refclk)
> + return;
I can't quickly tell. Are you intending "ref_clk" to be optional or
required? You check against "NULL" and return with no error message,
so I'm kinda assuming it's optional. ...but:
1. of_clk_get_by_name() doesn't return NULL when the clock wasn't
specified. It returns "-ENOENT". That means that (right now) anyone
who doesn't specify a "ref_clk" will get a crash when you try calling
clk_get_rate() on the error-code-clk.
2. It seems like it would be good to add a comment that
"dev_ref_clk_freq" was already initted to "REF_CLK_FREQ_INVAL in
ufshcd_alloc_host() to make it obvious how people are working that
didn't specify "ref_clk".
One note is that regardless of whether "ref_clk" is optional or
required, something about "ref_clk" should be mentioned in
"Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt" so people
know that's an important clock name.
Yet another note here is that I'm confused why you'd want to use
of_clk_get_by_name(). Why not use clk_get()? You've already got the
"dev" node and clk_get() should be preferred since not everyone uses
device tree.
OK, one last note is that clk_get() could return -EPROBE_DEFER. In
such a case you need to basically cancel your whole probe and
propagate the -EPROBE_DEFER. Make sure you think about that when
you're coding things up.
OK, I lied about the previous one being the last note. Why don't you
just add a bit of code in the ufshcd_init_clocks() loop. If you
notice that the clock name is "ref_clk" (similar to how
__ufshcd_setup_clocks() checks) then you can grab the frequency. Then
you can avoid dealing with all my comments above about
of_clk_get_by_name() and errors and -EPROBE_DEFER...
> + freq = clk_get_rate(refclk);
> +
> + hba->dev_ref_clk_freq =
> + ufs_get_bref_clk_from_hz(freq);
> +
> + if (hba->dev_ref_clk_freq == REF_CLK_FREQ_INVAL)
> + dev_err(hba->dev,
> + "%s: invalid ref_clk setting = %d\n",
> + __func__, freq);
nit: including "__func__" in dev_xxx() calls is discouraged. The
"dev_xxx" calls already print the device name and the string within a
given device driver should be unique enough so __func__ just adds crap
to the logs. If you really feel that __func__ adds something for you,
try posting up a patch to make all "dev_err" functions include
__func__. ...but I think you'd probably be rejected.
Also (more important): You're missing a clk_put(). Thus you're
leaking a reference to "ref_clk".
> +}
> +
> +static int ufshcd_set_dev_ref_clk(struct ufs_hba *hba)
> +{
> + int err, ref_clk = -1;
> + u32 freq = hba->dev_ref_clk_freq;
Ugh, this is ugly. hba->dev_ref_clk_freq could be -1 but you're
jamming it into a u32 here. That doesn't seem so ideal. Are you sure
-1 was the best choice for REF_CLK_FREQ_INVAL?
> +
> + err = ufshcd_query_attr_retry(hba, UPIU_QUERY_OPCODE_READ_ATTR,
> + QUERY_ATTR_IDN_REF_CLK_FREQ,
Re: [PATCH] scsi: ufs: Schedule clk gating work on correct queue
Hi,
On Fri, Oct 5, 2018 at 10:28 AM Evan Green wrote:
>
> With commit 10e5e37581fc ("scsi: ufs: Add clock ungating to a separate
> workqueue"), clock gating work was moved to a
> separate work queue with WQ_MEM_RECLAIM set, since clock
> gating could occur from a memory reclaim context. Unfortunately,
> clk_gating.gate_work was left queued via schedule_delayed_work,
> which is a system workqueue that does not have WQ_MEM_RECLAIM set.
> Because ufshcd_ungate_work attempts to cancel gate_work, the
> following warning appears:
>
> [ 14.174170] workqueue: WQ_MEM_RECLAIM ufs_clk_gating_0:ufshcd_ungate_work
> is flushing !WQ_MEM_RECLAIM events:ufshcd_gate_work
> [ 14.174179] WARNING: CPU: 4 PID: 173 at kernel/workqueue.c:2440
> check_flush_dependency+0x110/0x118
> [ 14.205725] CPU: 4 PID: 173 Comm: kworker/u16:3 Not tainted 4.14.68 #1
> [ 14.212437] Hardware name: Google Cheza (rev1) (DT)
> [ 14.217459] Workqueue: ufs_clk_gating_0 ufshcd_ungate_work
> [ 14.223107] task: ffc0f6a40080 task.stack: ff800a49
> [ 14.229195] PC is at check_flush_dependency+0x110/0x118
> [ 14.234569] LR is at check_flush_dependency+0x110/0x118
> [ 14.239944] pc : [] lr : [] pstate:
> 60c001c9
> [ 14.333050] Call trace:
> [ 14.427767] [] check_flush_dependency+0x110/0x118
> [ 14.434219] [] start_flush_work+0xac/0x1fc
> [ 14.440046] [] flush_work+0x40/0x94
> [ 14.445246] [] __cancel_work_timer+0x11c/0x1b8
> [ 14.451433] [] cancel_delayed_work_sync+0x20/0x30
> [ 14.457886] [] ufshcd_ungate_work+0x24/0xd0
> [ 14.463800] [] process_one_work+0x32c/0x690
> [ 14.469713] [] worker_thread+0x218/0x338
> [ 14.475361] [] kthread+0x120/0x130
> [ 14.480470] [] ret_from_fork+0x10/0x18
>
> The simple solution is to put the gate_work on the same WQ_MEM_RECLAIM
> work queue as the ungate_work.
>
> Fixes: 10e5e37581fc ("scsi: ufs: Add clock ungating to a separate workqueue")
> Signed-off-by: Evan Green
>
> ---
> drivers/scsi/ufs/ufshcd.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Seems sane to me:
Reviewed-by: Douglas Anderson
