All of lore.kernel.org
 help / color / mirror / Atom feed
From: Can Guo <cang@codeaurora.org>
To: Stanley Chu <stanley.chu@mediatek.com>
Cc: linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
	andy.teng@mediatek.com, jejb@linux.ibm.com,
	chun-hung.wu@mediatek.com, kuohong.wang@mediatek.com,
	linux-kernel@vger.kernel.org, avri.altman@wdc.com,
	linux-mediatek@lists.infradead.org, peter.wang@mediatek.com,
	alim.akhtar@samsung.com, matthias.bgg@gmail.com,
	asutoshd@codeaurora.org, bvanassche@acm.org,
	linux-arm-kernel@lists.infradead.org, beanhuo@micron.com
Subject: Re: [PATCH v3 1/2] scsi: ufs: pass device information to apply_dev_quirks
Date: Thu, 20 Feb 2020 09:36:57 +0800	[thread overview]
Message-ID: <57698522f7e1d9401ac27a0bd7f0756a@codeaurora.org> (raw)
In-Reply-To: <1582009359.26304.29.camel@mtksdccf07>

Hi Stanley,

On 2020-02-18 15:02, Stanley Chu wrote:
> Hi Can,
> 
> 
>> Hi Stanley,
>> 
>> Is this series merged? If no, would you mind moving
>> ufshcd_vops_apply_dev_quirks(hba, card); a little bit? Like below.
>> 
>> @@ -6852,14 +6852,14 @@ static void ufshcd_tune_unipro_params(struct
>> ufs_hba *hba)
>>                  ufshcd_tune_pa_hibern8time(hba);
>>          }
>> 
>> +       ufshcd_vops_apply_dev_quirks(hba, card);
>> +
>>          if (hba->dev_quirks & UFS_DEVICE_QUIRK_PA_TACTIVATE)
>>                  /* set 1ms timeout for PA_TACTIVATE */
>>                  ufshcd_dme_set(hba, UIC_ARG_MIB(PA_TACTIVATE), 10);
>> 
>> In this way, vendor codes have a chance to modify the dev_quirks
>> before ufshcd_tune_unipro_params() does the rest of its job.
>> 
> 
> This patch has been merged to 5.6-rc1.
> 
> Basically I am fine with your proposal. But if you need to move it to
> new mentioned position, our apply_dev_quirks callback also need
> corresponding change so it might need our co-works : )
> 
> For example, you could just post your proposed changes and then we 
> would
> provide corresponding change as soon as possible?
> 
> Besides, I would like to remind that allowing vendor to "fix" device
> quirks in advance imply that current common device quirks have some
> problems? If so, would you consider to fix common device quirks 
> instead?
> 
> 
>> Thanks,
>> Can Guo.
> 
> Thanks,
> Stanley Chu

Thanks for your cooperations on this :)

There are some failure seen with specific UFS devices on our platforms,
we can fix it with the quirk QUIRK_HOST_PA_TACTIVATE, but we are not
sure if other vendors need it or not. So we want to handle it more
carefully by limiting it to our platforms only. I had sent out that
patch weeks ago, so I will just upload the new patch as we both agreed
in that patch series.

Thanks,
Can Guo

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Can Guo <cang@codeaurora.org>
To: Stanley Chu <stanley.chu@mediatek.com>
Cc: linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
	avri.altman@wdc.com, alim.akhtar@samsung.com, jejb@linux.ibm.com,
	beanhuo@micron.com, asutoshd@codeaurora.org,
	matthias.bgg@gmail.com, bvanassche@acm.org,
	linux-mediatek@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kuohong.wang@mediatek.com,
	peter.wang@mediatek.com, chun-hung.wu@mediatek.com,
	andy.teng@mediatek.com
Subject: Re: [PATCH v3 1/2] scsi: ufs: pass device information to apply_dev_quirks
Date: Thu, 20 Feb 2020 09:36:57 +0800	[thread overview]
Message-ID: <57698522f7e1d9401ac27a0bd7f0756a@codeaurora.org> (raw)
In-Reply-To: <1582009359.26304.29.camel@mtksdccf07>

Hi Stanley,

On 2020-02-18 15:02, Stanley Chu wrote:
> Hi Can,
> 
> 
>> Hi Stanley,
>> 
>> Is this series merged? If no, would you mind moving
>> ufshcd_vops_apply_dev_quirks(hba, card); a little bit? Like below.
>> 
>> @@ -6852,14 +6852,14 @@ static void ufshcd_tune_unipro_params(struct
>> ufs_hba *hba)
>>                  ufshcd_tune_pa_hibern8time(hba);
>>          }
>> 
>> +       ufshcd_vops_apply_dev_quirks(hba, card);
>> +
>>          if (hba->dev_quirks & UFS_DEVICE_QUIRK_PA_TACTIVATE)
>>                  /* set 1ms timeout for PA_TACTIVATE */
>>                  ufshcd_dme_set(hba, UIC_ARG_MIB(PA_TACTIVATE), 10);
>> 
>> In this way, vendor codes have a chance to modify the dev_quirks
>> before ufshcd_tune_unipro_params() does the rest of its job.
>> 
> 
> This patch has been merged to 5.6-rc1.
> 
> Basically I am fine with your proposal. But if you need to move it to
> new mentioned position, our apply_dev_quirks callback also need
> corresponding change so it might need our co-works : )
> 
> For example, you could just post your proposed changes and then we 
> would
> provide corresponding change as soon as possible?
> 
> Besides, I would like to remind that allowing vendor to "fix" device
> quirks in advance imply that current common device quirks have some
> problems? If so, would you consider to fix common device quirks 
> instead?
> 
> 
>> Thanks,
>> Can Guo.
> 
> Thanks,
> Stanley Chu

Thanks for your cooperations on this :)

There are some failure seen with specific UFS devices on our platforms,
we can fix it with the quirk QUIRK_HOST_PA_TACTIVATE, but we are not
sure if other vendors need it or not. So we want to handle it more
carefully by limiting it to our platforms only. I had sent out that
patch weeks ago, so I will just upload the new patch as we both agreed
in that patch series.

Thanks,
Can Guo

WARNING: multiple messages have this Message-ID (diff)
From: Can Guo <cang@codeaurora.org>
To: Stanley Chu <stanley.chu@mediatek.com>
Cc: linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
	andy.teng@mediatek.com, jejb@linux.ibm.com,
	chun-hung.wu@mediatek.com, kuohong.wang@mediatek.com,
	linux-kernel@vger.kernel.org, avri.altman@wdc.com,
	linux-mediatek@lists.infradead.org, peter.wang@mediatek.com,
	alim.akhtar@samsung.com, matthias.bgg@gmail.com,
	asutoshd@codeaurora.org, bvanassche@acm.org,
	linux-arm-kernel@lists.infradead.org, beanhuo@micron.com
Subject: Re: [PATCH v3 1/2] scsi: ufs: pass device information to apply_dev_quirks
Date: Thu, 20 Feb 2020 09:36:57 +0800	[thread overview]
Message-ID: <57698522f7e1d9401ac27a0bd7f0756a@codeaurora.org> (raw)
In-Reply-To: <1582009359.26304.29.camel@mtksdccf07>

Hi Stanley,

On 2020-02-18 15:02, Stanley Chu wrote:
> Hi Can,
> 
> 
>> Hi Stanley,
>> 
>> Is this series merged? If no, would you mind moving
>> ufshcd_vops_apply_dev_quirks(hba, card); a little bit? Like below.
>> 
>> @@ -6852,14 +6852,14 @@ static void ufshcd_tune_unipro_params(struct
>> ufs_hba *hba)
>>                  ufshcd_tune_pa_hibern8time(hba);
>>          }
>> 
>> +       ufshcd_vops_apply_dev_quirks(hba, card);
>> +
>>          if (hba->dev_quirks & UFS_DEVICE_QUIRK_PA_TACTIVATE)
>>                  /* set 1ms timeout for PA_TACTIVATE */
>>                  ufshcd_dme_set(hba, UIC_ARG_MIB(PA_TACTIVATE), 10);
>> 
>> In this way, vendor codes have a chance to modify the dev_quirks
>> before ufshcd_tune_unipro_params() does the rest of its job.
>> 
> 
> This patch has been merged to 5.6-rc1.
> 
> Basically I am fine with your proposal. But if you need to move it to
> new mentioned position, our apply_dev_quirks callback also need
> corresponding change so it might need our co-works : )
> 
> For example, you could just post your proposed changes and then we 
> would
> provide corresponding change as soon as possible?
> 
> Besides, I would like to remind that allowing vendor to "fix" device
> quirks in advance imply that current common device quirks have some
> problems? If so, would you consider to fix common device quirks 
> instead?
> 
> 
>> Thanks,
>> Can Guo.
> 
> Thanks,
> Stanley Chu

Thanks for your cooperations on this :)

There are some failure seen with specific UFS devices on our platforms,
we can fix it with the quirk QUIRK_HOST_PA_TACTIVATE, but we are not
sure if other vendors need it or not. So we want to handle it more
carefully by limiting it to our platforms only. I had sent out that
patch weeks ago, so I will just upload the new patch as we both agreed
in that patch series.

Thanks,
Can Guo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-02-20  1:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-11  7:11 [PATCH v3 0/2] scsi: ufs: pass device information to apply_dev_quirks Stanley Chu
2020-01-11  7:11 ` Stanley Chu
2020-01-11  7:11 ` Stanley Chu
2020-01-11  7:11 ` [PATCH v3 1/2] " Stanley Chu
2020-01-11  7:11   ` Stanley Chu
2020-01-11  7:11   ` Stanley Chu
2020-02-17 12:20   ` Can Guo
2020-02-17 12:20     ` Can Guo
2020-02-17 12:20     ` Can Guo
2020-02-18  7:02     ` Stanley Chu
2020-02-18  7:02       ` Stanley Chu
2020-02-18  7:02       ` Stanley Chu
2020-02-20  1:36       ` Can Guo [this message]
2020-02-20  1:36         ` Can Guo
2020-02-20  1:36         ` Can Guo
2020-01-11  7:11 ` [PATCH v3 2/2] scsi: ufs-mediatek: add apply_dev_quirks variant operation Stanley Chu
2020-01-11  7:11   ` Stanley Chu
2020-01-11  7:11   ` Stanley Chu
2020-01-16  3:24 ` [PATCH v3 0/2] scsi: ufs: pass device information to apply_dev_quirks Martin K. Petersen
2020-01-16  3:24   ` Martin K. Petersen
2020-01-16  3:24   ` Martin K. Petersen

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=57698522f7e1d9401ac27a0bd7f0756a@codeaurora.org \
    --to=cang@codeaurora.org \
    --cc=alim.akhtar@samsung.com \
    --cc=andy.teng@mediatek.com \
    --cc=asutoshd@codeaurora.org \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=chun-hung.wu@mediatek.com \
    --cc=jejb@linux.ibm.com \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=matthias.bgg@gmail.com \
    --cc=peter.wang@mediatek.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.