* Re: [Fuego] [PATCH] busybox: add support for command head/hexdump/hostname/id/ifconfig/install
From: Tim.Bird @ 2018-07-23 23:34 UTC (permalink / raw)
To: wangmy, fuego
In-Reply-To: <1532324114-87301-2-git-send-email-wangmy@cn.fujitsu.com>
See comments inline below.
> -----Original Message-----
> From: Wang Mingyu
>
> Signed-off-by: Wang Mingyu <wangmy@cn.fujitsu.com>
> ---
> .../tests/Functional.busybox/tests/busybox_head.sh | 22
> ++++++++++++++++++++++
> .../Functional.busybox/tests/busybox_hexdump.sh | 19
> +++++++++++++++++++
> .../Functional.busybox/tests/busybox_hostname.sh | 13 +++++++++++++
> .../tests/Functional.busybox/tests/busybox_id.sh | 13 +++++++++++++
> .../Functional.busybox/tests/busybox_ifconfig.sh | 13 +++++++++++++
> .../Functional.busybox/tests/busybox_install.sh | 17 +++++++++++++++++
> 6 files changed, 97 insertions(+)
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_head.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_hostname.sh
> create mode 100644 engine/tests/Functional.busybox/tests/busybox_id.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> create mode 100644
> engine/tests/Functional.busybox/tests/busybox_install.sh
>
> diff --git a/engine/tests/Functional.busybox/tests/busybox_head.sh
> b/engine/tests/Functional.busybox/tests/busybox_head.sh
> new file mode 100644
> index 0000000..be0269e
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_head.sh
> @@ -0,0 +1,22 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command head
> +# 1) Option -n
> +
> +test="head"
> +
> +mkdir test_dir
> +touch test_dir/test1
This is not needed (the 'touch')
> +echo "This is the 1st line.">test_dir/test1
> +echo "This is the 2nd line.">>test_dir/test1
> +echo "This is the 3rd line.">>test_dir/test1
> +busybox head -n 2 test_dir/test1 > log
Please use a space before the redirection operator.
> +
> +if [ "$(busybox head -n 1 log)" = "This is the 1st line." ] && [ "$(tail -n 1 log)"
> = "This is the 2nd line." ]
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> +rm log
> +rm -rf test_dir
> diff --git a/engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> b/engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> new file mode 100644
> index 0000000..d598c72
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_hexdump.sh
> @@ -0,0 +1,19 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command hexdump
> +# 1) Option: -c
> +
> +test="hexdump"
> +
> +mkdir test_dir
> +touch test_dir/test1
> +echo "HELLO WORLD">test_dir/test1
> +busybox hexdump -c test_dir/test1 > log
> +if head -n 1 log | grep "0000000 H E L L O W O R L D \\\n" && [
> "$(tail -n 1 log)" = "000000c" ]
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> +rm log
> +rm -rf test_dir
> diff --git a/engine/tests/Functional.busybox/tests/busybox_hostname.sh
> b/engine/tests/Functional.busybox/tests/busybox_hostname.sh
> new file mode 100644
> index 0000000..f854515
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_hostname.sh
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command hostname
> +# 1) Option none
> +
> +test="hostname"
> +
> +if [ $(busybox hostname) = $(hostname) ]
On a busybox-based system, this just tests the program against itself.
Maybe compare with $(cat /etc/hostname)?
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> diff --git a/engine/tests/Functional.busybox/tests/busybox_id.sh
> b/engine/tests/Functional.busybox/tests/busybox_id.sh
> new file mode 100644
> index 0000000..9f53fcc
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_id.sh
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command id
> +# 1) Option none
> +
> +test="id"
> +
> +if [ "$(busybox id)" = "$(id)" ]
Same issue here. If busybox is the main tool for a board, then
'id' will just be a symlink to busybox, and this test just verifies
that the same command produces the same output.
This one I'm not sure what to do with this one. Maybe
see if there's a shell variable that has the UID?
Or, check that 'id' is not 'busybox id'?
Let me know what you think.
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> diff --git a/engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> b/engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> new file mode 100644
> index 0000000..31b07d2
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_ifconfig.sh
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command ifconfig
> +# 1) Option none
> +
> +test="ifconfig"
> +
> +if busybox ifconfig
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> diff --git a/engine/tests/Functional.busybox/tests/busybox_install.sh
> b/engine/tests/Functional.busybox/tests/busybox_install.sh
> new file mode 100644
> index 0000000..a8cba56
> --- /dev/null
> +++ b/engine/tests/Functional.busybox/tests/busybox_install.sh
> @@ -0,0 +1,17 @@
> +#!/bin/sh
> +
> +# The testscript checks the following options of the command install
> +# 1) Option none
> +
> +test="install"
> +
> +mkdir test_dir test_install_dir
> +echo "ls test_install_dir">test_dir/test1
I'm not sure what's going on here.
test1 should have the contents: 'ls test_install_dir'.
It's not clear to me that this is executable.
> +busybox install test_dir/test1 test_install_dir
> +if [ $(./test_install_dir/test1) = test1 ]
Are you trying to execute the script?
I'm confused.
> +then
> + echo " -> $test: TEST-PASS"
> +else
> + echo " -> $test: TEST-FAIL"
> +fi;
> +rm -rf test_dir test_install_dir;
> --
> 1.8.3.1
Thanks for the patch.
Please address my feedback and re-submit.
(Note: Sorry - but I will be out-of-the-office the rest of this week,
so my responses will be delayed until next week.)
Regards,
-- Tim
^ permalink raw reply
* USB: option: add support for DW5821e
From: Aleksander Morgado @ 2018-07-23 23:34 UTC (permalink / raw)
To: johan; +Cc: gregkh, bjorn, linux-usb, Aleksander Morgado, stable
The device exposes AT, NMEA and DIAG ports in both USB configurations.
The patch explicitly ignores interfaces 0 and 1, as they're bound to
other drivers already; and also interface 6, which is a GNSS interface
for which we don't have a driver yet.
T: Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 18 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 2
P: Vendor=413c ProdID=81d7 Rev=03.18
S: Manufacturer=DELL
S: Product=DW5821e Snapdragon X20 LTE
S: SerialNumber=0123456789ABCDEF
C: #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
T: Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 2
P: Vendor=413c ProdID=81d7 Rev=03.18
S: Manufacturer=DELL
S: Product=DW5821e Snapdragon X20 LTE
S: SerialNumber=0123456789ABCDEF
C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Cc: stable <stable@vger.kernel.org>
---
drivers/usb/serial/option.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 664e61f16b6a..0215b70c4efc 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -196,6 +196,8 @@ static void option_instat_callback(struct urb *urb);
#define DELL_PRODUCT_5800_V2_MINICARD_VZW 0x8196 /* Novatel E362 */
#define DELL_PRODUCT_5804_MINICARD_ATT 0x819b /* Novatel E371 */
+#define DELL_PRODUCT_5821E 0x81d7
+
#define KYOCERA_VENDOR_ID 0x0c88
#define KYOCERA_PRODUCT_KPC650 0x17da
#define KYOCERA_PRODUCT_KPC680 0x180a
@@ -1030,6 +1032,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, DELL_PRODUCT_5800_MINICARD_VZW, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, DELL_PRODUCT_5800_V2_MINICARD_VZW, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, DELL_PRODUCT_5804_MINICARD_ATT, 0xff, 0xff, 0xff) },
+ { USB_DEVICE(DELL_VENDOR_ID, DELL_PRODUCT_5821E),
+ .driver_info = RSVD(0) | RSVD(1) | RSVD(6) },
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_E100A) }, /* ADU-E100, ADU-310 */
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_500A) },
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_620UW) },
^ permalink raw reply related
* Re: [PATCH] phy: qcom-qmp: Fix dts bindings to reflect reality
From: Rob Herring @ 2018-07-23 23:33 UTC (permalink / raw)
To: Doug Anderson
Cc: Kishon Vijay Abraham I, Mark Rutland, devicetree,
linux-kernel@vger.kernel.org, Vivek Gautam, Manu Gautam,
Varadarajan Narayanan
In-Reply-To: <CAD=FV=UDq8oq+nKsa2mZWvAUueUFxEUSYz2JoZ=E7e131SOR=g@mail.gmail.com>
On Mon, Jul 23, 2018 at 11:37 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Mon, Jul 23, 2018 at 7:04 AM, Rob Herring <robh@kernel.org> wrote:
> > On Fri, Jul 20, 2018 at 11:54 AM Doug Anderson <dianders@chromium.org> wrote:
> >>
> >> Hi,
> >>
> >> On Fri, Jul 20, 2018 at 10:26 AM, Rob Herring <robh@kernel.org> wrote:
> >> > On Fri, Jul 20, 2018 at 9:13 AM Doug Anderson <dianders@chromium.org> wrote:
> >> >>
> >> >> Rob,
> >> >>
> >> >> On Fri, Jul 20, 2018 at 7:10 AM, Rob Herring <robh@kernel.org> wrote:
> >> >> > On Fri, Jul 06, 2018 at 04:31:42PM -0700, Douglas Anderson wrote:
> >> >> >> A few patches have landed for the qcom-qmp PHY that affect how you
> >> >> >> would write a device tree node. ...yet the bindings weren't updated.
> >> >> >> Let's remedy the situation and make the bindings refelect reality.
> >> >> >
> >> >> > "dt-bindings: phy: ..." for the subject.
> >> >>
> >> >> Sorry. Every subsystem has different conventions for this so I
> >> >> usually just do a "git log" on the file and make my best guess. I'll
> >> >> try to remember this for next time though.
> >> >
> >> > NP. I'd like to add this info to MAINTAINERS or maybe a git commit
> >> > hook could figure this out automagically.
> >> >
> >> >> In this case, though, it looks like this already landed. I see this
> >> >> patch in Kishon's next branch.
> >> >>
> >> >>
> >> >> >> Fixes: efb05a50c956 ("phy: qcom-qmp: Add support for QMP V3 USB3 PHY")
> >> >> >> Fixes: ac0d239936bd ("phy: qcom-qmp: Add support for runtime PM")
> >> >> >> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> >> >> >> ---
> >> >> >>
> >> >> >> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 14 ++++++++++++--
> >> >> >> 1 file changed, 12 insertions(+), 2 deletions(-)
> >> >> >>
> >> >> >> diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> >> >> >> index 266a1bb8bb6e..0c7629e88bf3 100644
> >> >> >> --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> >> >> >> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> >> >> >> @@ -12,7 +12,14 @@ Required properties:
> >> >> >> "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845,
> >> >> >> "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845.
> >> >> >>
> >> >> >> - - reg: offset and length of register set for PHY's common serdes block.
> >> >> >> + - reg:
> >> >> >> + - For "qcom,sdm845-qmp-usb3-phy":
> >> >> >> + - index 0: address and length of register set for PHY's common serdes
> >> >> >> + block.
> >> >> >> + - named register "dp_com" (using reg-names): address and length of the
> >> >> >> + DP_COM control block.
> >> >> >
> >> >> > You need to list reg-names and what are the names for the other 2
> >> >> > regions?
> >> >>
> >> >> Here's the code works. You can tell me how you want this expressed in
> >> >> the bindings:
> >> >>
> >> >> * In all cases the driver maps its main memory range (for the common
> >> >> serdes block) without specifying any name. This is equivalent to
> >> >> asking for index 0.
> >> >>
> >> >> * For "qcom,sdm845-qmp-usb3-phy" the driver requests a second memory
> >> >> range by name using the name "dp_com".
> >> >>
> >> >> ...basically the driver is inconsistent between using names and
> >> >> indices and I was trying to document that fact.
> >> >
> >> > That's fine as long as the indices are fixed.
> >> >
> >> >>
> >> >> I guess options:
> >> >>
> >> >> 1. I could reword this so it's clearer (open to suggestions)
> >> >>
> >> >> 2. I could add something to the bindings saying that the first reg
> >> >> name should be "reg-base" or something. Then the question is whether
> >> >> we should go to the code and start enforcing that. If we do choose to
> >> >> enforce it then it's technically breaking compatibility (though I
> >> >> doubt there is any real dts in the wild). If we don't choose to
> >> >> enforce it then why did we bother saying what it should be named?
> >> >
> >> > I think you need to state index 1 is dp_com (and only for
> >> > "qcom,sdm845-qmp-usb3-phy") and a name for index 0. 'reg-base' doesn't
> >> > seem great, but I don't have another suggestion.
> >>
> >> ...but why do we bother giving "dp_com" a name if we're saying it has
> >> to be index 1? It feels like the author of the driver was trying to
> >> transition from specifying to specifying registers by index to
> >> specifying them by name, but left the first register specified by
> >> index for compatibility (or code simplicity?). It seems like the
> >> whole point of referring to things by name is to _not_ force the index
> >> number.
> >
> > No. Specifying the order and indexes is how bindings are done.
> > "-names" is extra information, not a license to change the rules.
>
> OK.
>
> Just for context: I'm not trying to be argumentative or anything--I
> just seem to be lacking a fundamental understanding of why reg-names
> exists and when it should be used. I'm trying to ask questions so I
> can have a better intuition here and submit better patches / do better
> reviews. I'm sorry if I'm coming off as a jerk. :( I'm not trying
> to be.
>
> Do you happen to know if there's anything written up that explains all
> the conventions around reg-names and I can just read that?
Probably not. We should add it to the DT spec I guess.
> For context, it seems to me that clocks and registers have different
> conventions, but I certainly could be wrong. From what I've seen
> clocks are often specified in bindings by name and referred to in code
> by name. Conversely reg-names seems to be highly discouraged and
> people are told to just refer to them by index. The difference
> between the two always seemed strange to me, though I always assumed
> it was because it was more common to just have one or two register
> ranges but a whole chunk of clocks (and more get added over time as
> the driver matures).
That probably is because the clock binding has had clock-names from
the start (it may have been the first one). That was probably partly
due to the clock API also was mainly by name already if we want to
admit Linux influence on bindings. IIRC, reg-names came along for the
OMAP folks and was related to the hwmods stuff. Part of it was also
people wanting platform_get_resource_by_name to work when converting
to DT. If you haven't figured it out, I'm still not really a fan. It
is definitely more useful for some bindings than others.
There's a few cases where I think *-names is useful. The first is what
I mentioned where you could have holes in the list. The 2nd is things
like the standardized "wakeup" name for wakeup interrupts.
I really don't like seeing things like reset-names with a single entry
like "rst".
> >> I'm imagining a future compatible string that adds yet another address
> >> range. Presumably we'd refer to this by name too. In that case both
> >> of these would be fine:
> >>
> >> reg = <0xa x>, <0xb x>, <0xc x>;
> >> reg-names = "reg-base", "dp_com", "new_range"
> >>
> >> reg = <0xa x>, <0xc x>, <0xb x>;
> >> reg-names = "reg-base", "new_range", "dp_com"
> >
> > But why. There is absolutely no need to support both of these.
>
> I guess I'm trying to understand the motivation for reg-names. If you
> say that something must be index 1 and also have reg-name of "dp_com"
> then the reg-name isn't buying us anything and maybe the more proper
> fix is to change the driver to work by index and drop the whole name
> thing here? Should I do that?
That would be fine by me.
> > What you could need to support is this:
> >
> > reg-names = "reg-base", "new_range";
> >
> > The order is still fixed, but we have optional entries in the middle.
> > And that is the case when using -names is helpful. Otherwise, "-names"
> > is just unnecessary bloat to DT.
>
> From what you're saying the _only_ reason you'd ever want to use
> reg-names is if there is an optional register range. Is that right?
IMO, yes. But I'm not going to tell people to remove them unless there
is only a single entry.
> I think for me intuitively I expect that drivers will change and
> expand over time and I'd expect more / different (and maybe optional)
> ranges to be added. In general I feel like named registers scales
> better with less complexity.
They should only really change for new h/w and that should imply a new
compatible which can also define what is at each index.
> >> > For the driver, it's not the driver's job to enforce any of this.
> >>
> >> Sure, but anything that the driver doesn't enforce people will get
> >> wrong. In other words if we say that the name of the first register
> >> ought to be "reg-base" but don't enforce it then someone will later
> >> come in and say it's stupid that one of the names uses a dash and the
> >> other an underscore. They'll change "reg-base" and it will work.
> >> Someone else will decide that "reg-base" is a dumb name and will
> >> change it to "serdes". It will still work. Now we have a bindings
> >> that claims "reg-base" and lots of different device trees in practice.
> >
> > You are arguing against making the binding stricter and then worrying
> > about the driver getting things wrong. Stricter bindings leave less to
> > interpretation by the driver and less chance to get things wrong.
> > Unless "anything goes" and then the binding can never be "wrong".
>
> I guess I'm saying that my intuition says that over-specifying things
> seems bad to me. The driver will either ask for a register by name or
> by index and not both. In my mind either is a fine way to do it so as
> long as the driver and the binding is consistent then we have a
> functioning system. Specifying that people have to do get both the
> index and name right basically gives people twice as many places to do
> things wrong.
Validation should solve that problem mostly. The only thing we can't
validate is if the names are the right order, but the addresses are
not.
> > Again, it is not the kernel's job to validate bindings even though we
> > have little else right now. That will change soon hopefully.
> >
> >> If the whole "keep things compatible" is important then what matters
> >> more is what's happening in practice, not what's should happen in
> >> theory.
> >>
> >> IMO if the driver isn't enforcing that the first field be called
> >> "reg-base" then it shouldn't be in the bindings doc.
> >>
> >>
> >> BTW: I use the name "reg-base" in my example because that's what the
> >> register was named in downstream device trees that I found. Even if
> >> the name isn't terribly appealing, if it's not terribly objectionable
> >> I'd rather pick something that's closer to what people used in
> >> practice.
> >
> > I don't really care. People just make shit up anyway.
> >
> >>
> >> ---
> >>
> >> How about this?
> >
> > No.
> >
> >>
> >> - reg:
> >> - For "qcom,sdm845-qmp-usb3-phy" (names mapped by reg-names):
> >> - "reg-base": address and length of register set for PHY's common serdes
> >> block. MUST BE THE FIRST RANGE LISTED IN THE LIST (AKA index 0). Note
> >> that the name of "reg-base" is suggested but not enforced.
> >> - "dp-com": address and length of the DP_COM control block.
> >> - For all others (only one range--don't use reg-names)
> >> - offset and length of register set for PHY's common serdes block.
>
> OK, I guess I will try again then and you can tell me when I get it
> right (unless you tell me I should just change the driver to not use
> named registers at all). How about:
>
> - reg:
> - For "qcom,sdm845-qmp-usb3-phy":
> - index 0: address and length of register set for PHY's common serdes
> block.
> - index 1: address and length of the DP_COM control block.
Instead of repeating index 0 below, just say "for
'qcom,sdm845-qmp-usb3-phy' only" here.
> - For all others:
> - index 0: address and length of register set for PHY's common serdes
> block.
> - reg-names:
> - For "qcom,sdm845-qmp-usb3-phy":
> - Should be: "reg-base", "dp_com"
> - For all others:
> - The reg-names property shouldn't be defined.
>
>
> -Doug
^ permalink raw reply
* Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: Vladimir Zapolskiy @ 2018-07-23 23:31 UTC (permalink / raw)
To: Oleksij Rempel, Shawn Guo, Fabio Estevam, Rob Herring,
Mark Rutland, A.s. Dong, Vladimir Zapolskiy
Cc: devicetree, linux-arm-kernel, kernel, dl-linux-imx
In-Reply-To: <20180722063923.30222-6-o.rempel@pengutronix.de>
Hi Oleksij,
On 07/22/2018 09:39 AM, Oleksij Rempel wrote:
> The Mailbox controller is able to send messages (up to 4 32 bit words)
> between the endpoints.
>
> This driver was tested using the mailbox-test driver sending messages
> between the Cortex-A7 and the Cortex-M4.
>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
[snip]
> +static int imx_mu_startup(struct mbox_chan *chan)
> +{
> + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> + struct imx_mu_con_priv *cp = chan->con_priv;
> + int ret;
> +
> + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL, "imx_mu_chan[%i]",
> + cp->idx);
> + if (!cp->irq_desc)
> + return -ENOMEM;
> +
Again I would suggest to move this allocation to the loop in .probe function.
[snip]
> +
> + for (i = 0; i < IMX_MU_CHANS; i++) {
> + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> +
> + cp->idx = i;
> + cp->irq = irq;
^^^^ right over here.
> + priv->mbox_chans[i].con_priv = cp;
> + }
> +
please feel free to add my technical side review tag to the next version:
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
FWIW I find that review comments from Lucas are pretty valid, I would
recommend to incorporate them.
--
Best wishes,
Vladimir
^ permalink raw reply
* [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: Vladimir Zapolskiy @ 2018-07-23 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180722063923.30222-6-o.rempel@pengutronix.de>
Hi Oleksij,
On 07/22/2018 09:39 AM, Oleksij Rempel wrote:
> The Mailbox controller is able to send messages (up to 4 32 bit words)
> between the endpoints.
>
> This driver was tested using the mailbox-test driver sending messages
> between the Cortex-A7 and the Cortex-M4.
>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
[snip]
> +static int imx_mu_startup(struct mbox_chan *chan)
> +{
> + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> + struct imx_mu_con_priv *cp = chan->con_priv;
> + int ret;
> +
> + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL, "imx_mu_chan[%i]",
> + cp->idx);
> + if (!cp->irq_desc)
> + return -ENOMEM;
> +
Again I would suggest to move this allocation to the loop in .probe function.
[snip]
> +
> + for (i = 0; i < IMX_MU_CHANS; i++) {
> + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> +
> + cp->idx = i;
> + cp->irq = irq;
^^^^ right over here.
> + priv->mbox_chans[i].con_priv = cp;
> + }
> +
please feel free to add my technical side review tag to the next version:
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
FWIW I find that review comments from Lucas are pretty valid, I would
recommend to incorporate them.
--
Best wishes,
Vladimir
^ permalink raw reply
* qmi_wwan: fix interface number for DW5821e production firmware
From: Aleksander Morgado @ 2018-07-23 23:31 UTC (permalink / raw)
To: bjorn; +Cc: davem, netdev, linux-usb, Aleksander Morgado, stable
The original mapping for the DW5821e was done using a development
version of the firmware. Confirmed with the vendor that the final
USB layout ends up exposing the QMI control/data ports in USB
config #1, interface #0, not in interface #1 (which is now a HID
interface).
T: Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 2
P: Vendor=413c ProdID=81d7 Rev=03.18
S: Manufacturer=DELL
S: Product=DW5821e Snapdragon X20 LTE
S: SerialNumber=0123456789ABCDEF
C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
Fixes: e7e197edd09c25 ("qmi_wwan: add support for the Dell Wireless 5821e module")
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Cc: stable <stable@vger.kernel.org>
---
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8fac8e132c5b..0ed06d670a5f 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1246,7 +1246,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)}, /* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card (rev3) */
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)}, /* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)}, /* Dell Wireless 5811e */
- {QMI_FIXED_INTF(0x413c, 0x81d7, 1)}, /* Dell Wireless 5821e */
+ {QMI_FIXED_INTF(0x413c, 0x81d7, 0)}, /* Dell Wireless 5821e */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)}, /* HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module */
{QMI_FIXED_INTF(0x03f0, 0x9d1d, 1)}, /* HP lt4120 Snapdragon X5 LTE */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)}, /* WeTelecom WPD-600N */
^ permalink raw reply related
* Re: [PATCH v2] hexagon: modify ffs() and fls() to return int
From: Richard Kuo @ 2018-07-23 23:31 UTC (permalink / raw)
To: Randy Dunlap; +Cc: LKML, linux-hexagon, Geert Uytterhoeven
In-Reply-To: <39ac5a3f-b5fa-a928-6caf-a7a01251f5ea@infradead.org>
On Mon, Jul 23, 2018 at 04:27:47PM -0700, Randy Dunlap wrote:
> On 07/23/2018 03:50 PM, Richard Kuo wrote:
> > On Sun, Jul 22, 2018 at 04:03:58PM -0700, Randy Dunlap wrote:
> >> From: Randy Dunlap <rdunlap@infradead.org>
> >>
> >> Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
> >> printk format build warning. This is due to hexagon's ffs() being
> >> coded as returning long instead of int.
> >>
> >> Fix the printk format warning by changing all of hexagon's ffs() and
> >> fls() functions to return int instead of long. The variables that
> >> they return are already int instead of long. This return type
> >> matches the return type in <asm-generic/bitops/>.
> >>
> >> ../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
> >> ../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]
> >>
> >> There are no ffs() or fls() allmodconfig build errors after making this
> >> change.
> >>
> >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> >> Cc: Richard Kuo <rkuo@codeaurora.org>
> >> Cc: linux-hexagon@vger.kernel.org
> >> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> >> ---
> >> v2:
> >> add hexagon contacts, drop erroneous sh contacts; [thanks, Geert]
> >> only change return type for ffs() and fls() [thanks, Geert]
> >> [drop the changes for ffz(), __ffs(), and __fls()]
> >>
> >> arch/hexagon/include/asm/bitops.h | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >
> >
> > Acked-by: Richard Kuo <rkuo@codeaurora.org>
> >
>
> Hi Richard,
>
> You are listed as the arch/hexagon/ maintainer. Can you please merge these
> patches?
>
> thanks,
> --
> ~Randy
Yes, I can queue it up and take it through my tree.
Thanks,
Richard Kuo
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] remoteproc/davinci: Mark error recovery as disabled
From: Suman Anna @ 2018-07-23 23:27 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-remoteproc, Sekhar Nori, linux-arm-kernel, linux-kernel,
Suman Anna
The Davinci remoteproc driver does not support error recovery at
present, so mark the corresponding remoteproc flag appropriately
so that the debugfs flag shows the value as 'disabled' by default.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/remoteproc/da8xx_remoteproc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/remoteproc/da8xx_remoteproc.c b/drivers/remoteproc/da8xx_remoteproc.c
index b668e32996e2..53160d5ed543 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -284,6 +284,9 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
goto free_mem;
}
+ /* error recovery is not supported at present */
+ rproc->recovery_disabled = true;
+
drproc = rproc->priv;
drproc->rproc = rproc;
drproc->dsp_clk = dsp_clk;
--
2.18.0
^ permalink raw reply related
* [PATCH] remoteproc/davinci: Mark error recovery as disabled
From: Suman Anna @ 2018-07-23 23:27 UTC (permalink / raw)
To: linux-arm-kernel
The Davinci remoteproc driver does not support error recovery at
present, so mark the corresponding remoteproc flag appropriately
so that the debugfs flag shows the value as 'disabled' by default.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/remoteproc/da8xx_remoteproc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/remoteproc/da8xx_remoteproc.c b/drivers/remoteproc/da8xx_remoteproc.c
index b668e32996e2..53160d5ed543 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -284,6 +284,9 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
goto free_mem;
}
+ /* error recovery is not supported at present */
+ rproc->recovery_disabled = true;
+
drproc = rproc->priv;
drproc->rproc = rproc;
drproc->dsp_clk = dsp_clk;
--
2.18.0
^ permalink raw reply related
* [PATCH] remoteproc/davinci: Mark error recovery as disabled
From: Suman Anna @ 2018-07-23 23:27 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-remoteproc, Sekhar Nori, linux-arm-kernel, linux-kernel,
Suman Anna
The Davinci remoteproc driver does not support error recovery at
present, so mark the corresponding remoteproc flag appropriately
so that the debugfs flag shows the value as 'disabled' by default.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/remoteproc/da8xx_remoteproc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/remoteproc/da8xx_remoteproc.c b/drivers/remoteproc/da8xx_remoteproc.c
index b668e32996e2..53160d5ed543 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -284,6 +284,9 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
goto free_mem;
}
+ /* error recovery is not supported at present */
+ rproc->recovery_disabled = true;
+
drproc = rproc->priv;
drproc->rproc = rproc;
drproc->dsp_clk = dsp_clk;
--
2.18.0
^ permalink raw reply related
* Re: [PATCH v2] hexagon: modify ffs() and fls() to return int
From: Randy Dunlap @ 2018-07-23 23:27 UTC (permalink / raw)
To: Richard Kuo; +Cc: LKML, linux-hexagon, Geert Uytterhoeven
In-Reply-To: <20180723225025.GC12771@codeaurora.org>
On 07/23/2018 03:50 PM, Richard Kuo wrote:
> On Sun, Jul 22, 2018 at 04:03:58PM -0700, Randy Dunlap wrote:
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
>> printk format build warning. This is due to hexagon's ffs() being
>> coded as returning long instead of int.
>>
>> Fix the printk format warning by changing all of hexagon's ffs() and
>> fls() functions to return int instead of long. The variables that
>> they return are already int instead of long. This return type
>> matches the return type in <asm-generic/bitops/>.
>>
>> ../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
>> ../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]
>>
>> There are no ffs() or fls() allmodconfig build errors after making this
>> change.
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> Cc: Richard Kuo <rkuo@codeaurora.org>
>> Cc: linux-hexagon@vger.kernel.org
>> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
>> ---
>> v2:
>> add hexagon contacts, drop erroneous sh contacts; [thanks, Geert]
>> only change return type for ffs() and fls() [thanks, Geert]
>> [drop the changes for ffz(), __ffs(), and __fls()]
>>
>> arch/hexagon/include/asm/bitops.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>
>
> Acked-by: Richard Kuo <rkuo@codeaurora.org>
>
Hi Richard,
You are listed as the arch/hexagon/ maintainer. Can you please merge these
patches?
thanks,
--
~Randy
^ permalink raw reply
* [PATCH 0/2] PCI: NVMe reset quirk
From: Alex Williamson @ 2018-07-23 22:24 UTC (permalink / raw)
To: linux-pci; +Cc: linux-kernel, linux-nvme
As discussed in the 2nd patch, at least one NVMe controller sometimes
doesn't like being reset while enabled and another will timeout during
a subsequent re-enable if it happens too quickly after reset.
Introduce a device specific reset quirk for all NVMe class devices so
that we can try to get reliable behavior from them for device
assignment and any other users of the PCI subsystem reset interface.
Patches against current PCI next branch. Thanks,
Alex
---
Alex Williamson (2):
PCI: Export pcie_has_flr()
PCI: NVMe device specific reset quirk
drivers/pci/pci.c | 3 +
drivers/pci/quirks.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/pci.h | 1
3 files changed, 115 insertions(+), 1 deletion(-)
^ permalink raw reply
* [Drbd-dev] BuildRequires for drbd-utils
From: Digimer @ 2018-07-23 23:19 UTC (permalink / raw)
To: drbd-dev
Hi all,
I'm working on RPMs for Fedora, and noticed two missing build
dependencies in drbd-utils-9.5.0;
BuildRequires: automake
BuildRequires: libxslt
Cheers
--
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
^ permalink raw reply
* Re: [PATCH v7 08/12] mfd: intel-peci-client: Add PECI client MFD driver
From: Randy Dunlap @ 2018-07-23 22:21 UTC (permalink / raw)
To: Jae Hyun Yoo, Jean Delvare, Guenter Roeck, Rob Herring,
Mark Rutland, Lee Jones, Joel Stanley, Andrew Jeffery,
Jonathan Corbet, Greg Kroah-Hartman, Gustavo Pimentel,
Kishon Vijay Abraham I, Lorenzo Pieralisi, Darrick J . Wong,
Eric Sandeen, Arnd Bergmann, Wu Hao, Tomohiro Kusumi,
Bryant G . Ly, Frederic Barrat, David S . Miller,
Mauro Carvalho Chehab, Andrew Morton, Philippe Ombredanne,
Vinod Koul, Stephen Boyd, David Kershner, Uwe Kleine-Konig,
Sagar Dharia, Johan Hovold, Thomas Gleixner, Juergen Gross,
Cyrille Pitchen
Cc: linux-hwmon, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-doc, openbmc, James Feist, Jason M Biils,
Vernon Mauery
In-Reply-To: <20180723214751.1733-9-jae.hyun.yoo@linux.intel.com>
On 07/23/2018 02:47 PM, Jae Hyun Yoo wrote:
> This commit adds PECI client MFD driver.
>
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Andrew Jeffery <andrew@aj.id.au>
> Cc: James Feist <james.feist@linux.intel.com>
> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
> Cc: Joel Stanley <joel@jms.id.au>
> Cc: Vernon Mauery <vernon.mauery@linux.intel.com>
> ---
> drivers/mfd/Kconfig | 14 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/intel-peci-client.c | 182 ++++++++++++++++++++++++++
> include/linux/mfd/intel-peci-client.h | 81 ++++++++++++
> 4 files changed, 278 insertions(+)
> create mode 100644 drivers/mfd/intel-peci-client.c
> create mode 100644 include/linux/mfd/intel-peci-client.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index f3fa516011ec..e38b591479d4 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -595,6 +595,20 @@ config MFD_INTEL_MSIC
> Passage) chip. This chip embeds audio, battery, GPIO, etc.
> devices used in Intel Medfield platforms.
>
> +config MFD_INTEL_PECI_CLIENT
> + bool "Intel PECI client"
> + depends on (PECI || COMPILE_TEST)
> + select MFD_CORE
> + help
> + If you say yes to this option, support will be included for the
> + multi-funtional Intel PECI (Platform Environment Control Interface)
multi-functional
> + client. PECI is a one-wire bus interface that provides a communication
> + channel from PECI clients in Intel processors and chipset components
> + to external monitoring or control devices.
> +
> + Additional drivers must be enabled in order to use the functionality
> + of the device.
> +
> config MFD_IPAQ_MICRO
> bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support"
> depends on SA1100_H3100 || SA1100_H3600
--
~Randy
^ permalink raw reply
* Re: [Fuego] [PATCH] busybox: modify the code of option g+x in chmod1 test
From: Tim.Bird @ 2018-07-23 23:24 UTC (permalink / raw)
To: wangmy, fuego
In-Reply-To: <1532324114-87301-1-git-send-email-wangmy@cn.fujitsu.com>
OK - this is applied and pushed. But it was a bit harder to apply than anticipated
because your mailer decided to put the message body in base64 encoding.
You other patches don't have this issue. I'm not sure what happened on this
one. The only thing I can think of is maybe there was a non-8-bit-ASCII
character somewhere in the patch? The only "strange" characters are
the quotes (maybe in the patch message) - maybe one of those got turned into
a Unicode char or some other extended character-set character.
If you can, please check this.
-- Tim
> -----Original Message-----
> From: fuego-bounces@lists.linuxfoundation.org [mailto:fuego-
> bounces@lists.linuxfoundation.org] On Behalf Of Wang Mingyu
> Sent: Sunday, July 22, 2018 10:35 PM
> To: fuego@lists.linuxfoundation.org
> Subject: [Fuego] [PATCH] busybox: modify the code of option g+x in chmod1
> test
>
> Change the cut to retrieve the group permission bytes, to check that they are
> 'execute' ('x').
>
> Signed-off-by: Wang Mingyu <wangmy@cn.fujitsu.com>
> ---
> engine/tests/Functional.busybox/tests/busybox_chmod1.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> b/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> index cdc7d18..2eef95a 100644
> --- a/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> +++ b/engine/tests/Functional.busybox/tests/busybox_chmod1.sh
> @@ -21,7 +21,7 @@ else
> fi;
>
> busybox chmod g+x ./test_dir/test1
> -if [ "$(busybox ls -l ./test_dir | grep -v "total" | cut -b 1-3)" = "-rw" ]
> +if [ "$(busybox ls -l ./test_dir | grep -v "total" | cut -b 5-7)" = "r-x" ]
> then
> echo " -> $test: Changed file permissions verification#2 succeeded."
> else
> --
> 1.8.3.1
>
>
>
> _______________________________________________
> Fuego mailing list
> Fuego@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/fuego
^ permalink raw reply
* [PATCH net-next] tls: Fix improper revert in zerocopy_from_iter
From: Doron Roberts-Kedes @ 2018-07-23 22:20 UTC (permalink / raw)
To: David S . Miller
Cc: Dave Watson, Vakul Garg, Matt Mullins, netdev,
Doron Roberts-Kedes
The current code is problematic because the iov_iter is reverted and
never advanced in the non-error case. This patch skips the revert in the
non-error case. This patch also fixes the amount by which the iov_iter
is reverted. Currently, iov_iter is reverted by size, which can be
greater than the amount by which the iter was actually advanced.
Instead, mimic the tx path which reverts by the difference before and
after zerocopy_from_iter.
Fixes: 4718799817c5 ("tls: Fix zerocopy_from_iter iov handling")
Signed-off-by: Doron Roberts-Kedes <doronrk@fb.com>
---
net/tls/tls_sw.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 490f2bcc6313..2ea000baebf8 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -276,7 +276,7 @@ static int zerocopy_from_iter(struct sock *sk, struct iov_iter *from,
int length, int *pages_used,
unsigned int *size_used,
struct scatterlist *to, int to_max_pages,
- bool charge, bool revert)
+ bool charge)
{
struct page *pages[MAX_SKB_FRAGS];
@@ -327,8 +327,6 @@ static int zerocopy_from_iter(struct sock *sk, struct iov_iter *from,
out:
*size_used = size;
*pages_used = num_elem;
- if (revert)
- iov_iter_revert(from, size);
return rc;
}
@@ -431,7 +429,7 @@ int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
&ctx->sg_plaintext_size,
ctx->sg_plaintext_data,
ARRAY_SIZE(ctx->sg_plaintext_data),
- true, false);
+ true);
if (ret)
goto fallback_to_reg_send;
@@ -811,6 +809,7 @@ int tls_sw_recvmsg(struct sock *sk,
likely(!(flags & MSG_PEEK))) {
struct scatterlist sgin[MAX_SKB_FRAGS + 1];
int pages = 0;
+ int orig_chunk = chunk;
zc = true;
sg_init_table(sgin, MAX_SKB_FRAGS + 1);
@@ -820,9 +819,11 @@ int tls_sw_recvmsg(struct sock *sk,
err = zerocopy_from_iter(sk, &msg->msg_iter,
to_copy, &pages,
&chunk, &sgin[1],
- MAX_SKB_FRAGS, false, true);
- if (err < 0)
+ MAX_SKB_FRAGS, false);
+ if (err < 0) {
+ iov_iter_revert(&msg->msg_iter, chunk - orig_chunk);
goto fallback_to_reg_recv;
+ }
err = decrypt_skb(sk, skb, sgin);
for (; pages > 0; pages--)
--
2.17.1
^ permalink raw reply related
* Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting
From: Boris Brezillon @ 2018-07-23 23:22 UTC (permalink / raw)
To: NeilBrown
Cc: Brian Norris, Zhiqiang Hou, linux-mtd, Linux Kernel,
David Woodhouse, Boris BREZILLON, Marek Vasut, Richard Weinberger,
Cyrille Pitchen
In-Reply-To: <87in55po3a.fsf@notabene.neil.brown.name>
On Tue, 24 Jul 2018 08:46:33 +1000
NeilBrown <neilb@suse.com> wrote:
> On Mon, Jul 23 2018, Brian Norris wrote:
>
> > Hi Boris,
> >
> > On Mon, Jul 23, 2018 at 1:10 PM, Boris Brezillon
> > <boris.brezillon@bootlin.com> wrote:
> >> On Mon, 23 Jul 2018 11:13:50 -0700
> >> Brian Norris <computersforpeace@gmail.com> wrote:
> >>> I noticed this got merged, but I wanted to put my 2 cents in here:
> >>
> >> I wish you had replied to this thread when it was posted (more than
> >> 6 months ago). Reverting the patch now implies making some people
> >> unhappy because they'll have to resort to their old out-of-tree
> >> hacks :-(.
> >
> > I'd say I'm sorry for not following things closely these days, but I'm
> > not really that sorry. There are plenty of other capable hands. And if
> > y'all shoot yourselves in the foot, so be it. This patch isn't going
> > to blow things up, but now that I did finally notice it (because it
> > happened to show up in a list of backports I was looking at), I
> > thought better late than never to remind you.
> >
> > For way of notification: Marek already noticed that we've started down
> > a slippery slope months ago:
> >
> > https://lkml.org/lkml/2018/4/8/141
> > Re: [PATCH] mtd: spi-nor: clear Extended Address Reg on switch to
> > 3-byte addressing.
> >
> > I'm not quite sure why that wasn't taken to its logical conclusion --
> > that the hack should be reverted.
> >
> > This problem has been noted many times already, and we've always
> > stayed on the side of *avoiding* this hack. A few references from a
> > search of my email:
> >
> > http://lists.infradead.org/pipermail/linux-mtd/2013-March/046343.html
> > [PATCH 1/3] mtd: m25p80: utilize dedicated 4-byte addressing commands
> >
> > http://lists.infradead.org/pipermail/barebox/2014-September/020682.html
> > [RFC] MTD m25p80 3-byte addressing and boot problem
> >
> > http://lists.infradead.org/pipermail/linux-mtd/2015-February/057683.html
> > [PATCH 2/2] m25p80: if supported put chip to deep power down if not used
> >
> >>> On Wed, Dec 06, 2017 at 10:53:42AM +0800, Zhiqiang Hou wrote:
> >>> > From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> >>> >
> >>> > Restore the status to be compatible with legacy devices.
> >>> > Take Freescale eSPI boot for example, it copies (in 3 Byte
> >>> > addressing mode) the RCW and bootloader images from SPI flash
> >>> > without firing a reset signal previously, so the reboot command
> >>> > will fail without reseting the addressing mode of SPI flash.
> >>> > This patch implement .shutdown function to restore the status
> >>> > in reboot process, and add the same operation to the .remove
> >>> > function.
> >>>
> >>> We have previously rejected this patch multiple times, because the above
> >>> comment demonstrates a broken product.
> >>
> >> If we were to only support working HW parts, I fear Linux would not
> >> support a lot of HW (that's even more true when it comes to flashes :P).
> >
> > You stopped allowing UBI to attach to MLC NAND recently, no? That
> > sounds like almost the same boat -- you've probably killed quite a few
> > shitty products, if they were to use mainline directly.
> >
> > Anyway, that's derailing the issue. Supporting broken hardware isn't
> > something you try to do by applying the same hack to all systems. You
> > normally try to apply your hack as narrowly as possible. You seem to
> > imply that below. So maybe that's a solution to move forward with. But
> > I'd personally be just as happy to see the patch reverted.
> >
> >>> You cannot guarantee that all
> >>> reboots will invoke the .shutdown() method -- what about crashes? What
> >>> about watchdog resets? IIUC, those will hit the same broken behavior,
> >>> and have unexepcted behavior in your bootloader.
> >>
> >> Yes, there are corner cases that are not addressed with this approach,
> >
> > Is a system crash really a corner case? :D
> >
> >> but it still seems to improve things. Of course, that means the
> >> user should try to re-route all HW reset sources to SW ones (RESET input
> >> pin muxed to the GPIO controller, watchdog generating an interrupt
> >> instead of directly asserting the RESET output pin), which is not always
> >> possible, but even when it's not, isn't it better to have a setup that
> >> works fine 99% of the time instead of 50% of the time?
> >
> > Perhaps, but not at the expense of future development. And
> > realistically, no one is doing that if they have this hack. Most
> > people won't even know that this hack is protecting them at all (so
> > again, they won't try to mitigate the problem any further).
> >
> >>> I suppose one could argue for doing this in remove(), but AIUI you're
> >>> just papering over system bugs by introducing the shutdown() function
> >>> here. Thus, I'd prefer we drop the shutdown() method to avoid misleading
> >>> other users of this driver.
> >>
> >> I understand your point. But if the problem is about making sure people
> >> designing new boards get that right, why not complaining at probe time
> >> when things are wrong?
> >>
> >> I mean, spi_nor_restore() seems to only do something on very specific
> >> NORs (those on which a SW RESET does not resets the addressing
> >> mode).
> >
> > The point isn't that SW RESET doesn't reset the addressing mode -- it
> > does on any flash I've seen. The point is that most systems are built
> > around a stateless assumption in these flash. IIRC, there wasn't even
> > a SW RESET command at all until these "huge" flash came around and
> > stateful addressing modes came about. So boot ROMs and bootloaders
> > would have to be updated to start figuring out when/how to do this SW
> > RESET. And once two vendors start doing it differently (I'm not sure:
> > have they done this already? I think so) it's no longer something a
> > boot ROM will get right.
> >
> > The only way to get this stuff right is to have a hardware reset, or
> > else to avoid all of the stateful modes in software.
> >
> >> So, how about adding a flag that says "my board has the NOR HW
> >> RESET pin wired" (there would be a DT props to set that flag). Then you
> >> add a WARN_ON() when this flag is not set and a NOR chip impacted by
> >> this bug is detected.
> >
> > I'd kinda prefer the reverse. There really isn't a need to document
> > anything for a working system (software usually can't control this
> > RESET pin). The burden should be on the b0rked system to document
> > where it needs unsound hacks to survive.
> >
> >> This way you make sure people are informed that
> >> they're doing something wrong, and for those who can't change their HW
> >> (because it's already widely deployed), you have a fix that improve
> >> things.
> >
> > Or even better: put this hack behind a DT flag, so that one has to
> > admit that their board design is broken before it will even do
> > anything. Proposal: "linux,badly-designed-flash-reset".
> >
> > But, I'd prefer just (partially?) reverting this, and let the authors
> > submit something that works. We're not obligated to keep bad hacks in
> > the kernel.
> >
> > Brian
>
> One possibility that occurred to me when I was exploring this issue is
> to revert to 3-byte mode whenever 4-byte was not actively in use.
> So any access beyond 16Meg is:
> switch-to-4-byte ; perform IO ; switch to 3-byte
> or similar. On my hardware it would be more efficient to
> use the 4-byte opcode to perform the IO, then reset the cached
> 4th address byte that the NOR chip transparently remembered.
>
> This adds a little overhead, but should be fairly robust.
> It doesn't help if something goes terribly wrong while IO is happening,
> but I don't think any other software solution does either.
>
> How would you see that approach?
I think the problem stands: people that have proper HW mitigation for
this problem (NOR chip is reset when the Processor is reset) don't want
to pay the overhead. So, even if we go for this approach, we probably
want to only do that for broken HW.
^ permalink raw reply
* Re: [patch v3 -mm 3/6] mm, memcg: add hierarchical usage oom policy
From: David Rientjes @ 2018-07-23 23:22 UTC (permalink / raw)
To: Roman Gushchin
Cc: Andrew Morton, Michal Hocko, Vladimir Davydov, Johannes Weiner,
Tejun Heo, cgroups, linux-kernel, linux-mm
In-Reply-To: <20180723212855.GA25062@castle>
On Mon, 23 Jul 2018, Roman Gushchin wrote:
> > Roman, I'm trying to make progress so that the cgroup aware oom killer is
> > in a state that it can be merged. Would you prefer a second tunable here
> > to specify a cgroup's points includes memory from its subtree?
>
> Hi, David!
>
> It's hard to tell, because I don't have a clear picture of what you're
> suggesting now.
Each patch specifies what it does rather elaborately. If there's
confusion on what this patch, or any of the patches in this patchset, is
motivated by or addresses, please call it out specifically.
> My biggest concern about your last version was that it's hard
> to tell what oom_policy really defines. Each value has it's own application
> rules, which is a bit messy (some values are meaningful for OOMing cgroup only,
> other are reading on hierarchy traversal).
> If you know how to make it clear and non-contradictory,
> please, describe the proposed interface.
>
As my initial response stated, "tree" has cgroup aware properties but it
considers the subtree usage as its own. I do not know of any usecase,
today or in the future, that would want subtree usage accounted to its own
when being considered as a single indivisible memory consumer yet still
want per-process oom kill selection.
If you do not prefer that overloading, I can break the two out from one
another such that one tunable defines cgroup vs process, and another
defines subtree usage being considered or not. That's a perfectly fine
suggestion and I have no problem implementing it. The only reason I did
not was because I do not know of any user that would want process &&
subtree and that would reduce the number of files for mem cgroup by one.
If you'd like me to separate these out by adding another tunable, please
let me know. We will already have another tunable later, but is not
required for this to be merged as the cover letter states, to allow the
user to adjust the calculation for a subtree such that it may protect
important cgroups that are allowed to use more memory than others.
> > It would be helpful if you would also review the rest of the patchset.
>
> I think, that we should focus on interface semantics right now.
> If we can't agree on how the things should work, it makes no sense
> to discuss the implementation.
>
Yes, I have urged that we consider the interface in both the
memory.oom_group discussion as well as the discussion here, which is why
this patchset removes the mount option, does not lock down the entire
hierarchy into a single policy, and is extensible to be generally useful
outside of very special usecases.
^ permalink raw reply
* Re: [PATCH] dt-bindings: remove 'interrupt-parent' from bindings
From: Vladimir Zapolskiy @ 2018-07-23 23:20 UTC (permalink / raw)
To: Rob Herring, linux-kernel, devicetree; +Cc: Mark Rutland
In-Reply-To: <20180723221317.16394-1-robh@kernel.org>
Hi Rob,
On 07/24/2018 01:13 AM, Rob Herring wrote:
> 'interrupt-parent' is often documented as part of define bindings, but
> it is really outside the scope of a device binding. It's never required
> in a given node as it is often inherited from a parent node. Or it can
> be implicit if a parent node is an 'interrupt-controller' node. So
> remove it from all the binding files.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
[snip]
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt
> index 38211f344dc8..0bfb3ba55f4c 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt
> @@ -14,8 +14,6 @@ Required properties:
> Reset value is IRQ_TYPE_LEVEL_LOW.
>
> Optional properties:
> -- interrupt-parent: empty for MIC interrupt controller, link to parent
> - MIC interrupt controller for SIC1 and SIC2
> - interrupts: empty for MIC interrupt controller, cascaded MIC
> hardware interrupts for SIC1 and SIC2
>
I would rather ask you to keep the property here, it is optional in sense that
its presence distinguishes MIC and SIC types of interrupt controllers.
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 07/14] range-diff: respect diff_option.file rather than assuming 'stdout'
From: Eric Sunshine @ 2018-07-23 23:20 UTC (permalink / raw)
To: Stefan Beller
Cc: Git List, Johannes Schindelin,
Nguyễn Thái Ngọc Duy,
Ævar Arnfjörð Bjarmason
In-Reply-To: <CAGZ79kZ0OMrU_O5_rPdG7bNHRWQxVV1RguEg3g-pOa+kkgPCaA@mail.gmail.com>
On Mon, Jul 23, 2018 at 6:59 PM Stefan Beller <sbeller@google.com> wrote:
> On Sun, Jul 22, 2018 at 2:58 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > The actual diffs output by range-diff respect diff_option.file, which
> > range-diff passes down the call-chain, thus are destination-agnostic.
> > However, output_pair_header() is hard-coded to emit to 'stdout'. Fix
> > this by making output_pair_header() respect diff_option.file, as well.
> >
> > Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
>
> Depending how much the range diff series has progressed
> already, it might make sense to squash it there?
It could be done that way, though it would be nice for Dscho's
range-diff series to land without another re-roll, and it looks like
I'll probably be re-rolling this series, anyhow, to move
show_interdiff() to diff-lib.c and to fix its signature. Junio could
manage it as a "squash", but that's probably more work for him than
for me to retain it in this series. *And*, this change _is_ required
for this series, whereas it doesn't really matter for Dscho's series,
even though it's an obvious "fix".
Anyhow, whichever way Junio and Dscho would like to play it is fine with me.
^ permalink raw reply
* Re: [PATCH v5] media: dvb-frontends: add Socionext MN88443x ISDB-S/T demodulator driver
From: kbuild test robot @ 2018-07-23 22:15 UTC (permalink / raw)
To: Katsuhiro Suzuki
Cc: kbuild-all, Mauro Carvalho Chehab, linux-media, Masami Hiramatsu,
Jassi Brar, linux-arm-kernel, linux-kernel, Katsuhiro Suzuki
In-Reply-To: <20180723085150.24266-1-suzuki.katsuhiro@socionext.com>
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
Hi Katsuhiro,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.18-rc6 next-20180723]
[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/Katsuhiro-Suzuki/media-dvb-frontends-add-Socionext-MN88443x-ISDB-S-T-demodulator-driver/20180724-050011
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-i1-201829 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> drivers/media/dvb-frontends/mn88443x.c:15:10: fatal error: sc1501a.h: No such file or directory
#include "sc1501a.h"
^~~~~~~~~~~
compilation terminated.
vim +15 drivers/media/dvb-frontends/mn88443x.c
14
> 15 #include "sc1501a.h"
16
---
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: 27693 bytes --]
^ permalink raw reply
* Re: [PATCH v4] iio: chemical: Add support for Bosch BME680 sensor
From: David Frey @ 2018-07-23 22:16 UTC (permalink / raw)
To: Himanshu Jha, Daniel Baluta; +Cc: Linux Kernel Mailing List, linux-iio
In-Reply-To: <20180722222153.GA10066@himanshu-Vostro-3559>
On 7/22/2018 3:21 PM, Himanshu Jha wrote:
> On Sat, Jul 21, 2018 at 08:45:34PM +0300, Daniel Baluta wrote:
>> On Sat, Jul 21, 2018 at 6:43 PM, Andy Shevchenko
>> <andy.shevchenko@gmail.com> wrote:
>>> On Sat, Jul 21, 2018 at 6:36 PM, Himanshu Jha
>>> <himanshujha199640@gmail.com> wrote:
>>>
>>>>>> + /* Look up table 1 for the possible gas range values */
>>>>>> + u32 lookupTable1[16] = {2147483647u, 2147483647u, 2147483647u,
>>>>>> + 2147483647u, 2147483647u, 2126008810u,
>>>>>> + 2147483647u, 2130303777u, 2147483647u,
>>>>>> + 2147483647u, 2143188679u, 2136746228u,
>>>>>> + 2147483647u, 2126008810u, 2147483647u,
>>>>>> + 2147483647u};
>>>
>>> This one needs perhaps a bit of though, but...
>>>
>>>>>> + /* Look up table 2 for the possible gas range values */
>>>>>> + u32 lookupTable2[16] = {4096000000u, 2048000000u, 1024000000u,
>>>>>> + 512000000u, 255744255u, 127110228u, 64000000u,
>>>>>> + 32258064u, 16016016u, 8000000u, 4000000u,
>>>>>> + 2000000u, 1000000u, 500000u, 250000u, 125000u};
>>>
>>> ...this one obviously just a not needed one. You may replace it with a
>>> one constant and simple calculation to get either value (index from
>>> value, or value from index).
>>
>> Indeed this can be reduce to:
>>
>> 125.000 << (15 - idx).
>>
>> The real question here is if we approximate 255.744.255u to 256.00.00u how
>> much different is the result. Being a gas sensor I think it is very
>> hard to appreciate.
>>
>> We can go with this formula + adding a comment with the table with the
>> exact coefficients.
>
> So, I have planned to use this 125000 << (15 - idx) equation with
> approximating the array members.
>
> About the difference in results we would get after approximating isn't
> much of a problem IMHO because gas sensor is primarily used for IAQ, and
> IAQ is relative to the resistance reading.
>
> For eg:
>
> Resistance(ohm) IAQ
> value < 30K Very bad
> 30k < value < 50k worse
> 50k < value < 70k bad
> ...
> ..
> so on..
>
> So, what I simply imply is the scale will be adjusted and nothing else
> changes, unlike if it had been pressure, temperature, humidity.
>
> The IAQ implementation is userspace application suggesting
> good/bad/ugly air quality.
>
> And since we know David Frey is planning to use this sensor in his
> product mangOH board.
>
> So, David, how are you planning to use the gas sensing part in your
> product ? RGB leds, buzzer, alarm ?
>
> Thanks Andy for the suggestion :)
>
My understanding is that the Bosch BSEC (Bosch Sensortec Environmental
Cluster - https://www.bosch-sensortec.com/bst/products/all_products/bsec)
software calculates the indoor air quality (IAQ) which is presented in
the range of 0 to 500. BSEC is proprietary, pre-compiled static
library. I don't know how they derive the IAQ, but it seems that it
could be based on smoothing outlying gas resistance values and
integrating other values such as temperature, humidity and pressure.
Unless this driver can somehow produce IAQ values of equal or greater
reliability to the BSEC library, then I would prefer that it just
present the raw gas resistance value so that a user can write a program
to feed the sensor data into BSEC.
mangOH isn't really a traditional product. It's an open hardware board
designed around Sierra Wireless cellular modules that run Linux. So I
don't have any specific use case in mind, but I want to enable our users
(and thus future products) to make use of air quality measurements.
^ permalink raw reply
* `ohci_rh_resume()` called during `usb_dev_suspend()`
From: Paul Menzel @ 2018-07-23 23:19 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2542 bytes --]
Dear Linux folks,
Profiling the suspend to and resume/wake-up from ACPI S3 with
`sleepgraph.py` on an ASRock E350M1, I noticed that resume methods are
called during suspend.
Here is an excerpt from the callgraph.
> 600.376906 | 0) kworker-81 | | /* device_pm_callback_start: usb usb5, parent: 0000:00:14.5, type [suspend] */
> 600.376909 | 0) kworker-81 | | usb_dev_suspend() {
> 600.376911 | 0) kworker-81 | | usb_suspend() {
> 600.376913 | 0) kworker-81 | | __pm_runtime_resume() {
> 600.376915 | 0) kworker-81 | | _cond_resched() {
> 600.376917 | 0) kworker-81 | 0.565 us | rcu_all_qs();
> 600.376921 | 0) kworker-81 | 4.034 us | } /* _cond_resched */
> 600.376922 | 0) kworker-81 | 0.505 us | _raw_spin_lock_irqsave();
> 600.376926 | 0) kworker-81 | | rpm_resume() {
> 600.376928 | 0) kworker-81 | 0.573 us | _raw_spin_lock();
> 600.376934 | 0) kworker-81 | 0.706 us | rpm_resume();
> 600.376937 | 0) kworker-81 | 0.556 us | _raw_spin_lock();
> 600.376942 | 0) kworker-81 | 0.721 us | __rpm_get_callback();
> 600.376946 | 0) kworker-81 | 0.564 us | dev_pm_disable_wake_irq_check();
> 600.376949 | 0) kworker-81 | | rpm_callback() {
> 600.376952 | 0) kworker-81 | | __rpm_callback() {
> 600.376954 | 0) kworker-81 | | usb_runtime_resume() {
> 600.376956 | 0) kworker-81 | | usb_resume_both() {
> 600.376959 | 0) kworker-81 | | generic_resume() {
> 600.376960 | 0) kworker-81 | | hcd_bus_resume() {
> 600.376963 | 0) kworker-81 | | ohci_bus_resume [ohci_hcd]() {
> 600.376964 | 0) kworker-81 | 0.588 us | _raw_spin_lock_irq();
> 600.376968 | 0) kworker-81 | | ohci_rh_resume [ohci_hcd]() {
> 600.377043 | 0) kworker-81 | | msleep() {
Please find the full callgraph and the HTML output attached.
Is that expected?
Kind regards,
Paul
[1]: https://01.org/suspendresume
[-- Attachment #2: kodi_mem.html.7z --]
[-- Type: application/x-7z-compressed, Size: 41725 bytes --]
[-- Attachment #3: kodi_mem_ftrace-ohci.txt --]
[-- Type: text/plain, Size: 35634 bytes --]
600.376906 | 0) kworker-81 | | /* device_pm_callback_start: usb usb5, parent: 0000:00:14.5, type [suspend] */
600.376909 | 0) kworker-81 | | usb_dev_suspend() {
600.376911 | 0) kworker-81 | | usb_suspend() {
600.376913 | 0) kworker-81 | | __pm_runtime_resume() {
600.376915 | 0) kworker-81 | | _cond_resched() {
600.376917 | 0) kworker-81 | 0.565 us | rcu_all_qs();
600.376921 | 0) kworker-81 | 4.034 us | } /* _cond_resched */
600.376922 | 0) kworker-81 | 0.505 us | _raw_spin_lock_irqsave();
600.376926 | 0) kworker-81 | | rpm_resume() {
600.376928 | 0) kworker-81 | 0.573 us | _raw_spin_lock();
600.376934 | 0) kworker-81 | 0.706 us | rpm_resume();
600.376937 | 0) kworker-81 | 0.556 us | _raw_spin_lock();
600.376942 | 0) kworker-81 | 0.721 us | __rpm_get_callback();
600.376946 | 0) kworker-81 | 0.564 us | dev_pm_disable_wake_irq_check();
600.376949 | 0) kworker-81 | | rpm_callback() {
600.376952 | 0) kworker-81 | | __rpm_callback() {
600.376954 | 0) kworker-81 | | usb_runtime_resume() {
600.376956 | 0) kworker-81 | | usb_resume_both() {
600.376959 | 0) kworker-81 | | generic_resume() {
600.376960 | 0) kworker-81 | | hcd_bus_resume() {
600.376963 | 0) kworker-81 | | ohci_bus_resume [ohci_hcd]() {
600.376964 | 0) kworker-81 | 0.588 us | _raw_spin_lock_irq();
600.376968 | 0) kworker-81 | | ohci_rh_resume [ohci_hcd]() {
600.377043 | 0) kworker-81 | | msleep() {
600.377044 | 0) kworker-81 | 0.591 us | __msecs_to_jiffies();
600.377048 | 0) kworker-81 | | schedule_timeout() {
0) kworker-81 => kworker-434
1) sleepgr-779 => kworker-81
600.380611 | 1) kworker-81 | 3561.688 us | } /* schedule_timeout */
600.380613 | 1) kworker-81 | 3569.619 us | } /* msleep */
600.380625 | 1) kworker-81 | | msleep() {
600.380626 | 1) kworker-81 | 0.250 us | __msecs_to_jiffies();
600.380628 | 1) kworker-81 | | schedule_timeout() {
1) kworker-81 => kworker-434
0) kworker-787 => kworker-81
600.386557 | 0) kworker-81 | 5927.651 us | } /* schedule_timeout */
600.386560 | 0) kworker-81 | 5934.355 us | } /* msleep */
600.386565 | 0) kworker-81 | | msleep() {
600.386567 | 0) kworker-81 | 0.490 us | __msecs_to_jiffies();
600.386570 | 0) kworker-81 | | schedule_timeout() {
0) kworker-81 => kworker-434
0) kworker-434 => kworker-81
600.394208 | 0) kworker-81 | 7636.340 us | } /* schedule_timeout */
600.394211 | 0) kworker-81 | 7644.604 us | } /* msleep */
600.394212 | 0) kworker-81 | 0.687 us | _raw_spin_lock_irq();
600.394217 | 0) kworker-81 | 17247.00 us | } /* ohci_rh_resume [ohci_hcd] */
600.394218 | 0) kworker-81 | | usb_hcd_poll_rh_status() {
600.394220 | 0) kworker-81 | | ohci_hub_status_data [ohci_hcd]() {
600.394221 | 0) kworker-81 | 0.543 us | _raw_spin_lock_irqsave();
600.394301 | 0) kworker-81 | 65.859 us | _raw_spin_unlock_irqrestore();
600.394371 | 0) kworker-81 | 150.044 us | } /* ohci_hub_status_data [ohci_hcd] */
600.394373 | 0) kworker-81 | 153.600 us | } /* usb_hcd_poll_rh_status */
600.394375 | 0) kworker-81 | 17410.75 us | } /* ohci_bus_resume [ohci_hcd] */
600.394376 | 0) kworker-81 | 0.597 us | _raw_spin_lock_irq();
600.394380 | 0) kworker-81 | | usb_set_device_state() {
600.394382 | 0) kworker-81 | 0.499 us | _raw_spin_lock_irqsave();
600.394386 | 0) kworker-81 | 0.532 us | _raw_spin_unlock_irqrestore();
600.394389 | 0) kworker-81 | 7.880 us | } /* usb_set_device_state */
600.394391 | 0) kworker-81 | 1.164 us | usb_hub_find_child();
600.394395 | 0) kworker-81 | 0.621 us | usb_hub_find_child();
600.394399 | 0) kworker-81 | 0.514 us | usb_hub_find_child();
600.394403 | 0) kworker-81 | 17440.77 us | } /* hcd_bus_resume */
600.394404 | 0) kworker-81 | 17444.37 us | } /* generic_resume */
600.394406 | 0) kworker-81 | | usb_resume_interface.isra.4() {
600.394408 | 0) kworker-81 | | hub_resume() {
600.394410 | 0) kworker-81 | | hub_activate() {
600.394412 | 0) kworker-81 | | hub_ext_port_status() {
600.394413 | 0) kworker-81 | | mutex_lock() {
600.394415 | 0) kworker-81 | 0.695 us | _cond_resched();
600.394419 | 0) kworker-81 | 4.112 us | } /* mutex_lock */
600.394421 | 0) kworker-81 | | usb_control_msg() {
600.394422 | 0) kworker-81 | 22.651 us | kmem_cache_alloc_trace();
600.394449 | 0) kworker-81 | 24.147 us | usb_alloc_urb();
600.394477 | 0) kworker-81 | 486.801 us | usb_start_wait_urb();
600.394968 | 0) kworker-81 | 3.343 us | kfree();
600.394975 | 0) kworker-81 | 553.075 us | } /* usb_control_msg */
600.394977 | 0) kworker-81 | 0.558 us | mutex_unlock();
600.394981 | 0) kworker-81 | 567.881 us | } /* hub_ext_port_status */
600.394984 | 0) kworker-81 | | hub_ext_port_status() {
600.394985 | 0) kworker-81 | | mutex_lock() {
600.394987 | 0) kworker-81 | 0.722 us | _cond_resched();
600.394991 | 0) kworker-81 | 4.213 us | } /* mutex_lock */
600.394993 | 0) kworker-81 | | usb_control_msg() {
600.394994 | 0) kworker-81 | 21.092 us | kmem_cache_alloc_trace();
600.395019 | 0) kworker-81 | 20.009 us | usb_alloc_urb();
600.395042 | 0) kworker-81 | | usb_start_wait_urb() {
0) kworker-81 => kworker-434
0) kworker-787 => kworker-81
600.396526 | 0) kworker-81 | 1481.933 us | } /* usb_start_wait_urb */
600.396528 | 0) kworker-81 | 3.372 us | kfree();
600.396534 | 0) kworker-81 | 1540.251 us | } /* usb_control_msg */
600.396536 | 0) kworker-81 | 0.520 us | mutex_unlock();
600.396540 | 0) kworker-81 | 1555.112 us | } /* hub_ext_port_status */
600.396542 | 0) kworker-81 | | usb_submit_urb() {
600.396545 | 0) kworker-81 | 0.526 us | usb_urb_ep_type_check();
600.396549 | 0) kworker-81 | | usb_hcd_submit_urb() {
600.396550 | 0) kworker-81 | 0.510 us | usb_get_urb();
600.396554 | 0) kworker-81 | 0.585 us | _raw_spin_lock_irqsave();
600.396558 | 0) kworker-81 | 0.891 us | usb_hcd_link_urb_to_ep();
600.396562 | 0) kworker-81 | 0.511 us | _raw_spin_unlock_irqrestore();
600.396566 | 0) kworker-81 | 15.791 us | } /* usb_hcd_submit_urb */
600.396568 | 0) kworker-81 | 23.948 us | } /* usb_submit_urb */
600.396571 | 0) kworker-81 | | kick_hub_wq.part.9() {
600.396573 | 0) kworker-81 | 0.701 us | usb_autopm_get_interface_no_resume();
600.396577 | 0) kworker-81 | | queue_work_on() {
600.396579 | 0) kworker-81 | 10.675 us | __queue_work();
600.396593 | 0) kworker-81 | 14.645 us | } /* queue_work_on */
600.396595 | 0) kworker-81 | 22.325 us | } /* kick_hub_wq.part.9 */
600.396597 | 0) kworker-81 | 2185.388 us | } /* hub_activate */
600.396599 | 0) kworker-81 | 2189.006 us | } /* hub_resume */
600.396600 | 0) kworker-81 | 2192.768 us | } /* usb_resume_interface.isra.4 */
600.396602 | 0) kworker-81 | 19644.93 us | } /* usb_resume_both */
600.396604 | 0) kworker-81 | 19648.63 us | } /* usb_runtime_resume */
600.396606 | 0) kworker-81 | 0.558 us | _raw_spin_lock_irq();
600.396610 | 0) kworker-81 | 19657.32 us | } /* __rpm_callback */
600.396612 | 0) kworker-81 | 19661.36 us | } /* rpm_callback */
600.396615 | 0) kworker-81 | | __wake_up() {
600.396616 | 0) kworker-81 | | __wake_up_common_lock() {
600.396618 | 0) kworker-81 | 0.514 us | _raw_spin_lock_irqsave();
600.396621 | 0) kworker-81 | 0.709 us | __wake_up_common();
600.396625 | 0) kworker-81 | 0.547 us | _raw_spin_unlock_irqrestore();
600.396629 | 0) kworker-81 | 11.214 us | } /* __wake_up_common_lock */
600.396631 | 0) kworker-81 | 14.627 us | } /* __wake_up */
600.396633 | 0) kworker-81 | | rpm_idle() {
600.396634 | 0) kworker-81 | 0.801 us | rpm_check_suspend_allowed();
600.396639 | 0) kworker-81 | 4.396 us | } /* rpm_idle */
600.396640 | 0) kworker-81 | 0.661 us | __pm_runtime_idle();
600.396644 | 0) kworker-81 | 0.522 us | _raw_spin_lock_irq();
600.396648 | 0) kworker-81 | 19720.92 us | } /* rpm_resume */
600.396650 | 0) kworker-81 | 0.579 us | _raw_spin_unlock_irqrestore();
600.396654 | 0) kworker-81 | 19739.29 us | } /* __pm_runtime_resume */
600.396656 | 0) kworker-81 | | usb_suspend_both() {
600.396658 | 0) kworker-81 | | hub_suspend() {
600.396661 | 0) kworker-81 | | hub_quiesce() {
600.396662 | 0) kworker-81 | | usb_kill_urb() {
600.396664 | 0) kworker-81 | | _cond_resched() {
600.396666 | 0) kworker-81 | 0.540 us | rcu_all_qs();
600.396670 | 0) kworker-81 | 4.762 us | } /* _cond_resched */
600.396672 | 0) kworker-81 | | usb_hcd_unlink_urb() {
600.396674 | 0) kworker-81 | 0.567 us | _raw_spin_lock_irqsave();
600.396678 | 0) kworker-81 | | usb_get_dev() {
600.396680 | 0) kworker-81 | 0.585 us | get_device();
600.396684 | 0) kworker-81 | 4.349 us | } /* usb_get_dev */
600.396685 | 0) kworker-81 | 0.617 us | _raw_spin_unlock_irqrestore();
600.396689 | 0) kworker-81 | | unlink1() {
600.396691 | 0) kworker-81 | 0.573 us | _raw_spin_lock_irqsave();
600.396695 | 0) kworker-81 | | usb_hcd_unlink_urb_from_ep() {
600.396697 | 0) kworker-81 | 0.490 us | _raw_spin_lock();
600.396701 | 0) kworker-81 | 4.046 us | } /* usb_hcd_unlink_urb_from_ep */
600.396702 | 0) kworker-81 | | usb_hcd_giveback_urb() {
600.396704 | 0) kworker-81 | 0.478 us | _raw_spin_lock();
600.396708 | 0) kworker-81 | | __tasklet_hi_schedule() {
600.396709 | 0) kworker-81 | | __tasklet_schedule_common() {
600.396711 | 0) kworker-81 | 0.489 us | __raise_softirq_irqoff();
600.396715 | 0) kworker-81 | | wakeup_softirqd() {
600.396717 | 0) kworker-81 | | wake_up_process() {
600.396718 | 0) kworker-81 | 6.689 us | try_to_wake_up();
600.396728 | 0) kworker-81 | 10.227 us | } /* wake_up_process */
600.396730 | 0) kworker-81 | 13.870 us | } /* wakeup_softirqd */
600.396732 | 0) kworker-81 | 21.150 us | } /* __tasklet_schedule_common */
600.396734 | 0) kworker-81 | 24.620 us | } /* __tasklet_hi_schedule */
600.396735 | 0) kworker-81 | 31.807 us | } /* usb_hcd_giveback_urb */
600.396737 | 0) kworker-81 | 0.558 us | _raw_spin_unlock_irqrestore();
600.396741 | 0) kworker-81 | 50.480 us | } /* unlink1 */
600.396743 | 0) kworker-81 | | usb_put_dev() {
600.396744 | 0) kworker-81 | 0.620 us | put_device();
600.396748 | 0) kworker-81 | 4.316 us | } /* usb_put_dev */
600.396750 | 0) kworker-81 | 76.464 us | } /* usb_hcd_unlink_urb */
600.396752 | 0) kworker-81 | | _cond_resched() {
600.396754 | 0) kworker-81 | 0.493 us | rcu_all_qs();
600.396757 | 0) kworker-81 | 3.960 us | } /* _cond_resched */
600.396759 | 0) kworker-81 | 0.561 us | init_wait_entry();
600.396763 | 0) kworker-81 | | prepare_to_wait_event() {
600.396764 | 0) kworker-81 | 0.733 us | _raw_spin_lock_irqsave();
600.396768 | 0) kworker-81 | 0.582 us | _raw_spin_unlock_irqrestore();
600.396772 | 0) kworker-81 | 7.802 us | } /* prepare_to_wait_event */
600.396774 | 0) kworker-81 | | schedule() {
600.396776 | 0) kworker-81 | | rcu_note_context_switch() {
600.396777 | 0) kworker-81 | 0.495 us | rcu_sched_qs();
600.396781 | 0) kworker-81 | 4.024 us | } /* rcu_note_context_switch */
600.396783 | 0) kworker-81 | 0.493 us | _raw_spin_lock();
600.396786 | 0) kworker-81 | 0.923 us | update_rq_clock();
600.396790 | 0) kworker-81 | | deactivate_task() {
600.396793 | 0) kworker-81 | | dequeue_task_fair() {
600.396795 | 0) kworker-81 | | dequeue_entity() {
600.396796 | 0) kworker-81 | | update_curr() {
600.396798 | 0) kworker-81 | 0.528 us | update_min_vruntime();
600.396802 | 0) kworker-81 | 0.537 us | cpuacct_charge();
600.396805 | 0) kworker-81 | 7.724 us | } /* update_curr */
600.396807 | 0) kworker-81 | 0.600 us | __update_load_avg_se.isra.21();
600.396811 | 0) kworker-81 | 0.591 us | __update_load_avg_cfs_rq.isra.22();
600.396815 | 0) kworker-81 | 0.561 us | clear_buddies();
600.396818 | 0) kworker-81 | 0.608 us | account_entity_dequeue();
600.396822 | 0) kworker-81 | 0.531 us | update_cfs_group();
600.396825 | 0) kworker-81 | 29.358 us | } /* dequeue_entity */
600.396827 | 0) kworker-81 | 0.469 us | hrtick_update();
600.396832 | 0) kworker-81 | 37.247 us | } /* dequeue_task_fair */
600.396834 | 0) kworker-81 | 41.369 us | } /* deactivate_task */
600.396835 | 0) kworker-81 | | wq_worker_sleeping() {
600.396837 | 0) kworker-81 | 0.507 us | kthread_data();
600.396842 | 0) kworker-81 | 4.026 us | } /* wq_worker_sleeping */
600.396844 | 0) kworker-81 | | pick_next_task_fair() {
600.396846 | 0) kworker-81 | 0.490 us | check_cfs_rq_runtime();
600.396849 | 0) kworker-81 | | pick_next_entity() {
600.396851 | 0) kworker-81 | 0.508 us | clear_buddies();
600.396855 | 0) kworker-81 | 4.061 us | } /* pick_next_entity */
600.396857 | 0) kworker-81 | | put_prev_entity() {
600.396859 | 0) kworker-81 | 0.483 us | check_cfs_rq_runtime();
600.396863 | 0) kworker-81 | 4.064 us | } /* put_prev_entity */
600.396864 | 0) kworker-81 | | set_next_entity() {
600.396867 | 0) kworker-81 | 0.606 us | __update_load_avg_se.isra.21();
600.396870 | 0) kworker-81 | 0.556 us | __update_load_avg_cfs_rq.isra.22();
600.396874 | 0) kworker-81 | 8.356 us | } /* set_next_entity */
600.396876 | 0) kworker-81 | 30.584 us | } /* pick_next_task_fair */
600.396879 | 0) kworker-81 | 0.501 us | enter_lazy_tlb();
0) kworker-81 => kworker-434
0) kworker-434 => kworker-81
600.397304 | 0) kworker-81 | | finish_task_switch() {
600.397307 | 0) kworker-81 | ==========> |
600.397307 | 0) kworker-81 | | smp_apic_timer_interrupt() {
600.397309 | 0) kworker-81 | | irq_enter() {
600.397310 | 0) kworker-81 | | rcu_irq_enter() {
600.397312 | 0) kworker-81 | 0.555 us | rcu_nmi_enter();
600.397316 | 0) kworker-81 | 4.100 us | } /* rcu_irq_enter */
600.397318 | 0) kworker-81 | 0.760 us | irqtime_account_irq();
600.397322 | 0) kworker-81 | 11.439 us | } /* irq_enter */
600.397323 | 0) kworker-81 | | hrtimer_interrupt() {
600.397325 | 0) kworker-81 | 0.508 us | _raw_spin_lock_irqsave();
600.397329 | 0) kworker-81 | 0.837 us | ktime_get_update_offsets_now();
600.397332 | 0) kworker-81 | | __hrtimer_run_queues() {
600.397334 | 0) kworker-81 | 0.516 us | __next_base();
600.397338 | 0) kworker-81 | 0.867 us | __remove_hrtimer();
600.397341 | 0) kworker-81 | 0.540 us | _raw_spin_unlock_irqrestore();
600.397345 | 0) kworker-81 | | tick_sched_timer() {
600.397347 | 0) kworker-81 | 0.688 us | ktime_get();
600.397351 | 0) kworker-81 | | tick_sched_do_timer() {
600.397352 | 0) kworker-81 | 5.011 us | tick_do_update_jiffies64.part.5();
600.397361 | 0) kworker-81 | 8.903 us | } /* tick_sched_do_timer */
600.397363 | 0) kworker-81 | | tick_sched_handle() {
600.397364 | 0) kworker-81 | 9.874 us | update_process_times();
600.397377 | 0) kworker-81 | 0.537 us | profile_tick();
600.397381 | 0) kworker-81 | 17.055 us | } /* tick_sched_handle */
600.397383 | 0) kworker-81 | 0.605 us | hrtimer_forward();
600.397386 | 0) kworker-81 | 39.630 us | } /* tick_sched_timer */
600.397388 | 0) kworker-81 | 0.529 us | _raw_spin_lock_irq();
600.397391 | 0) kworker-81 | 0.917 us | enqueue_hrtimer();
600.397395 | 0) kworker-81 | 0.529 us | __next_base();
600.397399 | 0) kworker-81 | 0.517 us | __next_base();
600.397402 | 0) kworker-81 | 0.531 us | __next_base();
600.397406 | 0) kworker-81 | 72.143 us | } /* __hrtimer_run_queues */
600.397407 | 0) kworker-81 | | __hrtimer_get_next_event() {
600.397409 | 0) kworker-81 | | __hrtimer_next_event_base() {
600.397411 | 0) kworker-81 | 0.522 us | __next_base();
600.397414 | 0) kworker-81 | 3.678 us | } /* __hrtimer_next_event_base */
600.397416 | 0) kworker-81 | | __hrtimer_next_event_base() {
600.397417 | 0) kworker-81 | 0.505 us | __next_base();
600.397420 | 0) kworker-81 | 0.504 us | __next_base();
600.397424 | 0) kworker-81 | 0.505 us | __next_base();
600.397427 | 0) kworker-81 | 0.510 us | __next_base();
600.397430 | 0) kworker-81 | 13.422 us | } /* __hrtimer_next_event_base */
600.397432 | 0) kworker-81 | 23.157 us | } /* __hrtimer_get_next_event */
600.397433 | 0) kworker-81 | 0.525 us | _raw_spin_unlock_irqrestore();
600.397437 | 0) kworker-81 | | tick_program_event() {
600.397438 | 0) kworker-81 | | clockevents_program_event() {
600.397440 | 0) kworker-81 | 0.680 us | ktime_get();
600.397444 | 0) kworker-81 | 0.695 us | lapic_next_event();
600.397448 | 0) kworker-81 | 7.802 us | } /* clockevents_program_event */
600.397449 | 0) kworker-81 | 11.130 us | } /* tick_program_event */
600.397451 | 0) kworker-81 | 125.887 us | } /* hrtimer_interrupt */
600.397452 | 0) kworker-81 | | irq_exit() {
600.397454 | 0) kworker-81 | 0.804 us | irqtime_account_irq();
600.397458 | 0) kworker-81 | | do_softirq_own_stack() {
600.397460 | 0) kworker-81 | | call_on_stack() {
600.397462 | 0) kworker-81 | | __do_softirq() {
600.397464 | 0) kworker-81 | 0.766 us | irqtime_account_irq();
600.397467 | 0) kworker-81 | 1.262 us | run_timer_softirq();
600.397472 | 0) kworker-81 | 0.484 us | rcu_bh_qs();
600.397475 | 0) kworker-81 | 0.855 us | irqtime_account_irq();
600.397479 | 0) kworker-81 | 15.082 us | } /* __do_softirq */
600.397480 | 0) kworker-81 | 18.533 us | } /* call_on_stack */
600.397482 | 0) kworker-81 | 23.118 us | } /* do_softirq_own_stack */
600.397484 | 0) kworker-81 | 0.502 us | idle_cpu();
600.397487 | 0) kworker-81 | | rcu_irq_exit() {
600.397489 | 0) kworker-81 | 0.528 us | rcu_nmi_exit();
600.397492 | 0) kworker-81 | 3.782 us | } /* rcu_irq_exit */
600.397494 | 0) kworker-81 | 40.070 us | } /* irq_exit */
600.397496 | 0) kworker-81 | 187.073 us | } /* smp_apic_timer_interrupt */
600.397496 | 0) kworker-81 | <========== |
600.397498 | 0) kworker-81 | 192.165 us | } /* finish_task_switch */
600.397500 | 0) kworker-81 | 724.625 us | } /* schedule */
600.397501 | 0) kworker-81 | | prepare_to_wait_event() {
600.397503 | 0) kworker-81 | 0.534 us | _raw_spin_lock_irqsave();
600.397506 | 0) kworker-81 | 0.544 us | _raw_spin_unlock_irqrestore();
600.397510 | 0) kworker-81 | 7.472 us | } /* prepare_to_wait_event */
600.397512 | 0) kworker-81 | | finish_wait() {
600.397513 | 0) kworker-81 | 0.505 us | _raw_spin_lock_irqsave();
600.397517 | 0) kworker-81 | 0.522 us | _raw_spin_unlock_irqrestore();
600.397520 | 0) kworker-81 | 7.139 us | } /* finish_wait */
600.397522 | 0) kworker-81 | 857.975 us | } /* usb_kill_urb */
600.397524 | 0) kworker-81 | 861.707 us | } /* hub_quiesce */
600.397526 | 0) kworker-81 | 865.786 us | } /* hub_suspend */
600.397528 | 0) kworker-81 | | generic_suspend() {
600.397529 | 0) kworker-81 | | hcd_bus_suspend() {
600.397531 | 0) kworker-81 | | ohci_bus_suspend [ohci_hcd]() {
600.397533 | 0) kworker-81 | 0.617 us | _raw_spin_lock_irq();
600.397537 | 0) kworker-81 | | ohci_rh_suspend [ohci_hcd]() {
600.397540 | 0) kworker-81 | 0.985 us | update_done_list [ohci_hcd]();
600.397544 | 0) kworker-81 | 0.959 us | ohci_work.part.13 [ohci_hcd]();
600.397554 | 0) kworker-81 | 15.217 us | } /* ohci_rh_suspend [ohci_hcd] */
600.397555 | 0) kworker-81 | | del_timer_sync() {
600.397557 | 0) kworker-81 | | try_to_del_timer_sync() {
600.397559 | 0) kworker-81 | | lock_timer_base() {
600.397560 | 0) kworker-81 | 0.563 us | _raw_spin_lock_irqsave();
600.397564 | 0) kworker-81 | 3.844 us | } /* lock_timer_base */
600.397565 | 0) kworker-81 | 0.546 us | detach_if_pending();
600.397568 | 0) kworker-81 | 0.499 us | _raw_spin_unlock_irqrestore();
600.397572 | 0) kworker-81 | 13.834 us | } /* try_to_del_timer_sync */
600.397574 | 0) kworker-81 | 17.070 us | } /* del_timer_sync */
600.397576 | 0) kworker-81 | 42.649 us | } /* ohci_bus_suspend [ohci_hcd] */
600.397577 | 0) kworker-81 | | usb_set_device_state() {
600.397579 | 0) kworker-81 | 0.490 us | _raw_spin_lock_irqsave();
600.397582 | 0) kworker-81 | 0.576 us | _raw_spin_unlock_irqrestore();
600.397586 | 0) kworker-81 | 7.235 us | } /* usb_set_device_state */
600.397588 | 0) kworker-81 | | usb_phy_roothub_suspend() {
600.397589 | 0) kworker-81 | 0.478 us | usb_phy_roothub_power_off();
600.397593 | 0) kworker-81 | 3.791 us | } /* usb_phy_roothub_suspend */
600.397595 | 0) kworker-81 | 63.831 us | } /* hcd_bus_suspend */
600.397596 | 0) kworker-81 | 67.338 us | } /* generic_suspend */
600.397598 | 0) kworker-81 | | usb_hcd_flush_endpoint() {
600.397600 | 0) kworker-81 | | _cond_resched() {
600.397601 | 0) kworker-81 | 0.487 us | rcu_all_qs();
600.397605 | 0) kworker-81 | 3.954 us | } /* _cond_resched */
600.397607 | 0) kworker-81 | 0.653 us | _raw_spin_lock_irq();
600.397611 | 0) kworker-81 | 11.733 us | } /* usb_hcd_flush_endpoint */
600.397613 | 0) kworker-81 | | usb_hcd_flush_endpoint() {
600.397614 | 0) kworker-81 | | _cond_resched() {
600.397616 | 0) kworker-81 | 0.492 us | rcu_all_qs();
600.397619 | 0) kworker-81 | 3.690 us | } /* _cond_resched */
600.397621 | 0) kworker-81 | 0.499 us | _raw_spin_lock_irq();
600.397624 | 0) kworker-81 | 10.322 us | } /* usb_hcd_flush_endpoint */
600.397626 | 0) kworker-81 | 0.555 us | usb_hcd_flush_endpoint();
600.397629 | 0) kworker-81 | | usb_hcd_flush_endpoint() {
600.397631 | 0) kworker-81 | | _cond_resched() {
600.397632 | 0) kworker-81 | 0.496 us | rcu_all_qs();
600.397636 | 0) kworker-81 | 3.955 us | } /* _cond_resched */
600.397637 | 0) kworker-81 | 0.520 us | _raw_spin_lock_irq();
600.397641 | 0) kworker-81 | 10.904 us | } /* usb_hcd_flush_endpoint */
600.397643 | 0) kworker-81 | 0.520 us | usb_hcd_flush_endpoint();
600.397646 | 0) kworker-81 | 0.510 us | usb_hcd_flush_endpoint();
600.397649 | 0) kworker-81 | 0.513 us | usb_hcd_flush_endpoint();
600.397652 | 0) kworker-81 | 0.514 us | usb_hcd_flush_endpoint();
600.397655 | 0) kworker-81 | 0.520 us | usb_hcd_flush_endpoint();
600.397659 | 0) kworker-81 | 0.513 us | usb_hcd_flush_endpoint();
600.397662 | 0) kworker-81 | 0.519 us | usb_hcd_flush_endpoint();
600.397665 | 0) kworker-81 | 0.535 us | usb_hcd_flush_endpoint();
600.397668 | 0) kworker-81 | 0.505 us | usb_hcd_flush_endpoint();
600.397672 | 0) kworker-81 | 0.514 us | usb_hcd_flush_endpoint();
600.397675 | 0) kworker-81 | 0.511 us | usb_hcd_flush_endpoint();
600.397678 | 0) kworker-81 | 0.514 us | usb_hcd_flush_endpoint();
600.397682 | 0) kworker-81 | 0.511 us | usb_hcd_flush_endpoint();
600.397685 | 0) kworker-81 | 0.514 us | usb_hcd_flush_endpoint();
600.397688 | 0) kworker-81 | 0.511 us | usb_hcd_flush_endpoint();
600.397691 | 0) kworker-81 | 0.514 us | usb_hcd_flush_endpoint();
600.397694 | 0) kworker-81 | 0.510 us | usb_hcd_flush_endpoint();
600.397699 | 0) kworker-81 | 0.514 us | usb_hcd_flush_endpoint();
600.397702 | 0) kworker-81 | 0.517 us | usb_hcd_flush_endpoint();
600.397706 | 0) kworker-81 | 0.490 us | usb_hcd_flush_endpoint();
600.397710 | 0) kworker-81 | 0.511 us | usb_hcd_flush_endpoint();
600.397713 | 0) kworker-81 | 0.513 us | usb_hcd_flush_endpoint();
600.397716 | 0) kworker-81 | 0.546 us | usb_hcd_flush_endpoint();
600.397719 | 0) kworker-81 | 0.510 us | usb_hcd_flush_endpoint();
600.397722 | 0) kworker-81 | 0.543 us | usb_hcd_flush_endpoint();
600.397726 | 0) kworker-81 | 0.510 us | usb_hcd_flush_endpoint();
600.397729 | 0) kworker-81 | 0.536 us | usb_hcd_flush_endpoint();
600.397732 | 0) kworker-81 | 0.494 us | usb_hcd_flush_endpoint();
600.397736 | 0) kworker-81 | 1078.699 us | } /* usb_suspend_both */
600.397738 | 0) kworker-81 | 20825.76 us | } /* usb_suspend */
600.397740 | 0) kworker-81 | 20829.27 us | } /* usb_dev_suspend */
600.397742 | 0) kworker-81 | 0.543 us | dev_driver_string();
600.397746 | 0) kworker-81 | 0.514 us | dev_driver_string();
600.397749 | 0) kworker-81 | | /* device_pm_callback_end: usb usb5, err=0 */
^ permalink raw reply
* Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting
From: Boris Brezillon @ 2018-07-23 23:18 UTC (permalink / raw)
To: Brian Norris
Cc: Zhiqiang Hou, linux-mtd, Linux Kernel, David Woodhouse,
Boris BREZILLON, Marek Vasut, Richard Weinberger, Cyrille Pitchen,
NeilBrown
In-Reply-To: <CAN8TOE904WXMScHo1b2jhusz-L8eGBK=gzUUX079ZVfiFk+HoQ@mail.gmail.com>
+Neil
On Mon, 23 Jul 2018 15:06:43 -0700
Brian Norris <computersforpeace@gmail.com> wrote:
> Hi Boris,
>
> On Mon, Jul 23, 2018 at 1:10 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > On Mon, 23 Jul 2018 11:13:50 -0700
> > Brian Norris <computersforpeace@gmail.com> wrote:
> >> I noticed this got merged, but I wanted to put my 2 cents in here:
> >
> > I wish you had replied to this thread when it was posted (more than
> > 6 months ago). Reverting the patch now implies making some people
> > unhappy because they'll have to resort to their old out-of-tree
> > hacks :-(.
>
> I'd say I'm sorry for not following things closely these days, but I'm
> not really that sorry. There are plenty of other capable hands. And if
> y'all shoot yourselves in the foot, so be it. This patch isn't going
> to blow things up, but now that I did finally notice it (because it
> happened to show up in a list of backports I was looking at), I
> thought better late than never to remind you.
>
> For way of notification: Marek already noticed that we've started down
> a slippery slope months ago:
>
> https://lkml.org/lkml/2018/4/8/141
> Re: [PATCH] mtd: spi-nor: clear Extended Address Reg on switch to
> 3-byte addressing.
>
> I'm not quite sure why that wasn't taken to its logical conclusion --
> that the hack should be reverted.
>
> This problem has been noted many times already, and we've always
> stayed on the side of *avoiding* this hack. A few references from a
> search of my email:
>
> http://lists.infradead.org/pipermail/linux-mtd/2013-March/046343.html
> [PATCH 1/3] mtd: m25p80: utilize dedicated 4-byte addressing commands
>
> http://lists.infradead.org/pipermail/barebox/2014-September/020682.html
> [RFC] MTD m25p80 3-byte addressing and boot problem
>
> http://lists.infradead.org/pipermail/linux-mtd/2015-February/057683.html
> [PATCH 2/2] m25p80: if supported put chip to deep power down if not used
To my defense, I was not actively following SPI NOR topics at this
time, but, in the light of those discussions, I still keep thinking we
should try our best to improve support for broken HW.
So, ideally, we should find a way to support getting back to 3-byte
addressing mode when resetting, while generating enough noise to make
people well aware that their board design is broken (I think the
proposal of the new DT prop + a WARN_ON() is a good idea).
>
> >> On Wed, Dec 06, 2017 at 10:53:42AM +0800, Zhiqiang Hou wrote:
> >> > From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> >> >
> >> > Restore the status to be compatible with legacy devices.
> >> > Take Freescale eSPI boot for example, it copies (in 3 Byte
> >> > addressing mode) the RCW and bootloader images from SPI flash
> >> > without firing a reset signal previously, so the reboot command
> >> > will fail without reseting the addressing mode of SPI flash.
> >> > This patch implement .shutdown function to restore the status
> >> > in reboot process, and add the same operation to the .remove
> >> > function.
> >>
> >> We have previously rejected this patch multiple times, because the above
> >> comment demonstrates a broken product.
> >
> > If we were to only support working HW parts, I fear Linux would not
> > support a lot of HW (that's even more true when it comes to flashes :P).
>
> You stopped allowing UBI to attach to MLC NAND recently, no? That
> sounds like almost the same boat -- you've probably killed quite a few
> shitty products, if they were to use mainline directly.
Well, that's a bit different in that it's purely a SW issue, and we
also try to encourage people to take over the work we started with
Richard to fix that problem. But I get your point, we broke setups that
were working in an unreliable way, pretty much what you're suggesting to
do here.
>
> Anyway, that's derailing the issue. Supporting broken hardware isn't
> something you try to do by applying the same hack to all systems. You
> normally try to apply your hack as narrowly as possible.
This, I agree with.
> You seem to
> imply that below. So maybe that's a solution to move forward with. But
> I'd personally be just as happy to see the patch reverted.
>
> >> You cannot guarantee that all
> >> reboots will invoke the .shutdown() method -- what about crashes? What
> >> about watchdog resets? IIUC, those will hit the same broken behavior,
> >> and have unexepcted behavior in your bootloader.
> >
> > Yes, there are corner cases that are not addressed with this approach,
>
> Is a system crash really a corner case? :D
Well, nothing forces you to reset the platform using a HW reset when
that happens :P.
>
> > but it still seems to improve things. Of course, that means the
> > user should try to re-route all HW reset sources to SW ones (RESET input
> > pin muxed to the GPIO controller, watchdog generating an interrupt
> > instead of directly asserting the RESET output pin), which is not always
> > possible, but even when it's not, isn't it better to have a setup that
> > works fine 99% of the time instead of 50% of the time?
>
> Perhaps, but not at the expense of future development. And
> realistically, no one is doing that if they have this hack. Most
> people won't even know that this hack is protecting them at all (so
> again, they won't try to mitigate the problem any further).
Unless we add a huge backtrace at probe time which forces them to look
closer at what they did wrong (like you seem to suggest below).
>
> >> I suppose one could argue for doing this in remove(), but AIUI you're
> >> just papering over system bugs by introducing the shutdown() function
> >> here. Thus, I'd prefer we drop the shutdown() method to avoid misleading
> >> other users of this driver.
> >
> > I understand your point. But if the problem is about making sure people
> > designing new boards get that right, why not complaining at probe time
> > when things are wrong?
> >
> > I mean, spi_nor_restore() seems to only do something on very specific
> > NORs (those on which a SW RESET does not resets the addressing
> > mode).
>
> The point isn't that SW RESET doesn't reset the addressing mode -- it
> does on any flash I've seen. The point is that most systems are built
> around a stateless assumption in these flash. IIRC, there wasn't even
> a SW RESET command at all until these "huge" flash came around and
> stateful addressing modes came about. So boot ROMs and bootloaders
> would have to be updated to start figuring out when/how to do this SW
> RESET. And once two vendors start doing it differently (I'm not sure:
> have they done this already? I think so) it's no longer something a
> boot ROM will get right.
>
> The only way to get this stuff right is to have a hardware reset, or
> else to avoid all of the stateful modes in software.
Okay.
>
> > So, how about adding a flag that says "my board has the NOR HW
> > RESET pin wired" (there would be a DT props to set that flag). Then you
> > add a WARN_ON() when this flag is not set and a NOR chip impacted by
> > this bug is detected.
>
> I'd kinda prefer the reverse. There really isn't a need to document
> anything for a working system (software usually can't control this
> RESET pin). The burden should be on the b0rked system to document
> where it needs unsound hacks to survive.
That's true.
>
> > This way you make sure people are informed that
> > they're doing something wrong, and for those who can't change their HW
> > (because it's already widely deployed), you have a fix that improve
> > things.
>
> Or even better: put this hack behind a DT flag, so that one has to
> admit that their board design is broken before it will even do
> anything. Proposal: "linux,badly-designed-flash-reset".
I think we can remove the "linux," prefix. If it's badly designed, it
applies to all OSes, don't you think?
Regards,
Boris
^ permalink raw reply
* Re: [PATCH v5] PCI: Check for PCIe downtraining conditions
From: Jakub Kicinski @ 2018-07-23 22:14 UTC (permalink / raw)
To: Tal Gilboa
Cc: Alexandru Gagniuc, linux-pci@vger.kernel.org, bhelgaas@google.com,
keith.busch@intel.com, alex_gagniuc@dellteam.com,
austin_bolen@dell.com, shyam_iyer@dell.com,
jeffrey.t.kirsher@intel.com, ariel.elior@cavium.com,
michael.chan@broadcom.com, ganeshgr@chelsio.com, Tariq Toukan,
airlied@gmail.com, alexander.deucher@amd.com,
mike.marciniszyn@intel.com, linux-kernel@vger.kernel.org
In-Reply-To: <b9a6b3b8-56cf-8bb5-2568-071ccd8a4f28@mellanox.com>
On Tue, 24 Jul 2018 00:52:22 +0300, Tal Gilboa wrote:
> On 7/24/2018 12:01 AM, Jakub Kicinski wrote:
> > On Mon, 23 Jul 2018 15:03:38 -0500, Alexandru Gagniuc wrote:
> >> PCIe downtraining happens when both the device and PCIe port are
> >> capable of a larger bus width or higher speed than negotiated.
> >> Downtraining might be indicative of other problems in the system, and
> >> identifying this from userspace is neither intuitive, nor
> >> straightforward.
> >>
> >> The easiest way to detect this is with pcie_print_link_status(),
> >> since the bottleneck is usually the link that is downtrained. It's not
> >> a perfect solution, but it works extremely well in most cases.
> >>
> >> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> >> ---
> >>
> >> For the sake of review, I've created a __pcie_print_link_status() which
> >> takes a 'verbose' argument. If we agree want to go this route, and update
> >> the users of pcie_print_link_status(), I can split this up in two patches.
> >> I prefer just printing this information in the core functions, and letting
> >> drivers not have to worry about this. Though there seems to be strong for
> >> not going that route, so here it goes:
> >
> > FWIW the networking drivers print PCIe BW because sometimes the network
> > bandwidth is simply over-provisioned on multi port cards, e.g. 80Gbps
> > card on a x8 link.
> >
> > Sorry to bike shed, but currently the networking cards print the info
> > during probe. Would it make sense to move your message closer to probe
> > time? Rather than when device is added. If driver structure is
> > available, we could also consider adding a boolean to struct pci_driver
> > to indicate if driver wants the verbose message? This way we avoid
> > duplicated prints.
> >
> > I have no objection to current patch, it LGTM. Just a thought.
>
> I don't see the reason for having two functions. What's the problem with
> adding the verbose argument to the original function?
IMHO it's reasonable to keep the default parameter to what 90% of users
want by a means on a wrapper. The non-verbose output is provided by
the core already for all devices.
What do you think of my proposal above Tal? That would make the extra
wrapper unnecessary since the verbose parameter would be part of the
driver structure, and it would avoid the duplicated output.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.