| Message ID | 20190905192412.23116-1-lee.jones@linaro.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 127068abe85bf3dee50df51cb039a5a987a4a666 |
| Headers | show |
| Series | [RESEND,v3,1/1] i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630 | expand |
On Thu, Sep 05, 2019 at 08:24:12PM +0100, Lee Jones wrote: > We have a production-level laptop (Lenovo Yoga C630) which is exhibiting > a rather horrific bug. When I2C HID devices are being scanned for at > boot-time the QCom Geni based I2C (Serial Engine) attempts to use DMA. > When it does, the laptop reboots and the user never sees the OS. > > Attempts are being made to debug the reason for the spontaneous reboot. > No luck so far, hence the requirement for this hot-fix. This workaround > will be removed once we have a viable fix. > > Signed-off-by: Lee Jones <lee.jones@linaro.org> Perfect now. Applied to for-current, thanks!
Quoting Lee Jones (2019-09-05 12:24:12) > We have a production-level laptop (Lenovo Yoga C630) which is exhibiting > a rather horrific bug. When I2C HID devices are being scanned for at > boot-time the QCom Geni based I2C (Serial Engine) attempts to use DMA. > When it does, the laptop reboots and the user never sees the OS. > > Attempts are being made to debug the reason for the spontaneous reboot. > No luck so far, hence the requirement for this hot-fix. This workaround > will be removed once we have a viable fix. > > Signed-off-by: Lee Jones <lee.jones@linaro.org> > --- > drivers/i2c/busses/i2c-qcom-geni.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c > index a89bfce5388e..17abf60c94ae 100644 > --- a/drivers/i2c/busses/i2c-qcom-geni.c > +++ b/drivers/i2c/busses/i2c-qcom-geni.c > @@ -355,11 +355,13 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, > { > dma_addr_t rx_dma; > unsigned long time_left; > - void *dma_buf; > + void *dma_buf = NULL; > struct geni_se *se = &gi2c->se; > size_t len = msg->len; > > - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); > + if (!of_machine_is_compatible("lenovo,yoga-c630")) This compatible isn't in the 5.3 rc series nor is it in linux-next yet. Is this "hot-fix" for the next merge window? Or is this compatible string being generated by firmware somewhere and thus isn't part of the kernel? > + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); > + > if (dma_buf) > geni_se_select_mode(se, GENI_SE_DMA); > else
On Thu, 05 Sep 2019, Stephen Boyd wrote: > Quoting Lee Jones (2019-09-05 12:24:12) > > We have a production-level laptop (Lenovo Yoga C630) which is exhibiting > > a rather horrific bug. When I2C HID devices are being scanned for at > > boot-time the QCom Geni based I2C (Serial Engine) attempts to use DMA. > > When it does, the laptop reboots and the user never sees the OS. > > > > Attempts are being made to debug the reason for the spontaneous reboot. > > No luck so far, hence the requirement for this hot-fix. This workaround > > will be removed once we have a viable fix. > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org> > > --- > > drivers/i2c/busses/i2c-qcom-geni.c | 12 ++++++++---- > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c > > index a89bfce5388e..17abf60c94ae 100644 > > --- a/drivers/i2c/busses/i2c-qcom-geni.c > > +++ b/drivers/i2c/busses/i2c-qcom-geni.c > > @@ -355,11 +355,13 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, > > { > > dma_addr_t rx_dma; > > unsigned long time_left; > > - void *dma_buf; > > + void *dma_buf = NULL; > > struct geni_se *se = &gi2c->se; > > size_t len = msg->len; > > > > - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); > > + if (!of_machine_is_compatible("lenovo,yoga-c630")) > > This compatible isn't in the 5.3 rc series nor is it in linux-next yet. > Is this "hot-fix" for the next merge window? Or is this compatible > string being generated by firmware somewhere and thus isn't part of the > kernel? It's on the list and will be in all of the distro v5.3 release kernels. https://lkml.org/lkml/2019/9/5/695 > > + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); > > + > > if (dma_buf) > > geni_se_select_mode(se, GENI_SE_DMA); > > else
> > This compatible isn't in the 5.3 rc series nor is it in linux-next yet. > > Is this "hot-fix" for the next merge window? Or is this compatible > > string being generated by firmware somewhere and thus isn't part of the > > kernel? > > It's on the list and will be in all of the distro v5.3 release kernels. > > https://lkml.org/lkml/2019/9/5/695 And why don't the distro kernels simply pick up this patch, too?
On Fri, 06 Sep 2019, Wolfram Sang wrote: > > > This compatible isn't in the 5.3 rc series nor is it in linux-next yet. > > > Is this "hot-fix" for the next merge window? Or is this compatible > > > string being generated by firmware somewhere and thus isn't part of the > > > kernel? > > > > It's on the list and will be in all of the distro v5.3 release kernels. > > > > https://lkml.org/lkml/2019/9/5/695 > > And why don't the distro kernels simply pick up this patch, too? I could send it to them and find out. They are on kernel-freeze now, on the lead-up to the release date (next month), but I think they're still taking bug fixes.
On Fri, Sep 06, 2019 at 08:56:00AM +0100, Lee Jones wrote: > On Fri, 06 Sep 2019, Wolfram Sang wrote: > > > > This compatible isn't in the 5.3 rc series nor is it in linux-next yet. > > > > Is this "hot-fix" for the next merge window? Or is this compatible > > > > string being generated by firmware somewhere and thus isn't part of the > > > > kernel? > > > > > > It's on the list and will be in all of the distro v5.3 release kernels. > > > > > > https://lkml.org/lkml/2019/9/5/695 > > > > And why don't the distro kernels simply pick up this patch, too? > > I could send it to them and find out. They are on kernel-freeze now, > on the lead-up to the release date (next month), but I think they're > still taking bug fixes. Please do.
On Fri, 06 Sep 2019, Wolfram Sang wrote: > On Fri, Sep 06, 2019 at 08:56:00AM +0100, Lee Jones wrote: > > On Fri, 06 Sep 2019, Wolfram Sang wrote: > > > > > This compatible isn't in the 5.3 rc series nor is it in linux-next yet. > > > > > Is this "hot-fix" for the next merge window? Or is this compatible > > > > > string being generated by firmware somewhere and thus isn't part of the > > > > > kernel? > > > > > > > > It's on the list and will be in all of the distro v5.3 release kernels. > > > > > > > > https://lkml.org/lkml/2019/9/5/695 > > > > > > And why don't the distro kernels simply pick up this patch, too? > > > > I could send it to them and find out. They are on kernel-freeze now, > > on the lead-up to the release date (next month), but I think they're > > still taking bug fixes. > > Please do. Submitted. Does this mean you plan to have this merged for v5.4?
> Does this mean you plan to have this merged for v5.4?
Only if the machine DTS is expected to land in 5.4. But Stephen said it
is not in liunx-next yet?
On Sat, Sep 7, 2019 at 9:17 AM Wolfram Sang <wsa@the-dreams.de> wrote: > > > > Does this mean you plan to have this merged for v5.4? > > Only if the machine DTS is expected to land in 5.4. But Stephen said it > is not in liunx-next yet? > It appears to be in arm-soc for-next: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=for-next BR, -R
On Sat, Sep 07, 2019 at 10:56:34AM -0700, Rob Clark wrote: > On Sat, Sep 7, 2019 at 9:17 AM Wolfram Sang <wsa@the-dreams.de> wrote: > > > > > > > Does this mean you plan to have this merged for v5.4? > > > > Only if the machine DTS is expected to land in 5.4. But Stephen said it > > is not in liunx-next yet? > > > > It appears to be in arm-soc for-next: > > https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=for-next Still not in linux-next. Please ping me or resend this patch once it hits linux-next.
On Fri 13 Sep 07:28 PDT 2019, Wolfram Sang wrote: > On Sat, Sep 07, 2019 at 10:56:34AM -0700, Rob Clark wrote: > > On Sat, Sep 7, 2019 at 9:17 AM Wolfram Sang <wsa@the-dreams.de> wrote: > > > > > > > > > > Does this mean you plan to have this merged for v5.4? > > > > > > Only if the machine DTS is expected to land in 5.4. But Stephen said it > > > is not in liunx-next yet? > > > > > > > It appears to be in arm-soc for-next: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=for-next > > Still not in linux-next. Please ping me or resend this patch once it > hits linux-next. > It seems linux-next is now pulling from the soc.git, rather than arm-soc.git, but Arnd is still pushing patches to arm-soc.git. Arnd says that the patch will be in v5.4 and I merged Arnd's tree and gave it a spin here and this patch makes it boot. So please merge this patch for v5.4 as well. Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Thanks, Bjorn
> It seems linux-next is now pulling from the soc.git, rather than > arm-soc.git, but Arnd is still pushing patches to arm-soc.git. Can you ask them to fix this? > Arnd says that the patch will be in v5.4 and I merged Arnd's tree and > gave it a spin here and this patch makes it boot. So please merge this > patch for v5.4 as well. No worries, this is clearly a bugfix. So it will easily go in with the same release as the DTS file. > Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Thanks!
On Fri, 13 Sep 2019, Wolfram Sang wrote: > > > It seems linux-next is now pulling from the soc.git, rather than > > arm-soc.git, but Arnd is still pushing patches to arm-soc.git. > > Can you ask them to fix this? Linux next is on vacation for month. The last tag was next-20190904. > > Arnd says that the patch will be in v5.4 and I merged Arnd's tree and > > gave it a spin here and this patch makes it boot. So please merge this > > patch for v5.4 as well. > > No worries, this is clearly a bugfix. So it will easily go in with the > same release as the DTS file. Thanks. The DTS commit will go in for v5.4.
On Fri, Sep 13, 2019 at 6:13 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > > On Fri 13 Sep 07:28 PDT 2019, Wolfram Sang wrote: > > > On Sat, Sep 07, 2019 at 10:56:34AM -0700, Rob Clark wrote: > > > On Sat, Sep 7, 2019 at 9:17 AM Wolfram Sang <wsa@the-dreams.de> wrote: > > > > > > > > > > > > > Does this mean you plan to have this merged for v5.4? > > > > > > > > Only if the machine DTS is expected to land in 5.4. But Stephen said it > > > > is not in liunx-next yet? > > > > > > > > > > It appears to be in arm-soc for-next: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=for-next > > > > Still not in linux-next. Please ping me or resend this patch once it > > hits linux-next. > > > > It seems linux-next is now pulling from the soc.git, rather than > arm-soc.git, but Arnd is still pushing patches to arm-soc.git. I'm still pushing identical contents to both, but plan to remove the old tree after the merge window. Arnd
On Fri, 13 Sep 2019, Wolfram Sang wrote: > > > It seems linux-next is now pulling from the soc.git, rather than > > arm-soc.git, but Arnd is still pushing patches to arm-soc.git. > > Can you ask them to fix this? > > > Arnd says that the patch will be in v5.4 and I merged Arnd's tree and > > gave it a spin here and this patch makes it boot. So please merge this > > patch for v5.4 as well. > > No worries, this is clearly a bugfix. So it will easily go in with the > same release as the DTS file. DTS file now upstream (44acee207844).
On Fri, 13 Sep 2019, Wolfram Sang wrote: > > > It seems linux-next is now pulling from the soc.git, rather than > > arm-soc.git, but Arnd is still pushing patches to arm-soc.git. > > Can you ask them to fix this? > > > Arnd says that the patch will be in v5.4 and I merged Arnd's tree and > > gave it a spin here and this patch makes it boot. So please merge this > > patch for v5.4 as well. > > No worries, this is clearly a bugfix. So it will easily go in with the > same release as the DTS file. Still not in Mainline. Is the plan to send this through the -rcs?
On Thu, Sep 05, 2019 at 08:24:12PM +0100, Lee Jones wrote: > We have a production-level laptop (Lenovo Yoga C630) which is exhibiting > a rather horrific bug. When I2C HID devices are being scanned for at > boot-time the QCom Geni based I2C (Serial Engine) attempts to use DMA. > When it does, the laptop reboots and the user never sees the OS. > > Attempts are being made to debug the reason for the spontaneous reboot. > No luck so far, hence the requirement for this hot-fix. This workaround > will be removed once we have a viable fix. > > Signed-off-by: Lee Jones <lee.jones@linaro.org> Applied to for-current, thanks!
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index a89bfce5388e..17abf60c94ae 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -355,11 +355,13 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, { dma_addr_t rx_dma; unsigned long time_left; - void *dma_buf; + void *dma_buf = NULL; struct geni_se *se = &gi2c->se; size_t len = msg->len; - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); + if (!of_machine_is_compatible("lenovo,yoga-c630")) + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); + if (dma_buf) geni_se_select_mode(se, GENI_SE_DMA); else @@ -394,11 +396,13 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, { dma_addr_t tx_dma; unsigned long time_left; - void *dma_buf; + void *dma_buf = NULL; struct geni_se *se = &gi2c->se; size_t len = msg->len; - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); + if (!of_machine_is_compatible("lenovo,yoga-c630")) + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32); + if (dma_buf) geni_se_select_mode(se, GENI_SE_DMA); else
We have a production-level laptop (Lenovo Yoga C630) which is exhibiting a rather horrific bug. When I2C HID devices are being scanned for at boot-time the QCom Geni based I2C (Serial Engine) attempts to use DMA. When it does, the laptop reboots and the user never sees the OS. Attempts are being made to debug the reason for the spontaneous reboot. No luck so far, hence the requirement for this hot-fix. This workaround will be removed once we have a viable fix. Signed-off-by: Lee Jones <lee.jones@linaro.org> --- drivers/i2c/busses/i2c-qcom-geni.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)