* [PATCH 0/9] serial: Fix out-of-bounds accesses through DT aliases
From: Geert Uytterhoeven @ 2018-02-20 9:40 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: devicetree, Barry Song, Geert Uytterhoeven, Vineet Gupta,
Michal Simek, linux-kernel, linux-renesas-soc, linux-serial,
Jiri Slaby, linux-snps-arc, linux-arm-kernel
Hi all,
Serial drivers used on DT platforms use the "serialN" alias in DT to
obtain the serial port index for a specific port. Drivers typically use
a fixed-size array for keeping track of all available serial ports.
However, several drivers do not perform any validation on the index
obtained from DT, which may lead to out-of-bounds accesses of these
fixed-size arrays.
While the DTB passed to the kernel might be considered trusted, some of
these out-of-bounds accesses can be triggered by a legitimate DTB:
- In some drivers the size of the array is defined by a Kconfig
symbol, so a user who doesn't need all serial ports may lower this
value rightfully,
- Tomorrow's new SoC may have more serial ports than the fixed-size
array in today's driver can accommodate, which the user may forget
to enlarge.
Hence this series fixes that by adding checks for out-of-range aliases,
logging an error message when triggered.
Tested on r8a7791/koelsch (sh-sci), all other drivers were
compile-tested only.
Thanks for your comments!
Geert Uytterhoeven (9):
serial: arc_uart: Fix out-of-bounds access through DT alias
serial: fsl_lpuart: Fix out-of-bounds access through DT alias
serial: imx: Fix out-of-bounds access through DT alias
serial: mxs-auart: Fix out-of-bounds access through DT alias
serial: pxa: Fix out-of-bounds access through DT alias
serial: samsung: Fix out-of-bounds access through DT alias
serial: sh-sci: Fix out-of-bounds access through DT alias
serial: sirf: Fix out-of-bounds access through DT alias
serial: xuartps: Fix out-of-bounds access through DT alias
drivers/tty/serial/arc_uart.c | 5 +++++
drivers/tty/serial/fsl_lpuart.c | 4 ++++
drivers/tty/serial/imx.c | 5 +++++
drivers/tty/serial/mxs-auart.c | 4 ++++
drivers/tty/serial/pxa.c | 4 ++++
drivers/tty/serial/samsung.c | 4 ++++
drivers/tty/serial/sh-sci.c | 4 ++++
drivers/tty/serial/sirfsoc_uart.c | 5 +++++
drivers/tty/serial/xilinx_uartps.c | 2 +-
9 files changed, 36 insertions(+), 1 deletion(-)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Kai-Heng Feng @ 2018-02-18 8:13 UTC (permalink / raw)
To: Hans de Goede
Cc: Marcel Holtmann, Brian Norris, Gustavo F. Padovan, Johan Hedberg,
Bluez mailing list, linux-serial, ACPI Devel Maling List, stable,
Leif Liddy, Matthias Kaehlcke, Daniel Drake, matadeen,
Linux Kernel Mailing List, Greg Kroah-Hartman, Guenter Roeck
In-Reply-To: <1a08612e-2531-3711-ec0f-a867e86d0009@redhat.com>
> On 16 Feb 2018, at 8:10 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>
>
> Ok, I've asked the reporter of:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1514836
>
> Which is how I got involved in this to provide DMI data and
> I will whip up a patch for his machine and ask him to test
> and once that is done submit upstream. This is the only machine
> I'm aware of though and looking at the history of this I think
> there will be others.
I have one machine needs the quirk. I’ll also send a patch to
match its DMI.
Kai-Heng
>
>> I addition we can add a module option to btusb.ko that allows us to force this flag to be set. That way testing this is easy on a vendor kernel. A bunch of the btusb quirks (and also core quirks) can be tested via module options or debugfs.
>
> Yes a module option for this is a good idea.
>
> Regards,
>
> Hans
>
>
^ permalink raw reply
* Re: [PATCH v2 3/7] soc: qcom: Add GENI based QUP Wrapper driver
From: Karthik Ramasubramanian @ 2018-02-16 20:44 UTC (permalink / raw)
To: Amit Kucheria
Cc: corbet, Andy Gross, david.brown, robh+dt, mark.rutland, wsa,
gregkh, linux-doc, linux-arm-msm, devicetree, linux-i2c,
linux-serial, jslaby, Sagar Dharia, Girish Mahadevan
In-Reply-To: <CAHLCerOf3WMUind8-5Z+c6iXyyYvdjS7MaMbO8WzNU2-VaREPg@mail.gmail.com>
On 2/14/2018 4:07 AM, Amit Kucheria wrote:
> On Sat, Jan 13, 2018 at 6:35 AM, Karthikeyan Ramasubramanian
> <kramasub@codeaurora.org> wrote:
>> This driver manages the Generic Interface (GENI) firmware based Qualcomm
>> Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation
>> programmable module composed of multiple Serial Engines (SE) and supports
>> a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. This
>> driver also enables managing the serial interface independent aspects of
>> Serial Engines.
>>
>> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
>> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
>> Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
>
>
>> +int geni_se_resources_off(struct geni_se_rsc *rsc)
>> +{
>> + int ret = 0;
>> + struct geni_se_device *geni_se_dev;
>> +
>> + if (unlikely(!rsc || !rsc->wrapper_dev))
>> + return -EINVAL;
>> +
>> + geni_se_dev = dev_get_drvdata(rsc->wrapper_dev);
>> + if (unlikely(!geni_se_dev))
>> + return -ENODEV;
>> +
>> + ret = pinctrl_select_state(rsc->geni_pinctrl, rsc->geni_gpio_sleep);
>
> You need to include linux/pinctrl/consumer.h for devm_pinctrl_get
>
> I couldn't compile test it w/o it.
>
I think marking the dependencies might help with this compilation issue.
Else I will include the concerned header file. One way or the other, I
will ensure that this issue does not get hit in my follow-up patch series.
Regards,
Karthik.
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: prevent lockup on full TTY buffers
From: Greg KH @ 2018-02-16 18:44 UTC (permalink / raw)
To: Ulrich Hecht
Cc: linux-renesas-soc, linux-serial, wsa, geert, yoshihiro.shimoda.uh
In-Reply-To: <1518696147-23790-1-git-send-email-ulrich.hecht+renesas@gmail.com>
On Thu, Feb 15, 2018 at 01:02:27PM +0100, Ulrich Hecht wrote:
> When the TTY buffers fill up to the configured maximum, a system lockup
> occurs:
>
> [ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
> [ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
> [ 598.838755] Task dump for CPU 0:
> [ 598.841977] swapper/0 R running task 0 0 0 0x00000022
> [ 598.849023] Call trace:
> [ 598.851476] __switch_to+0x98/0xb0
> [ 598.854870] (null)
>
> This can be prevented by doing a dummy read of the RX data register.
>
> This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
> reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
> as well.
>
> Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Should this go to older kernel versions as well?
If so, how far back?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Brian Norris @ 2018-02-16 17:59 UTC (permalink / raw)
To: Hans de Goede
Cc: Marcel Holtmann, Gustavo F. Padovan, Johan Hedberg,
Bluez mailing list, linux-serial, ACPI Devel Maling List, stable,
Leif Liddy, Matthias Kaehlcke, Daniel Drake, Kai-Heng Feng,
matadeen, Linux Kernel Mailing List, Greg Kroah-Hartman,
Guenter Roeck
In-Reply-To: <1a08612e-2531-3711-ec0f-a867e86d0009@redhat.com>
Hi,
On Fri, Feb 16, 2018 at 01:10:20PM +0100, Hans de Goede wrote:
> On 16-02-18 12:45, Marcel Holtmann wrote:
> > Hi Hans,
> >
> > > > > > > Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
> > > > > > > removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
> > > > > > > instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
> > > > > > >
> > > > > > > This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
> > > > > > > has several issues (see the original commit message). An added advantage
> > > > > > > of moving over to the USB-core reset-resume handling is that it also
> > > > > > > disables autosuspend for these devices, which is similarly broken on these.
> > > > > >
> > > > > > Wait, is autosuspend actually broken for all QCA Rome chipsets? I don't
> > > > > > think so -- I'm using one now.
> > > > >
> > > > > And have you manually enabled USB autosuspend for it, or are you
> > > > > running something which might have done so, e.g. powertop --auto-tune ?
> > > > >
> > > > > Because if you did not do that then you're already not using autosuspend
> > > > > for your QCA devices and this patch will change nothing.
> > > > I use a set of udev rules that manually whitelist devices for
> > > > autosuspend. You can see it here:
> > > > https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
> > > > You'll find at least one Rome chip in there.
> > > >
> > > > > > Thus, this is a poor solution, which
> > > > > > negatively affects my systems. However, I see that this patch was
> > > > > > applied regardless...
> > > > >
> > > > > Note that there already is a quirk to handle broken suspend/resume
> > > > > behavior on ALL QCA devices in older kernels. Also note that the
> > > > Yes, and the quirk was broken, and I made sure it got reverted when it
> > > > broke my devices ;)
> > >
> > > Note that the revert for this:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d06d5895c15
> > >
> > > Says: "This commit causes a regression on some QCA ROME chips. The USB device reset happens
> > > in btusb_open(), hence firmware loading gets interrupted."
> > >
> > > And says:
> > >
> > > "If we really want to reset the USB device, we need to do it before btusb_open(). Let's
> > > handle it in drivers/usb/core/quirks.c."
Just a note: I didn't write that part ;) I also didn't have evidence to
say that *no* QCA chipset was broken. I just knew that on my platform
with my QCA ROME chipset, there was no problem.
> > > It does not mention that the quirk is not necessary on some devices only
> > > that the implementation of it we had before had issues.
> > >
> > > And the original commit of the quirk:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/drivers/bluetooth/btusb.c?id=fd865802c66bc451dc515ed89360f84376ce1a56
> > >
> > > Says: "There's been numerous reported instances where BTUSB_QCA_ROME
> > > bluetooth controllers stop functioning upon resume from suspend."
> > >
> > > So it may be platform specific but it is not just limited to 1 or
> > > 2 platforms I think.
Understood for most of the above. But I'll stick a "citation needed" on
the "numerous reported instances" claim. As I note below, I believe that
is the crux of the problem: understanding what platforms actually
reported this problem. All attempts to "fix" it have broken things in
one way or another, which have just caused noise since then.
> > > Note I'm not saying that I don't believe you that the quirk is not
> > > necessary on your devices.
> > >
> > > > > patches series which this commit builds on top of was already
> > > > > setting USB_QUIRK_RESET_RESUME for some devices in
> > > > > usb/core/quirks.c.
> > > > >
> > > > > All my commit does is instead of duplicating all the QCA USB-ids in
> > > > > usb/core/quirks.c, move the setting of USB_QUIRK_RESET_RESUME
> > > > > to btusb.c so that we don't need to duplicate the USB-id tables.
> > > > I was slightly more OK with marking specific IDs as broken, because
> > > > those IDs didn't happen to be ones that I knew were currently working.
> > > > Now you're breaking my systems again. But this time, it's more subtle
> > > > because bluetooth will still work, but we just suck more power leaving
> > > > our USB port active all the time.
> > >
> > > I see, sorry about that. Ok, so we are going to need to make the
> > > reset-on-resume quirking more fine grained. I can see 3 ways to do this:
> > >
> > > 1) Make it a separate per usb-id BTUSB_RESET_RESUME flag in the
> > > usb_device_id table inside btusb.c (I still believe duplicating most
> > > ids to usb/core/quirks.c is a bad idea).
> > >
> > > 2) Use dmi based whitelisting to opt out of reset-resume behavior on
> > > QCA btusb devices.
> > >
> > > 3) Use dmi based blacklisting which enables reset-resume behavior.
> > >
> > > In retrospect I guess 3 would have been best, but if we do that now
> > > it will cause regressions.
> > >
> > > I guess we should go with 1. adding the BTUSB_RESET_RESUME to all the
> > > QCA usb-ids except for the ones where you know things work and which
> > > only seem to be used in working devices (based on you not having
> > > objections against the additions of the quirk for some ids to
> > > drivers/usb/core/quirks.c).
> > >
> > > And if then those usb-ids do turn out to have broken suspend on
> > > on some devices too I guess we need to move to 2.
> >
> > actually if this is really platform related as Qualcomm is indicating, then we should just go with 3) and the two platforms that previously added quirks to usb/core/quirks.c and blacklist these. I am all for figuring out what is going on here. So lets blacklist these and see how this goes. Maybe there are only two bad platforms out there and we are making too much fuzz about this. Before we added quirks in the USB core these platforms were just plain broken as well. So not much different situation than before. We need to push the DMI blacklisting back into -stable as well and that means any impact of a 3rd broken platform briefly working and then be broken again is slim and also fixable via -stable.
>
> Ok, I've asked the reporter of:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1514836
Are you even sure that this reporter is seeing the original symptom at
all (BT loses power, and therefore firmware)? Their report shows them
running 4.15, which had this commit:
fd865802c66b Bluetooth: btusb: fix QCA Rome suspend/resume
which is admittedly completely broken. It breaks even perfectly working
BT/USB devices, like mine. That's where I first complained, and we got
this into 4.16-rc1:
7d06d5895c15 Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"
Isn't it possible your reporter has no further problem, and none if this
is actually important to them? I'd just caution you to be careful before
assuming you need to add blacklist info for their DMI...
As I read it, you need to investigate who are the "numerous reported
instances" that generated commit fd865802c66b in the first place. That's
where this mess started, IIUC.
But otherwise, yes, option 3 sounds OK. FWIW, my systems are ARM based
and don't have DMI data, so option 2 wouldn't work.
> Which is how I got involved in this to provide DMI data and
> I will whip up a patch for his machine and ask him to test
> and once that is done submit upstream. This is the only machine
> I'm aware of though and looking at the history of this I think
> there will be others.
>
> > I addition we can add a module option to btusb.ko that allows us to force this flag to be set. That way testing this is easy on a vendor kernel. A bunch of the btusb quirks (and also core quirks) can be tested via module options or debugfs.
>
> Yes a module option for this is a good idea.
That too. Or, would be nice to be able to force it either way. So if
someone erroneously sticks the flag in this driver (yet again), we can
easily undo that.
Brian
^ permalink raw reply
* Re: udev USB autosupend whitelist (was Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version)
From: Brian Norris @ 2018-02-16 16:49 UTC (permalink / raw)
To: Hans de Goede
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-bluetooth,
linux-serial, linux-acpi, stable, Leif Liddy, Matthias Kaehlcke,
Daniel Drake, Kai-Heng Feng, matadeen, linux-kernel,
Greg Kroah-Hartman, Guenter Roeck, Benson Leung
In-Reply-To: <0a13d0f3-8e0d-74df-df9c-2bf0622a9fb6@redhat.com>
+ Benson (and there are probably others that know better answers)
Hi,
On Fri, Feb 16, 2018 at 09:26:37AM +0100, Hans de Goede wrote:
> Going a bit off-topic here, so changed the subject.
> I will reply on topic in another mail.
>
> On 16-02-18 03:27, Brian Norris wrote:
> > I use a set of udev rules that manually whitelist devices for
> > autosuspend. You can see it here:
> >
> > https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
> >
> > You'll find at least one Rome chip in there.
>
> Oh, that is a very interesting link for the work I've been doing to
> improve Linux power-consumption in general:
>
> https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
>
> I was actually planning on at least doing such a list for WWAN modems,
> for btusb my approach has been to just enable it everywhere
> (except for QCA devices as I got bugreports for those).
>
> Note that I plan to eventually submit this whitelist to the
> udev rules which are part of systemd upstream, so if chromeos
> is using systemd too, this is something to be aware of for you.
Chrome OS does not currently use systemd, but thanks for the heads up.
> Question, is the white-listing of the root and rate-limiting
> hubs really necessary? I thought these have this enabled by default?
This list is old and maintained by several of my team, originating from
quite a ways back (i.e., much older kernels). It's quite possible that
some of it is redundant today.
> Also any caveats here I should be aware of?
That it's only maintained for the express purpose of Chrome{device}s?
There's no guarantee that there aren't platform issues with other
systems, for instance :)
I'm not really aware of any particular caveats otherwise.
Brian
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: prevent lockup on full TTY buffers
From: Ulrich Hecht @ 2018-02-16 14:27 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Linux-Renesas, linux-serial, Geert Uytterhoeven, shimoda
In-Reply-To: <20180215131237.4yi42wq4duic7uaq@katana>
On Thu, Feb 15, 2018 at 2:12 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> This can be prevented by doing a dummy read of the RX data register.
>
> Just so I understand the issue correctly: We are reading the register to
> throw the content away to prevent it being used in the TTY buffers?
Not quite. The problem was that if the buffers are full,
sci_receive_chars() returned immediately without reading anything from
the data register, and that led to a lockup. I am not fully sure why
that is so (I arrived at the fix by examining how the different code
paths look from the serial controller's perspective), but dropping
data here fixes it. At this point buffers are full, so any data
received will have to be discarded anyway.
CU
Uli
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Hans de Goede @ 2018-02-16 12:10 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Brian Norris, Gustavo F. Padovan, Johan Hedberg,
Bluez mailing list, linux-serial, ACPI Devel Maling List, stable,
Leif Liddy, Matthias Kaehlcke, Daniel Drake, Kai-Heng Feng,
matadeen, Linux Kernel Mailing List, Greg Kroah-Hartman,
Guenter Roeck
In-Reply-To: <6B37F6AC-1103-4FCF-A5DC-4BA236A7B11B@holtmann.org>
Hi,
On 16-02-18 12:45, Marcel Holtmann wrote:
> Hi Hans,
>
>>>>>> Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
>>>>>> removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
>>>>>> instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
>>>>>>
>>>>>> This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
>>>>>> has several issues (see the original commit message). An added advantage
>>>>>> of moving over to the USB-core reset-resume handling is that it also
>>>>>> disables autosuspend for these devices, which is similarly broken on these.
>>>>>
>>>>> Wait, is autosuspend actually broken for all QCA Rome chipsets? I don't
>>>>> think so -- I'm using one now.
>>>>
>>>> And have you manually enabled USB autosuspend for it, or are you
>>>> running something which might have done so, e.g. powertop --auto-tune ?
>>>>
>>>> Because if you did not do that then you're already not using autosuspend
>>>> for your QCA devices and this patch will change nothing.
>>> I use a set of udev rules that manually whitelist devices for
>>> autosuspend. You can see it here:
>>> https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
>>> You'll find at least one Rome chip in there.
>>>
>>>>> Thus, this is a poor solution, which
>>>>> negatively affects my systems. However, I see that this patch was
>>>>> applied regardless...
>>>>
>>>> Note that there already is a quirk to handle broken suspend/resume
>>>> behavior on ALL QCA devices in older kernels. Also note that the
>>> Yes, and the quirk was broken, and I made sure it got reverted when it
>>> broke my devices ;)
>>
>> Note that the revert for this:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d06d5895c15
>>
>> Says: "This commit causes a regression on some QCA ROME chips. The USB device reset happens
>> in btusb_open(), hence firmware loading gets interrupted."
>>
>> And says:
>>
>> "If we really want to reset the USB device, we need to do it before btusb_open(). Let's
>> handle it in drivers/usb/core/quirks.c."
>>
>> It does not mention that the quirk is not necessary on some devices only
>> that the implementation of it we had before had issues.
>>
>> And the original commit of the quirk:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/drivers/bluetooth/btusb.c?id=fd865802c66bc451dc515ed89360f84376ce1a56
>>
>> Says: "There's been numerous reported instances where BTUSB_QCA_ROME
>> bluetooth controllers stop functioning upon resume from suspend."
>>
>> So it may be platform specific but it is not just limited to 1 or
>> 2 platforms I think.
>>
>> Note I'm not saying that I don't believe you that the quirk is not
>> necessary on your devices.
>>
>>>> patches series which this commit builds on top of was already
>>>> setting USB_QUIRK_RESET_RESUME for some devices in
>>>> usb/core/quirks.c.
>>>>
>>>> All my commit does is instead of duplicating all the QCA USB-ids in
>>>> usb/core/quirks.c, move the setting of USB_QUIRK_RESET_RESUME
>>>> to btusb.c so that we don't need to duplicate the USB-id tables.
>>> I was slightly more OK with marking specific IDs as broken, because
>>> those IDs didn't happen to be ones that I knew were currently working.
>>> Now you're breaking my systems again. But this time, it's more subtle
>>> because bluetooth will still work, but we just suck more power leaving
>>> our USB port active all the time.
>>
>> I see, sorry about that. Ok, so we are going to need to make the
>> reset-on-resume quirking more fine grained. I can see 3 ways to do this:
>>
>> 1) Make it a separate per usb-id BTUSB_RESET_RESUME flag in the
>> usb_device_id table inside btusb.c (I still believe duplicating most
>> ids to usb/core/quirks.c is a bad idea).
>>
>> 2) Use dmi based whitelisting to opt out of reset-resume behavior on
>> QCA btusb devices.
>>
>> 3) Use dmi based blacklisting which enables reset-resume behavior.
>>
>> In retrospect I guess 3 would have been best, but if we do that now
>> it will cause regressions.
>>
>> I guess we should go with 1. adding the BTUSB_RESET_RESUME to all the
>> QCA usb-ids except for the ones where you know things work and which
>> only seem to be used in working devices (based on you not having
>> objections against the additions of the quirk for some ids to
>> drivers/usb/core/quirks.c).
>>
>> And if then those usb-ids do turn out to have broken suspend on
>> on some devices too I guess we need to move to 2.
>
> actually if this is really platform related as Qualcomm is indicating, then we should just go with 3) and the two platforms that previously added quirks to usb/core/quirks.c and blacklist these. I am all for figuring out what is going on here. So lets blacklist these and see how this goes. Maybe there are only two bad platforms out there and we are making too much fuzz about this. Before we added quirks in the USB core these platforms were just plain broken as well. So not much different situation than before. We need to push the DMI blacklisting back into -stable as well and that means any impact of a 3rd broken platform briefly working and then be broken again is slim and also fixable via -stable.
Ok, I've asked the reporter of:
https://bugzilla.redhat.com/show_bug.cgi?id=1514836
Which is how I got involved in this to provide DMI data and
I will whip up a patch for his machine and ask him to test
and once that is done submit upstream. This is the only machine
I'm aware of though and looking at the history of this I think
there will be others.
> I addition we can add a module option to btusb.ko that allows us to force this flag to be set. That way testing this is easy on a vendor kernel. A bunch of the btusb quirks (and also core quirks) can be tested via module options or debugfs.
Yes a module option for this is a good idea.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Marcel Holtmann @ 2018-02-16 11:45 UTC (permalink / raw)
To: Hans de Goede
Cc: Brian Norris, Gustavo F. Padovan, Johan Hedberg,
Bluez mailing list, linux-serial, ACPI Devel Maling List, stable,
Leif Liddy, Matthias Kaehlcke, Daniel Drake, Kai-Heng Feng,
matadeen, Linux Kernel Mailing List, Greg Kroah-Hartman,
Guenter Roeck
In-Reply-To: <345b0de8-1a23-d2f8-bc56-507eadf7faa7@redhat.com>
Hi Hans,
>>>>> Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
>>>>> removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
>>>>> instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
>>>>>
>>>>> This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
>>>>> has several issues (see the original commit message). An added advantage
>>>>> of moving over to the USB-core reset-resume handling is that it also
>>>>> disables autosuspend for these devices, which is similarly broken on these.
>>>>
>>>> Wait, is autosuspend actually broken for all QCA Rome chipsets? I don't
>>>> think so -- I'm using one now.
>>>
>>> And have you manually enabled USB autosuspend for it, or are you
>>> running something which might have done so, e.g. powertop --auto-tune ?
>>>
>>> Because if you did not do that then you're already not using autosuspend
>>> for your QCA devices and this patch will change nothing.
>> I use a set of udev rules that manually whitelist devices for
>> autosuspend. You can see it here:
>> https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
>> You'll find at least one Rome chip in there.
> >
>>>> Thus, this is a poor solution, which
>>>> negatively affects my systems. However, I see that this patch was
>>>> applied regardless...
>>>
>>> Note that there already is a quirk to handle broken suspend/resume
>>> behavior on ALL QCA devices in older kernels. Also note that the
>> Yes, and the quirk was broken, and I made sure it got reverted when it
>> broke my devices ;)
>
> Note that the revert for this:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d06d5895c15
>
> Says: "This commit causes a regression on some QCA ROME chips. The USB device reset happens
> in btusb_open(), hence firmware loading gets interrupted."
>
> And says:
>
> "If we really want to reset the USB device, we need to do it before btusb_open(). Let's
> handle it in drivers/usb/core/quirks.c."
>
> It does not mention that the quirk is not necessary on some devices only
> that the implementation of it we had before had issues.
>
> And the original commit of the quirk:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/drivers/bluetooth/btusb.c?id=fd865802c66bc451dc515ed89360f84376ce1a56
>
> Says: "There's been numerous reported instances where BTUSB_QCA_ROME
> bluetooth controllers stop functioning upon resume from suspend."
>
> So it may be platform specific but it is not just limited to 1 or
> 2 platforms I think.
>
> Note I'm not saying that I don't believe you that the quirk is not
> necessary on your devices.
>
>>> patches series which this commit builds on top of was already
>>> setting USB_QUIRK_RESET_RESUME for some devices in
>>> usb/core/quirks.c.
>>>
>>> All my commit does is instead of duplicating all the QCA USB-ids in
>>> usb/core/quirks.c, move the setting of USB_QUIRK_RESET_RESUME
>>> to btusb.c so that we don't need to duplicate the USB-id tables.
>> I was slightly more OK with marking specific IDs as broken, because
>> those IDs didn't happen to be ones that I knew were currently working.
>> Now you're breaking my systems again. But this time, it's more subtle
>> because bluetooth will still work, but we just suck more power leaving
>> our USB port active all the time.
>
> I see, sorry about that. Ok, so we are going to need to make the
> reset-on-resume quirking more fine grained. I can see 3 ways to do this:
>
> 1) Make it a separate per usb-id BTUSB_RESET_RESUME flag in the
> usb_device_id table inside btusb.c (I still believe duplicating most
> ids to usb/core/quirks.c is a bad idea).
>
> 2) Use dmi based whitelisting to opt out of reset-resume behavior on
> QCA btusb devices.
>
> 3) Use dmi based blacklisting which enables reset-resume behavior.
>
> In retrospect I guess 3 would have been best, but if we do that now
> it will cause regressions.
>
> I guess we should go with 1. adding the BTUSB_RESET_RESUME to all the
> QCA usb-ids except for the ones where you know things work and which
> only seem to be used in working devices (based on you not having
> objections against the additions of the quirk for some ids to
> drivers/usb/core/quirks.c).
>
> And if then those usb-ids do turn out to have broken suspend on
> on some devices too I guess we need to move to 2.
actually if this is really platform related as Qualcomm is indicating, then we should just go with 3) and the two platforms that previously added quirks to usb/core/quirks.c and blacklist these. I am all for figuring out what is going on here. So lets blacklist these and see how this goes. Maybe there are only two bad platforms out there and we are making too much fuzz about this. Before we added quirks in the USB core these platforms were just plain broken as well. So not much different situation than before. We need to push the DMI blacklisting back into -stable as well and that means any impact of a 3rd broken platform briefly working and then be broken again is slim and also fixable via -stable.
I addition we can add a module option to btusb.ko that allows us to force this flag to be set. That way testing this is easy on a vendor kernel. A bunch of the btusb quirks (and also core quirks) can be tested via module options or debugfs.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v7 02/37] asm-generic/io.h: move ioremap_nocache/ioremap_uc/ioremap_wc/ioremap_wt out of ifndef CONFIG_MMU
From: kbuild test robot @ 2018-02-16 10:47 UTC (permalink / raw)
Cc: kbuild-all, greentime, linux-kernel, arnd, linux-arch, tglx,
jason, marc.zyngier, robh+dt, netdev, deanbo422, devicetree, viro,
dhowells, will.deacon, daniel.lezcano, linux-serial,
geert.uytterhoeven, linus.walleij, mark.rutland, greg, ren_guo,
rdunlap, davem, jonas, stefan.kristiansson, shorne, green.hu,
Vincent Chen
In-Reply-To: <ff404658ececd53f1bf111067c587c4e3eb695af.1518505384.git.greentime@andestech.com>
[-- Attachment #1: Type: text/plain, Size: 30529 bytes --]
Hi Greentime,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc1 next-20180216]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Greentime-Hu/Andes-nds32-Linux-Kernel-Port/20180216-155013
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All error/warnings (new ones prefixed by >>):
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/io.h:25,
from /kbuild/src/consumer/drivers//staging/comedi/drivers/comedi_8254.c:118:
>> /kbuild/src/consumer/include/asm-generic/io.h:864:15: error: conflicting types for 'ioremap'
void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
^~~~~~~
In file included from /kbuild/src/consumer/include/linux/io.h:25:0,
from /kbuild/src/consumer/drivers//staging/comedi/drivers/comedi_8254.c:118:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:59:29: note: previous definition of 'ioremap' was here
static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
^~~~~~~
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/io.h:25,
from /kbuild/src/consumer/drivers//staging/comedi/drivers/comedi_8254.c:118:
>> /kbuild/src/consumer/include/asm-generic/io.h:865:25: error: conflicting types for 'ioremap_nocache'
#define ioremap_nocache ioremap_nocache
^
>> /kbuild/src/consumer/include/asm-generic/io.h:866:29: note: in expansion of macro 'ioremap_nocache'
static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
^~~~~~~~~~~~~~~
In file included from /kbuild/src/consumer/include/linux/io.h:25:0,
from /kbuild/src/consumer/drivers//staging/comedi/drivers/comedi_8254.c:118:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:35:29: note: previous definition of 'ioremap_nocache' was here
static inline void __iomem *ioremap_nocache(unsigned long offset,
^~~~~~~~~~~~~~~
--
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/io.h:25,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_glue.h:45,
from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_fw.c:40:
>> /kbuild/src/consumer/include/asm-generic/io.h:864:15: error: conflicting types for 'ioremap'
void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
^~~~~~~
In file included from /kbuild/src/consumer/include/linux/io.h:25:0,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_glue.h:45,
from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_fw.c:40:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:59:29: note: previous definition of 'ioremap' was here
static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
^~~~~~~
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/io.h:25,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_glue.h:45,
from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_fw.c:40:
>> /kbuild/src/consumer/include/asm-generic/io.h:865:25: error: conflicting types for 'ioremap_nocache'
#define ioremap_nocache ioremap_nocache
^
>> /kbuild/src/consumer/include/asm-generic/io.h:866:29: note: in expansion of macro 'ioremap_nocache'
static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
^~~~~~~~~~~~~~~
In file included from /kbuild/src/consumer/include/linux/io.h:25:0,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_glue.h:45,
from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_fw.c:40:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:35:29: note: previous definition of 'ioremap_nocache' was here
static inline void __iomem *ioremap_nocache(unsigned long offset,
^~~~~~~~~~~~~~~
In file included from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_glue.h:64:0,
from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_fw.c:40:
/kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_defs.h:109:0: warning: "WSR" redefined
#define WSR 0x01 /* sta: wide scsi received [W]*/
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/bitops.h:22:0,
from /kbuild/src/consumer/include/linux/bitops.h:38,
from /kbuild/src/consumer/include/linux/kernel.h:11,
from /kbuild/src/consumer/include/linux/list.h:9,
from /kbuild/src/consumer/include/linux/wait.h:7,
from /kbuild/src/consumer/include/linux/completion.h:12,
from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_glue.h:43,
from /kbuild/src/consumer/drivers//scsi/sym53c8xx_2/sym_fw.c:40:
/kbuild/src/consumer/arch/xtensa/include/asm/processor.h:220:0: note: this is the location of the previous definition
#define WSR(v,sr) __asm__ __volatile__ ("wsr %0,"__stringify(sr) :: "a"(v));
--
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/io.h:25,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/include/linux/pci.h:32,
from /kbuild/src/consumer/drivers//net/ethernet/intel/ixgbe/ixgbe_main.c:31:
>> /kbuild/src/consumer/include/asm-generic/io.h:864:15: error: conflicting types for 'ioremap'
void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
^~~~~~~
In file included from /kbuild/src/consumer/include/linux/io.h:25:0,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/include/linux/pci.h:32,
from /kbuild/src/consumer/drivers//net/ethernet/intel/ixgbe/ixgbe_main.c:31:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:59:29: note: previous definition of 'ioremap' was here
static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
^~~~~~~
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/io.h:25,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/include/linux/pci.h:32,
from /kbuild/src/consumer/drivers//net/ethernet/intel/ixgbe/ixgbe_main.c:31:
>> /kbuild/src/consumer/include/asm-generic/io.h:865:25: error: conflicting types for 'ioremap_nocache'
#define ioremap_nocache ioremap_nocache
^
>> /kbuild/src/consumer/include/asm-generic/io.h:866:29: note: in expansion of macro 'ioremap_nocache'
static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
^~~~~~~~~~~~~~~
In file included from /kbuild/src/consumer/include/linux/io.h:25:0,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/include/linux/pci.h:32,
from /kbuild/src/consumer/drivers//net/ethernet/intel/ixgbe/ixgbe_main.c:31:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:35:29: note: previous definition of 'ioremap_nocache' was here
static inline void __iomem *ioremap_nocache(unsigned long offset,
^~~~~~~~~~~~~~~
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/atomic.h:21:0,
from /kbuild/src/consumer/include/linux/atomic.h:5,
from /kbuild/src/consumer/include/linux/debug_locks.h:6,
from /kbuild/src/consumer/include/linux/lockdep.h:28,
from /kbuild/src/consumer/include/linux/spinlock_types.h:18,
from /kbuild/src/consumer/include/linux/spinlock.h:82,
from /kbuild/src/consumer/include/linux/seqlock.h:36,
from /kbuild/src/consumer/include/linux/time.h:6,
from /kbuild/src/consumer/include/linux/stat.h:19,
from /kbuild/src/consumer/include/linux/module.h:10,
from /kbuild/src/consumer/drivers//net/ethernet/intel/ixgbe/ixgbe_main.c:30:
/kbuild/src/consumer/drivers//net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_xdp_setup':
/kbuild/src/consumer/arch/xtensa/include/asm/cmpxchg.h:139:3: warning: value computed is not used [-Wunused-value]
((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/kbuild/src/consumer/drivers//net/ethernet/intel/ixgbe/ixgbe_main.c:9949:4: note: in expansion of macro 'xchg'
xchg(&adapter->rx_ring[i]->xdp_prog, adapter->xdp_prog);
^~~~
--
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/gameport.h:11,
from /kbuild/src/consumer/drivers//input/joystick/analog.c:36:
>> /kbuild/src/consumer/include/asm-generic/io.h:864:15: error: conflicting types for 'ioremap'
void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
^~~~~~~
In file included from /kbuild/src/consumer/include/linux/gameport.h:11:0,
from /kbuild/src/consumer/drivers//input/joystick/analog.c:36:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:59:29: note: previous definition of 'ioremap' was here
static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
^~~~~~~
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/gameport.h:11,
from /kbuild/src/consumer/drivers//input/joystick/analog.c:36:
>> /kbuild/src/consumer/include/asm-generic/io.h:865:25: error: conflicting types for 'ioremap_nocache'
#define ioremap_nocache ioremap_nocache
^
>> /kbuild/src/consumer/include/asm-generic/io.h:866:29: note: in expansion of macro 'ioremap_nocache'
static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
^~~~~~~~~~~~~~~
In file included from /kbuild/src/consumer/include/linux/gameport.h:11:0,
from /kbuild/src/consumer/drivers//input/joystick/analog.c:36:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:35:29: note: previous definition of 'ioremap_nocache' was here
static inline void __iomem *ioremap_nocache(unsigned long offset,
^~~~~~~~~~~~~~~
/kbuild/src/consumer/drivers//input/joystick/analog.c:176:2: warning: #warning Precise timer not defined for this architecture. [-Wcpp]
#warning Precise timer not defined for this architecture.
^~~~~~~
--
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/io.h:25,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/ib_verbs.c:39:
>> /kbuild/src/consumer/include/asm-generic/io.h:864:15: error: conflicting types for 'ioremap'
void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
^~~~~~~
In file included from /kbuild/src/consumer/include/linux/io.h:25:0,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/ib_verbs.c:39:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:59:29: note: previous definition of 'ioremap' was here
static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
^~~~~~~
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/io.h:25,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/ib_verbs.c:39:
>> /kbuild/src/consumer/include/asm-generic/io.h:865:25: error: conflicting types for 'ioremap_nocache'
#define ioremap_nocache ioremap_nocache
^
>> /kbuild/src/consumer/include/asm-generic/io.h:866:29: note: in expansion of macro 'ioremap_nocache'
static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
^~~~~~~~~~~~~~~
In file included from /kbuild/src/consumer/include/linux/io.h:25:0,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/ib_verbs.c:39:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:35:29: note: previous definition of 'ioremap_nocache' was here
static inline void __iomem *ioremap_nocache(unsigned long offset,
^~~~~~~~~~~~~~~
In file included from /kbuild/src/consumer/include/linux/kernel.h:11:0,
from /kbuild/src/consumer/include/linux/interrupt.h:6,
from /kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/ib_verbs.c:39:
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/ib_verbs.c: In function 'bnxt_re_query_device':
/kbuild/src/consumer/include/linux/bitops.h:7:24: warning: left shift count >= width of type [-Wshift-count-overflow]
#define BIT(nr) (1UL << (nr))
^
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/bnxt_re.h:61:34: note: in expansion of macro 'BIT'
#define BNXT_RE_MAX_MR_SIZE_HIGH BIT(39)
^~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/bnxt_re.h:62:30: note: in expansion of macro 'BNXT_RE_MAX_MR_SIZE_HIGH'
#define BNXT_RE_MAX_MR_SIZE BNXT_RE_MAX_MR_SIZE_HIGH
^~~~~~~~~~~~~~~~~~~~~~~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/ib_verbs.c:149:25: note: in expansion of macro 'BNXT_RE_MAX_MR_SIZE'
ib_attr->max_mr_size = BNXT_RE_MAX_MR_SIZE;
^~~~~~~~~~~~~~~~~~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/ib_verbs.c: In function 'bnxt_re_reg_user_mr':
/kbuild/src/consumer/include/linux/bitops.h:7:24: warning: left shift count >= width of type [-Wshift-count-overflow]
#define BIT(nr) (1UL << (nr))
^
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/bnxt_re.h:61:34: note: in expansion of macro 'BIT'
#define BNXT_RE_MAX_MR_SIZE_HIGH BIT(39)
^~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/bnxt_re.h:62:30: note: in expansion of macro 'BNXT_RE_MAX_MR_SIZE_HIGH'
#define BNXT_RE_MAX_MR_SIZE BNXT_RE_MAX_MR_SIZE_HIGH
^~~~~~~~~~~~~~~~~~~~~~~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/ib_verbs.c:3553:15: note: in expansion of macro 'BNXT_RE_MAX_MR_SIZE'
if (length > BNXT_RE_MAX_MR_SIZE) {
^~~~~~~~~~~~~~~~~~~
/kbuild/src/consumer/include/linux/bitops.h:7:24: warning: left shift count >= width of type [-Wshift-count-overflow]
#define BIT(nr) (1UL << (nr))
^
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/bnxt_re.h:61:34: note: in expansion of macro 'BIT'
#define BNXT_RE_MAX_MR_SIZE_HIGH BIT(39)
^~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/bnxt_re.h:62:30: note: in expansion of macro 'BNXT_RE_MAX_MR_SIZE_HIGH'
#define BNXT_RE_MAX_MR_SIZE BNXT_RE_MAX_MR_SIZE_HIGH
^~~~~~~~~~~~~~~~~~~~~~~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/ib_verbs.c:3555:12: note: in expansion of macro 'BNXT_RE_MAX_MR_SIZE'
length, BNXT_RE_MAX_MR_SIZE);
^~~~~~~~~~~~~~~~~~~
--
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/io.h:25,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:39:
>> /kbuild/src/consumer/include/asm-generic/io.h:864:15: error: conflicting types for 'ioremap'
void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
^~~~~~~
In file included from /kbuild/src/consumer/include/linux/io.h:25:0,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:39:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:59:29: note: previous definition of 'ioremap' was here
static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
^~~~~~~
In file included from /kbuild/src/consumer/arch/xtensa/include/asm/io.h:82:0,
from /kbuild/src/consumer/include/linux/io.h:25,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:39:
>> /kbuild/src/consumer/include/asm-generic/io.h:865:25: error: conflicting types for 'ioremap_nocache'
#define ioremap_nocache ioremap_nocache
^
>> /kbuild/src/consumer/include/asm-generic/io.h:866:29: note: in expansion of macro 'ioremap_nocache'
static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
^~~~~~~~~~~~~~~
In file included from /kbuild/src/consumer/include/linux/io.h:25:0,
from /kbuild/src/consumer/include/linux/irq.h:25,
from /kbuild/src/consumer/include/asm-generic/hardirq.h:13,
from ./arch/xtensa/include/generated/asm/hardirq.h:1,
from /kbuild/src/consumer/include/linux/hardirq.h:9,
from /kbuild/src/consumer/include/linux/interrupt.h:13,
from /kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:39:
/kbuild/src/consumer/arch/xtensa/include/asm/io.h:35:29: note: previous definition of 'ioremap_nocache' was here
static inline void __iomem *ioremap_nocache(unsigned long offset,
^~~~~~~~~~~~~~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq':
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:333:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle,
^
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:336:12: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
(struct bnxt_qplib_srq *)q_handle,
^
In file included from /kbuild/src/consumer/include/linux/swab.h:5:0,
from /kbuild/src/consumer/include/uapi/linux/byteorder/big_endian.h:13,
from /kbuild/src/consumer/include/linux/byteorder/big_endian.h:5,
from /kbuild/src/consumer/arch/xtensa/include/uapi/asm/byteorder.h:8,
from /kbuild/src/consumer/arch/xtensa/include/asm/bitops.h:23,
from /kbuild/src/consumer/include/linux/bitops.h:38,
from /kbuild/src/consumer/include/linux/kernel.h:11,
from /kbuild/src/consumer/include/linux/interrupt.h:6,
from /kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:39:
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq':
/kbuild/src/consumer/include/uapi/linux/swab.h:130:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(__builtin_constant_p((__u64)(x)) ? \
^
/kbuild/src/consumer/include/uapi/linux/byteorder/big_endian.h:31:43: note: in expansion of macro '__swab64'
#define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
^~~~~~~~
/kbuild/src/consumer/include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64'
#define cpu_to_le64 __cpu_to_le64
^~~~~~~~~~~~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:567:19: note: in expansion of macro 'cpu_to_le64'
req.srq_handle = cpu_to_le64(srq);
^~~~~~~~~~~
/kbuild/src/consumer/include/uapi/linux/swab.h:24:4: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(((__u64)(x) & (__u64)0x00000000000000ffULL) << 56) | \
^
/kbuild/src/consumer/include/uapi/linux/swab.h:131:2: note: in expansion of macro '___constant_swab64'
___constant_swab64(x) : \
^~~~~~~~~~~~~~~~~~
/kbuild/src/consumer/include/uapi/linux/byteorder/big_endian.h:31:43: note: in expansion of macro '__swab64'
#define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
^~~~~~~~
/kbuild/src/consumer/include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64'
#define cpu_to_le64 __cpu_to_le64
^~~~~~~~~~~~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:567:19: note: in expansion of macro 'cpu_to_le64'
req.srq_handle = cpu_to_le64(srq);
^~~~~~~~~~~
/kbuild/src/consumer/include/uapi/linux/swab.h:25:4: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(((__u64)(x) & (__u64)0x000000000000ff00ULL) << 40) | \
^
/kbuild/src/consumer/include/uapi/linux/swab.h:131:2: note: in expansion of macro '___constant_swab64'
___constant_swab64(x) : \
^~~~~~~~~~~~~~~~~~
/kbuild/src/consumer/include/uapi/linux/byteorder/big_endian.h:31:43: note: in expansion of macro '__swab64'
#define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
^~~~~~~~
/kbuild/src/consumer/include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64'
#define cpu_to_le64 __cpu_to_le64
^~~~~~~~~~~~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:567:19: note: in expansion of macro 'cpu_to_le64'
req.srq_handle = cpu_to_le64(srq);
^~~~~~~~~~~
/kbuild/src/consumer/include/uapi/linux/swab.h:26:4: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(((__u64)(x) & (__u64)0x0000000000ff0000ULL) << 24) | \
^
/kbuild/src/consumer/include/uapi/linux/swab.h:131:2: note: in expansion of macro '___constant_swab64'
___constant_swab64(x) : \
^~~~~~~~~~~~~~~~~~
/kbuild/src/consumer/include/uapi/linux/byteorder/big_endian.h:31:43: note: in expansion of macro '__swab64'
#define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
^~~~~~~~
/kbuild/src/consumer/include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64'
#define cpu_to_le64 __cpu_to_le64
^~~~~~~~~~~~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:567:19: note: in expansion of macro 'cpu_to_le64'
req.srq_handle = cpu_to_le64(srq);
^~~~~~~~~~~
/kbuild/src/consumer/include/uapi/linux/swab.h:27:4: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(((__u64)(x) & (__u64)0x00000000ff000000ULL) << 8) | \
^
/kbuild/src/consumer/include/uapi/linux/swab.h:131:2: note: in expansion of macro '___constant_swab64'
___constant_swab64(x) : \
^~~~~~~~~~~~~~~~~~
/kbuild/src/consumer/include/uapi/linux/byteorder/big_endian.h:31:43: note: in expansion of macro '__swab64'
#define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
^~~~~~~~
/kbuild/src/consumer/include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64'
#define cpu_to_le64 __cpu_to_le64
^~~~~~~~~~~~~
/kbuild/src/consumer/drivers//infiniband/hw/bnxt_re/qplib_fp.c:567:19: note: in expansion of macro 'cpu_to_le64'
req.srq_handle = cpu_to_le64(srq);
..
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 53096 bytes --]
^ permalink raw reply
* Re: [PATCH v7 02/37] asm-generic/io.h: move ioremap_nocache/ioremap_uc/ioremap_wc/ioremap_wt out of ifndef CONFIG_MMU
From: kbuild test robot @ 2018-02-16 9:30 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, greentime-MUIXKm3Oiri1Z/+hSey0Gg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
linux-arch-u79uwXL29TY76Z2rM5mHXA, tglx-hfZtesqFncYOwBW4kG4KsQ,
jason-NLaQJdtUoK4Be96aLqz0jA, marc.zyngier-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
deanbo422-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
dhowells-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
geert.uytterhoeven-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
greg-U8xfFu+wG4EAvxtiuMwx3w, ren_guo-Y+KPrCd2zL4AvxtiuMwx3w,
rdunlap-wEGCiKHe2LqWVfeAwA7xHQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jonas-A9uVI2HLR7kOP4wsBPIw7w,
stefan.kristiansson-MbMCFXIvDHJFcC0YU169RA,
shorne-Re5JQEeQqe8AvxtiuMwx3w, green.hu-Re5JQEeQqe8AvxtiuMwx3w,
Vincent Chen
In-Reply-To: <ff404658ececd53f1bf111067c587c4e3eb695af.1518505384.git.greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 8703 bytes --]
Hi Greentime,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc1 next-20180216]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Greentime-Hu/Andes-nds32-Linux-Kernel-Port/20180216-155013
config: cris-etrax-100lx_v2_defconfig (attached as .config)
compiler: cris-linux-gcc (GCC) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=cris
All warnings (new ones prefixed by >>):
In file included from arch/cris/include/asm/io.h:24:0,
from include/linux/io.h:25,
from arch/cris/mm/ioremap.c:14:
include/asm-generic/io.h:864:15: error: conflicting types for 'ioremap'
void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
^~~~~~~
In file included from include/linux/io.h:25:0,
from arch/cris/mm/ioremap.c:14:
arch/cris/include/asm/io.h:15:30: note: previous definition of 'ioremap' was here
static inline void __iomem * ioremap (unsigned long offset, unsigned long size)
^~~~~~~
In file included from arch/cris/include/asm/io.h:24:0,
from include/linux/io.h:25,
from arch/cris/mm/ioremap.c:14:
include/asm-generic/io.h:865:25: error: conflicting types for 'ioremap_nocache'
#define ioremap_nocache ioremap_nocache
^
include/asm-generic/io.h:866:29: note: in expansion of macro 'ioremap_nocache'
static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
^~~~~~~~~~~~~~~
In file included from include/linux/io.h:25:0,
from arch/cris/mm/ioremap.c:14:
arch/cris/include/asm/io.h:22:23: note: previous declaration of 'ioremap_nocache' was here
extern void __iomem * ioremap_nocache(unsigned long offset, unsigned long size);
^~~~~~~~~~~~~~~
In file included from arch/cris/include/asm/io.h:24:0,
from include/linux/io.h:25,
from arch/cris/mm/ioremap.c:14:
include/asm-generic/io.h:865:25: error: conflicting types for 'ioremap_nocache'
#define ioremap_nocache ioremap_nocache
^
>> arch/cris/mm/ioremap.c:80:15: note: in expansion of macro 'ioremap_nocache'
void __iomem *ioremap_nocache(unsigned long phys_addr, unsigned long size)
^~~~~~~~~~~~~~~
include/asm-generic/io.h:865:25: note: previous definition of 'ioremap_nocache' was here
#define ioremap_nocache ioremap_nocache
^
include/asm-generic/io.h:866:29: note: in expansion of macro 'ioremap_nocache'
static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
^~~~~~~~~~~~~~~
vim +/ioremap_nocache +80 arch/cris/mm/ioremap.c
e32cbc3d Haavard Skinnemoen 2006-09-30 @14 #include <linux/io.h>
^1da177e Linus Torvalds 2005-04-16 15 #include <asm/pgalloc.h>
556dcee7 Jesper Nilsson 2008-10-21 16 #include <arch/memmap.h>
^1da177e Linus Torvalds 2005-04-16 17
^1da177e Linus Torvalds 2005-04-16 18 /*
^1da177e Linus Torvalds 2005-04-16 19 * Generic mapping function (not visible outside):
^1da177e Linus Torvalds 2005-04-16 20 */
^1da177e Linus Torvalds 2005-04-16 21
^1da177e Linus Torvalds 2005-04-16 22 /*
^1da177e Linus Torvalds 2005-04-16 23 * Remap an arbitrary physical address space into the kernel virtual
^1da177e Linus Torvalds 2005-04-16 24 * address space. Needed when the kernel wants to access high addresses
^1da177e Linus Torvalds 2005-04-16 25 * directly.
^1da177e Linus Torvalds 2005-04-16 26 *
^1da177e Linus Torvalds 2005-04-16 27 * NOTE! We need to allow non-page-aligned mappings too: we will obviously
^1da177e Linus Torvalds 2005-04-16 28 * have to convert them into an offset in a page-aligned mapping, but the
^1da177e Linus Torvalds 2005-04-16 29 * caller shouldn't need to know that small detail.
^1da177e Linus Torvalds 2005-04-16 30 */
4f18cfbf Mikael Starvik 2005-07-27 31 void __iomem * __ioremap_prot(unsigned long phys_addr, unsigned long size, pgprot_t prot)
^1da177e Linus Torvalds 2005-04-16 32 {
4f18cfbf Mikael Starvik 2005-07-27 33 void __iomem * addr;
^1da177e Linus Torvalds 2005-04-16 34 struct vm_struct * area;
^1da177e Linus Torvalds 2005-04-16 35 unsigned long offset, last_addr;
^1da177e Linus Torvalds 2005-04-16 36
^1da177e Linus Torvalds 2005-04-16 37 /* Don't allow wraparound or zero size */
^1da177e Linus Torvalds 2005-04-16 38 last_addr = phys_addr + size - 1;
^1da177e Linus Torvalds 2005-04-16 39 if (!size || last_addr < phys_addr)
^1da177e Linus Torvalds 2005-04-16 40 return NULL;
^1da177e Linus Torvalds 2005-04-16 41
^1da177e Linus Torvalds 2005-04-16 42 /*
^1da177e Linus Torvalds 2005-04-16 43 * Mappings have to be page-aligned
^1da177e Linus Torvalds 2005-04-16 44 */
^1da177e Linus Torvalds 2005-04-16 45 offset = phys_addr & ~PAGE_MASK;
^1da177e Linus Torvalds 2005-04-16 46 phys_addr &= PAGE_MASK;
^1da177e Linus Torvalds 2005-04-16 47 size = PAGE_ALIGN(last_addr+1) - phys_addr;
^1da177e Linus Torvalds 2005-04-16 48
^1da177e Linus Torvalds 2005-04-16 49 /*
^1da177e Linus Torvalds 2005-04-16 50 * Ok, go for it..
^1da177e Linus Torvalds 2005-04-16 51 */
^1da177e Linus Torvalds 2005-04-16 52 area = get_vm_area(size, VM_IOREMAP);
^1da177e Linus Torvalds 2005-04-16 53 if (!area)
^1da177e Linus Torvalds 2005-04-16 54 return NULL;
4f18cfbf Mikael Starvik 2005-07-27 55 addr = (void __iomem *)area->addr;
e32cbc3d Haavard Skinnemoen 2006-09-30 56 if (ioremap_page_range((unsigned long)addr, (unsigned long)addr + size,
e32cbc3d Haavard Skinnemoen 2006-09-30 57 phys_addr, prot)) {
4f18cfbf Mikael Starvik 2005-07-27 58 vfree((void __force *)addr);
^1da177e Linus Torvalds 2005-04-16 59 return NULL;
^1da177e Linus Torvalds 2005-04-16 60 }
4f18cfbf Mikael Starvik 2005-07-27 61 return (void __iomem *) (offset + (char __iomem *)addr);
4f18cfbf Mikael Starvik 2005-07-27 62 }
4f18cfbf Mikael Starvik 2005-07-27 63
4f18cfbf Mikael Starvik 2005-07-27 64 void __iomem * __ioremap(unsigned long phys_addr, unsigned long size, unsigned long flags)
4f18cfbf Mikael Starvik 2005-07-27 65 {
4f18cfbf Mikael Starvik 2005-07-27 66 return __ioremap_prot(phys_addr, size,
4f18cfbf Mikael Starvik 2005-07-27 67 __pgprot(_PAGE_PRESENT | __READABLE |
4f18cfbf Mikael Starvik 2005-07-27 68 __WRITEABLE | _PAGE_GLOBAL |
4f18cfbf Mikael Starvik 2005-07-27 69 _PAGE_KERNEL | flags));
4f18cfbf Mikael Starvik 2005-07-27 70 }
4f18cfbf Mikael Starvik 2005-07-27 71
4f18cfbf Mikael Starvik 2005-07-27 72 /**
4f18cfbf Mikael Starvik 2005-07-27 73 * ioremap_nocache - map bus memory into CPU space
4f18cfbf Mikael Starvik 2005-07-27 74 * @offset: bus address of the memory
4f18cfbf Mikael Starvik 2005-07-27 75 * @size: size of the resource to map
4f18cfbf Mikael Starvik 2005-07-27 76 *
4f18cfbf Mikael Starvik 2005-07-27 77 * Must be freed with iounmap.
4f18cfbf Mikael Starvik 2005-07-27 78 */
4f18cfbf Mikael Starvik 2005-07-27 79
4f18cfbf Mikael Starvik 2005-07-27 @80 void __iomem *ioremap_nocache(unsigned long phys_addr, unsigned long size)
4f18cfbf Mikael Starvik 2005-07-27 81 {
4f18cfbf Mikael Starvik 2005-07-27 82 return __ioremap(phys_addr | MEM_NON_CACHEABLE, size, 0);
^1da177e Linus Torvalds 2005-04-16 83 }
82e6df1e Jesper Nilsson 2014-10-01 84 EXPORT_SYMBOL(ioremap_nocache);
^1da177e Linus Torvalds 2005-04-16 85
:::::: The code at line 80 was first introduced by commit
:::::: 4f18cfbf0990bfc2e8e7706eeb9e5bef898ae923 [PATCH] CRIS update: mm
:::::: TO: Mikael Starvik <mikael.starvik-VrBV9hrLPhE@public.gmane.org>
:::::: CC: Linus Torvalds <torvalds-hNm40g4Ew95AfugRpC6u6w@public.gmane.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 8927 bytes --]
^ permalink raw reply
* Re: [PATCH] [PATCH] tty/serial: atmel: add new version check for usart
From: Richard Genoud @ 2018-02-16 9:27 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Jonas Danielsson, Greg Kroah-Hartman, Alexandre Belloni,
linux-serial, Jiri Slaby, linux-arm-kernel
In-Reply-To: <e20ced24-666b-32b7-92cd-d30e1a10b42e@microchip.com>
2018-02-05 13:36 GMT+01:00 Nicolas Ferre <nicolas.ferre@microchip.com>:
> On 29/01/2018 at 12:39, Jonas Danielsson wrote:
>> On our at91sam9260 based board the usart0 and usart1 ports report
>> their versions (ATMEL_US_VERSION) as 0x10302. This version is not
>> included in the current checks in the driver.
>>
>> Signed-off-by: Jonas Danielsson <jonas@orbital-systems.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
>
Acked-by: Richard Genoud <richard.genoud@gmail.com>
> It must be the AT91SAM9260 rev. B SoC, isn't it?
>
> Thanks for your patch.
>
> Best regards,
> Nicolas
Thanks !
Richard.
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Hans de Goede @ 2018-02-16 8:56 UTC (permalink / raw)
To: Brian Norris
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-bluetooth,
linux-serial, linux-acpi, stable, Leif Liddy, Matthias Kaehlcke,
Daniel Drake, Kai-Heng Feng, matadeen, linux-kernel,
Greg Kroah-Hartman, Guenter Roeck
In-Reply-To: <20180216022721.GA69988@rodete-desktop-imager.corp.google.com>
Hi,
On 16-02-18 03:27, Brian Norris wrote:
> Hi Hans,
>
> On Tue, Feb 13, 2018 at 12:25:55PM +0100, Hans de Goede wrote:
>> On 13-02-18 03:24, Brian Norris wrote:
>>> On Mon, Jan 08, 2018 at 10:44:16AM +0100, Hans de Goede wrote:
>>>> Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
>>>> removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
>>>> instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
>>>>
>>>> This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
>>>> has several issues (see the original commit message). An added advantage
>>>> of moving over to the USB-core reset-resume handling is that it also
>>>> disables autosuspend for these devices, which is similarly broken on these.
>>>
>>> Wait, is autosuspend actually broken for all QCA Rome chipsets? I don't
>>> think so -- I'm using one now.
>>
>> And have you manually enabled USB autosuspend for it, or are you
>> running something which might have done so, e.g. powertop --auto-tune ?
>>
>> Because if you did not do that then you're already not using autosuspend
>> for your QCA devices and this patch will change nothing.
>
> I use a set of udev rules that manually whitelist devices for
> autosuspend. You can see it here:
>
> https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
>
> You'll find at least one Rome chip in there.
>
>>> Thus, this is a poor solution, which
>>> negatively affects my systems. However, I see that this patch was
>>> applied regardless...
>>
>> Note that there already is a quirk to handle broken suspend/resume
>> behavior on ALL QCA devices in older kernels. Also note that the
>
> Yes, and the quirk was broken, and I made sure it got reverted when it
> broke my devices ;)
Note that the revert for this:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d06d5895c15
Says: "This commit causes a regression on some QCA ROME chips. The USB device reset happens
in btusb_open(), hence firmware loading gets interrupted."
And says:
"If we really want to reset the USB device, we need to do it before btusb_open(). Let's
handle it in drivers/usb/core/quirks.c."
It does not mention that the quirk is not necessary on some devices only
that the implementation of it we had before had issues.
And the original commit of the quirk:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/drivers/bluetooth/btusb.c?id=fd865802c66bc451dc515ed89360f84376ce1a56
Says: "There's been numerous reported instances where BTUSB_QCA_ROME
bluetooth controllers stop functioning upon resume from suspend."
So it may be platform specific but it is not just limited to 1 or
2 platforms I think.
Note I'm not saying that I don't believe you that the quirk is not
necessary on your devices.
>> patches series which this commit builds on top of was already
>> setting USB_QUIRK_RESET_RESUME for some devices in
>> usb/core/quirks.c.
>>
>> All my commit does is instead of duplicating all the QCA USB-ids in
>> usb/core/quirks.c, move the setting of USB_QUIRK_RESET_RESUME
>> to btusb.c so that we don't need to duplicate the USB-id tables.
>
> I was slightly more OK with marking specific IDs as broken, because
> those IDs didn't happen to be ones that I knew were currently working.
> Now you're breaking my systems again. But this time, it's more subtle
> because bluetooth will still work, but we just suck more power leaving
> our USB port active all the time.
I see, sorry about that. Ok, so we are going to need to make the
reset-on-resume quirking more fine grained. I can see 3 ways to do this:
1) Make it a separate per usb-id BTUSB_RESET_RESUME flag in the
usb_device_id table inside btusb.c (I still believe duplicating most
ids to usb/core/quirks.c is a bad idea).
2) Use dmi based whitelisting to opt out of reset-resume behavior on
QCA btusb devices.
3) Use dmi based blacklisting which enables reset-resume behavior.
In retrospect I guess 3 would have been best, but if we do that now
it will cause regressions.
I guess we should go with 1. adding the BTUSB_RESET_RESUME to all the
QCA usb-ids except for the ones where you know things work and which
only seem to be used in working devices (based on you not having
objections against the additions of the quirk for some ids to
drivers/usb/core/quirks.c).
And if then those usb-ids do turn out to have broken suspend on
on some devices too I guess we need to move to 2.
>> The result of the combination of these patches is that the custom
>> DIY reset on resume handling btusb.c was doing is now replaced
>> by setting the standard USB-core USB_QUIRK_RESET_RESUME quirk.
>>
>> As a (desirable) side effect this also disables USB autosuspend
>> for QCA devices since the USB-core does not allow USB autosuspend
>> on devices with the USB_QUIRK_RESET_RESUME quirk. Testing has shown
>> this to be necessary on at least some QCA devices and given that
>> these devices tend to loose there firmware on a suspend, it seems
>> sensible to not allow autosuspend on them.
>
> But you're not accurately targeting the "some". AFAICT, you're wasting
> power on my system.
OK, so it turns out that this is a platform problem, which was not
known to those involved until now. As mentioned before solution 3.
from my above list of solutions would then be ideal, but I don't see
how we can get there now without causing regressions where bluetooth
stops working completely for people.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Marcel Holtmann @ 2018-02-16 8:43 UTC (permalink / raw)
To: Brian Norris
Cc: Hans de Goede, Gustavo F. Padovan, Johan Hedberg,
Bluez mailing list, linux-serial, ACPI Devel Maling List, stable,
Leif Liddy, Matthias Kaehlcke, Daniel Drake, Kai-Heng Feng,
matadeen, Linux Kernel Mailing List, Greg Kroah-Hartman,
Guenter Roeck
In-Reply-To: <20180216022721.GA69988@rodete-desktop-imager.corp.google.com>
Hi Brian,
>>> On Mon, Jan 08, 2018 at 10:44:16AM +0100, Hans de Goede wrote:
>>>> Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
>>>> removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
>>>> instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
>>>>
>>>> This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
>>>> has several issues (see the original commit message). An added advantage
>>>> of moving over to the USB-core reset-resume handling is that it also
>>>> disables autosuspend for these devices, which is similarly broken on these.
>>>
>>> Wait, is autosuspend actually broken for all QCA Rome chipsets? I don't
>>> think so -- I'm using one now.
>>
>> And have you manually enabled USB autosuspend for it, or are you
>> running something which might have done so, e.g. powertop --auto-tune ?
>>
>> Because if you did not do that then you're already not using autosuspend
>> for your QCA devices and this patch will change nothing.
>
> I use a set of udev rules that manually whitelist devices for
> autosuspend. You can see it here:
>
> https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
>
> You'll find at least one Rome chip in there.
>
>>> Thus, this is a poor solution, which
>>> negatively affects my systems. However, I see that this patch was
>>> applied regardless...
>>
>> Note that there already is a quirk to handle broken suspend/resume
>> behavior on ALL QCA devices in older kernels. Also note that the
>
> Yes, and the quirk was broken, and I made sure it got reverted when it
> broke my devices ;)
>
>> patches series which this commit builds on top of was already
>> setting USB_QUIRK_RESET_RESUME for some devices in
>> usb/core/quirks.c.
>>
>> All my commit does is instead of duplicating all the QCA USB-ids in
>> usb/core/quirks.c, move the setting of USB_QUIRK_RESET_RESUME
>> to btusb.c so that we don't need to duplicate the USB-id tables.
>
> I was slightly more OK with marking specific IDs as broken, because
> those IDs didn't happen to be ones that I knew were currently working.
> Now you're breaking my systems again. But this time, it's more subtle
> because bluetooth will still work, but we just suck more power leaving
> our USB port active all the time.
>
>> The result of the combination of these patches is that the custom
>> DIY reset on resume handling btusb.c was doing is now replaced
>> by setting the standard USB-core USB_QUIRK_RESET_RESUME quirk.
>>
>> As a (desirable) side effect this also disables USB autosuspend
>> for QCA devices since the USB-core does not allow USB autosuspend
>> on devices with the USB_QUIRK_RESET_RESUME quirk. Testing has shown
>> this to be necessary on at least some QCA devices and given that
>> these devices tend to loose there firmware on a suspend, it seems
>> sensible to not allow autosuspend on them.
>
> But you're not accurately targeting the "some". AFAICT, you're wasting
> power on my system.
>
>>> What justifications was found for this anyway? AIUI, this is a platform
>>> bug, and not entirely a chipset bug.
>>
>> No this is believed to be a chipset issue, hence also the quirk in
>> older kernels to always reset these devices after a normal suspend/resume.
>
> I have Qualcomm telling me this is a platform issue. I haven't noticed
> problems with autosuspend nor system suspend/resume on my platform. Do
> you have any more detail on this issue? Have you consulsted QCA folks?
>
> Unfortunately, Greg is already queueing this patch up to all the -stable
> trees, so I'm going to have to revert it yet again in Chromium
> kernels...
if this is a platform issue, then doing this based on VID:PID pairs is wrong no matter what. Then again, if we have really dedicated VID:PID combination for certain platforms, we could also just whitelist them in the driver. The btusb.c already contains an extra blacklist check. It is easy to add another USB ID table for a QCA whitelist.
Regards
Marcel
^ permalink raw reply
* udev USB autosupend whitelist (was Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version)
From: Hans de Goede @ 2018-02-16 8:26 UTC (permalink / raw)
To: Brian Norris
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-bluetooth,
linux-serial, linux-acpi, stable, Leif Liddy, Matthias Kaehlcke,
Daniel Drake, Kai-Heng Feng, matadeen, linux-kernel,
Greg Kroah-Hartman, Guenter Roeck
In-Reply-To: <20180216022721.GA69988@rodete-desktop-imager.corp.google.com>
Hi,
Going a bit off-topic here, so changed the subject.
I will reply on topic in another mail.
On 16-02-18 03:27, Brian Norris wrote:
> Hi Hans,
>
> On Tue, Feb 13, 2018 at 12:25:55PM +0100, Hans de Goede wrote:
>> On 13-02-18 03:24, Brian Norris wrote:
>>> On Mon, Jan 08, 2018 at 10:44:16AM +0100, Hans de Goede wrote:
>>>> Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
>>>> removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
>>>> instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
>>>>
>>>> This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
>>>> has several issues (see the original commit message). An added advantage
>>>> of moving over to the USB-core reset-resume handling is that it also
>>>> disables autosuspend for these devices, which is similarly broken on these.
>>>
>>> Wait, is autosuspend actually broken for all QCA Rome chipsets? I don't
>>> think so -- I'm using one now.
>>
>> And have you manually enabled USB autosuspend for it, or are you
>> running something which might have done so, e.g. powertop --auto-tune ?
>>
>> Because if you did not do that then you're already not using autosuspend
>> for your QCA devices and this patch will change nothing.
>
> I use a set of udev rules that manually whitelist devices for
> autosuspend. You can see it here:
>
> https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
>
> You'll find at least one Rome chip in there.
Oh, that is a very interesting link for the work I've been doing to
improve Linux power-consumption in general:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
I was actually planning on at least doing such a list for WWAN modems,
for btusb my approach has been to just enable it everywhere
(except for QCA devices as I got bugreports for those).
Note that I plan to eventually submit this whitelist to the
udev rules which are part of systemd upstream, so if chromeos
is using systemd too, this is something to be aware of for you.
Question, is the white-listing of the root and rate-limiting
hubs really necessary? I thought these have this enabled by default?
Also any caveats here I should be aware of?
Regards,
Hans
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Guenter Roeck @ 2018-02-16 3:23 UTC (permalink / raw)
To: Brian Norris, Hans de Goede
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-bluetooth,
linux-serial, linux-acpi, stable, Leif Liddy, Matthias Kaehlcke,
Daniel Drake, Kai-Heng Feng, matadeen, linux-kernel,
Greg Kroah-Hartman
In-Reply-To: <20180216022721.GA69988@rodete-desktop-imager.corp.google.com>
On 02/15/2018 06:27 PM, Brian Norris wrote:
> Hi Hans,
>
> On Tue, Feb 13, 2018 at 12:25:55PM +0100, Hans de Goede wrote:
>> On 13-02-18 03:24, Brian Norris wrote:
>>> On Mon, Jan 08, 2018 at 10:44:16AM +0100, Hans de Goede wrote:
>>>> Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
>>>> removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
>>>> instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
>>>>
>>>> This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
>>>> has several issues (see the original commit message). An added advantage
>>>> of moving over to the USB-core reset-resume handling is that it also
>>>> disables autosuspend for these devices, which is similarly broken on these.
>>>
>>> Wait, is autosuspend actually broken for all QCA Rome chipsets? I don't
>>> think so -- I'm using one now.
>>
>> And have you manually enabled USB autosuspend for it, or are you
>> running something which might have done so, e.g. powertop --auto-tune ?
>>
>> Because if you did not do that then you're already not using autosuspend
>> for your QCA devices and this patch will change nothing.
>
> I use a set of udev rules that manually whitelist devices for
> autosuspend. You can see it here:
>
> https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
>
> You'll find at least one Rome chip in there.
>
>>> Thus, this is a poor solution, which
>>> negatively affects my systems. However, I see that this patch was
>>> applied regardless...
>>
>> Note that there already is a quirk to handle broken suspend/resume
>> behavior on ALL QCA devices in older kernels. Also note that the
>
> Yes, and the quirk was broken, and I made sure it got reverted when it
> broke my devices ;)
>
>> patches series which this commit builds on top of was already
>> setting USB_QUIRK_RESET_RESUME for some devices in
>> usb/core/quirks.c.
>>
>> All my commit does is instead of duplicating all the QCA USB-ids in
>> usb/core/quirks.c, move the setting of USB_QUIRK_RESET_RESUME
>> to btusb.c so that we don't need to duplicate the USB-id tables.
>
> I was slightly more OK with marking specific IDs as broken, because
> those IDs didn't happen to be ones that I knew were currently working.
> Now you're breaking my systems again. But this time, it's more subtle
> because bluetooth will still work, but we just suck more power leaving
> our USB port active all the time.
>
>> The result of the combination of these patches is that the custom
>> DIY reset on resume handling btusb.c was doing is now replaced
>> by setting the standard USB-core USB_QUIRK_RESET_RESUME quirk.
>>
>> As a (desirable) side effect this also disables USB autosuspend
>> for QCA devices since the USB-core does not allow USB autosuspend
>> on devices with the USB_QUIRK_RESET_RESUME quirk. Testing has shown
>> this to be necessary on at least some QCA devices and given that
>> these devices tend to loose there firmware on a suspend, it seems
>> sensible to not allow autosuspend on them.
>
> But you're not accurately targeting the "some". AFAICT, you're wasting
> power on my system.
>
>>> What justifications was found for this anyway? AIUI, this is a platform
>>> bug, and not entirely a chipset bug.
>>
>> No this is believed to be a chipset issue, hence also the quirk in
>> older kernels to always reset these devices after a normal suspend/resume.
>
> I have Qualcomm telling me this is a platform issue. I haven't noticed
> problems with autosuspend nor system suspend/resume on my platform. Do
> you have any more detail on this issue? Have you consulsted QCA folks?
>
> Unfortunately, Greg is already queueing this patch up to all the -stable
> trees, so I'm going to have to revert it yet again in Chromium
> kernels...
>
Grumble Grumble Grumble. I'll try to remember to revert this patch when I merge
v4.14.20 into chromeos-4.14. Please remind me if I forget for some reason.
I don't see it queued in v4.4.y - is that still coming ? Hope I won't miss it.
Guenter
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Brian Norris @ 2018-02-16 2:27 UTC (permalink / raw)
To: Hans de Goede
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-bluetooth,
linux-serial, linux-acpi, stable, Leif Liddy, Matthias Kaehlcke,
Daniel Drake, Kai-Heng Feng, matadeen, linux-kernel,
Greg Kroah-Hartman, Guenter Roeck
In-Reply-To: <8cd918fd-bf6f-70ac-e561-e7deffa695f0@redhat.com>
Hi Hans,
On Tue, Feb 13, 2018 at 12:25:55PM +0100, Hans de Goede wrote:
> On 13-02-18 03:24, Brian Norris wrote:
> > On Mon, Jan 08, 2018 at 10:44:16AM +0100, Hans de Goede wrote:
> > > Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
> > > removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
> > > instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
> > >
> > > This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
> > > has several issues (see the original commit message). An added advantage
> > > of moving over to the USB-core reset-resume handling is that it also
> > > disables autosuspend for these devices, which is similarly broken on these.
> >
> > Wait, is autosuspend actually broken for all QCA Rome chipsets? I don't
> > think so -- I'm using one now.
>
> And have you manually enabled USB autosuspend for it, or are you
> running something which might have done so, e.g. powertop --auto-tune ?
>
> Because if you did not do that then you're already not using autosuspend
> for your QCA devices and this patch will change nothing.
I use a set of udev rules that manually whitelist devices for
autosuspend. You can see it here:
https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
You'll find at least one Rome chip in there.
> > Thus, this is a poor solution, which
> > negatively affects my systems. However, I see that this patch was
> > applied regardless...
>
> Note that there already is a quirk to handle broken suspend/resume
> behavior on ALL QCA devices in older kernels. Also note that the
Yes, and the quirk was broken, and I made sure it got reverted when it
broke my devices ;)
> patches series which this commit builds on top of was already
> setting USB_QUIRK_RESET_RESUME for some devices in
> usb/core/quirks.c.
>
> All my commit does is instead of duplicating all the QCA USB-ids in
> usb/core/quirks.c, move the setting of USB_QUIRK_RESET_RESUME
> to btusb.c so that we don't need to duplicate the USB-id tables.
I was slightly more OK with marking specific IDs as broken, because
those IDs didn't happen to be ones that I knew were currently working.
Now you're breaking my systems again. But this time, it's more subtle
because bluetooth will still work, but we just suck more power leaving
our USB port active all the time.
> The result of the combination of these patches is that the custom
> DIY reset on resume handling btusb.c was doing is now replaced
> by setting the standard USB-core USB_QUIRK_RESET_RESUME quirk.
>
> As a (desirable) side effect this also disables USB autosuspend
> for QCA devices since the USB-core does not allow USB autosuspend
> on devices with the USB_QUIRK_RESET_RESUME quirk. Testing has shown
> this to be necessary on at least some QCA devices and given that
> these devices tend to loose there firmware on a suspend, it seems
> sensible to not allow autosuspend on them.
But you're not accurately targeting the "some". AFAICT, you're wasting
power on my system.
> > What justifications was found for this anyway? AIUI, this is a platform
> > bug, and not entirely a chipset bug.
>
> No this is believed to be a chipset issue, hence also the quirk in
> older kernels to always reset these devices after a normal suspend/resume.
I have Qualcomm telling me this is a platform issue. I haven't noticed
problems with autosuspend nor system suspend/resume on my platform. Do
you have any more detail on this issue? Have you consulsted QCA folks?
Unfortunately, Greg is already queueing this patch up to all the -stable
trees, so I'm going to have to revert it yet again in Chromium
kernels...
Brian
^ permalink raw reply
* Re: [PATCH v7 04/37] earlycon: add reg-offset to physical address before mapping
From: Rob Herring @ 2018-02-15 15:40 UTC (permalink / raw)
To: Greentime Hu, Greg Kroah-Hartman
Cc: greentime, linux-kernel@vger.kernel.org, Arnd Bergmann,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier, netdev,
deanbo422, devicetree, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial, Geert Uytterhoeven, Linus Walleij,
Mark Rutland, Greg KH, ren_guo, Randy Dunlap, David Miller
In-Reply-To: <968497070242f849dd70ab1fa81635451f8fda7f.1518505384.git.greentime@andestech.com>
On Tue, Feb 13, 2018 at 3:09 AM, Greentime Hu <green.hu@gmail.com> wrote:
> It will get the wrong virtual address because port->mapbase is not added
> the correct reg-offset yet. We have to update it before earlycon_map()
> is called
>
> Signed-off-by: Greentime Hu <greentime@andestech.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Peter Hurley <peter@hurleysoftware.com>
> Cc: stable@vger.kernel.org
> Fixes: 088da2a17619 ("of: earlycon: Initialize port fields from DT
> properties")
This should get applied now rather than sit in numerous revisions of
this series for nds32.
Acked-by: Rob Herring <robh@kernel.org>
Greg, can you apply?
Rob
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: prevent lockup on full TTY buffers
From: Wolfram Sang @ 2018-02-15 13:12 UTC (permalink / raw)
To: Ulrich Hecht; +Cc: linux-renesas-soc, linux-serial, geert, yoshihiro.shimoda.uh
In-Reply-To: <1518696147-23790-1-git-send-email-ulrich.hecht+renesas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 215 bytes --]
> This can be prevented by doing a dummy read of the RX data register.
Just so I understand the issue correctly: We are reading the register to
throw the content away to prevent it being used in the TTY buffers?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] serial: sh-sci: use hrtimer for receive timeout
From: Ulrich Hecht @ 2018-02-15 12:02 UTC (permalink / raw)
To: linux-renesas-soc, linux-serial
Cc: wsa, geert, yoshihiro.shimoda.uh, Ulrich Hecht
High latencies of classic timers cause performance issues for high-
speed serial transmissions. This patch transforms rx_timer into an
hrtimer to reduce the minimum latency.
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
---
drivers/tty/serial/sh-sci.c | 47 +++++++++++++++++++++++++++++----------------
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index d9f399c..553f30c 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -33,6 +33,7 @@
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/ioport.h>
+#include <linux/ktime.h>
#include <linux/major.h>
#include <linux/module.h>
#include <linux/mm.h>
@@ -143,8 +144,8 @@ struct sci_port {
void *rx_buf[2];
size_t buf_len_rx;
struct work_struct work_tx;
- struct timer_list rx_timer;
- unsigned int rx_timeout;
+ struct hrtimer rx_timer;
+ unsigned int rx_timeout; /* microseconds */
#endif
unsigned int rx_frame;
int rx_trigger;
@@ -1229,6 +1230,15 @@ static void sci_rx_dma_release(struct sci_port *s, bool enable_pio)
}
}
+static void start_hrtimer_us(struct hrtimer *hrt, unsigned long usec)
+{
+ long sec = usec / 1000000;
+ long nsec = (usec % 1000000) * 1000;
+ ktime_t t = ktime_set(sec, nsec);
+
+ hrtimer_start(hrt, t, HRTIMER_MODE_REL);
+}
+
static void sci_dma_rx_complete(void *arg)
{
struct sci_port *s = arg;
@@ -1247,7 +1257,7 @@ static void sci_dma_rx_complete(void *arg)
if (active >= 0)
count = sci_dma_rx_push(s, s->rx_buf[active], s->buf_len_rx);
- mod_timer(&s->rx_timer, jiffies + s->rx_timeout);
+ start_hrtimer_us(&s->rx_timer, s->rx_timeout);
if (count)
tty_flip_buffer_push(&port->state->port);
@@ -1391,9 +1401,9 @@ static void work_fn_tx(struct work_struct *work)
dma_async_issue_pending(chan);
}
-static void rx_timer_fn(struct timer_list *t)
+static enum hrtimer_restart rx_timer_fn(struct hrtimer *t)
{
- struct sci_port *s = from_timer(s, t, rx_timer);
+ struct sci_port *s = container_of(t, struct sci_port, rx_timer);
struct dma_chan *chan = s->chan_rx;
struct uart_port *port = &s->port;
struct dma_tx_state state;
@@ -1410,7 +1420,7 @@ static void rx_timer_fn(struct timer_list *t)
active = sci_dma_rx_find_active(s);
if (active < 0) {
spin_unlock_irqrestore(&port->lock, flags);
- return;
+ return HRTIMER_NORESTART;
}
status = dmaengine_tx_status(s->chan_rx, s->active_rx, &state);
@@ -1420,7 +1430,7 @@ static void rx_timer_fn(struct timer_list *t)
s->active_rx, active);
/* Let packet complete handler take care of the packet */
- return;
+ return HRTIMER_NORESTART;
}
dmaengine_pause(chan);
@@ -1435,7 +1445,7 @@ static void rx_timer_fn(struct timer_list *t)
if (status == DMA_COMPLETE) {
spin_unlock_irqrestore(&port->lock, flags);
dev_dbg(port->dev, "Transaction complete after DMA engine was stopped");
- return;
+ return HRTIMER_NORESTART;
}
/* Handle incomplete DMA receive */
@@ -1460,6 +1470,8 @@ static void rx_timer_fn(struct timer_list *t)
serial_port_out(port, SCSCR, scr | SCSCR_RIE);
spin_unlock_irqrestore(&port->lock, flags);
+
+ return HRTIMER_NORESTART;
}
static struct dma_chan *sci_request_dma_chan(struct uart_port *port,
@@ -1571,7 +1583,8 @@ static void sci_request_dma(struct uart_port *port)
dma += s->buf_len_rx;
}
- timer_setup(&s->rx_timer, rx_timer_fn, 0);
+ hrtimer_init(&s->rx_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ s->rx_timer.function = rx_timer_fn;
if (port->type == PORT_SCIFA || port->type == PORT_SCIFB)
sci_submit_rx(s);
@@ -1630,9 +1643,9 @@ static irqreturn_t sci_rx_interrupt(int irq, void *ptr)
/* Clear current interrupt */
serial_port_out(port, SCxSR,
ssr & ~(SCIF_DR | SCxSR_RDxF(port)));
- dev_dbg(port->dev, "Rx IRQ %lu: setup t-out in %u jiffies\n",
+ dev_dbg(port->dev, "Rx IRQ %lu: setup t-out in %u us\n",
jiffies, s->rx_timeout);
- mod_timer(&s->rx_timer, jiffies + s->rx_timeout);
+ start_hrtimer_us(&s->rx_timer, s->rx_timeout);
return IRQ_HANDLED;
}
@@ -1643,7 +1656,7 @@ static irqreturn_t sci_rx_interrupt(int irq, void *ptr)
scif_set_rtrg(port, s->rx_trigger);
mod_timer(&s->rx_fifo_timer, jiffies + DIV_ROUND_UP(
- s->rx_frame * s->rx_fifo_timeout, 1000));
+ s->rx_frame * HZ * s->rx_fifo_timeout, 1000000));
}
/* I think sci_receive_chars has to be called irrespective
@@ -2079,7 +2092,7 @@ static void sci_shutdown(struct uart_port *port)
if (s->chan_rx) {
dev_dbg(port->dev, "%s(%d) deleting rx_timer\n", __func__,
port->line);
- del_timer_sync(&s->rx_timer);
+ hrtimer_cancel(&s->rx_timer);
}
#endif
@@ -2480,11 +2493,11 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
if (termios->c_cflag & PARENB)
bits++;
- s->rx_frame = (100 * bits * HZ) / (baud / 10);
+ s->rx_frame = (10000 * bits) / (baud / 100);
#ifdef CONFIG_SERIAL_SH_SCI_DMA
- s->rx_timeout = DIV_ROUND_UP(s->buf_len_rx * 2 * s->rx_frame, 1000);
- if (s->rx_timeout < msecs_to_jiffies(20))
- s->rx_timeout = msecs_to_jiffies(20);
+ s->rx_timeout = s->buf_len_rx * 2 * s->rx_frame;
+ if (s->rx_timeout < 20)
+ s->rx_timeout = 20;
#endif
if ((termios->c_cflag & CREAD) != 0)
--
2.7.4
^ permalink raw reply related
* [PATCH] serial: sh-sci: prevent lockup on full TTY buffers
From: Ulrich Hecht @ 2018-02-15 12:02 UTC (permalink / raw)
To: linux-renesas-soc, linux-serial
Cc: wsa, geert, yoshihiro.shimoda.uh, Ulrich Hecht
When the TTY buffers fill up to the configured maximum, a system lockup
occurs:
[ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
[ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
[ 598.838755] Task dump for CPU 0:
[ 598.841977] swapper/0 R running task 0 0 0 0x00000022
[ 598.849023] Call trace:
[ 598.851476] __switch_to+0x98/0xb0
[ 598.854870] (null)
This can be prevented by doing a dummy read of the RX data register.
This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
as well.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
---
drivers/tty/serial/sh-sci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index d9f399c..db2ebec 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -885,6 +885,8 @@ static void sci_receive_chars(struct uart_port *port)
/* Tell the rest of the system the news. New characters! */
tty_flip_buffer_push(tport);
} else {
+ /* TTY buffers full; read from RX reg to prevent lockup */
+ serial_port_in(port, SCxRDR);
serial_port_in(port, SCxSR); /* dummy read */
sci_clear_SCxSR(port, SCxSR_RDxF_CLEAR(port));
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] serial: 8250: Add Nuvoton NPCM UART
From: Avi Fishman @ 2018-02-15 10:15 UTC (permalink / raw)
To: Joel Stanley, Andy Shevchenko
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland,
linux-serial-u79uwXL29TY76Z2rM5mHXA, devicetree,
AP MS30 Linux Kernel community, Jeremy Kerr, Tomer Maimon
In-Reply-To: <11dff5a3498949118b883b39be028611-qcV2a/0u7bE377JQJD9m/laTQe2KTcn/@public.gmane.org>
> From: joel.stan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org [mailto:joel.stan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] On Behalf Of Joel Stanley
> Sent: Thursday, February 15, 2018 4:00 AM
>
> On Wed, Feb 14, 2018 at 3:22 AM, Andy Shevchenko <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Mon, Feb 12, 2018 at 6:48 AM, Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> wrote:
>>> The Nuvoton UART is almost compatible with the 8250 driver when
>>> probed via the 8250_of driver, however it requires some extra
>>> configuration at startup.
>>
>>
>>> + [PORT_NPCM] = {
>>> + .name = "Nuvoton 16550",
>>> + .fifo_size = 16,
>>> + .tx_loadsz = 16,
>>> + .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
>>> + UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
>>> + .rxtrig_bytes = {1, 4, 8, 14},
>>> + .flags = UART_CAP_FIFO,
>>
>>> +
>>
>> Redundant.
>
> You are referring to the extra whitespace?
>
>>> + },
>>
>>> + /*
>>> + * Nuvoton calls the scratch register 'UART_TOR' (timeout
>>> + * register). Enable it, and set TIOC (timeout interrupt
>>> + * comparator) to be 0x20 for correct operation.
>>> + */
>>> + serial_port_out(port, UART_NPCM_TOR, UART_NPCM_TOIE |
>>> + 0x20);
>>
>>> +/* Nuvoton NPCM UARTs have a custom divisor calculation */
>>> + return DIV_ROUND_CLOSEST(port->uartclk, 16 * baud + 2) - 2;
>>
>> Is there any link to datasheet?
>
> I have a copy of the datasheet under NDA. The Nuvoton guys might be able to help you out. Avi?
In the spec the calculation is as follows:
BaudOut = Selected UART Clock Source / ( 16 * [Divisor + 2] )
To translate it to our code is:
baud = port->uartclk / (16 * (Divisor + 2) )
So it should calculate without the "+ 2" inside as follow:
+ return DIV_ROUND_CLOSEST(port->uartclk, 16 * baud) - 2;
In order to get the spec you can add somthing like that:
"For getting the NPCM7XX Data Sheet please contact bmc_marketing-KrzQf0k3Iz9BDgjK7y7TUQ@public.gmane.org".
BTW Andy, Intel has our Data Sheet under NDA, you can ask Mihm James
<james.mihm-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>.
>
>>
>>> +/* Nuvoton UART */
>>> +#define PORT_NPCM 118
>>
>> We have gaps there. #40 is perfect place for this one.
>
> Ok, I will move it up. Thanks for the review.
>
> Cheers,
>
> Joel
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] serial: 8250: Add Nuvoton NPCM UART
From: Joel Stanley @ 2018-02-15 2:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Tomer Maimon, Avi Fishman,
Jeremy Kerr
The Nuvoton UART is almost compatible with the 8250 driver when probed
via the 8250_of driver, however it requires some extra configuration
at startup.
Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
---
v2:
Remove redundant whitespace
Use port number 40 to fill in a gap
Documentation/devicetree/bindings/serial/8250.txt | 1 +
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 29 +++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 +++
include/uapi/linux/serial_reg.h | 5 ++++
5 files changed, 39 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index dad3b2ec66d4..aeb6db4e35c3 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -24,6 +24,7 @@ Required properties:
- "ti,da830-uart"
- "aspeed,ast2400-vuart"
- "aspeed,ast2500-vuart"
+ - "nuvoton,npcm750-uart"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index 160b8906d9b9..9835b1c1cbe1 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -316,6 +316,7 @@ static const struct of_device_id of_platform_serial_table[] = {
{ .compatible = "mrvl,mmp-uart",
.data = (void *)PORT_XSCALE, },
{ .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
+ { .compatible = "nuvoton,npcm750-uart", .data = (void *)PORT_NPCM, },
{ /* end of list */ },
};
MODULE_DEVICE_TABLE(of, of_platform_serial_table);
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 1328c7e70108..a72222f8b005 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -293,6 +293,15 @@ static const struct serial8250_config uart_config[] = {
UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
.flags = UART_CAP_FIFO,
},
+ [PORT_NPCM] = {
+ .name = "Nuvoton 16550",
+ .fifo_size = 16,
+ .tx_loadsz = 16,
+ .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
+ UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
+ .rxtrig_bytes = {1, 4, 8, 14},
+ .flags = UART_CAP_FIFO,
+ },
};
/* Uart divisor latch read */
@@ -2140,6 +2149,15 @@ int serial8250_do_startup(struct uart_port *port)
UART_DA830_PWREMU_MGMT_FREE);
}
+ if (port->type == PORT_NPCM) {
+ /*
+ * Nuvoton calls the scratch register 'UART_TOR' (timeout
+ * register). Enable it, and set TIOC (timeout interrupt
+ * comparator) to be 0x20 for correct operation.
+ */
+ serial_port_out(port, UART_NPCM_TOR, UART_NPCM_TOIE | 0x20);
+ }
+
#ifdef CONFIG_SERIAL_8250_RSA
/*
* If this is an RSA port, see if we can kick it up to the
@@ -2462,6 +2480,15 @@ static unsigned int xr17v35x_get_divisor(struct uart_8250_port *up,
return quot_16 >> 4;
}
+/* Nuvoton NPCM UARTs have a custom divisor calculation */
+static unsigned int npcm_get_divisor(struct uart_8250_port *up,
+ unsigned int baud)
+{
+ struct uart_port *port = &up->port;
+
+ return DIV_ROUND_CLOSEST(port->uartclk, 16 * baud + 2) - 2;
+}
+
static unsigned int serial8250_get_divisor(struct uart_8250_port *up,
unsigned int baud,
unsigned int *frac)
@@ -2482,6 +2509,8 @@ static unsigned int serial8250_get_divisor(struct uart_8250_port *up,
quot = 0x8002;
else if (up->port.type == PORT_XR17V35X)
quot = xr17v35x_get_divisor(up, baud, frac);
+ else if (up->port.type == PORT_NPCM)
+ quot = npcm_get_divisor(up, baud);
else
quot = uart_get_divisor(port, baud);
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 1c8413f93e3d..dce5f9dae121 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -76,6 +76,9 @@
#define PORT_SUNZILOG 38
#define PORT_SUNSAB 39
+/* Nuvoton UART */
+#define PORT_NPCM 40
+
/* Intel EG20 */
#define PORT_PCH_8LINE 44
#define PORT_PCH_2LINE 45
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index be07b5470f4b..f82f3c869df9 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -376,5 +376,10 @@
#define UART_ALTR_EN_TXFIFO_LW 0x01 /* Enable the TX FIFO Low Watermark */
#define UART_ALTR_TX_LOW 0x41 /* Tx FIFO Low Watermark */
+
+/* Nuvoton NPCM timeout register */
+#define UART_NPCM_TOR 7
+#define UART_NPCM_TOIE BIT(7) /* Timeout Interrupt Enable */
+
#endif /* _LINUX_SERIAL_REG_H */
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] serial: 8250: Add Nuvoton NPCM UART
From: Joel Stanley @ 2018-02-15 2:00 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, linux-serial,
devicetree, Linux Kernel Mailing List, Tomer Maimon, Avi Fishman,
Jeremy Kerr
In-Reply-To: <CAHp75VcCj2PtPgMEb+9ZmO-1t_K16oyY97vn3FbHr=LkGvna-Q@mail.gmail.com>
On Wed, Feb 14, 2018 at 3:22 AM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, Feb 12, 2018 at 6:48 AM, Joel Stanley <joel@jms.id.au> wrote:
>> The Nuvoton UART is almost compatible with the 8250 driver when probed
>> via the 8250_of driver, however it requires some extra configuration
>> at startup.
>
>
>> + [PORT_NPCM] = {
>> + .name = "Nuvoton 16550",
>> + .fifo_size = 16,
>> + .tx_loadsz = 16,
>> + .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
>> + UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
>> + .rxtrig_bytes = {1, 4, 8, 14},
>> + .flags = UART_CAP_FIFO,
>
>> +
>
> Redundant.
You are referring to the extra whitespace?
>> + },
>
>> + /*
>> + * Nuvoton calls the scratch register 'UART_TOR' (timeout
>> + * register). Enable it, and set TIOC (timeout interrupt
>> + * comparator) to be 0x20 for correct operation.
>> + */
>> + serial_port_out(port, UART_NPCM_TOR, UART_NPCM_TOIE | 0x20);
>
>> +/* Nuvoton NPCM UARTs have a custom divisor calculation */
>> + return DIV_ROUND_CLOSEST(port->uartclk, 16 * baud + 2) - 2;
>
> Is there any link to datasheet?
I have a copy of the datasheet under NDA. The Nuvoton guys might be
able to help you out. Avi?
>
>> +/* Nuvoton UART */
>> +#define PORT_NPCM 118
>
> We have gaps there. #40 is perfect place for this one.
Ok, I will move it up. Thanks for the review.
Cheers,
Joel
^ permalink raw reply
* Re: INFO: rcu detected stall in tty_ioctl
From: Dmitry Vyukov @ 2018-02-14 14:58 UTC (permalink / raw)
To: syzbot
Cc: Alexey.Brodkin, Andy Shevchenko, Ard Biesheuvel, babu.moger,
david, dzickus, eric, Greg Kroah-Hartman, H. Peter Anvin,
jan.kiszka, Jiri Slaby, LKML, linux-serial, Ingo Molnar, npiggin,
phil, rafael.gago, sean.wang, syzkaller-bugs, Thomas Gleixner,
the arch/x86 maintainers
In-Reply-To: <089e082bdf106667a50560f672cc@google.com>
On Sat, Dec 23, 2017 at 12:48 AM, syzbot
<bot+4e86372b8cb60e44613ff63e5dd1dcaffa7a4d29@syzkaller.appspotmail.com>
wrote:
> syzkaller has found reproducer for the following crash on
> 37759fa6d0fa9e4d6036d19ac12f555bfc0aeafd
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
I think this is fixed with:
#syz fix: n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)
> INFO: rcu_sched self-detected stall on CPU
> 1-...!: (124998 ticks this GP) idle=1aa/1/4611686018427387906
> softirq=6401/6401 fqs=178
> (t=125000 jiffies g=3233 c=3232 q=384)
> rcu_sched kthread starved for 124263 jiffies! g3233 c3232 f0x0
> RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
> rcu_sched R running task 23272 8 2 0x80000000
> Call Trace:
> context_switch kernel/sched/core.c:2800 [inline]
> __schedule+0x8eb/0x2060 kernel/sched/core.c:3376
> schedule+0xf5/0x430 kernel/sched/core.c:3435
> schedule_timeout+0x13e/0x6f0 kernel/time/timer.c:1818
> rcu_gp_kthread+0x9dd/0x18e0 kernel/rcu/tree.c:2231
> kthread+0x33c/0x400 kernel/kthread.c:238
> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
> NMI backtrace for cpu 1
> CPU: 1 PID: 3169 Comm: syzkaller626814 Not tainted 4.15.0-rc4-mm1+ #49
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> nmi_cpu_backtrace+0x1d2/0x210 lib/nmi_backtrace.c:103
> nmi_trigger_cpumask_backtrace+0x122/0x180 lib/nmi_backtrace.c:62
> arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
> trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
> rcu_dump_cpu_stacks+0x186/0x1de kernel/rcu/tree.c:1375
> print_cpu_stall kernel/rcu/tree.c:1524 [inline]
> check_cpu_stall.isra.62+0xbb8/0x15b0 kernel/rcu/tree.c:1592
> __rcu_pending kernel/rcu/tree.c:3362 [inline]
> rcu_pending kernel/rcu/tree.c:3424 [inline]
> rcu_check_callbacks+0x238/0xd20 kernel/rcu/tree.c:2764
> update_process_times+0x30/0x60 kernel/time/timer.c:1630
> tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
> tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1148
> __run_hrtimer kernel/time/hrtimer.c:1210 [inline]
> __hrtimer_run_queues+0x358/0xe20 kernel/time/hrtimer.c:1274
> hrtimer_interrupt+0x1c2/0x5e0 kernel/time/hrtimer.c:1308
> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
> smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
> apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
> </IRQ>
> RIP: 0010:variable_test_bit arch/x86/include/asm/bitops.h:332 [inline]
> RIP: 0010:inq_canon drivers/tty/n_tty.c:2409 [inline]
> RIP: 0010:n_tty_ioctl+0x218/0x2d0 drivers/tty/n_tty.c:2429
> RSP: 0018:ffff8801c914fb48 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff11
> RAX: 0000000000000643 RBX: ffffc900018c3060 RCX: ffffffff8293be5c
> RDX: 0000000000000000 RSI: 00000000749d30db RDI: ffffc900018c4260
> RBP: ffff8801c914fb88 R08: 1ffff10039229e99 R09: 0000000000000004
> R10: ffff8801c914f988 R11: 0000000000000003 R12: ffffc900018c2000
> R13: 00000002e0efd643 R14: 0000000020a6bffc R15: ffff8801c8493938
> tty_ioctl+0x336/0x1610 drivers/tty/tty_io.c:2640
> vfs_ioctl fs/ioctl.c:46 [inline]
> do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
> SYSC_ioctl fs/ioctl.c:701 [inline]
> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x445b39
> RSP: 002b:00007f6ed1479d18 EFLAGS: 00000293 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00000000006dac3c RCX: 0000000000445b39
> RDX: 0000000020a6bffc RSI: 000000000000541b RDI: 0000000000000013
> RBP: 00000000006dac38 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000293 R12: 6d74702f7665642f
> R13: 00007ffe16e1657f R14: 00007f6ed147a9c0 R15: 0000000000000008
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/089e082bdf106667a50560f672cc%40google.com.
>
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox