Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()
On Wed, 2017-05-17 at 22:05 -0700, Bjorn Andersson wrote: > > It seems very important to a lot of people... I get blinking, I guess, but I don't get toggling for every packet :) The throughput thing we did in iwlwifi seems like a so much better idea. Not that it really matters for this discussion though. > But if ieee80211_free_txskb() is the counterpart of > ieee80211_tx_status() then we should be able to push the > ieee80211_led_tx() call down into ieee80211_report_used_skb() and > handle both cases. Yeah, I guess that works. > The ieee80211_free_txskb() seems to be used in various cases where we > discard skbs, but perhaps this is not an issue in reality. Those should be code paths that are really rare, when we fail allocations in some places, etc. So it shouldn't really lead to any problems. > Looking around it seems that we either have a call to free_txskb() or > one of the tx_status(); Yes, you're right - we always need one of those for each SKB that passed through mac80211, everything else is already a bug. > where the _noskb() would need some special > handling. Are there others or would it be reasonable to add a call in > this one "special" case? Now that I think more about it, the _noskb() doesn't actually make sense - it's for a separate status report, pretty much only for rate control feedback, but the SKB should be freed separately with free_txskb(). johannes
Re: [PATCH 1/2] mtd: nand: add generic helpers to check, match, maximize ECC settings
On Thu, 18 May 2017 15:27:11 +0900
Masahiro Yamada wrote:
> Hi Boris,
>
>
>
> 2017-05-15 20:54 GMT+09:00 Boris Brezillon
> :
> > Hi Masahiro,
> >
> > Sorry for the late reply.
> >
> > On Mon, 8 May 2017 12:40:47 +0900
> > Masahiro Yamada wrote:
> >
> >> Hi Boris,
> >>
> >>
> >> 2017-04-29 1:32 GMT+09:00 Boris Brezillon
> >> :
> >>
> >> >> + for (setting = caps->ecc_settings; setting->step; setting++) {
> >> >> + /* If chip->ecc.size is already set, respect it. */
> >> >> + if (chip->ecc.size && setting->step != chip->ecc.size)
> >> >> + continue;
> >> >> +
> >> >> + /* If chip->ecc.strength is already set, respect it. */
> >> >> + if (chip->ecc.strength &&
> >> >> + setting->strength != chip->ecc.strength)
> >> >> + continue;
> >> >
> >> > Hm, I don't get it. If chip->ecc.strength and chip->ecc.size are
> >> > explicitly set, you should just call nand_check_ecc_caps() and skip
> >> > nand_try_to_match_ecc_req(). Why would you call
> >> > nand_try_to_match_ecc_req() in this case?
> >>
> >>
> >> I want to call this function if
> >> ecc.size is specified but ecc.strength is not
> >> (or vice versa).
> >
> > That's not a valid combination. I accepted the case where
> > nand-ecc-step-size is not defined in the DT just because sometime you
> > only have one possible setting which is imposed by the controller. In
> > this case ecc.size should be explicitly set by the driver not left to 0.
> >
> >>
> >>
> >> If both ecc.size and ecc.strength are already specified,
> >> you are right, no need to call this function.
> >> This function can check the sanity of the specified
> >> combination of (step, strength), but this is the same
> >> as what nand_check_ecc_caps() does.
>
>
> I am working on the next version because I really need to
> merge all of my Denali controller patches for my SoCs.
Okay.
>
>
> One question about this part.
>
>
>/* If chip->ecc.size is already set, respect it. */
>if (chip->ecc.size && step_size != chip->ecc.size)
>continue;
>
> Does this make sense for nand_try_to_maximize_ecc()?
>
> (In other words, can nand-ecc-maximize stand together with
> nand-ecc-step-size?)
It could make sense if one wants to maximize the strength for a
specific step-size, but most of the time the user will let the driver
choose the best step-size+strength pair.
Re: [PATCH 03/23] uuid: remove uuid_be defintions from the uapi header
On Thu, 2017-05-18 at 08:26 +0200, Christoph Hellwig wrote:
> We don't use uuid_be and the UUID_BE constants in any uapi headers, so make
> them private to the kernel.
On the assumption that no user program uses them?
Is that a safe assumption?
> diff --git a/include/uapi/linux/uuid.h b/include/uapi/linux/uuid.h
> index 3738e5fb6a4d..0099756c4bac 100644
> --- a/include/uapi/linux/uuid.h
> +++ b/include/uapi/linux/uuid.h
> @@ -24,10 +24,6 @@ typedef struct {
> __u8 b[16];
> } uuid_le;
>
> -typedef struct {
> - __u8 b[16];
> -} uuid_be;
> -
> #define UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
> ((uuid_le) \
> {{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \
> @@ -35,20 +31,8 @@ typedef struct {
> (c) & 0xff, ((c) >> 8) & 0xff,\
> (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }})
>
> -#define UUID_BE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
> -((uuid_be) \
> -{{ ((a) >> 24) & 0xff, ((a) >> 16) & 0xff, ((a) >> 8) & 0xff, (a) & 0xff, \
> - ((b) >> 8) & 0xff, (b) & 0xff,\
> - ((c) >> 8) & 0xff, (c) & 0xff,\
> - (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }})
> -
> #define NULL_UUID_LE \
> UUID_LE(0x, 0x, 0x, 0x00, 0x00, 0x00, 0x00, \
> 0x00, 0x00, 0x00, 0x00)
>
> -#define NULL_UUID_BE \
> - UUID_BE(0x, 0x, 0x, 0x00, 0x00, 0x00, 0x00, \
> - 0x00, 0x00, 0x00, 0x00)
> -
> -
> #endif /* _UAPI_LINUX_UUID_H_ */
Re: [PATCH 03/23] uuid: remove uuid_be defintions from the uapi header
On Thu, May 18, 2017 at 12:12:45AM -0700, Joe Perches wrote: > On Thu, 2017-05-18 at 08:26 +0200, Christoph Hellwig wrote: > > We don't use uuid_be and the UUID_BE constants in any uapi headers, so make > > them private to the kernel. > > On the assumption that no user program uses them? > Is that a safe assumption? It's not a userspace ABI, so by defintion it does not break an existing user program. If someone was using it they should be using uuid_t from libuuid instead, as that gives them the routines to deal with it.
Re: [PATCH] sched: remove sched_find_first_bit()
* Yury Norov wrote: > On Tue, May 16, 2017 at 10:30:42AM +0200, Ingo Molnar wrote: > > > > * Yury Norov wrote: > > > > > I collected about 700 results in dmesg, and took 600 fastest. > > > For the vanilla kernel, the average value is 368, and for patched > > > kernel it is 388. It's 5% slower. But the standard deviation is > > > really big for both series' - 131 and 106 cycles respectively, which > > > is ~ 30%. And so, my conclusion is: there's no benefit in using > > > sched_find_first_bit() comparing to find_first_bit(). > > > > Erm, so you in essence claim: > > > > "according to measurements the new code is 5% slower, with a high, 30% > > stddev, hence the new code is better!" > > > > Basic logic fail... > > > > Thanks, > > > > Ingo > > No, in essence I claim that scatter is so big (in both cases, and in > case of vanilla kernel even bigger) that 5% is not a meaningful > difference. To be specific - new measured value is inside the > confidence interval of previous one. Firstly, the high spread is due to the poor measurement method: by increasing the number of measurements the standard deviation can be reduced. Secondly, and most importantly, the claim you made based on the numbers is simply false: > > > And so, my conclusion is: there's no benefit in using > > > sched_find_first_bit() comparing to find_first_bit(). you _measured no benefit_, and in fact the result you got is leaning towards it being a benefit. When doing a proper measurement it might strengthen, vanish or turn around - we simply don't know. Thanks, Ingo
Re: sparse on scripts/kconfig/*.c
On Wed, May 17, 2017 at 07:53:35PM -0700, Randy Dunlap wrote: > > I did a 'git pull' for updates. On the rebuild, I get this error: > > macro_table.c:30:31: fatal error: cwchash/hashtable.h: No such file or > directory > #include "cwchash/hashtable.h" > > My problem? > > thanks for your help. That's weird. I haven't touched that code in years so I can't imagine what's going on. :/ My fresh clone works. regards, dan carpenter
Re: [PATCH] drm/amd/powerplay: ensure loop does not wraparound on decrement
Am 17.05.2017 20:13, schrieb Colin King:
> From: Colin Ian King
>
> The current for loop decrements i when it is zero and this causes
> a wrap-around back to ~0 because i is unsigned. In the unlikely event
> that mask is 0, the loop will run forever. Fix this so we can't loop
> forever.
>
> Detected by CoverityScan, CID#1435469 ("Unsigned compared against 0")
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index ad30f5d3a10d..d92c9b9b15be 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> @@ -4199,7 +4199,7 @@ static int vega10_force_clock_level(struct pp_hwmgr
> *hwmgr,
> }
> data->smc_state_table.gfx_boot_level = i;
>
> - for (i = 31; i >= 0; i--) {
> + for (i = 32; --i; ) {
> if (mask & (1 << i))
> break;
> }
nitpicking:
we notices at several points that programmers are bad at counting backwards.
Is there a reason not to start with i=0 ?
re,
wh
[PATCH v6 0/9] AXP803 PMIC support for Pine64
The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus support added). This patchset adds support for it and enabled it in Pine64 device tree. Some parts of this patchset is already applied, including basical AXP803 MFD code and A64 RSB device node. Thus this patchset is now still two parts, but a bit different to older revisions: - Part1: from PATCH 1/9 to PATCH 4/9, which focus on enabling AXP803 in the device tree: the R_INTC interrupt controller (for the NMI line, which is connected to AXP803 on Pine64), and finally the basical AXP803 node. - Part2: from PATCH 5/9 to PATCH 9/9, which are enabling the regulator function of the AXP803 PMIC. Finally Wi-Fi function is added as a usage of regulators function. PATCH 1 adds device tree binding of A64 R_INTC. PATCH 2 really adds support for A64 R_INTC in NMI driver. PATCH 3 adds R_INTC node in A64 device tree. PATCH 4 adds AXP803 node to the Pine64 device tree by using already applied drivers/bindings. PATCH 5 adds support for AXP803 regulators in AXP20x regulatoe driver. (The binding is already applied) PATCH 6 enables the AXP803 regulator cell in MFD driver. PATCH 7 adds a DTSI file for AXP803, like other older AXP PMICs. PATCH 8 enables AXP803 regulators in Pine64 device tree. PATCH 9 enables Wi-Fi for Pine64. Icenowy Zheng (9): irqchip/sunxi-nmi: add A64 R_INTC to the binding doc irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC arm64: allwinner: a64: add NMI (R_INTC) controller on A64 arm64: allwinner: a64: add AXP803 node to Pine64 device tree regulator: axp20x-regulator: add support for AXP803 mfd: axp20x: add axp20x-regulator cell for AXP803 arm64: allwinner: a64: add DTSI file for AXP803 PMIC arm64: allwinner: a64: enable AXP803 regulators for Pine64 arm64: allwinner: a64: enable Wi-Fi for Pine64 .../interrupt-controller/allwinner,sunxi-nmi.txt | 7 +- arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 136 ++ arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++ drivers/irqchip/irq-sunxi-nmi.c| 13 ++ drivers/mfd/axp20x.c | 3 +- drivers/regulator/axp20x-regulator.c | 153 ++--- include/linux/mfd/axp20x.h | 37 + 8 files changed, 482 insertions(+), 25 deletions(-) create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi -- 2.12.2
[PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
The A31 NMI driver seems to be using wrong base address. As we're going to convert to use a correct NMI base address (and correctly name it to R_INTC as the datasheet suggests), add a new compatible string for the "correct" R_INTC, which we will use for A64 SoC. Signed-off-by: Icenowy Zheng Acked-by: Rob Herring --- Changes in v6: - Added Rob's ACK. .../bindings/interrupt-controller/allwinner,sunxi-nmi.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt index 81cd3692405e..fea0c6a6211f 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt @@ -3,8 +3,11 @@ Allwinner Sunxi NMI Controller Required properties: -- compatible : should be "allwinner,sun7i-a20-sc-nmi" or - "allwinner,sun6i-a31-sc-nmi" or "allwinner,sun9i-a80-nmi" +- compatible : should be one of: + "allwinner,sun6i-a31-sc-nmi" + "allwinner,sun7i-a20-sc-nmi" + "allwinner,sun9i-a80-nmi" + "allwinner,sun50i-a64-r-intc" - reg : Specifies base physical address and size of the registers. - interrupt-controller : Identifies the node as an interrupt controller - #interrupt-cells : Specifies the number of cells needed to encode an -- 2.12.2
[PATCH v6 4/9] arm64: allwinner: a64: add AXP803 node to Pine64 device tree
The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.
Add its device node.
Signed-off-by: Icenowy Zheng
---
Changes in v6:
- Rebase on next-20170517.
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 7c533b6d4ba9..36001884ed33 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -107,6 +107,17 @@
status = "okay";
};
+&r_rsb {
+ status = "okay";
+
+ axp803: pmic@3a3 {
+ compatible = "x-powers,axp803";
+ reg = <0x3a3>;
+ interrupt-parent = <&r_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
/* On Exp and Euler connectors */
&uart0 {
pinctrl-names = "default";
--
2.12.2
Re: [PATCH] X86: don't report PAT on CPUs that don't support it
* Mikulas Patocka wrote: > On Tue, 16 May 2017, H. Peter Anvin wrote: > > > On 04/18/17 12:07, Mikulas Patocka wrote: > > > > > > However, on AMD K6-3 CPU, the processor initialization code never calls > > > pat_init() and so __pat_enabled stays 1 and the function pat_enabled() > > > returns true, even though the K6-3 CPU doesn't support PAT. > > > > > > > OK, now I'm wondering: are you actually *using* said K6-3 machine, and > > I use it for playing music, browsing with the links browser and connecting > to other machines with ssh. That machine is slow but it is completely > quiet. > > It is also good to run my own software on a slow CPU to make sure that > there are no obvious inefficiencies. > > > if so, are you actually dependent on write combining on it? The reason > > Those K6-3 MTRRs improve framebuffer write throughput by 33%. > > > I'm asking is because I would personally like to completely remove the > > support for using MTRRs to create WC mappings, as it only affects a > > handful of ancient CPUs: Pentium Pro, Pentium II, K6-*, and possibly > > some Cyrix/Centaur part. Earlier CPUs didn't have WC, but could set WB, > > WT or UC via the page tables without needing the PAT MSR, and newer CPUs > > have PAT. > > MTRRs are also needed on Pentium 3, Core Solo and Core Duo due to an > erratum that makes it not possible to set WC with PAT. See the comment > before "clear_cpu_cap(c, X86_FEATURE_PAT)" in early_init_intel(). Ok, I'm inclined to apply your regression fix - hpa do you concur? Thanks, Ingo
[PATCH v6 7/9] arm64: allwinner: a64: add DTSI file for AXP803 PMIC
As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
like the old DTSI files for AXP20x/22x, for the common parts of the
PMIC.
Signed-off-by: Icenowy Zheng
Acked-by: Mark Brown
---
Changes in v5:
- Added Mark Brown's ACK.
Changes in v4:
- Re-sorted the nodes.
arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++
1 file changed, 150 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi
b/arch/arm64/boot/dts/allwinner/axp803.dtsi
new file mode 100644
index ..ff8af52743ff
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2017 Icenowy Zheng
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP803 Integrated Power Management Chip
+ * http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf
+ */
+
+&axp803 {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ regulators {
+ /* Default work frequency for buck regulators */
+ x-powers,dcdc-freq = <3000>;
+
+ reg_aldo1: aldo1 {
+ regulator-name = "aldo1";
+ };
+
+ reg_aldo2: aldo2 {
+ regulator-name = "aldo2";
+ };
+
+ reg_aldo3: aldo3 {
+ regulator-name = "aldo3";
+ };
+
+ reg_dc1sw: dc1sw {
+ regulator-name = "dc1sw";
+ };
+
+ reg_dcdc1: dcdc1 {
+ regulator-name = "dcdc1";
+ };
+
+ reg_dcdc2: dcdc2 {
+ regulator-name = "dcdc2";
+ };
+
+ reg_dcdc3: dcdc3 {
+ regulator-name = "dcdc3";
+ };
+
+ reg_dcdc4: dcdc4 {
+ regulator-name = "dcdc4";
+ };
+
+ reg_dcdc5: dcdc5 {
+ regulator-name = "dcdc5";
+ };
+
+ reg_dcdc6: dcdc6 {
+ regulator-name = "dcdc6";
+ };
+
+ reg_dldo1: dldo1 {
+ regulator-name = "dldo1";
+ };
+
+ reg_dldo2: dldo2 {
+ regulator-name = "dldo2";
+ };
+
+ reg_dldo3: dldo3 {
+ regulator-name = "dldo3";
+ };
+
+ reg_dldo4: dldo4 {
+ regulator-name = "dldo4";
+ };
+
+ reg_eldo1: eldo1 {
+ regulator-name = "eldo1";
+ };
+
+ reg_eldo2: eldo2 {
+ regulator-name = "eldo2";
+ };
+
+ reg_eldo3: eldo3 {
+ regulator-name = "eldo3";
+ };
+
+ reg_fldo1: fldo1 {
+ regulator-name = "fldo1";
+ };
+
+ reg_fldo2: fldo2 {
+
[PATCH v6 5/9] regulator: axp20x-regulator: add support for AXP803
AXP803 PMIC also have a series of regulators (DCDCs and LDOs)
controllable via I2C/RSB bus.
Add support for them.
Signed-off-by: Icenowy Zheng
Acked-by: Chen-Yu Tsai
---
Changes in v4:
- Fixed somewhere which mention AXP806 before 803.
Changes in v2:
- Place AXP803 codes before AXP806/809 ones.
- Fixed some errors in regulator description.
- Reuse AXP803 DLDO2 range for AXP806 CLDO2 & AXP809 DLDO1.
drivers/regulator/axp20x-regulator.c | 153 ++-
include/linux/mfd/axp20x.h | 37 +
2 files changed, 168 insertions(+), 22 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 0b9d4e3e52c7..e2608fe770b9 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,82 @@ static const struct regulator_desc
axp22x_drivevbus_regulator = {
.ops= &axp20x_ops_sw,
};
+static const struct regulator_linear_range axp803_dcdc234_ranges[] = {
+ REGULATOR_LINEAR_RANGE(50, 0x0, 0x46, 1),
+ REGULATOR_LINEAR_RANGE(122, 0x47, 0x4b, 2),
+};
+
+static const struct regulator_linear_range axp803_dcdc5_ranges[] = {
+ REGULATOR_LINEAR_RANGE(80, 0x0, 0x20, 1),
+ REGULATOR_LINEAR_RANGE(114, 0x21, 0x44, 2),
+};
+
+static const struct regulator_linear_range axp803_dcdc6_ranges[] = {
+ REGULATOR_LINEAR_RANGE(60, 0x0, 0x32, 1),
+ REGULATOR_LINEAR_RANGE(112, 0x33, 0x47, 2),
+};
+
+/* AXP806's CLDO2 and AXP809's DLDO1 shares the same range */
+static const struct regulator_linear_range axp803_dldo2_ranges[] = {
+ REGULATOR_LINEAR_RANGE(70, 0x0, 0x1a, 10),
+ REGULATOR_LINEAR_RANGE(340, 0x1b, 0x1f, 20),
+};
+
+static const struct regulator_desc axp803_regulators[] = {
+ AXP_DESC(AXP803, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
+AXP803_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(0)),
+ AXP_DESC_RANGES(AXP803, DCDC2, "dcdc2", "vin2", axp803_dcdc234_ranges,
+ 76, AXP803_DCDC2_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(1)),
+ AXP_DESC_RANGES(AXP803, DCDC3, "dcdc3", "vin3", axp803_dcdc234_ranges,
+ 76, AXP803_DCDC3_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(2)),
+ AXP_DESC_RANGES(AXP803, DCDC4, "dcdc4", "vin4", axp803_dcdc234_ranges,
+ 76, AXP803_DCDC4_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(3)),
+ AXP_DESC_RANGES(AXP803, DCDC5, "dcdc5", "vin5", axp803_dcdc5_ranges,
+ 68, AXP803_DCDC5_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(4)),
+ AXP_DESC_RANGES(AXP803, DCDC6, "dcdc6", "vin6", axp803_dcdc6_ranges,
+ 72, AXP803_DCDC6_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(5)),
+ /* secondary switchable output of DCDC1 */
+ AXP_DESC_SW(AXP803, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+ BIT(7)),
+ AXP_DESC(AXP803, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(5)),
+ AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(6)),
+ AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(7)),
+ AXP_DESC(AXP803, DLDO1, "dldo1", "dldoin", 700, 3300, 100,
+AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(3)),
+ AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin", axp803_dldo2_ranges,
+ 32, AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
+ BIT(4)),
+ AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
+AXP22X_DLDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
+ AXP_DESC(AXP803, DLDO4, "dldo4", "dldoin", 700, 3300, 100,
+AXP22X_DLDO4_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(6)),
+ AXP_DESC(AXP803, ELDO1, "eldo1", "eldoin", 700, 1900, 50,
+AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
+ AXP_DESC(AXP803, ELDO2, "eldo2", "eldoin", 700, 1900, 50,
+AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
+ AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
+AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
+ AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
+AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
+ AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
+AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
+ AXP_DESC_IO(AXP803, LDO_IO0, "ldo-io0", "ips", 700, 3300, 100,
+ AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
+ AXP22X_IO_ENABLED, AXP2
[PATCH v6 6/9] mfd: axp20x: add axp20x-regulator cell for AXP803
As axp20x-regulator now supports AXP803, add a cell for it.
Signed-off-by: Icenowy Zheng
Acked-by: Chen-Yu Tsai
---
Changes in v5:
- Removed wrong snippet.
Changes in v4:
- Added a trailing comma for new cell, for easier further cell addition.
Changes in v3:
- Make the new cell one-liner.
drivers/mfd/axp20x.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 1dc6235778eb..917b6ddc4f15 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
.name = "axp20x-pek",
.num_resources = ARRAY_SIZE(axp803_pek_resources),
.resources = axp803_pek_resources,
- }
+ },
+ { .name = "axp20x-regulator" },
};
static struct mfd_cell axp806_cells[] = {
--
2.12.2
[PATCH v6 8/9] arm64: allwinner: a64: enable AXP803 regulators for Pine64
Add support of AXP803 regulators in the Pine64 device tree, in order to
enable many future functionalities, e.g. Wi-Fi.
Signed-off-by: Icenowy Zheng
---
Changes in v6:
- Rebased on next-20170517.
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +
1 file changed, 109 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 36001884ed33..40921bacb39c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -118,6 +118,115 @@
};
};
+#include "axp803.dtsi"
+
+®_aldo1 {
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ regulator-name = "vcc-csi";
+};
+
+®_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-pl";
+};
+
+®_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <270>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+®_dc1sw {
+ regulator-name = "vcc-phy";
+};
+
+®_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-3v3";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <130>;
+ regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+®_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-name = "vcc-dram";
+};
+
+®_dcdc6 {
+ regulator-always-on;
+ regulator-min-microvolt = <110>;
+ regulator-max-microvolt = <110>;
+ regulator-name = "vdd-sys";
+};
+
+®_dldo1 {
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-hdmi";
+};
+
+®_dldo2 {
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-mipi";
+};
+
+®_dldo3 {
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "avdd-csi";
+};
+
+®_dldo4 {
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-wifi";
+};
+
+®_eldo1 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-name = "cpvdd";
+};
+
+®_eldo3 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-name = "vdd-1v8-csi";
+};
+
+®_fldo1 {
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-name = "vcc-1v2-hsic";
+};
+
+®_fldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <110>;
+ regulator-max-microvolt = <110>;
+ regulator-name = "vdd-cpus";
+};
+
+®_rtc_ldo {
+ regulator-name = "vcc-rtc";
+};
+
/* On Exp and Euler connectors */
&uart0 {
pinctrl-names = "default";
--
2.12.2
[PATCH v6 9/9] arm64: allwinner: a64: enable Wi-Fi for Pine64
The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
one provides I/O voltage).
Add device node for it.
Although the Wi-Fi module is an external module which should be inserted
to a header, according to my personal talk with TL Lim, he does not want
this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm as
other GPIO headers).
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 40921bacb39c..6e43e2c07025 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -68,6 +68,11 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+ };
};
&ehci0 {
@@ -99,6 +104,17 @@
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_dldo4>;
+ vqmmc-supply = <®_eldo1>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ non-removable;
+ bus-width = <4>;
+ status = "okay";
+};
+
&ohci0 {
status = "okay";
};
--
2.12.2
Re: [PATCH 3/3] arm: dts: rk322x: add watchdog device node.
Am Donnerstag, 18. Mai 2017, 11:58:04 CEST schrieb Frank Wang: > Hi, > > Sorry, I forgot to declare that this change required below patch on > patchwork. > https://patchwork.kernel.org/patch/9703945/ I found that yesterday already and brought everything in the correct order when applying :-) Heiko > > > BR. > Frank > > On 2017/5/18 11:18, kbuild test robot wrote: > > Hi Frank, > > > > [auto build test ERROR on rockchip/for-next] > > [also build test ERROR on v4.12-rc1 next-20170517] > > [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/Frank-Wang/add-and-fix-some-devi > > ce-node-for-rk322x-SoC/20170518-081958 base: > > https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git > > for-next config: arm-at91_dt_defconfig (attached as .config) > > compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 > > > > reproduce: > > wget > > https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/ma > > ke.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross > > # save the attached .config to linux build tree > > make.cross ARCH=arm > > > > All errors (new ones prefixed by >>): > >>> Error: arch/arm/boot/dts/rk322x.dtsi:286.18-19 syntax error > >>> > > FATAL ERROR: Unable to parse input tree > > > > --- > > 0-DAY kernel test infrastructureOpen Source Technology > > Center https://lists.01.org/pipermail/kbuild-all Intel > > Corporation
[PATCH v6 3/9] arm64: allwinner: a64: add NMI (R_INTC) controller on A64
Allwinner A64 SoC features a R_INTC controller, which controls the NMI
line, and this interrupt line is usually connected to the AXP PMIC.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Changes in v4:
- Changes it to use R_INTC binding and change node label to r_intc.
- Fixed MMIO region.
- Dropped Chen-Yu's ACK due to big change.
Changes in v2:
- Added Chen-Yu's ACK.
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 90dc4ec79485..45c7c3145248 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -445,6 +445,14 @@
;
};
+ r_intc: interrupt-controller@1f00c00 {
+ compatible = "allwinner,sun50i-a64-r-intc";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x01f00c00 0x400>;
+ interrupts = ;
+ };
+
r_ccu: clock@1f01400 {
compatible = "allwinner,sun50i-a64-r-ccu";
reg = <0x01f01400 0x100>;
--
2.12.2
[PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC
Add support for the newly imported compatible for the A64 R_INTC in
irq-sunxi-nmi driver.
Signed-off-by: Icenowy Zheng
---
Changes in v5:
- Fix A64 R_INTC compatible.
drivers/irqchip/irq-sunxi-nmi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
index 668730c5cb66..5559c1d593bf 100644
--- a/drivers/irqchip/irq-sunxi-nmi.c
+++ b/drivers/irqchip/irq-sunxi-nmi.c
@@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs = {
.enable = 0x04,
};
+static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
+ .ctrl = 0x0c,
+ .pend = 0x10,
+ .enable = 0x40,
+};
+
static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
u32 val)
{
@@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct device_node
*node,
return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
}
IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi", sun9i_nmi_irq_init);
+
+static int __init sun50i_nmi_irq_init(struct device_node *node,
+struct device_node *parent)
+{
+ return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
+}
+IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
sun50i_nmi_irq_init);
--
2.12.2
Re: [PATCH 7/8] clocksource/drivers/fttmr010: Merge Moxa into FTTMR010
Hey Linus, On Wed, May 17, 2017 at 10:05 PM, Linus Walleij wrote: > This merges the Moxa Art timer driver into the Faraday FTTMR010 > driver and replaces all Kconfig symbols to use the Faraday > driver instead. We are now so similar that the drivers can > be merged by just adding a few lines to the Faraday timer. Nice work! I gave this a spin on hardware and it didn't work :( > > Differences: > > - The Faraday driver explicitly sets the counter to count > upwards for the clocksource, removing the need for the > clocksource core to invert the value. > > - The Faraday driver also handles sched_clock() > > I am just guessing at the way the Aspeed has moved the count > up/down bits to bits 3, 8 and 11 (keeping the bits pertaining > to a certain timer together), so this really needs testing on > the Aspeed. I'm guessing like this because it is what I would > have done, if I was rewriting some VHDL/Verilog to extend > these three timers to 8 (as the Aspeed apparently does). > > After this we have one driver for all three SoCs and a generic > Faraday FTTMR010 timer driver, which is nice. > > Cc: Joel Stanley > Cc: Jonas Jensen > Signed-off-by: Linus Walleij > --- > ARM SoC folks: please ACK this so it can be merged with in the > clocksource subsystem once it works. > > Joel: it would be super if you can test this. If you have some > vendor tree or similar that actually indicates where the > up/down counter bits are it's even better, but I'm hoping that > this half-assed guesswork will JustWork(TM) (yeah, famous > last words, sorry...) Thanks for the rework! Unfortunately the Aspeed IP does not have bits to control the direction of counting, and the timers only count down. Bits 3, 7 and 11 are marked reserved in the data sheet. Can you rework the patch to count down? As an aside, we have a pretty decent model for the Aspeed SoCs in Qemu. If you want to use it to smoketest your rework: $ qemu-system-arm -m 512 -M ast2500-evb -nodefaults -nographic -serial stdio -kernel arch/arm/boot/zImage -dtb arch/arm/boot/dts/aspeed-ast2500-evb.dtb I tested with Ubuntu's qemu v2.8. It looks like we have a bug when the kernel tries to use the clock the way your driver works, so we will look at that. It does function properly for the current upstream code. Cheers, Joel > --- > arch/arm/mach-aspeed/Kconfig | 2 +- > arch/arm/mach-moxart/Kconfig | 2 +- > drivers/clocksource/Kconfig | 7 - > drivers/clocksource/Makefile | 1 - > drivers/clocksource/moxart_timer.c | 256 > --- > drivers/clocksource/timer-fttmr010.c | 52 +-- > 6 files changed, 46 insertions(+), 274 deletions(-) > delete mode 100644 drivers/clocksource/moxart_timer.c > > diff --git a/arch/arm/mach-aspeed/Kconfig b/arch/arm/mach-aspeed/Kconfig > index f3f8c5c658db..2d5570e6e186 100644 > --- a/arch/arm/mach-aspeed/Kconfig > +++ b/arch/arm/mach-aspeed/Kconfig > @@ -4,7 +4,7 @@ menuconfig ARCH_ASPEED > select SRAM > select WATCHDOG > select ASPEED_WATCHDOG > - select MOXART_TIMER > + select FTTMR010_TIMER > select MFD_SYSCON > select PINCTRL > help > diff --git a/arch/arm/mach-moxart/Kconfig b/arch/arm/mach-moxart/Kconfig > index 70db2abf6163..a4a91f9a3301 100644 > --- a/arch/arm/mach-moxart/Kconfig > +++ b/arch/arm/mach-moxart/Kconfig > @@ -4,7 +4,7 @@ menuconfig ARCH_MOXART > select CPU_FA526 > select ARM_DMA_MEM_BUFFERABLE > select FARADAY_FTINTC010 > - select MOXART_TIMER > + select FTTMR010_TIMER > select GPIOLIB > select PHYLIB if NETDEVICES > help > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig > index 545d541ae20e..1b22ade4c8f1 100644 > --- a/drivers/clocksource/Kconfig > +++ b/drivers/clocksource/Kconfig > @@ -188,13 +188,6 @@ config ATLAS7_TIMER > help > Enables support for the Atlas7 timer. > > -config MOXART_TIMER > - bool "Moxart timer driver" if COMPILE_TEST > - depends on GENERIC_CLOCKEVENTS > - select CLKSRC_MMIO > - help > - Enables support for the Moxart timer. > - > config MXS_TIMER > bool "Mxs timer driver" if COMPILE_TEST > depends on GENERIC_CLOCKEVENTS > diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile > index 2b5b56a6f00f..cf0c30b6ec1f 100644 > --- a/drivers/clocksource/Makefile > +++ b/drivers/clocksource/Makefile > @@ -26,7 +26,6 @@ obj-$(CONFIG_ORION_TIMER) += time-orion.o > obj-$(CONFIG_BCM2835_TIMER)+= bcm2835_timer.o > obj-$(CONFIG_CLPS711X_TIMER) += clps711x-timer.o > obj-$(CONFIG_ATLAS7_TIMER) += timer-atlas7.o > -obj-$(CONFIG_MOXART_TIMER) += moxart_timer.o > obj-$(CONFIG_MXS_TIMER)+= mxs_timer.o > obj-$(CONFIG_CLKSRC_PXA) += pxa_timer.o > obj-$(CONFIG_PRIMA2_TIMER) += timer-prima2.o > diff --git a/drivers/clocksource/moxart_timer.c > b/drivers/clocksource/
Re: Watchdog detected hard lockup.
Hello Sumit, please Cc kernel mailing list. Cc Petr, Peter, Steven, kernel-list On (05/18/17 12:22), Sumit Gemini wrote: >Hi Sergey, > > I read your comment on [1]https://lkml.org/lkml/2016/9/27/279. Here you were > talking about using alt_printk instead of printk. > I Got this crash, could this crash related to call printk recursively? > Could you please tell me why i got this crash? Do you see any suspicious > entry here? > > [2324956.184374] Kernel panic - not syncing: Watchdog detected hard LOCKUP > on cpu 1 > [2324956.184374] Pid: 0, comm: kworker/0:0 Tainted: P > 3.1.10-gb20-default #1 > [2324956.184374] Call Trace: > [2324956.184374] [] dump_trace+0x98/0x223 > [2324956.184374] [] dump_stack+0x69/0x6f > [2324956.184374] [] panic+0xa4/0x1b4 > [2324956.184374] [] watchdog_overflow_callback+0x79/0x9e > [2324956.184374] [] __perf_event_overflow+0xf9/0x185 > [2324956.184374] [] intel_pmu_handle_irq+0x15d/0x1be > [2324956.184374] [] perf_event_nmi_handler+0x3e/0x87 > [2324956.184374] [] notifier_call_chain+0x2e/0x5b > [2324956.184374] [] __atomic_notifier_call_chain+0x3a/0x4d > [2324956.184374] [] notify_die+0x2d/0x32 > [2324956.184374] [] default_do_nmi+0x29/0x1b5 > [2324956.184374] [] do_nmi+0x47/0x6f > [2324956.184374] [] nmi+0x20/0x30 > [2324956.184374] [] arch_local_irq_save+0x1/0x17 > [2324956.184374] [] _raw_spin_lock_irqsave+0xf/0x39 > [2324956.184374] [] down_trylock+0xb/0x29 > [2324956.184374] [] console_trylock+0xf/0x47 > [2324956.184374] [] console_unlock+0x100/0x129 > [2324956.184374] [] vprintk+0x348/0x394 > [2324956.184374] [] printk+0x53/0x58 > [2324956.184374] [] ip_handle_martian_source+0x6d/0xf6 > [2324956.184374] [] ip_route_input_slow+0x45d/0x462 > [2324956.184374] [] ip_route_input_common+0x217/0x231 > [2324956.184374] [] arp_process+0x181/0x4ac > [2324956.184374] [] __netif_receive_skb+0x317/0x36b > [2324956.184374] [] __netif_receive_skb+0x266/0x36b > [2324956.184374] [] netif_receive_skb+0x7e/0x84 > [2324956.184374] [] napi_skb_finish+0x1c/0x31 > [2324956.184374] [] igb_clean_rx_irq+0x30d/0x39e [igb] > [2324956.184374] [] igb_poll+0x4e/0x74 [igb] > [2324956.184374] [] net_rx_action+0x65/0x178 > [2324956.184374] [] __do_softirq+0xb2/0x19d > [2324956.184374] [] call_softirq+0x1c/0x30 > [2324956.184374] [] do_softirq+0x3c/0x7b > [2324956.184374] [] irq_exit+0x3c/0xac > [2324956.184374] [] do_IRQ+0x82/0x98 > [2324956.184374] [] common_interrupt+0x6e/0x6e > [2324956.184374] [] intel_idle+0xdd/0x104 > [2324956.184374] [] cpuidle_idle_call+0xdf/0x181 > [2324956.184374] [] cpu_idle+0x56/0xa9 > > I shell be very greatful to you. > your CPU1 couldn't acquire console_sem spin_lock down_trylock() raw_spin_lock_irqsave(&sem->lock, flags); and _probably_ looped on it with local IRQs disabled long enough to disappoint the NMI watchdog, which eventually declared a hard lockup condition. but I'm not entirely sure it stuck looping on sem->lock, it could be the case that your net IRQ took too much time and by the time NMI declared hard lockup we were just unlucky to execute down_trylock(). on the other hand, the fact that you see IRQ ip_handle_martian_source() printk() console_unlock() is already not really good. first of all, you had hit ip_route_input slow path; second, you hit pr_warn()/pr_err or print_hex_dump(), so the kernel was reporting you something abnormal. printk() invoked from IRQ context managed to acquire the console_sem and spent some time printing the messages to the serial console, console_unlock() in the call trace. which sometimes can be a call for troubles. printk() can't always be safely called from atomic contexts, just because of cases like this. I don't know how big ->hard_header_len can be, but that print_hex_dump() can take some extra time. if you also happened to have other printk messages coming from other CPUs in the meantime, then CPU1 had have to spent even more time in console_unlock() printing those messages; from IRQ handler. hm, this doesn't look to me as a printk recursion, at least after a quick look. either, a) something was holding sem->lock, can't tell what exactly (unlikely) or b) your IRQ handler just happened to execute way too long. given that there was printk()->console_unlock() and probably a hex dump of skb, this is a more likely root cause. -ss
Re: races between blk-cgroup operations and I/O scheds in blk-mq (?)
> Il giorno 17 mag 2017, alle ore 21:12, Tejun Heo ha scritto: > > Hello, > > On Mon, May 15, 2017 at 09:49:13PM +0200, Paolo Valente wrote: >> So, unless you tell me that there are other races I haven't seen, or, >> even worse, that I'm just talking nonsense, I have thought of a simple >> solution to address this issue without resorting to the request_queue >> lock: further caching, on blkg lookups, the only policy or blkg data >> the scheduler may use, and access this data directly when needed. By >> doing so, the issue is reduced to the occasional use of stale data. >> And apparently this already happens, e.g., in cfq when it uses the >> weight of a cfq_queue associated with a process whose group has just >> been changed (and for which a blkg_lookup has not yet been invoked). >> The same should happen when cfq invokes cfq_log_cfqq for such a >> cfq_queue, as this function prints the path of the group the bfq_queue >> belongs to. > > I haven't studied the code but the problem sounds correct to me. All > of blkcg code assumes the use of rq lock. And, yeah, none of the hot > paths requires strong synchornization. All the actual management > operations can be synchronized separately and the hot lookup path can > be protected with rcu and maybe percpu reference counters. > Great, thanks for this ack. User reports do confirm the problem, and, so far, the effectiveness of a solution I have implemented. I'm finalizing the patch for submission. Thanks, Paolo > Thanks. > > -- > tejun
答复: [PATCH 1/2] PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC
-邮件原件-
发件人: arndbergm...@gmail.com [mailto:arndbergm...@gmail.com] 代表 Arnd Bergmann
发送时间: 2017年5月18日 4:29
收件人: songxiaowei
抄送: Bjorn Helgaas; Kishon; Jingoo Han; Tomasz Nowicki; Keith Busch;
niklas.cas...@axis.com; Duc Dang; liudongdong (C); Chenfeng (puck); Guodong Xu;
Wangbinghui; Suzhuangluan; Linux Kernel Mailing List; linux-pci
主题: Re: [PATCH 1/2] PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC
On Fri, May 12, 2017 at 3:51 AM, Song Xiaowei wrote:
> From: songxiaowei
Looks good overall, just a few details:
Please fix your ~/.gitconfig to contain the same real name ("Song Xiaowei"
instead of "songxiaowei") that you use for sending the emails.
> +
> +static int kirin_pcie_phy_init(struct kirin_pcie *kirin_pcie) {
...
> + reg_val = kirin_apb_phy_readl(kirin_pcie, 0x400);
> + while (reg_val & pipe_clk_stable) {
> + udelay(100);
> + if (time == 0) {
> + dev_err(kirin_pcie->pci->dev, "PIPE clk is not
> stable\n");
> + return -EINVAL;
> + }
> + time--;
> + reg_val = kirin_apb_phy_readl(kirin_pcie, 0x400);
> + }
If this is not called with interrupts disabled, please use a sleeping function
(e.g. msleep(1)) as the delay and compare against ktime_before() to see how
much total time has expired when waiting for a timeout, instead of using a
counter.
Since the time of pipe clk stable is from 450us to 520us, I think function
usleep_range is better.
The patches is going to be updated.
-Xiaowei.
> diff --git a/drivers/pci/dwc/pcie-kirin.h
> b/drivers/pci/dwc/pcie-kirin.h new file mode 100644 index
> ..ad9a3b427298
> --- /dev/null
> +++ b/drivers/pci/dwc/pcie-kirin.h
> @@ -0,0 +1,79 @@
> +/*
> + * PCIe host controller driver for Kirin 960 SoCs
> + *
> + * Copyright (C) 2015 Huawei Electronics Co., Ltd.
> + * http://www.huawei.com
> + *
> + * Author: Xiaowei Song
The header is only used in one .c file, so just remove it and add the contents
to that file.
Arnd
Re: [PATCH v3 3/6] clk: sunxi-ng: Add driver for A83T CCU
On Thu, May 18, 2017 at 11:58:06AM +0800, Chen-Yu Tsai wrote:
> +/*
> + * MMC2 supports both old and new timing modes. When the new timing
> + * mode is active, the output clock rate is halved by two. Here we
> + * treat it as a variable pre-divider. Note that the pre-divider is
> + * _not_ included in the possible factors during a set clock rate
> + * operation. It is only read out.
> + */
> +#define SUN8I_A83T_MMC2_REG 0x090
> +static const struct ccu_mux_var_prediv mmc2_new_timing_predivs[] = {
> + { .index = 0, .shift = 30, .width = 1 },
> + { .index = 1, .shift = 30, .width = 1 },
> +};
> +static struct ccu_mp mmc2_clk = {
> + .enable = BIT(31),
> + .m = _SUNXI_CCU_DIV(0, 4),
> + .p = _SUNXI_CCU_DIV(16, 2),
> + .mux= {
> + .shift = 24,
> + .width = 2,
> + .var_predivs= mmc2_new_timing_predivs,
> + .n_var_predivs = ARRAY_SIZE(mmc2_new_timing_predivs),
> + },
> + .common = {
> + .reg= 0x090,
> + .hw.init= CLK_HW_INIT_PARENTS("mmc2",
> + mod0_default_parents,
> + &ccu_mp_ops,
> + CLK_GET_RATE_NOCACHE),
> + },
> +};
> +
> +static SUNXI_CCU_PHASE(mmc2_sample_clk, "mmc2-sample", "mmc2",
> +0x090, 20, 3, 0);
> +static SUNXI_CCU_PHASE(mmc2_output_clk, "mmc2-output", "mmc2",
> +0x090, 8, 3, 0);
I'm sorry to be a pain for this, but we're in the exact same situation
for the A83T than the A33 or the H3. There's no reason we'd do
something different with the MMC clocks only on the A83T.
What I'd like to happen is:
1) Get the A83T ccu driver in, without *any* of the new mode
handling.
2) Work on the new mode for the A33, A83T and H3 (and the other I
might have forgotten).
This issue really isn't A83 specific, there's no reason to come up
with A83 specific code.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [linux-sunxi] [PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
On Thu, May 18, 2017 at 3:16 PM, Icenowy Zheng wrote: > The A31 NMI driver seems to be using wrong base address. > > As we're going to convert to use a correct NMI base address (and > correctly name it to R_INTC as the datasheet suggests), add a new > compatible string for the "correct" R_INTC, which we will use for A64 > SoC. > > Signed-off-by: Icenowy Zheng > Acked-by: Rob Herring The subject prefix might need a bit of work, but otherwise Reviewed-by: Chen-Yu Tsai
Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure
On Wed, May 17, 2017 at 07:36:46PM +0200, Markus Trippelsdorf wrote: > Since: > commit cfafcd117da0216520568c195cb2f6cd1980c4bb > Author: Peter Zijlstra > Date: Wed Mar 22 11:35:58 2017 +0100 > > futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock() > > glibc's nptl/tst-robustpi8 testcase fails: > > glibc-build % ./nptl/tst-robustpi8 > tst-robustpi8: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full: > Assertion `INTERNAL_SYSCALL_ERRNO (e, __err) != ESRCH || !robust' failed. OK, so how do I get those tests build? I did a checkout of glibc.git glibc$ mkdir build; cd build build$ ../configure --disable-sanity-checks ; make -j40 build$ ./nptl/tst-robustpi8 -bash: ./nptl/tst-robustpi8: No such file or directory "make tests" doesn't seem to work either even though its a build target listed in the Makefiles. What magic incantation do I need?
Re: [PATCH] efi/libstub: Indicate clang the relocation mode for arm64
On 18 May 2017 at 00:24, Greg Hackmann wrote:
> On 05/11/2017 06:51 AM, Ard Biesheuvel wrote:
> [snip]
>>
>> In my opinion, the correct fix would be to make -fpie (as opposed to
>> -fpic) imply hidden visibility, given that PIE executables don't
>> export symbols in the first place, and so the preemption rules do not
>> apply. It is worth a try whether -fpie works as expected in this case
>> on Clang, but the last time I tried it on GCC, it behaved exactly like
>> -fpic.
>
>
> Thanks a lot for the detailed description and your suggestions!
>
> A clang build with -fpie for the EFI stub succeeds without complaints
> about GOT entries. I will send out an updated patch (with -fpie only
> for clang) later.
>
Good! I never liked the visibility hack, which is why I never upstreamed
it.
Could you please check how recent GCC behaves?
>>>
>>>
>>> I tried GCC v4.9.4 and v6.3.1, both build the EFI stub with -fpie
>>> without errors.
>>>
>>> Are you suggesting to use -fpie for both clang and GCC? Do you know
>>> what the minimum required GCC version is for building an arm64 kernel?
>>
>>
>> Yes. Up until now, we have been relying on the position independent
>> nature of small model code, but it would be better to specify it
>> explicitly, so if -fpie gives us mostly identical code and does not
>> need visibility hacks, I would prefer to add it for all compilers and
>> not have an exception only for Clang. Note that the same applies to
>> the entire kernel when built in KASLR mode, so it would also be good
>> to know our options here.
>>
>> Arnd, Will, what is the oldest GCC version we claim to support for arm64?
>>
>
> Unfortunately, after looking into this a bit more, -fpie by itself doesn't
> force clang to disable symbol preeemption. For example when building the
> EFI stub from 4.9 with clang, -fpie gives me a stub that crashes with a
> synchronous exception inside handle_kernel_image(). The faulting
> instruction is a read from __nokaslr that still goes through the GOT.
>
> Right now you'll get a usable EFI stub with -fpie anyway, since 60f38de7a8d4
> ("efi/libstub: Unify command line param parsing") masked the problem when it
> moved __nokaslr behind a helper function. But AIUI there's nothing really
> preventing a similar problem in the future.
>
> You *can* force clang to disable symbol preemption using "-fpie
> -mpie-copy-relocations". That said, I don't know enough about EFI to say
> whether this is actually appropriate for building the EFI stub.
Thanks for digging into this. It is really quite unfortunate that it
is so difficult to force Clang (or GCC for that matter) to generate
relative references without the compiler assuming that you are
building a shared library. Perhaps we need a stronger version of
-fvisibility=hidden, i.e., one that applies to extern declarations as
well.
For the stub, we could simply replace all remaining extern symbol
references (if any) with accessor functions, such as the one I added
for __nokaslr (which is actually needed for x86 as well, for different
reasons). Let me look into this.
[PATCH] thunderbolt: fix spelling mistake: "missmatch" -> "mismatch"
From: Colin Ian King
Trivial fix to spelling mistake in tb_sw_warn warning message
Signed-off-by: Colin Ian King
---
drivers/thunderbolt/eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
index 6392990c984d..1c3eb937a728 100644
--- a/drivers/thunderbolt/eeprom.c
+++ b/drivers/thunderbolt/eeprom.c
@@ -283,7 +283,7 @@ int tb_drom_read_uid_only(struct tb_switch *sw, u64 *uid)
crc = tb_crc8(data + 1, 8);
if (crc != data[0]) {
- tb_sw_warn(sw, "uid crc8 missmatch (expected: %#x, got: %#x)\n",
+ tb_sw_warn(sw, "uid crc8 mismatch (expected: %#x, got: %#x)\n",
data[0], crc);
return -EIO;
}
--
2.11.0
Re: [PATCH] ARM: sun8i: v3s: fix build of Lichee Pi Zero Dock dtb
On Thu, May 18, 2017 at 10:53:32AM +0800, Icenowy Zheng wrote: > The Lichee Pi Zero Dock dtb file is not added to the Makefile, so that > it won't be built; and the file contains a problem that prevents it > from being correctly built. > > Fix these issues. > > Signed-off-by: Icenowy Zheng I squashed it into the previous patch, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
[PATCH] phy: phy-brcm-sata: Fix a loop timeout
We expect to timeout with "try" set to zero but it's a post-op so
actually it ends with it set to -1. I've fixed this by changing it to a
pre-op.
Fixes: 024812889ad1 ("phy: Add SATA3 PHY support for Broadcom NSP SoC")
Signed-off-by: Dan Carpenter
diff --git a/drivers/phy/broadcom/phy-brcm-sata.c
b/drivers/phy/broadcom/phy-brcm-sata.c
index ccbc3d994998..48fb016ce689 100644
--- a/drivers/phy/broadcom/phy-brcm-sata.c
+++ b/drivers/phy/broadcom/phy-brcm-sata.c
@@ -329,7 +329,7 @@ static int brcm_nsp_sata_init(struct brcm_sata_port *port)
/* Wait for pll_seq_done bit */
try = 50;
- while (try--) {
+ while (--try) {
val = brcm_sata_phy_rd(base, BLOCK0_REG_BANK,
BLOCK0_XGXSSTATUS);
if (val & BLOCK0_XGXSSTATUS_PLL_LOCK)
[Patch v3 2/3] PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC
Hisilicon PCIe Driver shares the common functions fo PCIe dw-host
The poweron functions is developed on hi3660 SoC, while Others Functions
are common for Kirin series SoCs.
Lowpower(L1ss and SR), hotplug and MSI feature are not supported
currently.
Cc: Guodong Xu
Signed-off-by: Song Xiaowei
---
drivers/pci/dwc/Kconfig | 10 +
drivers/pci/dwc/Makefile | 1 +
drivers/pci/dwc/pcie-kirin.c | 519 +++
3 files changed, 530 insertions(+)
create mode 100644 drivers/pci/dwc/pcie-kirin.c
diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
index d2d2ba5b8a68..13e617b78430 100644
--- a/drivers/pci/dwc/Kconfig
+++ b/drivers/pci/dwc/Kconfig
@@ -130,4 +130,14 @@ config PCIE_ARTPEC6
Say Y here to enable PCIe controller support on Axis ARTPEC-6
SoCs. This PCIe controller uses the DesignWare core.
+config PCIE_KIRIN
+ depends on OF && ARM64
+ bool "HiSilicon Kirin series SoCs PCIe controllers"
+ depends on PCI
+ select PCIEPORTBUS
+ select PCIE_DW_HOST
+ help
+ Say Y here if you want PCIe controller support on HiSilicon Kirin
series SoCs
+ kirin960 SoC
+
endmenu
diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
index a2df13c28798..4bd69bacd4ab 100644
--- a/drivers/pci/dwc/Makefile
+++ b/drivers/pci/dwc/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
+obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
new file mode 100644
index ..5011f6c72e7c
--- /dev/null
+++ b/drivers/pci/dwc/pcie-kirin.c
@@ -0,0 +1,519 @@
+/*
+ * PCIe host controller driver for Kirin Phone SoCs
+ *
+ * Copyright (C) 2015 Hilisicon Electronics Co., Ltd.
+ * http://www.huawei.com
+ *
+ * Author: Xiaowei Song
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "pcie-designware.h"
+
+#define to_kirin_pcie(x) dev_get_drvdata((x)->dev)
+
+#define REF_CLK_FREQ 1
+
+/* PCIe ELBI registers */
+#define SOC_PCIECTRL_CTRL0_ADDR 0x000
+#define SOC_PCIECTRL_CTRL1_ADDR 0x004
+#define SOC_PCIEPHY_CTRL2_ADDR 0x008
+#define SOC_PCIEPHY_CTRL3_ADDR 0x00c
+#define PCIE_ELBI_SLV_DBI_ENABLE (0x1 << 21)
+
+#define PCIE_APP_LTSSM_ENABLE 0x01c
+#define PCIE_APB_PHY_CTRL0 0x0
+#define PCIE_APB_PHY_CTRL1 0x4
+#define PCIE_APB_PHY_STATUS0 0x400
+#define PCIE_LINKUP_ENABLE (0x8020)
+#define PCIE_LTSSM_ENABLE_BIT(0x1 << 11)
+#define PIPE_CLK_STABLE(0x1 << 19)
+#define PIPE_CLK_MAX_TRY_TIMES 10
+#define PHY_REF_PAD_BIT(0x1 << 8)
+#define PHY_PWR_DOWN_BIT (0x1 << 22)
+#define PHY_RST_ACK_BIT(0x1 << 16)
+
+/* info lacated in sysctrl */
+#define SCTRL_PCIE_CMOS_OFFSET 0x60
+#define SCTRL_PCIE_CMOS_BIT0x10
+#define SCTRL_PCIE_ISO_OFFSET 0x44
+#define SCTRL_PCIE_ISO_BIT 0x30
+#define SCTRL_PCIE_HPCLK_OFFSET0x190
+#define SCTRL_PCIE_HPCLK_BIT 0x184000
+#define SCTRL_PCIE_OE_OFFSET 0x14a
+#define PCIE_DEBOUNCE_PARAM0xF0F400
+#define PCIE_OE_BYPASS (0x3 << 28)
+
+/*peri_crg ctrl*/
+#define CRGCTRL_PCIE_ASSERT_OFFSET 0x88
+#define CRGCTRL_PCIE_ASSERT_BIT0x8c00
+
+/* Time for delay*/
+#define REF_2_PERST_MIN(2)
+#define REF_2_PERST_MAX(25000)
+#define PERST_2_ACCESS_MIN (1)
+#define PERST_2_ACCESS_MAX (12000)
+#define LINK_WAIT_MIN (900)
+#define LINK_WAIT_MAX (1000)
+#define PIPE_CLK_WAIT_MIN (550)
+#define PIPE_CLK_WAIT_MAX (600)
+
+struct kirin_pcie {
+ void __iomem*apb_base;
+ void __iomem*phy_base;
+ struct regmap *crgctrl;
+ struct regmap *sysctrl;
+ struct clk *apb_sys_clk;
+ struct clk *apb_phy_clk;
+ struct clk *phy_ref_clk;
+ struct clk *pcie_aclk;
+ struct clk *pcie_aux_clk;
+ int gpio_id_reset;
+ struct dw_pcie *pci;
+};
+
+static inline void kirin_apb_ctrl_writel(struct kirin_pcie *kirin_pcie,
+ u32 val, u32 reg)
+{
+ writel(val, kirin_pcie->apb_base + reg);
+}
+
+st
Re: Microchip USB Hub Driver Harmonization
On Thu, May 18, 2017 at 7:33 AM, Richard Leitner wrote: >>> 2. What would be a good prefix for common headers/functions/macros/etc.? >>> I thought of "mcusbhub"... Would that be OK? Or are there any >>> conventions/better proposals on that? >> >> >> If you are going to develop one driver for entire family, then you could >> even choose just one name. Let's say the most generic. >> >> I don't quite understand the meaning behind "harmonizing drivers". > > > I'm currently evaluating if it is feasible to create one common driver for > all USB hubs. Due to the fact there are currently only 3 hub types > implemented mainline (the Microchip homepage lists 36 USB Hub products [1]) > it involves quite a lot data-sheet reading ;-) > > As a first step (and also the final one if implementing a common driver is > not feasible) I thought of creating a common header/source file which > implements all "re-useable" functions/macros/etc. Would that also be an > accepted solution? I understand. It is fine with me. You could make common part in few ways, e.g.: 1. prepare re-usable functions etc (as you said), 2. create one driver core (with init/probe/remove/exit etc) which delegates most of the body to specific handlers around. The benefit of the second approach is that one sees immediately that there is one driver for entire family. >>> 3. Currently only usb3503 supports "platform data". Is this still needed >>> or may it be removed? >> >> >> I think it is still used, e.g. by: >> arch/arm/boot/dts/exynos5250-spring.dts > > > Please correct me if I'm wrong, but isn't that DT only? > > The reason why I'm asking if it may be removed is because the only file > including "linux/platform_data/usb3503.h" is the usb3503.c driver itself and > it's also the only file using "struct usb3503_platform_data". Ah yes, my mistake. I understood that you are asking about "platform driver", not "platform data". From my perspective all boards use DT so there is no platform data. In other drivers I found that some folks from x86 world use SFI/platform_data but I do not know if it applies here. Anyway removing platform data is fine with me. Best regards, Krzysztof
[PATCH] ASoC: audio-graph-card: fix spelling mistake: "missmatch" -> "mismatch"
From: Colin Ian King
Trivial fix to spelling mistake in dev_err message
Signed-off-by: Colin Ian King
---
sound/soc/generic/audio-graph-card.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/generic/audio-graph-card.c
b/sound/soc/generic/audio-graph-card.c
index 07e010d38596..e0c26380921e 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -107,7 +107,7 @@ static int asoc_graph_card_dai_link_of(struct device_node
*cpu_port,
int ret;
if (rcpu_ep != cpu_ep) {
- dev_err(dev, "remote-endpoint missmatch (%s/%s/%s)\n",
+ dev_err(dev, "remote-endpoint mismatch (%s/%s/%s)\n",
cpu_ep->name, codec_ep->name, rcpu_ep->name);
ret = -EINVAL;
goto dai_link_of_err;
--
2.11.0
[Patch v3 3/3] defconfig: PCI: Enable Kirin PCIe defconfig
Cc: Guodong Xu Signed-off-by: Song Xiaowei --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 7c48028ec64a..d56d8f1062ab 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -71,6 +71,7 @@ CONFIG_PCI_XGENE=y CONFIG_PCI_LAYERSCAPE=y CONFIG_PCI_HISI=y CONFIG_PCIE_QCOM=y +CONFIG_PCIE_KIRIN=y CONFIG_PCIE_ARMADA_8K=y CONFIG_ARM64_VA_BITS_48=y CONFIG_SCHED_MC=y -- 2.11.GIT
[PATCH] net: ieee802154: fix net_device reference release too early
This patch fixes the kernel oops when release net_device reference in advance. In function raw_sendmsg(i think the dgram_sendmsg has the same problem), there is a race condition between dev_put and dev_queue_xmit when the device is gong that maybe lead to dev_queue_ximt to see an illegal net_device pointer. So i think that dev_put should be behind of the dev_queue_xmit. Also, explicit set skb->sk is needless, sock_alloc_send_skb is already set it. Signed-off-by: linzhang --- net/ieee802154/socket.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c index eedba76..a60658c 100644 --- a/net/ieee802154/socket.c +++ b/net/ieee802154/socket.c @@ -301,15 +301,14 @@ static int raw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size) goto out_skb; skb->dev = dev; - skb->sk = sk; skb->protocol = htons(ETH_P_IEEE802154); - dev_put(dev); - err = dev_queue_xmit(skb); if (err > 0) err = net_xmit_errno(err); + dev_put(dev); + return err ?: size; out_skb: @@ -690,15 +689,14 @@ static int dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t size) goto out_skb; skb->dev = dev; - skb->sk = sk; skb->protocol = htons(ETH_P_IEEE802154); - dev_put(dev); - err = dev_queue_xmit(skb); if (err > 0) err = net_xmit_errno(err); + dev_put(dev); + return err ?: size; out_skb: -- 1.8.3.1
Re: [PATCH 2/2] dax: Fix race between colliding PMD & PTE entries
On Wed 17-05-17 11:16:39, Ross Zwisler wrote:
> We currently have two related PMD vs PTE races in the DAX code. These can
> both be easily triggered by having two threads reading and writing
> simultaneously to the same private mapping, with the key being that private
> mapping reads can be handled with PMDs but private mapping writes are
> always handled with PTEs so that we can COW.
>
> Here is the first race:
>
> CPU 0 CPU 1
>
> (private mapping write)
> __handle_mm_fault()
> create_huge_pmd() - FALLBACK
> handle_pte_fault()
> passes check for pmd_devmap()
>
> (private mapping read)
> __handle_mm_fault()
> create_huge_pmd()
> dax_iomap_pmd_fault() inserts PMD
>
> dax_iomap_pte_fault() does a PTE fault, but we already have a DAX PMD
> installed in our page tables at this spot.
>
>
> Here's the second race:
>
> CPU 0 CPU 1
>
> (private mapping write)
> __handle_mm_fault()
> create_huge_pmd() - FALLBACK
> (private mapping read)
> __handle_mm_fault()
> passes check for pmd_none()
> create_huge_pmd()
>
> handle_pte_fault()
> dax_iomap_pte_fault() inserts PTE
> dax_iomap_pmd_fault() inserts PMD,
> but we already have a PTE at
> this spot.
So I don't see how this second scenario can happen. dax_iomap_pmd_fault()
will call grab_mapping_entry(). That will either find PTE entry in the
radix tree -> EEXIST and we retry the fault. Or we will not find PTE entry
-> try to insert PMD entry which collides with the PTE entry -> EEXIST and
we retry the fault. Am I missing something?
The first scenario seems to be possible. dax_iomap_pmd_fault() will create
PMD entry in the radix tree. Then dax_iomap_pte_fault() will come, do
grab_mapping_entry(), there it sees entry is PMD but we are doing PTE fault
so I'd think that pmd_downgrade = true... But actually the condition there
doesn't trigger in this case. And that's a catch that although we asked
grab_mapping_entry() for PTE, we've got PMD back and that screws us later.
Actually I'm not convinced your patch quite fixes this because
dax_load_hole() or dax_insert_mapping_entry() will modify the passed entry
with the assumption that it's PTE entry and so they will likely corrupt the
entry in the radix tree.
So I think to fix the first case we should rather modify
grab_mapping_entry() to properly go through the pmd_downgrade path once we
find PMD entry and we do PTE fault.
What do you think?
Honza
>
> The core of the issue is that while there is isolation between faults to
> the same range in the DAX fault handlers via our DAX entry locking, there
> is no isolation between faults in the code in mm/memory.c. This means for
> instance that this code in __handle_mm_fault() can run:
>
> if (pmd_none(*vmf.pmd) && transparent_hugepage_enabled(vma)) {
> ret = create_huge_pmd(&vmf);
>
> But by the time we actually get to run the fault handler called by
> create_huge_pmd(), the PMD is no longer pmd_none() because a racing PTE
> fault has installed a normal PMD here as a parent. This is the cause of
> the 2nd race. The first race is similar - there is the following check in
> handle_pte_fault():
>
> } else {
> /* See comment in pte_alloc_one_map() */
> if (pmd_devmap(*vmf->pmd) || pmd_trans_unstable(vmf->pmd))
> return 0;
>
> So if a pmd_devmap() PMD (a DAX PMD) has been installed at vmf->pmd, we
> will bail and retry the fault. This is correct, but there is nothing
> preventing the PMD from being installed after this check but before we
> actually get to the DAX PTE fault handlers.
>
> In my testing these races result in the following types of errors:
>
> BUG: Bad rss-counter state mm:8800a817d280 idx:1 val:1
> BUG: non-zero nr_ptes on freeing mm: 15
>
> Fix this issue by having the DAX fault handlers verify that it is safe to
> continue their fault after they have taken an entry lock to block other
> racing faults.
>
> Signed-off-by: Ross Zwisler
> Reported-by: Pawel Lebioda
> Cc: sta...@vger.kernel.org
>
> ---
>
> I've written a new xfstest for this race, which I will send in response to
> this patch series. This series has also survived an xfstest run without
> any new issues.
>
> ---
> fs/dax.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index c22eaf1..3cc02d1 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @
[Patch v3 1/3] arm64: dts: hi3660: add pcie node
Add PCIe node for hi3660, and add binding documentation.
Cc: Guodong Xu
Signed-off-by: Song Xiaowei
---
.../devicetree/bindings/pci/hisilicon-pcie.txt | 52 ++
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 31 +
2 files changed, 83 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
index a339dbb15493..71491178c86c 100644
--- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
@@ -85,3 +85,55 @@ Example:
0x0 0 0 4 &mbigen_pcie0 650 4>;
status = "ok";
};
+
+
+
+HiSilicon Kirin SoC PCIe host DT description
+
+Kirin PCIe host controller is also based on Designware PCI core.
+It shares common functions with PCIe Designware core driver and inherits
+common properties defined in
+Documentation/devicetree/bindings/pci/designware-pci.txt.
+
+Additional properties are described here:
+
+Required properties
+- compatible: Should contain "hisilicon,kirin-pcie".
+- reg: Should contain rc_dbi, apb, phy, config registers location and length.
+- reg-names: Must include the following entries:
+ "dbi": controller configuration registers;
+ "apb": apb Ctrl register;
+ "phy": apb PHY register;
+ "config": PCIe configuration space registers.
+- reset-gpio: perst assert/deassert gpio
+
+Optional properties:
+- status: Either "ok" or "disabled".
+
+Kirin960 Example:
+kirin_pcie@f400 {
+compatible = "hisilicon,kirin-pcie";
+reg = <0x0 0xf400 0x0 0x1000>, <0x0 0xff3fe000
0x0 0x1000>,
+ <0x0 0xf3f2 0x0 0x4>, <0x0 0xF500
0 0x2000>;
+reg-names = "dbi","apb","phy", "config";
+bus-range = <0x0 0x1>;
+#address-cells = <3>;
+#size-cells = <2>;
+device_type = "pci";
+ranges = <0x0200 0x0 0x 0x0 0xf600 0x0
0x200>;
+num-lanes = <1>;
+#interrupt-cells = <1>;
+interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <0x0 0 0 2 &gic 0 0 0 283 4>,
+<0x0 0 0 3 &gic 0 0 0 284 4>,
+<0x0 0 0 4 &gic 0 0 0 285 4>;
+clocks = <&crg_ctrl HI3660_PCIEPHY_REF>,
+<&crg_ctrl HI3660_CLK_GATE_PCIEAUX>,
+<&crg_ctrl HI3660_PCLK_GATE_PCIE_PHY>,
+<&crg_ctrl HI3660_PCLK_GATE_PCIE_SYS>,
+<&crg_ctrl HI3660_ACLK_GATE_PCIE>;
+clock-names = "pcie_phy_ref", "pcie_aux",
+"pcie_apb_phy", "pcie_apb_sys", "pcie_aclk";
+reset-gpio = <&gpio11 1 0 >;
+status = "ok";
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 3983086bd67b..2406a54947df 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -156,5 +156,36 @@
clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
+
+ kirin_pcie@f400 {
+ compatible = "hisilicon,kirin-pcie";
+ reg = <0x0 0xf400 0x0 0x1000>,
+ <0x0 0xff3fe000 0x0 0x1000>,
+ <0x0 0xf3f2 0x0 0x4>,
+ <0x0 0xF500 0x0 0x2000>;
+ reg-names = "dbi", "apb", "phy", "config";
+ bus-range = <0x0 0x1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x0200 0x0 0x 0x0
+ 0xf600 0x0 0x200>;
+ num-lanes = <1>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <0x0 0 0 1 &gic 0 0 0 282 4>,
+ <0x0 0 0 2 &gic 0 0 0 283 4>,
+ <0x0 0 0 3 &gic 0 0 0 284 4>,
+ <0x0 0 0 4 &gic 0 0 0 285 4>;
+ clocks = <&crg_ctrl HI3660_PCIEPHY_REF>,
+ <&crg_ctrl HI3660_CLK_GATE_PCIEAUX>,
+ <&crg_ctrl HI3660_PCLK_GATE_PCIE_PHY>,
+ <&crg_ctrl HI3660_PCLK_GATE_PCIE_SYS>,
+ <&crg_ctrl HI3660_ACLK_GATE_PCIE>;
+
Re: [PATCH v3 3/6] clk: sunxi-ng: Add driver for A83T CCU
On Thu, May 18, 2017 at 3:39 PM, Maxime Ripard
wrote:
> On Thu, May 18, 2017 at 11:58:06AM +0800, Chen-Yu Tsai wrote:
>> +/*
>> + * MMC2 supports both old and new timing modes. When the new timing
>> + * mode is active, the output clock rate is halved by two. Here we
>> + * treat it as a variable pre-divider. Note that the pre-divider is
>> + * _not_ included in the possible factors during a set clock rate
>> + * operation. It is only read out.
>> + */
>> +#define SUN8I_A83T_MMC2_REG 0x090
>> +static const struct ccu_mux_var_prediv mmc2_new_timing_predivs[] = {
>> + { .index = 0, .shift = 30, .width = 1 },
>> + { .index = 1, .shift = 30, .width = 1 },
>> +};
>> +static struct ccu_mp mmc2_clk = {
>> + .enable = BIT(31),
>> + .m = _SUNXI_CCU_DIV(0, 4),
>> + .p = _SUNXI_CCU_DIV(16, 2),
>> + .mux= {
>> + .shift = 24,
>> + .width = 2,
>> + .var_predivs= mmc2_new_timing_predivs,
>> + .n_var_predivs = ARRAY_SIZE(mmc2_new_timing_predivs),
>> + },
>> + .common = {
>> + .reg= 0x090,
>> + .hw.init= CLK_HW_INIT_PARENTS("mmc2",
>> + mod0_default_parents,
>> + &ccu_mp_ops,
>> + CLK_GET_RATE_NOCACHE),
>> + },
>> +};
>> +
>> +static SUNXI_CCU_PHASE(mmc2_sample_clk, "mmc2-sample", "mmc2",
>> +0x090, 20, 3, 0);
>> +static SUNXI_CCU_PHASE(mmc2_output_clk, "mmc2-output", "mmc2",
>> +0x090, 8, 3, 0);
>
> I'm sorry to be a pain for this, but we're in the exact same situation
> for the A83T than the A33 or the H3. There's no reason we'd do
> something different with the MMC clocks only on the A83T.
>
> What I'd like to happen is:
> 1) Get the A83T ccu driver in, without *any* of the new mode
> handling.
> 2) Work on the new mode for the A33, A83T and H3 (and the other I
> might have forgotten).
>
> This issue really isn't A83 specific, there's no reason to come up
> with A83 specific code.
So to recap, you want mmc2_clk without the new pre-dividers here.
Then we add them for _all_ SoCs that have the old/new mode switch
at the same time. Is that correct?
This really isn't A83T specific code. It's just one way to handle
the extra divider for the new timing mode. Obviously we will add the
functions to query and set the timing mode bit, but that will be
generic. If you want all code related to the new mode in one patch,
then I understand.
ChenYu
Re: [PATCH v3 14/21] drm/sun4i: tcon: multiply the vtotal when not in interlace
On Wed, May 17, 2017 at 05:50:45PM +0800, Chen-Yu Tsai wrote:
> On Wed, May 17, 2017 at 3:40 PM, Maxime Ripard
> wrote:
> > It appears that the total vertical resolution needs to be doubled when
> > we're not in interlaced. Make sure that is the case.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 +
> > 1 file changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index 62e254aedb57..a0f9a8a516c7 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -153,7 +153,7 @@ static int sun4i_tcon_get_clk_delay(struct
> > drm_display_mode *mode,
> > void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
> > struct drm_display_mode *mode)
> > {
> > - unsigned int bp, hsync, vsync;
> > + unsigned int bp, hsync, vsync, vtotal;
> > u8 clk_delay;
> > u32 val = 0;
> >
> > @@ -192,9 +192,26 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
> > DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
> > mode->crtc_vtotal, bp);
> >
> > + /*
> > +* The vertical resolution needs to be doubled in all
> > +* cases. We could use crtc_vtotal and always multiply by two,
> > +* but that leads to a rounding error in interlace when vtotal
> > +* is odd.
> > +*
> > +* This happens with TV's PAL for example, where vtotal will
> > +* be 625, crtc_vtotal 312, and thus crtc_vtotal * 2 will be
> > +* 624, which apparently confuses the hardware.
> > +*
> > +* To work around this, we will always use vtotal, and
> > +* multiply by two only if we're not in interlace.
> > +*/
> > + vtotal = mode->vtotal;
> > + if (!(mode->flags & DRM_MODE_FLAG_INTERLACE))
> > + vtotal = vtotal * 2;
> > +
> > /* Set vertical display timings */
> > regmap_write(tcon->regs, SUN4I_TCON0_BASIC2_REG,
> > -SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal * 2) |
> > +SUN4I_TCON0_BASIC2_V_TOTAL(vtotal) |
> > SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
> >
> > /* Set Hsync and Vsync length */
> > @@ -279,9 +296,9 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> > /* Set vertical display timings */
> > bp = mode->crtc_vtotal - mode->crtc_vsync_start;
> > DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
> > -mode->vtotal, bp);
> > +mode->crtc_vtotal, bp);
>
> You should duplicate the logic from channel 0 to channel 1.
> In fact, interlaced modes happen predominantly on channel 1,
> for composite and HDMI modes.
Gaah, you're right, this was obviously meant for the channel 1.. I'll
resend.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH v6 2/9] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC
On Thu, May 18, 2017 at 03:16:46PM +0800, Icenowy Zheng wrote: > Add support for the newly imported compatible for the A64 R_INTC in > irq-sunxi-nmi driver. > > Signed-off-by: Icenowy Zheng Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v6 1/9] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
On Thu, May 18, 2017 at 03:16:45PM +0800, Icenowy Zheng wrote: > The A31 NMI driver seems to be using wrong base address. > > As we're going to convert to use a correct NMI base address (and > correctly name it to R_INTC as the datasheet suggests), add a new > compatible string for the "correct" R_INTC, which we will use for A64 > SoC. > > Signed-off-by: Icenowy Zheng > Acked-by: Rob Herring Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 23/23] uuid: remove uuid_be
On Thu, May 18, 2017 at 9:27 AM, Christoph Hellwig wrote:
> Everything uses uuid_t now.
>
> Signed-off-by: Christoph Hellwig
> ---
Excellent!
I reviewed the entire series. You may add
Reviewed-by: Amir Goldstein
to any of the patches as you see fit.
Now let's talk about how this is going to be merged.
Do you intend to send Linus a pull request?
Get those patches merged via someone else's tree?
Is this branch listed for linux-next build?
The reason I am asking is because this last removal patch should probably
be applied near the end of the merge window (?).
Because maintainers cannot apply patches with code that uses the new
uuid_t to linux-next branches and we don't want linux-next build to fail
with new code that uses uuid_be...
More to the point, I would like to re-post the patch
("tmpfs: generate random sb->s_uuid") using uuid_gen()
instead of generate_random_uuid() as you proposed.
Hugh has already acked the intent "once fs is agreed on the way to go"
When and how would I have this patch applied?
Obvious solution.. can you apply this patch to your branch?
Do you need me to re-post it?
Thanks for working on this!
Amir.
Re: [PATCH] mm,oom: fix oom invocation issues
On Wed 17-05-17 20:43:16, Roman Gushchin wrote:
> On Wed, May 17, 2017 at 06:14:46PM +0200, Michal Hocko wrote:
> > On Wed 17-05-17 16:26:20, Roman Gushchin wrote:
[...]
> > > After some investigations I've found some issues:
> > >
> > > 1) Prior to commit 1af8bb432695 ("mm, oom: fortify task_will_free_mem()"),
> > >if a process with a pending SIGKILL was calling out_of_memory(),
> > >it was always immediately selected as a victim.
> >
> > Yes but this had its own issues. Mainly picking the same victim again
> > without making a further progress.
>
> That is why I've added this check into the pagefault_out_of_memory(),
> rather than out_of_memory(), where it was earlier.
As I've said in my previous email, this alone makes some sense but I do
not think it is a bug fix but rather a short cut that should be safe to
do because we should check fatal signals on the way out of the #PF.
> > >But now, after some changes, it's not always a case.
> > >If a process has been reaped at the moment, MMF_SKIP_FLAG is set,
> > >task_will_free_mem() will return false, and a new
> > >victim selection logic will be started.
> >
> > right. The point is that it doesn't make any sense to consider such a
> > task because it either cannot be reaped or it has been reaped and there
> > is not much left to consider. It would be interesting to see what
> > happened in your case.
> >
> > >This actually happens if a userspace pagefault causing an OOM.
> > >pagefault_out_of_memory() is called in a context of a faulting
> > >process after it has been selected as OOM victim (assuming, it
> > >has), and killed. With some probability (there is a race with
> > >oom_reaper thread) this process will be passed to the oom reaper
> > >again, or an innocent victim will be selected and killed.
> > >
> > > 2) We clear up the task->oom_reaper_list before setting
> > >the MMF_OOM_SKIP flag, so there is a race.
> >
> > I am not sure what you mean here. Why would a race matter?
>
> oom_reaper_list pointer is zeroed before MMF_OOM_SKIP flag is set.
> Inbetween this process can be selected again and added to the
> oom reaper queue. It's not a big issue, still.
I still do not see why it would matter. Even if we queue this task again
then oom_lock would prevent from parallel reaping and even if we do not
race then it is not so harmfull to crawl over all mappings just to find
out that nothing is left to be reaped.
[...]
> > > 2) Set the MMF_OOM_SKIP bit in wake_oom_reaper() before adding a
> > >process to the oom_reaper list. If it's already set, do nothing.
> > >Do not rely on tsk->oom_reaper_list value.
> >
> > This is wrong. The sole purpose of MMF_OOM_SKIP is to let the oom
> > selection logic know that this task is not interesting anymore. Setting
> > it in wake_oom_reaper means it would be set _before_ the oom_reaper had
> > any chance to free any memory from the task. So we would
>
> But if have selected a task once, it has no way back.
> Anyway it will be reaped or will quit by itself soon. Right?
yes and we have to wait for one or the other...
> So, under no circumstances we should consider choosing them
> as an OOM victim again.
and that is exactly what we do right now. We just postpone a new task
selection. Put simply we just wait while there is a pending oom victim
and MMF_OOM_SKIP is a way to skip such a pending victim if we believe
there is no much hope to release some memory anymore.
> There are no reasons to calculate it's badness again, etc.
Yes that is true but oom_badness has to consider MMF_OOM_SKIP anyway
(mainly because it is called from more places).
> > > 3) Check the MMF_OOM_SKIP even if OOM is triggered by a sysrq.
> >
> > The code is a bit messy here but we do check MMF_OOM_SKIP in that case.
> > We just do it in oom_badness(). So this is not needed, strictly
> > speaking.
> >
> > That being said I would like to here more about the cause of the OOM and
> > the full dmesg would be interesting. The proposed setting of
> > MMF_OOM_SKIP before the task is reaped is a nogo, though.
>
> If so, how you will prevent putting a process again into the reaper list,
> if it's already reaped?
We simply do not care all that much as already said.
> > 1) would be
> > acceptable I think but I would have to think about it some more.
>
> Actually, the first problem is much more serious, as it leads
> to a killing of second process.
That sounds like a bug to me. I will investigate further.
> The second one can lead only to a unnecessary wake up of
> the oom reaper thread, which is not great, but acceptable.
yes.
--
Michal Hocko
SUSE Labs
[PATCH v3 3/6] iommu/iova: adjust __cached_rbnode_insert_update
For case 2 and 3, adjust cached32_node to the new place, case 1 keep no
change.
For example:
case1: (the right part was allocated)
|--|
|<-free>|<--new_iova-->|
|
|
cached32_node
case2: (all was allocated)
|--|
|<-new_iova--->|
|
|
cached32_node
case3:
|---|..|-|
|..free..|<--new_iova-->|
| |
| |
cached32_node(new) cached32_node(old)
Signed-off-by: Zhen Lei
---
drivers/iommu/iova.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index d0c19ec..1b8e136 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -91,12 +91,16 @@ __get_cached_rbnode(struct iova_domain *iovad, unsigned
long *limit_pfn)
}
static void
-__cached_rbnode_insert_update(struct iova_domain *iovad,
- unsigned long limit_pfn, struct iova *new)
+__cached_rbnode_insert_update(struct iova_domain *iovad, struct iova *new)
{
- if (limit_pfn != iovad->dma_32bit_pfn)
+ struct iova *cached_iova;
+
+ if (new->pfn_hi > iovad->dma_32bit_pfn)
return;
- iovad->cached32_node = &new->node;
+
+ cached_iova = rb_entry(iovad->cached32_node, struct iova, node);
+ if (new->pfn_lo <= cached_iova->pfn_lo)
+ iovad->cached32_node = rb_prev(&new->node);
}
static void
@@ -159,12 +163,10 @@ static int __alloc_and_insert_iova_range(struct
iova_domain *iovad,
{
struct rb_node *prev, *curr;
unsigned long flags;
- unsigned long saved_pfn;
unsigned int pad_size = 0;
/* Walk the tree backwards */
spin_lock_irqsave(&iovad->iova_rbtree_lock, flags);
- saved_pfn = limit_pfn;
curr = __get_cached_rbnode(iovad, &limit_pfn);
prev = curr;
while (curr) {
@@ -198,11 +200,10 @@ static int __alloc_and_insert_iova_range(struct
iova_domain *iovad,
/* If we have 'prev', it's a valid place to start the insertion. */
iova_insert_rbtree(&iovad->rbroot, new, prev);
- __cached_rbnode_insert_update(iovad, saved_pfn, new);
+ __cached_rbnode_insert_update(iovad, new);
spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags);
-
return 0;
}
--
2.5.0
[PATCH v3 1/6] iommu/iova: cut down judgement times
Below judgement can only be satisfied at the last time, which produced 2N
judgements(suppose N times failed, 0 or 1 time successed) in vain.
if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) {
return iova;
}
Signed-off-by: Zhen Lei
Reviewed-by: Robin Murphy
---
drivers/iommu/iova.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 5c88ba7..333a9cc 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -291,15 +291,12 @@ private_find_iova(struct iova_domain *iovad, unsigned
long pfn)
while (node) {
struct iova *iova = rb_entry(node, struct iova, node);
- /* If pfn falls within iova's range, return iova */
- if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) {
- return iova;
- }
-
if (pfn < iova->pfn_lo)
node = node->rb_left;
- else if (pfn > iova->pfn_lo)
+ else if (pfn > iova->pfn_hi)
node = node->rb_right;
+ else
+ return iova;/* pfn falls within iova's range */
}
return NULL;
--
2.5.0
[PATCH v3 5/6] iommu/iova: move the caculation of pad mask out of loop
I'm not sure whether the compiler can optimize it, but move it out will
be better. At least, it does not require lock protection.
Signed-off-by: Zhen Lei
---
drivers/iommu/iova.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 711b10a..338930b 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -155,23 +155,16 @@ iova_insert_rbtree(struct rb_root *root, struct iova
*iova,
rb_insert_color(&iova->node, root);
}
-/*
- * Computes the padding size required, to make the start address
- * naturally aligned on the power-of-two order of its size
- */
-static unsigned int
-iova_get_pad_size(unsigned int size, unsigned int limit_pfn)
-{
- return (limit_pfn + 1 - size) & (__roundup_pow_of_two(size) - 1);
-}
-
static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
unsigned long size, unsigned long limit_pfn,
struct iova *new, bool size_aligned)
{
struct rb_node *prev, *curr;
unsigned long flags;
- unsigned int pad_size = 0;
+ unsigned long pad_mask, pad_size = 0;
+
+ if (size_aligned)
+ pad_mask = __roundup_pow_of_two(size) - 1;
/* Walk the tree backwards */
spin_lock_irqsave(&iovad->iova_rbtree_lock, flags);
@@ -185,8 +178,13 @@ static int __alloc_and_insert_iova_range(struct
iova_domain *iovad,
else if (limit_pfn < curr_iova->pfn_hi)
goto adjust_limit_pfn;
else {
+ /*
+* Computes the padding size required, to make the start
+* address naturally aligned on the power-of-two order
+* of its size
+*/
if (size_aligned)
- pad_size = iova_get_pad_size(size, limit_pfn);
+ pad_size = (limit_pfn + 1 - size) & pad_mask;
if ((curr_iova->pfn_hi + size + pad_size) <= limit_pfn)
break; /* found a free slot */
}
--
2.5.0
[PATCH v3 4/6] iommu/iova: to optimize the allocation performance of dma64
Currently we always search free iova space for dma64 begin at the last
node of iovad rb-tree. In the worst case, there maybe too many nodes exist
at the tail, so that we should traverse many times for the first loop in
__alloc_and_insert_iova_range. As we traced, more than 10K times for the
case of iperf.
__alloc_and_insert_iova_range:
..
curr = __get_cached_rbnode(iovad, &limit_pfn);
//--> return rb_last(&iovad->rbroot);
while (curr) {
..
curr = rb_prev(curr);
}
So add cached64_node to take the same effect as cached32_node, and add
the start_pfn boundary of dma64, to prevent a iova cross both dma32 and
dma64 area.
|---|--|
|<--cached32_node-->||
| |
start_pfn dma_32bit_pfn + 1
Signed-off-by: Zhen Lei
---
drivers/iommu/iova.c | 46 +++---
include/linux/iova.h | 5 +++--
2 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 1b8e136..711b10a 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -37,10 +37,15 @@ insert_iova_boundary(struct iova_domain *iovad)
{
struct iova *iova;
unsigned long start_pfn_32bit = iovad->start_pfn;
+ unsigned long start_pfn_64bit = iovad->dma_32bit_pfn + 1;
iova = reserve_iova(iovad, start_pfn_32bit, start_pfn_32bit);
BUG_ON(!iova);
iovad->cached32_node = &iova->node;
+
+ iova = reserve_iova(iovad, start_pfn_64bit, start_pfn_64bit);
+ BUG_ON(!iova);
+ iovad->cached64_node = &iova->node;
}
void
@@ -62,8 +67,8 @@ init_iova_domain(struct iova_domain *iovad, unsigned long
granule,
init_iova_rcaches(iovad);
/*
-* Insert boundary nodes for dma32. So cached32_node can not be NULL in
-* future.
+* Insert boundary nodes for dma32 and dma64. So cached32_node and
+* cached64_node can not be NULL in future.
*/
insert_iova_boundary(iovad);
}
@@ -75,10 +80,10 @@ __get_cached_rbnode(struct iova_domain *iovad, unsigned
long *limit_pfn)
struct rb_node *cached_node;
struct rb_node *next_node;
- if (*limit_pfn > iovad->dma_32bit_pfn)
- return rb_last(&iovad->rbroot);
- else
+ if (*limit_pfn <= iovad->dma_32bit_pfn)
cached_node = iovad->cached32_node;
+ else
+ cached_node = iovad->cached64_node;
next_node = rb_next(cached_node);
if (next_node) {
@@ -94,29 +99,32 @@ static void
__cached_rbnode_insert_update(struct iova_domain *iovad, struct iova *new)
{
struct iova *cached_iova;
+ struct rb_node **cached_node;
- if (new->pfn_hi > iovad->dma_32bit_pfn)
- return;
+ if (new->pfn_hi <= iovad->dma_32bit_pfn)
+ cached_node = &iovad->cached32_node;
+ else
+ cached_node = &iovad->cached64_node;
- cached_iova = rb_entry(iovad->cached32_node, struct iova, node);
+ cached_iova = rb_entry(*cached_node, struct iova, node);
if (new->pfn_lo <= cached_iova->pfn_lo)
- iovad->cached32_node = rb_prev(&new->node);
+ *cached_node = rb_prev(&new->node);
}
static void
__cached_rbnode_delete_update(struct iova_domain *iovad, struct iova *free)
{
struct iova *cached_iova;
- struct rb_node *curr;
+ struct rb_node **cached_node;
- curr = iovad->cached32_node;
- cached_iova = rb_entry(curr, struct iova, node);
+ if (free->pfn_hi <= iovad->dma_32bit_pfn)
+ cached_node = &iovad->cached32_node;
+ else
+ cached_node = &iovad->cached64_node;
- if (free->pfn_lo >= cached_iova->pfn_lo) {
- /* only cache if it's below 32bit pfn */
- if (free->pfn_hi <= iovad->dma_32bit_pfn)
- iovad->cached32_node = rb_prev(&free->node);
- }
+ cached_iova = rb_entry(*cached_node, struct iova, node);
+ if (free->pfn_lo >= cached_iova->pfn_lo)
+ *cached_node = rb_prev(&free->node);
}
/* Insert the iova into domain rbtree by holding writer lock */
@@ -262,7 +270,7 @@ EXPORT_SYMBOL_GPL(iova_cache_put);
* alloc_iova - allocates an iova
* @iovad: - iova domain in question
* @size: - size of page frames to allocate
- * @limit_pfn: - max limit address
+ * @limit_pfn: - max limit address(included)
* @size_aligned: - set if size_aligned address range is required
* This function allocates an iova in the range iovad->start_pfn to limit_pfn,
* searching top-down from limit_pfn to iovad->start_pfn. If the size_aligned
@@ -381,7 +389,7 @@ EXPORT_SYMBOL_GPL(free_iova);
* alloc_iova_fast - allocates an iova from rcache
* @iovad: - iova domain in question
* @size: - size of page frames to
[PATCH v3 0/6] iommu/iova: improve the allocation performance of dma64
v2 -> v3:
It's been a long time. I have not received any advise except Robin Murphy's. So
the major changes is just deleted an old patch ("iommu/iova: fix incorrect
variable types")
and merged it into patch 5 of this version.
v1 -> v2:
Because the problem of my email-server, all patches sent to Joerg Roedel
failed.
So I repost all these patches again, there is no changes.
v1:
64 bits devices is very common now. But currently we only defined a
cached32_node
to optimize the allocation performance of dma32, and I saw some dma64 drivers
chose
to allocate iova from dma32 space first, maybe becuase of current dma64
performance
problem or some other reasons.
For example:(in drivers/iommu/amd_iommu.c)
static unsigned long dma_ops_alloc_iova(..
{
..
if (dma_mask > DMA_BIT_MASK(32))
pfn = alloc_iova_fast(&dma_dom->iovad, pages,
IOVA_PFN(DMA_BIT_MASK(32)));
if (!pfn)
pfn = alloc_iova_fast(&dma_dom->iovad, pages,
IOVA_PFN(dma_mask));
For the details of why dma64 iova allocation performance is very bad, please
refer the
description of patch-5.
In this patch series, I added a cached64_node to manage the dma64 iova
space(iova>=4G), it
takes the same effect as cached32_node(iova<4G).
Below it's the performance data before and after my patch series:
(before)$ iperf -s
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
[ 4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35898
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.2 sec 7.88 MBytes 6.48 Mbits/sec
[ 5] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35900
[ 5] 0.0-10.3 sec 7.88 MBytes 6.43 Mbits/sec
[ 4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 35902
[ 4] 0.0-10.3 sec 7.88 MBytes 6.43 Mbits/sec
(after)$ iperf -s
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
[ 4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36330
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.09 GBytes 933 Mbits/sec
[ 5] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36332
[ 5] 0.0-10.0 sec 1.10 GBytes 939 Mbits/sec
[ 4] local 192.168.1.106 port 5001 connected with 192.168.1.198 port 36334
[ 4] 0.0-10.0 sec 1.10 GBytes 938 Mbits/sec
Zhen Lei (6):
iommu/iova: cut down judgement times
iommu/iova: insert start_pfn boundary of dma32
iommu/iova: adjust __cached_rbnode_insert_update
iommu/iova: to optimize the allocation performance of dma64
iommu/iova: move the caculation of pad mask out of loop
iommu/iova: fix iovad->dma_32bit_pfn as the last pfn of dma32
drivers/iommu/amd_iommu.c| 7 +-
drivers/iommu/dma-iommu.c| 21 ++
drivers/iommu/intel-iommu.c | 11 +--
drivers/iommu/iova.c | 143 +--
drivers/misc/mic/scif/scif_rma.c | 3 +-
include/linux/iova.h | 7 +-
6 files changed, 93 insertions(+), 99 deletions(-)
--
2.5.0
[PATCH v3 2/6] iommu/iova: insert start_pfn boundary of dma32
Reserve the first granule size memory(start at start_pfn) as boundary
iova, to make sure that iovad->cached32_node can not be NULL in future.
Meanwhile, changed the assignment of iovad->cached32_node from rb_next to
rb_prev of &free->node in function __cached_rbnode_delete_update.
Signed-off-by: Zhen Lei
---
drivers/iommu/iova.c | 63 ++--
1 file changed, 37 insertions(+), 26 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 333a9cc..d0c19ec 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -32,6 +32,17 @@ static unsigned long iova_rcache_get(struct iova_domain
*iovad,
static void init_iova_rcaches(struct iova_domain *iovad);
static void free_iova_rcaches(struct iova_domain *iovad);
+static void
+insert_iova_boundary(struct iova_domain *iovad)
+{
+ struct iova *iova;
+ unsigned long start_pfn_32bit = iovad->start_pfn;
+
+ iova = reserve_iova(iovad, start_pfn_32bit, start_pfn_32bit);
+ BUG_ON(!iova);
+ iovad->cached32_node = &iova->node;
+}
+
void
init_iova_domain(struct iova_domain *iovad, unsigned long granule,
unsigned long start_pfn, unsigned long pfn_32bit)
@@ -45,27 +56,38 @@ init_iova_domain(struct iova_domain *iovad, unsigned long
granule,
spin_lock_init(&iovad->iova_rbtree_lock);
iovad->rbroot = RB_ROOT;
- iovad->cached32_node = NULL;
iovad->granule = granule;
iovad->start_pfn = start_pfn;
iovad->dma_32bit_pfn = pfn_32bit;
init_iova_rcaches(iovad);
+
+ /*
+* Insert boundary nodes for dma32. So cached32_node can not be NULL in
+* future.
+*/
+ insert_iova_boundary(iovad);
}
EXPORT_SYMBOL_GPL(init_iova_domain);
static struct rb_node *
__get_cached_rbnode(struct iova_domain *iovad, unsigned long *limit_pfn)
{
- if ((*limit_pfn > iovad->dma_32bit_pfn) ||
- (iovad->cached32_node == NULL))
+ struct rb_node *cached_node;
+ struct rb_node *next_node;
+
+ if (*limit_pfn > iovad->dma_32bit_pfn)
return rb_last(&iovad->rbroot);
- else {
- struct rb_node *prev_node = rb_prev(iovad->cached32_node);
- struct iova *curr_iova =
- rb_entry(iovad->cached32_node, struct iova, node);
- *limit_pfn = curr_iova->pfn_lo - 1;
- return prev_node;
+ else
+ cached_node = iovad->cached32_node;
+
+ next_node = rb_next(cached_node);
+ if (next_node) {
+ struct iova *next_iova = rb_entry(next_node, struct iova, node);
+
+ *limit_pfn = min(*limit_pfn, next_iova->pfn_lo - 1);
}
+
+ return cached_node;
}
static void
@@ -83,20 +105,13 @@ __cached_rbnode_delete_update(struct iova_domain *iovad,
struct iova *free)
struct iova *cached_iova;
struct rb_node *curr;
- if (!iovad->cached32_node)
- return;
curr = iovad->cached32_node;
cached_iova = rb_entry(curr, struct iova, node);
if (free->pfn_lo >= cached_iova->pfn_lo) {
- struct rb_node *node = rb_next(&free->node);
- struct iova *iova = rb_entry(node, struct iova, node);
-
/* only cache if it's below 32bit pfn */
- if (node && iova->pfn_lo < iovad->dma_32bit_pfn)
- iovad->cached32_node = node;
- else
- iovad->cached32_node = NULL;
+ if (free->pfn_hi <= iovad->dma_32bit_pfn)
+ iovad->cached32_node = rb_prev(&free->node);
}
}
@@ -142,7 +157,7 @@ static int __alloc_and_insert_iova_range(struct iova_domain
*iovad,
unsigned long size, unsigned long limit_pfn,
struct iova *new, bool size_aligned)
{
- struct rb_node *prev, *curr = NULL;
+ struct rb_node *prev, *curr;
unsigned long flags;
unsigned long saved_pfn;
unsigned int pad_size = 0;
@@ -172,13 +187,9 @@ static int __alloc_and_insert_iova_range(struct
iova_domain *iovad,
curr = rb_prev(curr);
}
- if (!curr) {
- if (size_aligned)
- pad_size = iova_get_pad_size(size, limit_pfn);
- if ((iovad->start_pfn + size + pad_size) > limit_pfn) {
- spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags);
- return -ENOMEM;
- }
+ if (unlikely(!curr)) {
+ spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags);
+ return -ENOMEM;
}
/* pfn_lo will point to size aligned address if size_aligned is set */
--
2.5.0
[PATCH v3 6/6] iommu/iova: fix iovad->dma_32bit_pfn as the last pfn of dma32
To make sure iovad->cached32_node and iovad->cached64_node can exactly
control dma32 and dma64 area. It also help us to remove the parameter
pfn_32bit of init_iova_domain.
Signed-off-by: Zhen Lei
---
drivers/iommu/amd_iommu.c| 7 ++-
drivers/iommu/dma-iommu.c| 21 -
drivers/iommu/intel-iommu.c | 11 +++
drivers/iommu/iova.c | 4 ++--
drivers/misc/mic/scif/scif_rma.c | 3 +--
include/linux/iova.h | 2 +-
6 files changed, 13 insertions(+), 35 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 63cacf5..9aebfa6 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -61,7 +61,6 @@
/* IO virtual address start page frame number */
#define IOVA_START_PFN (1)
#define IOVA_PFN(addr) ((addr) >> PAGE_SHIFT)
-#define DMA_32BIT_PFN IOVA_PFN(DMA_BIT_MASK(32))
/* Reserved IOVA ranges */
#define MSI_RANGE_START(0xfee0)
@@ -1776,8 +1775,7 @@ static struct dma_ops_domain *dma_ops_domain_alloc(void)
if (!dma_dom->domain.pt_root)
goto free_dma_dom;
- init_iova_domain(&dma_dom->iovad, PAGE_SIZE,
-IOVA_START_PFN, DMA_32BIT_PFN);
+ init_iova_domain(&dma_dom->iovad, PAGE_SIZE, IOVA_START_PFN);
/* Initialize reserved ranges */
copy_reserved_iova(&reserved_iova_ranges, &dma_dom->iovad);
@@ -2747,8 +2745,7 @@ static int init_reserved_iova_ranges(void)
struct pci_dev *pdev = NULL;
struct iova *val;
- init_iova_domain(&reserved_iova_ranges, PAGE_SIZE,
-IOVA_START_PFN, DMA_32BIT_PFN);
+ init_iova_domain(&reserved_iova_ranges, PAGE_SIZE, IOVA_START_PFN);
lockdep_set_class(&reserved_iova_ranges.iova_rbtree_lock,
&reserved_rbtree_key);
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 8348f366..b3455d4 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -290,18 +290,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain,
dma_addr_t base,
/* ...then finally give it a kicking to make sure it fits */
base_pfn = max_t(unsigned long, base_pfn,
domain->geometry.aperture_start >> order);
- end_pfn = min_t(unsigned long, end_pfn,
- domain->geometry.aperture_end >> order);
}
- /*
-* PCI devices may have larger DMA masks, but still prefer allocating
-* within a 32-bit mask to avoid DAC addressing. Such limitations don't
-* apply to the typical platform device, so for those we may as well
-* leave the cache limit at the top of their range to save an rb_last()
-* traversal on every allocation.
-*/
- if (dev && dev_is_pci(dev))
- end_pfn &= DMA_BIT_MASK(32) >> order;
/* start_pfn is always nonzero for an already-initialised domain */
if (iovad->start_pfn) {
@@ -310,19 +299,17 @@ int iommu_dma_init_domain(struct iommu_domain *domain,
dma_addr_t base,
pr_warn("Incompatible range for DMA domain\n");
return -EFAULT;
}
- /*
-* If we have devices with different DMA masks, move the free
-* area cache limit down for the benefit of the smaller one.
-*/
- iovad->dma_32bit_pfn = min(end_pfn, iovad->dma_32bit_pfn);
return 0;
}
- init_iova_domain(iovad, 1UL << order, base_pfn, end_pfn);
+ init_iova_domain(iovad, 1UL << order, base_pfn);
if (!dev)
return 0;
+ if (end_pfn < iovad->dma_32bit_pfn)
+ dev_dbg(dev, "ancient device or dma range missed some bits?");
+
return iova_reserve_iommu_regions(dev, domain);
}
EXPORT_SYMBOL(iommu_dma_init_domain);
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 90ab011..266b96b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -82,8 +82,6 @@
#define IOVA_START_PFN (1)
#define IOVA_PFN(addr) ((addr) >> PAGE_SHIFT)
-#define DMA_32BIT_PFN IOVA_PFN(DMA_BIT_MASK(32))
-#define DMA_64BIT_PFN IOVA_PFN(DMA_BIT_MASK(64))
/* page table handling */
#define LEVEL_STRIDE (9)
@@ -1874,8 +1872,7 @@ static int dmar_init_reserved_ranges(void)
struct iova *iova;
int i;
- init_iova_domain(&reserved_iova_list, VTD_PAGE_SIZE, IOVA_START_PFN,
- DMA_32BIT_PFN);
+ init_iova_domain(&reserved_iova_list, VTD_PAGE_SIZE, IOVA_START_PFN);
lockdep_set_class(&reserved_iova_list.iova_rbtree_lock,
&reserved_rbtree_key);
@@ -1933,8 +1930,7 @@ static int domain_init(struct dmar_domain *domain, struct
intel_iommu *iommu,
int adjust_width,
Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure
On 2017.05.18 at 09:40 +0200, Peter Zijlstra wrote: > On Wed, May 17, 2017 at 07:36:46PM +0200, Markus Trippelsdorf wrote: > > Since: > > commit cfafcd117da0216520568c195cb2f6cd1980c4bb > > Author: Peter Zijlstra > > Date: Wed Mar 22 11:35:58 2017 +0100 > > > > futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock() > > > > glibc's nptl/tst-robustpi8 testcase fails: > > > > glibc-build % ./nptl/tst-robustpi8 > > tst-robustpi8: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full: > > Assertion `INTERNAL_SYSCALL_ERRNO (e, __err) != ESRCH || !robust' failed. > > OK, so how do I get those tests build? > > I did a checkout of glibc.git > > glibc$ mkdir build; cd build > build$ ../configure --disable-sanity-checks ; make -j40 > build$ ./nptl/tst-robustpi8 > -bash: ./nptl/tst-robustpi8: No such file or directory > > "make tests" doesn't seem to work either even though its a build target > listed in the Makefiles. > > What magic incantation do I need? Something like: % ~/glibc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --with-headers=/usr/include --enable-add-ons --enable-kernel=4.10 --with-tls --with-__thread --enable-bind-now --without-gd --without-cvs --disable-profile --disable-multi-arch --disable-werror % make -j128 % make -j128 check But I've attached the testcase, so building should be unnecessary. -- Markus tst-robustpi8.xz Description: Binary data
[PATCH v3 3/4] irqchip: armada-370-xp: re-enable per-CPU interrupts at resume time
Commit d17cab4451df1 ("irqchip: Kill off set_irq_flags usage") changed
the code of armada_370_xp_mpic_irq_map() from using set_irq_flags() to
irq_set_probe().
While the commit log seems to imply that there are no functional
changes, there are indeed functional changes introduced by this commit:
the IRQ_NOAUTOEN flag is no longer cleared. This functional change
caused a regression on Armada XP, which no longer works properly after
suspend/resume because per-CPU interrupts remain disabled. This
regression was temporarly worked around in commit
353d6d6c82e5d ("irqchip/armada-370-xp: Fix regression by clearing
IRQ_NOAUTOEN"), but it is not the most satisfying solution. This commit
implements the solution that was initially discussed with Thomas
Gleixner.
Due to how the hardware registers work, the irq-armada-370-xp cannot
simply save/restore a bunch of registers at suspend/resume to make sure
that the interrupts remain in the same state after resuming. Therefore,
it relies on the kernel to say whether the interrupt is disabled or not,
using the irqd_irq_disabled() function. This was all working fine while
the IRQ_NOAUTOEN flag was cleared.
With the change introduced by Rob Herring in d17cab4451df1, the
IRQ_NOAUTOEN flag is now set for all interrupts. irqd_irq_disabled()
returns false for per-CPU interrupts, and therefore our per-CPU
interrupts are no longer re-enabled after resume.
This commit fixes that by using irqd_irq_disabled() only for global
interrupts, and using the newly introduced irq_percpu_is_enabled() for
per-CPU interrupts.
Also, it fixes a related problems that per-CPU interrupts were only
re-enabled on the boot CPU and not other CPUs. Until now this wasn't a
problem since on this platform, only the local timers are using per-CPU
interrupts and the local timers of secondary CPUs are turned off/on
during CPU hotplug before suspend, after after resume. However, since
Linux 4.4, we are also be using per-CPU interrupts for the network
controller, so we need to properly restore the per-CPU interrupts on
secondary CPUs as well.
Signed-off-by: Thomas Petazzoni
---
drivers/irqchip/irq-armada-370-xp.c | 46 -
1 file changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-armada-370-xp.c
b/drivers/irqchip/irq-armada-370-xp.c
index 1f7dea6..1d4de6e 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -360,7 +360,6 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
irq_set_percpu_devid(virq);
irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
handle_percpu_devid_irq);
-
} else {
irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
handle_level_irq);
@@ -424,16 +423,40 @@ static void armada_mpic_send_doorbell(const struct
cpumask *mask,
ARMADA_370_XP_SW_TRIG_INT_OFFS);
}
+static void armada_xp_mpic_reenable_percpu(void)
+{
+ unsigned int irq;
+
+ /* Re-enable per-CPU interrupts that were enabled before suspend */
+ for (irq = 0; irq < ARMADA_370_XP_MAX_PER_CPU_IRQS; irq++) {
+ struct irq_data *data;
+ int virq;
+
+ virq = irq_linear_revmap(armada_370_xp_mpic_domain, irq);
+ if (virq == 0)
+ continue;
+
+ data = irq_get_irq_data(virq);
+
+ if (!irq_percpu_is_enabled(virq))
+ continue;
+
+ armada_370_xp_irq_unmask(data);
+ }
+}
+
static int armada_xp_mpic_starting_cpu(unsigned int cpu)
{
armada_xp_mpic_perf_init();
armada_xp_mpic_smp_cpu_init();
+ armada_xp_mpic_reenable_percpu();
return 0;
}
static int mpic_cascaded_starting_cpu(unsigned int cpu)
{
armada_xp_mpic_perf_init();
+ armada_xp_mpic_reenable_percpu();
enable_percpu_irq(parent_irq, IRQ_TYPE_NONE);
return 0;
}
@@ -581,16 +604,27 @@ static void armada_370_xp_mpic_resume(void)
if (virq == 0)
continue;
- if (!is_percpu_irq(irq))
+ data = irq_get_irq_data(virq);
+
+ if (!is_percpu_irq(irq)) {
+ /* Non per-CPU interrupts */
writel(irq, per_cpu_int_base +
ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
- else
+ if (!irqd_irq_disabled(data))
+ armada_370_xp_irq_unmask(data);
+ } else {
+ /* Per-CPU interrupts */
writel(irq, main_int_base +
ARMADA_370_XP_INT_SET_ENABLE_OFFS);
- data = irq_get_irq_data(virq);
- if (!irqd_irq_disabled(data))
- armada_370_xp_irq_unmask(data);
+ /*
+
[PATCH v3 1/4] irqchip: armada-370-xp: re-order register definitions
In order to clarify to which register base the various register definitions apply, this commit re-orders them, and adds a comment that clearly indicate which registers are relative to "main_int_base" and which registers are relative to "per_cpu_int_base". Signed-off-by: Thomas Petazzoni Acked-by: Gregory CLEMENT --- drivers/irqchip/irq-armada-370-xp.c | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c index eb0d4d4..76147df 100644 --- a/drivers/irqchip/irq-armada-370-xp.c +++ b/drivers/irqchip/irq-armada-370-xp.c @@ -34,25 +34,24 @@ #include #include -/* Interrupt Controller Registers Map */ -#define ARMADA_370_XP_INT_SET_MASK_OFFS(0x48) -#define ARMADA_370_XP_INT_CLEAR_MASK_OFFS (0x4C) -#define ARMADA_370_XP_INT_FABRIC_MASK_OFFS (0x54) -#define ARMADA_370_XP_INT_CAUSE_PERF(cpu) (1 << cpu) - +/* Registers relative to main_int_base */ #define ARMADA_370_XP_INT_CONTROL (0x00) +#define ARMADA_370_XP_SW_TRIG_INT_OFFS (0x04) #define ARMADA_370_XP_INT_SET_ENABLE_OFFS (0x30) #define ARMADA_370_XP_INT_CLEAR_ENABLE_OFFS(0x34) #define ARMADA_370_XP_INT_SOURCE_CTL(irq) (0x100 + irq*4) #define ARMADA_370_XP_INT_SOURCE_CPU_MASK 0xF #define ARMADA_370_XP_INT_IRQ_FIQ_MASK(cpuid) ((BIT(0) | BIT(8)) << cpuid) -#define ARMADA_370_XP_CPU_INTACK_OFFS (0x44) +/* Registers relative to per_cpu_int_base */ +#define ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS (0x08) +#define ARMADA_370_XP_IN_DRBEL_MSK_OFFS(0x0c) #define ARMADA_375_PPI_CAUSE (0x10) - -#define ARMADA_370_XP_SW_TRIG_INT_OFFS (0x4) -#define ARMADA_370_XP_IN_DRBEL_MSK_OFFS (0xc) -#define ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS(0x8) +#define ARMADA_370_XP_CPU_INTACK_OFFS (0x44) +#define ARMADA_370_XP_INT_SET_MASK_OFFS(0x48) +#define ARMADA_370_XP_INT_CLEAR_MASK_OFFS (0x4C) +#define ARMADA_370_XP_INT_FABRIC_MASK_OFFS (0x54) +#define ARMADA_370_XP_INT_CAUSE_PERF(cpu) (1 << cpu) #define ARMADA_370_XP_MAX_PER_CPU_IRQS (28) -- 2.7.4
[PATCH v3 4/4] Revert "irqchip/armada-370-xp: Fix regression by clearing IRQ_NOAUTOEN"
This reverts commit 353d6d6c82e5d2533ba22e7f9fb081582bf50dc2, which is no longer needed, now that the irq-armada-370-xp driver properly re-enables per-CPU interrupt on both the boot CPU and secondary CPUs after resume. Signed-off-by: Thomas Petazzoni --- drivers/irqchip/irq-armada-370-xp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c index 1d4de6e..577b428 100644 --- a/drivers/irqchip/irq-armada-370-xp.c +++ b/drivers/irqchip/irq-armada-370-xp.c @@ -365,7 +365,6 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h, handle_level_irq); } irq_set_probe(virq); - irq_clear_status_flags(virq, IRQ_NOAUTOEN); return 0; } -- 2.7.4
[PATCH v3 2/4] irqchip: armada-370-xp: document the overall driver logic
Since the overall logic of the driver to handle the global and per-CPU masking of the interrupts is far from trivial, this commit adds a long comment detailing how the hardware operates and what strategy the driver implements on top of that. Signed-off-by: Thomas Petazzoni Acked-by: Gregory CLEMENT --- drivers/irqchip/irq-armada-370-xp.c | 80 + 1 file changed, 80 insertions(+) diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c index 76147df..1f7dea6 100644 --- a/drivers/irqchip/irq-armada-370-xp.c +++ b/drivers/irqchip/irq-armada-370-xp.c @@ -34,6 +34,86 @@ #include #include +/* + * Overall diagram of the Armada XP interrupt controller: + * + *To CPU 0 To CPU 1 + * + * /\ /\ + * || || + * +---+ +---+ + * | || | + * |per-CPU||per-CPU| + * | mask/unmask || mask/unmask | + * | CPU0 || CPU1 | + * | || | + * +---++---+ + */\ /\ + *|| || + *\\___// + * || + *+---+ + *| | + *| Global interrupt | + *|mask/unmask| + *| | + *+---+ + * /\ + * || + * interrupt from + * device + * + * The "global interrupt mask/unmask" is modified using the + * ARMADA_370_XP_INT_SET_ENABLE_OFFS and + * ARMADA_370_XP_INT_CLEAR_ENABLE_OFFS registers, which are relative + * to "main_int_base". + * + * The "per-CPU mask/unmask" is modified using the + * ARMADA_370_XP_INT_SET_MASK_OFFS and + * ARMADA_370_XP_INT_CLEAR_MASK_OFFS registers, which are relative to + * "per_cpu_int_base". This base address points to a special address, + * which automatically accesses the registers of the current CPU. + * + * The per-CPU mask/unmask can also be adjusted using the global + * per-interrupt ARMADA_370_XP_INT_SOURCE_CTL register, which we use + * to configure interrupt affinity. + * + * Due to this model, all interrupts need to be mask/unmasked at two + * different levels: at the global level and at the per-CPU level. + * + * This driver takes the following approach to deal with this: + * + * - For global interrupts: + * + *At ->map() time, a global interrupt is unmasked at the per-CPU + *mask/unmask level. It is therefore unmasked at this level for + *the current CPU, running the ->map() code. This allows to have + *the interrupt unmasked at this level in non-SMP + *configurations. In SMP configurations, the ->set_affinity() + *callback is called, which using the + *ARMADA_370_XP_INT_SOURCE_CTL() readjusts the per-CPU mask/unmask + *for the interrupt. + * + *The ->mask() and ->unmask() operations only mask/unmask the + *interrupt at the "global" level. + * + *So, a global interrupt is enabled at the per-CPU level as soon + *as it is mapped. At run time, the masking/unmasking takes place + *at the global level. + * + * - For per-CPU interrupts + * + *At ->map() time, a per-CPU interrupt is unmasked at the global + *mask/unmask level. + * + *The ->mask() and ->unmask() operations mask/unmask the interrupt + *at the per-CPU level. + * + *So, a per-CPU interrupt is enabled at the global level as soon + *as it is mapped. At run time, the masking/unmasking takes place + *at the per-CPU level. + */ + /* Registers relative to main_int_base */ #define ARMADA_370_XP_INT_CONTROL (0x00) #define ARMADA_370_XP_SW_TRIG_INT_OFFS (0x04) -- 2.7.4
Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32
On Wed, May 17, 2017 at 09:16:47PM +, Chris Packham wrote: > MV64x60 is pretty old. I considered gutting mv64x60_edac.c to make a > separate driver but that would just be more code to maintain. Well, one thing we did with layerscape and mpc85xx EDAC modules is share the FSL memory controller IP through fsl_ddr_edac.c which both modules link. I dunno, perhaps you could do something similar by extracting the common parts and this way avoid any breakage of the PPC side of things - since apparently finding such hw is not easy - and then link those into your driver. And your driver could just be a wrapper containing the EDAC glue to make it a separate ARM armada_edac.c or so. Anyway, just an idea. Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH v3 0/4] irqchip: armada-370-xp: remove IRQ_NOAUTOEN workaround
Hello,
This is the third version of a patch series initially posted in
October 2015, under the title:
[PATCH 0/5] Fix regression introduced by set_irq_flags() removal
at the time, the regression was worked around in commit
353d6d6c82e5d2533ba22e7f9fb081582bf50dc2 ("irqchip/armada-370-xp: Fix
regression by clearing IRQ_NOAUTOEN") and this series brings the
proper fix for the original issue, while reverting the work around.
Changes since v2:
- Rebased on top of v4.12-rc1.
Changes since v1:
- Rebased on top of v4.10.
- Patch "kernel: irq: implement is_enabled_percpu_irq()" dropped,
since it has been merged upstream as commit
f0cb32207307e9d7b3ee8117078b7a37f8d0166e ("genirq: Implement
irq_percpu_is_enabled()")
- Patch "irqchip: armada-370-xp: prepare additions to
armada_xp_mpic_secondary_init()" dropped, since similar changes
were merged as part of the overall CPU hotplug rework.
- Patches "irqchip: armada-370-xp: re-order register definitions" and
"irqchip: armada-370-xp: document the overall driver logic" moved
at the beginning of the series.
- Acked-by added on "irqchip: armada-370-xp: re-order register
definitions" and "irqchip: armada-370-xp: document the overall
driver logic"
- In patch "irqchip: armada-370-xp: document the overall driver
logic", fix minor presentation detail in the ASCII art diagram.
- In patch "irqchip: armada-370-xp: re-enable per-CPU interrupts at
resume time":
- Move the per-CPU interrupt re-enabling logic for secondary cores
into a utility function armada_xp_mpic_reenable_percpu() called
by both armada_xp_mpic_starting_cpu() and
mpic_cascaded_starting_cpu().
- Instead of iterating on all IRQs and filtering the per-CPU ones,
only iterate on the first ARMADA_370_XP_MAX_PER_CPU_IRQS, which
are the only per-CPU ones. Suggested by Grégory Clement.
- Use the irq_percpu_is_enabled() API, which was the one actually
merged, instead of the one originally proposed in the v1 of this
series.
- Addition of a patch reverting the work around.
Thanks,
Thomas
Thomas Petazzoni (4):
irqchip: armada-370-xp: re-order register definitions
irqchip: armada-370-xp: document the overall driver logic
irqchip: armada-370-xp: re-enable per-CPU interrupts at resume time
Revert "irqchip/armada-370-xp: Fix regression by clearing
IRQ_NOAUTOEN"
drivers/irqchip/irq-armada-370-xp.c | 146 +++-
1 file changed, 129 insertions(+), 17 deletions(-)
--
2.7.4
Re: [PATCH 06/21] VFS: Introduce a superblock configuration context [ver #3]
On Wed, May 17, 2017 at 1:31 PM, David Howells wrote: > Miklos Szeredi wrote: > >> > (b) is internal-only at the moment, used by NFS submounts as triggered by >> > automounts. There isn't currently any way to supply mount options to this. >> >> And all blockdev based fs. > > I see what you're getting at. In which case there are more cases: > > (a) new mount, new sb struct with no source (eg. procfs, sysfs, tmpfs) > (b) new mount, new sb struct, params loaded from filesystem data (eg. bdev) > (c) new mount, new sb struct, params derived from parent (eg. NFS automount) > (d) new mount, shared extant sb struct > (e) remount > > In the case of (d) where we're attempting to make another mount for an extant > super_block struct and we need to check the consistency of the parameters. Yes. Current behavior seems to just ignore given options (except MS_RDONLY) in that case, so we need to keep that possibility. Also I think it would be good to allow selecting when superblock is created: - non-exclusive create: if exists return it, if not create it - exclusive create: only create if non-existent - non-create: only return if exists > >> > Ah - but some of these options have to be set *inside* sget() or before the >> > superblock becomes live, even the ones that can be changed in-flight. >> >> That would be the "???" category. Any concrete examples? > > NFS is a good example. You need parameters that indicate the server to talk > to and specify I/O parameters before you even get the superblock as you have > to talk to the server first. I think this is particularly true of NFSv2/3 > where you need to talk to mountd. > > This would also be true of AFS. There you have to access the network to look > up the volume ID before you can call sget() as the volume ID is part of the > index key to the set of super_block structs. > > Further, some of these values (I/O parameters in NFS's case, for example) form > part of the super_block struct index key, so you have to set those inside > sget()'s set callback. So what I propose is: 1) call ->parse_option() would get indication what we are trying to do (find and/or create and/or reconfig) this step is optional, the the filesystem type could possibly be enough for the following steps 2) call ->get_tree() pass sc containing parsed options and flags controlling the creation of the superblock (create/exclusive) this step is optional, not called if we are given an sb to work with (i.e. only reconfig) 3) call ->reconfig() pass sc containing parsed options this step is optional, we might be instructed just to find or create the sb > >> >> Also I think silently ignoring options is not always the right answer. >> > >> > Example? >> >> mount /dev/sda -oacl /mnt >> mount /dev/sda -onoacl /mnt2 > > So you'd like to give an error or a warning if ACLs are not supported, either > by the filesystem or the kernel as a whole? What I was getting at is that the second mount will ignore the "noacl" option. It's not something we apparently care much about (but will definitely want to keep as back-compat thing for the mount(2) interface). But for the new interface I think we need something less crazy. One solution would be the exclusive create, which doesn't have this problem. Maybe that's enough; not sure if we need anything more sophisticated. >> You are thinking on the wrong level. Of course mount(2) needs to >> handle MS_NOSUID et al. But it's doing it now, and it isn't parsing >> "nosuid", just translating MS_NOSUID to MNT_NOSUID. > > Ummm... That's done by the parser in this case, so effectively it is. Where exactly? You are not touching do_mount(), which is where the MS_*** -> MNT_*** translation is done. >> For the fsopen() case you won't need to parse "nosuid" because that's a flag >> for fsmount(). > > Whilst this is true, that means that the parser has to operate differently in > the mount(2) and fsopen(2) cases - which I was trying to avoid. I don't get it. We never passed MNT_* options as strings to the kernel. That was parsed by mount(8) and translated to MS_* flags. So how would mount(2) and fsopen(2) need to operate differently regarding parsing MNT_* options, when we want neither to do it? >> The only thing fsmount() should take from the sc is the root_dentry. >> It should be equivalent to what currently is a bind mount, except it >> should be able to fully configure the new mount. > > It needs to take the device name as well. I wonder if it would be possible to > store the device name on the superblock and then leave a path-in-mount in the Ah, mnt_devname. The device name as just a special type of option and as such should be stored in the superblock. > vfsmount struct to fabricate a :/ later. Though this would > change the behaviour if someone did: > > mknod /dev/foo b 8 1 > mknod /dev/bar b 8 1 > mount /dev/foo /mnt/foo > mount /dev/bar /mnt/bar > > as /pr
Re: [PATCH] ASoC: audio-graph-card: fix spelling mistake: "missmatch" -> "mismatch"
Hi Colin
> From: Colin Ian King
>
> Trivial fix to spelling mistake in dev_err message
>
> Signed-off-by: Colin Ian King
> ---
Grr... I want to have brown paper bag
Acked-by: Kuninori Morimoto
> sound/soc/generic/audio-graph-card.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/generic/audio-graph-card.c
> b/sound/soc/generic/audio-graph-card.c
> index 07e010d38596..e0c26380921e 100644
> --- a/sound/soc/generic/audio-graph-card.c
> +++ b/sound/soc/generic/audio-graph-card.c
> @@ -107,7 +107,7 @@ static int asoc_graph_card_dai_link_of(struct device_node
> *cpu_port,
> int ret;
>
> if (rcpu_ep != cpu_ep) {
> - dev_err(dev, "remote-endpoint missmatch (%s/%s/%s)\n",
> + dev_err(dev, "remote-endpoint mismatch (%s/%s/%s)\n",
> cpu_ep->name, codec_ep->name, rcpu_ep->name);
> ret = -EINVAL;
> goto dai_link_of_err;
> --
> 2.11.0
>
Re: [RESEND PATCH v3] sched/deadline: Remove unnecessary condition in push_dl_task()
Hi, On 18/05/17 11:00, Byungchul Park wrote: > On Fri, May 12, 2017 at 10:05:59AM +0900, Byungchul Park wrote: > > pick_next_pushable_dl_task(rq) has BUG_ON(rq->cpu != task_cpu(task)) > > when it returns a task other than NULL, which means that task_cpu(task) > > must be rq->cpu. So if task == next_task, then task_cpu(next_task) must > > be rq->cpu as well. Remove the redundant condition and make code simpler. > > > > By this patch, unnecessary one branch and two LOAD operations in 'if' > > statement can be avoided. > > +cc rost...@goodmis.org > +cc juri.le...@arm.com > +cc bris...@redhat.com > > > > > Signed-off-by: Byungchul Park > > Reviewed-by: Steven Rostedt (VMware) > > Reviewed-by: Juri Lelli It looked, and still looks, good to me. :) Thanks, - Juri
Re: [PATCH 4.4-only] openvswitch: clear sender cpu before forwarding packets
On Wed, May 17, 2017 at 10:21:09AM +0100, Anoob Soman wrote: > On 17/05/17 09:19, Greg KH wrote: > > Why is this a non-upstream patch? What commit in Linus's tree fixed > > this? Why not just backport that? > > > > thanks, > > > > greg k-h > > Agreed, I think it is sensible to backport 52bd2d62ce67 "net: better > skb->sender_cpu and skb->napi_id cohabitation" to 4.4, rather than having a > different patch. So backporting that one patch solves the issue here? Can you please verify it, and let me know before I apply it? thanks, greg k-h
Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure
On 05/18/2017 09:40 AM, Peter Zijlstra wrote: > OK, so how do I get those tests build? > > I did a checkout of glibc.git > > glibc$ mkdir build; cd build > build$ ../configure --disable-sanity-checks ; make -j40 > build$ ./nptl/tst-robustpi8 > -bash: ./nptl/tst-robustpi8: No such file or directory > > "make tests" doesn't seem to work either even though its a build target > listed in the Makefiles. This builds the nptl test: make subdirs=nptl run-built-tests=no To run a single test, use this: bash -x testrun.sh nptl/tst-robustpi8 This is required because the test might not be compatible with the installed glibc (some nptl tests are whitebox tests). You can feed the command line printed due to “bash -x” into strace or a debugger. The environment variable settings aren't necessary for most tests. Thanks, Florian
Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure
On Thu, May 18, 2017 at 10:04:39AM +0200, Markus Trippelsdorf wrote: > On 2017.05.18 at 09:40 +0200, Peter Zijlstra wrote: > > On Wed, May 17, 2017 at 07:36:46PM +0200, Markus Trippelsdorf wrote: > > > Since: > > > commit cfafcd117da0216520568c195cb2f6cd1980c4bb > > > Author: Peter Zijlstra > > > Date: Wed Mar 22 11:35:58 2017 +0100 > > > > > > futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock() > > > > > > glibc's nptl/tst-robustpi8 testcase fails: > > > > > > glibc-build % ./nptl/tst-robustpi8 > > > tst-robustpi8: ../nptl/pthread_mutex_lock.c:424: > > > __pthread_mutex_lock_full: Assertion `INTERNAL_SYSCALL_ERRNO (e, __err) > > > != ESRCH || !robust' failed. > > > > OK, so how do I get those tests build? > > > > I did a checkout of glibc.git > > > > glibc$ mkdir build; cd build > > build$ ../configure --disable-sanity-checks ; make -j40 > > build$ ./nptl/tst-robustpi8 > > -bash: ./nptl/tst-robustpi8: No such file or directory > > > > "make tests" doesn't seem to work either even though its a build target > > listed in the Makefiles. > > > > What magic incantation do I need? > > Something like: > > % ~/glibc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib > --with-headers=/usr/include --enable-add-ons --enable-kernel=4.10 --with-tls > --with-__thread --enable-bind-now --without-gd --without-cvs > --disable-profile --disable-multi-arch --disable-werror I specifically didn't want to set --prefix=/usr etc.. because I didn't want to run any risk of the thing actually installing and wrecking my system, I'll try the other bits through. > % make -j128 > % make -j128 check make check is failing here: /usr/local/src/glibc/build/math/test-ldouble-carg.o -MD -MP -MF /usr/local/src/glibc/build/math/test-ldouble-carg.o.dt -MT /usr/local/src/glibc/build/math/test-ldouble-carg.o /usr/bin/ld: /usr/local/src/glibc/build/math/test-math-iszero.o: relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status > But I've attached the testcase, so building should be unnecessary. Thanks..
Re: [PATCH v2] perf report: fix off-by-one for non-activation frames
On Mittwoch, 17. Mai 2017 07:12:21 CEST Namhyung Kim wrote:
> On Tue, May 16, 2017 at 06:26:47PM +0200, Milian Wolff wrote:
> > On Dienstag, 16. Mai 2017 18:17:26 CEST Milian Wolff wrote:
> > > On Dienstag, 16. Mai 2017 16:38:29 CEST Namhyung Kim wrote:
> > > > On Tue, May 16, 2017 at 10:59:51AM +0200, Milian Wolff wrote:
> > > > > As the documentation for dwfl_frame_pc says, frames that
> > > > > are no activation frames need to have their program counter
> > > > > decremented by one to properly find the function of the caller.
> > > > >
> > > > > This fixes many cases where perf report currently attributes
> > > > > the cost to the next line. I.e. I have code like this:
> > > > >
> > > > > ~~~
> > > > >
> > > > > #include
> > > > > #include
> > > > >
> > > > > using namespace std;
> > > > >
> > > > > int main()
> > > > > {
> > > > >
> > > > > this_thread::sleep_for(chrono::milliseconds(1000));
> > > > > this_thread::sleep_for(chrono::milliseconds(100));
> > > > > this_thread::sleep_for(chrono::milliseconds(10));
> > > > >
> > > > > return 0;
> > > > >
> > > > > }
> > > > >
> > > > > ~~~
> > > >
> > > > It'd be nice if the test program has a signal frame for verification.
> > >
> > > I have pretty much zero experience about signals. Would it be enough to
> > > add
> > > a signal handler for, say, SIGUSR1 to my test application and then
> > > trigger
> > > a sleep when that signal is delivered? If that should be enough, I'll
> > > write
> > > and test it out.
> >
> > ~~~
> > #include
> > #include
> > #include
> >
> > using namespace std;
> >
> > volatile bool run_loop = true;
> >
> > void my_handler(int signum)
> > {
> >
> > this_thread::sleep_for(chrono::milliseconds(1000));
> > this_thread::sleep_for(chrono::milliseconds(100));
> > this_thread::sleep_for(chrono::milliseconds(10));
> > run_loop = false;
> >
> > }
> >
> > int main()
> > {
> >
> > signal(SIGUSR1, my_handler);
> >
> > while (run_loop) {}
> >
> > return 0;
> >
> > }
> > ~~~
> >
> > This does not properly unwind neither before nor after this patch. I only
> > ever>
> > get:
> >100.00% core.c:0
> >
> > ---__schedule core.c:0
> >
> >schedule
> >do_nanosleep hrtimer.c:0
> >hrtimer_nanosleep
> >sys_nanosleep
> >entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
> >__nanosleep_nocancel .:0
> >std::this_thread::sleep_for >
> >
> > thread:323
> >
> > So... should this work? Please tell me how to test this properly.
>
> How did you send the SIGUSR1 to the process?
>
> Anyway it does nothing to do with inlining, right? I just wrote a
> test code below to burn a cpu with or without a signal frame.
>
> $ nl -ba frame-addr.c
> 1#include
> 2#include
> 3#include
> 4
> 5#define __noinline __attribute__((noinline))
> 6
> 7__noinline void bar(void)
> 8{
> 9 volatile long cnt = 0;
> 10
> 11 for (cnt = 0; cnt < 1; cnt++);
> 12}
> 13
> 14__noinline void foo(void)
> 15{
> 16 bar();
> 17}
> 18
> 19void sig_handler(int sig)
> 20{
> 21 foo();
> 22}
> 23
> 24int main(void)
> 25{
> 26 signal(SIGUSR1, sig_handler);
> 27 raise(SIGUSR1);
> 28
> 29 foo();
> 30 return 0;
> 31}
>
> $ gcc -O2 -g -fno-optimize-sibling-calls -o frame-addr frame-addr.c
>
> $ perf record --call-graph dwarf ./frame-addr
>
> $ perf report -q -g srcline | head -15
> 99.88% frame-addr frame-addr[.] bar
>
> ---bar frame-addr.c:11
> foo frame-addr.c:16
>
> |--51.12%--main frame-addr.c:29
> |
> | __libc_start_main
> | _start
>
> --48.76%--sig_handler frame-addr.c:21
> 0x33a8f
> raise .:0
> main frame-addr.c:29 <--- bad
> __libc_start_main
> _start
>
> Note that 'raise' was called at line 27. It seems that simply
> checking current frame fixes it.
Got it - thanks for your test case. I fixed it and will resend v3 of this
patch shortly.
Thanks
--
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
smime.p7s
Description: S/MIME cryptographic signature
[PATCH] irqchip/gicv3-its: skip irq affinity setting when target cpu is the same as current setting
From: MaJun
Just skip the irq affinity setting when the target cpu is the same as
current setting.
This is a small optimization for irq affinity setting logic.
Signed-off-by: MaJun
---
drivers/irqchip/irq-gic-v3-its.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 45ea1933..b335280 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -644,9 +644,12 @@ static int its_set_affinity(struct irq_data *d, const
struct cpumask *mask_val,
if (cpu >= nr_cpu_ids)
return -EINVAL;
- target_col = &its_dev->its->collections[cpu];
- its_send_movi(its_dev, target_col, id);
- its_dev->event_map.col_map[id] = cpu;
+ /* don't set the affinity when the target cpu is same as current one */
+ if (cpu != its_dev->event_map.col_map[id]) {
+ target_col = &its_dev->its->collections[cpu];
+ its_send_movi(its_dev, target_col, id);
+ its_dev->event_map.col_map[id] = cpu;
+ }
return IRQ_SET_MASK_OK_DONE;
}
--
1.7.12.4
Re: [PATCH 3/9] kthread: remove unused macros
On Wed, May 17, 2017 at 02:09:52PM +0200, Petr Mladek wrote: > On Tue 2017-05-16 13:48:06, Christoph Hellwig wrote: > > KTHREAD_DELAYED_WORK_INIT and DEFINE_KTHREAD_DELAYED_WORK are unused > > and are using a timer helper that's about to go away. > > A patch using this API is flying around, see > https://lkml.kernel.org/r/1476715742-14924-1-git-send-email-pmla...@suse.com > And I have one more, for hung_task.c, in the drawer. > > I admit that I got sidetracked and did not push these conversions > last months. But the conversions are useful and I want to continue > or find a trainee that might continue. > > I wanted to make your life easier, took inspiration from the > workqueues conversion and prepared the patch below. It is tested > with the above mentioned API user. > > Please, let me known if you would prefer another approach. > I do not want to complicate development of the new timer API. Thanks, I'll add your patch to the series. I just have a tendency to remove unused bits instead of trying to fix them up without being able to test the result.
Re: [PATCH 2/2 -v2] drm: drop drm_[cm]alloc* helpers
Am 17.05.2017 um 14:23 schrieb Michal Hocko: As it turned out my allyesconfig on x86_64 wasn't sufficient and 0day build machinery found a failure on arm architecture. It was clearly a typo. Now I have pushed this to my build battery with cross arch compilers and it passes so there shouldn't more surprises hopefully. Here is the v2. --- From 4a00b3ade5ca4514f7affd8de6f7119c8d5c5a86 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Tue, 16 May 2017 11:00:47 +0200 Subject: [PATCH -v2] drm: drop drm_[cm]alloc* helpers Now that drm_[cm]alloc* helpers are simple one line wrappers around kvmalloc_array and drm_free_large is just kvfree alias we can drop them and replace by their native forms. This shouldn't introduce any functional change. Changes since v1 - fix typo in drivers/gpu//drm/etnaviv/etnaviv_gem.c - noticed by 0day build robot Suggested-by: Daniel Vetter Signed-off-by: Michal Hocko Acked-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c| 16 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 19 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 +-- drivers/gpu/drm/drm_gem.c | 6 +-- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 12 ++--- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c| 4 +- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 12 ++--- drivers/gpu/drm/exynos/exynos_drm_gem.c| 11 +++-- drivers/gpu/drm/i915/i915_debugfs.c| 4 +- drivers/gpu/drm/i915/i915_gem.c| 4 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 34 +++--- drivers/gpu/drm/i915/i915_gem_gtt.c| 6 +-- drivers/gpu/drm/i915/i915_gem_userptr.c| 8 ++-- drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 12 ++--- drivers/gpu/drm/msm/msm_gem.c | 10 ++-- drivers/gpu/drm/radeon/radeon_cs.c | 11 +++-- drivers/gpu/drm/radeon/radeon_gem.c| 2 +- drivers/gpu/drm/radeon/radeon_ring.c | 4 +- drivers/gpu/drm/radeon/radeon_vm.c | 4 +- drivers/gpu/drm/ttm/ttm_tt.c | 13 +++--- drivers/gpu/drm/udl/udl_dmabuf.c | 2 +- drivers/gpu/drm/udl/udl_gem.c | 2 +- drivers/gpu/drm/vc4/vc4_gem.c | 15 +++--- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 27 +-- include/drm/drmP.h | 1 - include/drm/drm_mem_util.h | 53 -- 26 files changed, 126 insertions(+), 173 deletions(-) delete mode 100644 include/drm/drm_mem_util.h diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c index a6649874e6ce..9f0247cdda5e 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c @@ -96,7 +96,7 @@ static int amdgpu_bo_list_set(struct amdgpu_device *adev, int r; unsigned long total_size = 0; - array = drm_malloc_ab(num_entries, sizeof(struct amdgpu_bo_list_entry)); + array = kvmalloc_array(num_entries, sizeof(struct amdgpu_bo_list_entry), GFP_KERNEL); if (!array) return -ENOMEM; memset(array, 0, num_entries * sizeof(struct amdgpu_bo_list_entry)); @@ -148,7 +148,7 @@ static int amdgpu_bo_list_set(struct amdgpu_device *adev, for (i = 0; i < list->num_entries; ++i) amdgpu_bo_unref(&list->array[i].robj); - drm_free_large(list->array); + kvfree(list->array); list->gds_obj = gds_obj; list->gws_obj = gws_obj; @@ -163,7 +163,7 @@ static int amdgpu_bo_list_set(struct amdgpu_device *adev, error_free: while (i--) amdgpu_bo_unref(&array[i].robj); - drm_free_large(array); + kvfree(array); return r; } @@ -224,7 +224,7 @@ void amdgpu_bo_list_free(struct amdgpu_bo_list *list) amdgpu_bo_unref(&list->array[i].robj); mutex_destroy(&list->lock); - drm_free_large(list->array); + kvfree(list->array); kfree(list); } @@ -244,8 +244,8 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data, int r; - info = drm_malloc_ab(args->in.bo_number, -sizeof(struct drm_amdgpu_bo_list_entry)); + info = kvmalloc_array(args->in.bo_number, +sizeof(struct drm_amdgpu_bo_list_entry), GFP_KERNEL); if (!info) return -ENOMEM; @@ -311,11 +311,11 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data, memset(args, 0, sizeof(*args)); args->out.list_handle = handle; - drm_free_large(info); + kvfree(info); return 0; error_free: - drm_free_large(info); + kvfree(info); return r; } diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/a
Re: [PATCH 2/9] timers: provide a "modern" variant of timers
> b) give the union a name (breaks any reference to timer_list->func in C code):
>
> + union {
> + void(*func)(struct timer_list *timer);
> + void(*function)(unsigned long);
> + } u;
I'll look into that, as it seems a lot safer, and places outside
the timer code shouldn't really touch it (although I bet they do,
so more fixes for this series..)
> I fear this breaks lockdep output, which turns the name of
> the timer into a string that gets printed later. It should work
> when these are macros, or a macro wrapping an inline function
> like __init_timer is.
Ok, I'll fix it up. Although this macro mess isn't really readable
at all.
Re: [PATCH 9/9] timers: remove old timer initialization macros
On Tue, May 16, 2017 at 09:43:34PM +0200, Arnd Bergmann wrote:
> > - * Don't use the macros below, use DECLARE_TIMER and INIT_TIMER with their
> > + * Don't use the macro below, use DECLARE_TIMER and INIT_TIMER with their
> > * improved callback signature above.
> > */
> > -#define __TIMER_INITIALIZER(_function, _expires, _data, _flags) { \
> > +#define DEFINE_TIMER(_name, _function, _expires, _data)\
> > + struct timer_list _name = { \
> > .entry = { .next = TIMER_ENTRY_STATIC },\
> > .function = (_function),\
> > .expires = (_expires), \
> > .data = (_data),\
> > - .flags = (_flags), \
> > __TIMER_LOCKDEP_MAP_INITIALIZER(\
> > __FILE__ ":" __stringify(__LINE__)) \
> > }
>
> Not sure what to do about it, but I notice that the '_expires'
> argument is completely
> bogus, I don't see any way it could be used in a meaningful way, and the only
> user that passes anything other than zero is
> arch/mips/mti-malta/malta-display.c
> and that seems to be unintentional.
DEFINE_TIMER is the old macro and instead of fixing it up I'll just
make sure the new DECLARE_TIMER gets rid of it.
Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.
Hi,
On 05/17/2017 12:16 AM, Eric Anholt wrote:
Laurent Pinchart writes:
Hi Eric,
On Tuesday 16 May 2017 09:47:49 Eric Anholt wrote:
Rob Herring writes:
On Mon, May 15, 2017 at 7:03 PM, Eric Anholt wrote:
Laurent Pinchart writes:
Hi Eric,
Thank you for the patch.
On Thursday 11 May 2017 16:56:23 Eric Anholt wrote:
The Raspberry Pi 7" Touchscreen is a DPI touchscreen panel with
DSI->DPI bridge and touchscreen controller integrated, that connects
to the Raspberry Pi through its 15-pin "DSI" connector (some lines are
DSI, some lines are I2C).
This device is represented in the DT as three nodes (DSI device, I2C
device, panel). Input will be left to a separate binding later, as it
will be a basic I2C client device.
Signed-off-by: Eric Anholt
---
.../raspberrypi,7inch-touchscreen-bridge.txt | 68 ++
.../panel/raspberrypi,7inch-touchscreen-panel.txt | 7 +++
2 files changed, 75 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touc
hscreen-bridge.txt create mode 100644
Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touch
screen-panel.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to
uchscreen-bridge.txt
b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to
uchscreen-bridge.txt new file mode 100644
index ..a5669beaf68f
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to
uchscreen-bridge.txt
@@ -0,0 +1,68 @@
+Official 7" (800x480) Raspberry Pi touchscreen panel's bridge.
+
+This DSI panel contains:
+
+- TC358762 DSI->DPI bridge
+- Atmel microcontroller on I2C for power sequencing the DSI bridge and
+ controlling backlight
+- Touchscreen controller on I2C for touch input
+
+and this covers the TC358762 bridge and Atmel microcontroller, while
+../panel/raspberrypi,7inch-touchscreen-panel.txt covers the panel.
The TC358762 is a standalone bridge that doesn't depend on the ATTiny
microcontroller used by the RPI. As it's usable standalone, I believe
this binding should be split in two.
Do you have a plan for how I would implement a driver on top of that
binding change, though? Note that we don't program the Toshiba
directly, we only send commands to the Atmel.
I agree. If it is a black box and the interface to the host is defined
by the Atmel uC firmware, then that's what the DT should describe.
Perhaps a diagram here or pointer to one would help and remove
mentioning what kind of bridge chip it is.
It's a *very* black box. I have some non-public schematics that don't
even say what panel is involved, and no documentation of the uc
interface. The driver code is just replicating the firmware's
programming sequence.
I would certainly love to be building a generic TC358762 driver, which
would be a lot more satisfying. I just don't think it's doable for this
panel. Given that, what do I need to do to the DT? Should I just drop
mention of the Toshiba and talk about this being a bridge with a custom
microcontroller firmware?
I think that would be best, yes. Could you share a simple block-diagram of the
hardware ? It would help turning my random advices into semi-random advices
:-)
In terms of physical connections:
[15-pin "DSI" connector on 2835]
| |
| I2C | DSI
| |
/ \SPI |
[TS] [Atmel]--[TC358762]
\|
\PWM|
\ | DPI
[some backlight]--[some unknown panel]
The binding I'm trying to create is to expose what's necessary for a
driver that talks I2C to the Atmel, which then controls the PWM and does
the command sequence over SPI to the Toshiba that sets up its end of the
DSI link.
The bridge (Atmel + TC358762 combination) here looks like it's primarily
an i2c device (i.e, the control bus is i2c). Therefore, the drm-bridge
driver here should be an i2c driver instead of a mipi_dsi_driver.
We have the facility to create a mipi DSI device without the need to have
a corresponding node in DT. The ADV7533 and TC358767 drivers are examples
of that.
The following is what the binding could look like, it's same as what Rob
also mentioned previously in the thread.
Thanks,
Archit
dsi1: dsi@7e70 {
#address-cells = <1>;
#size-cells = <0>;
<...>
/* The SoC's DSI input/output port */
ports {
#address-cells = <1>;
#size-cells = <0>;
/* port@0 if needed */
port@1 {
dsi_out_port: endpoint {
reg = <1>;
remote-endpoint = <&bridge_dsi_port>;
};
};
};
};
i2c_dsi: i2c {
compatible = "i2c-gpio";
#address-cells = <1>;
#size-cells = <0>;
gpios = <&gpio 28 0
&gpio 29 0>;
Re: RFC: better timer interface
On Tue, May 16, 2017 at 10:26:39PM +0200, Arnd Bergmann wrote: > If we keep the unusual *_timer() naming (rather than timer_*() as hrtimer > has), we could use one of > > a) start_timer(struct timer_list *timer, unsigned long ms); > b) restart_timer(struct timer_list *timer, unsigned long ms); > c) mod_timer_ms(struct timer_list *timer, unsigned long ms); > mod_timer_sec(struct timer_list *timer, unsigned long sec); > > The first is slightly shorter but conflicts with three files that use > the same name for a local function name. The third one fits > well with the existing interfaces and provides both millisecond > and second versions, I'd probably go with that. Yeah, I'd take c) as well. I'll give it a spin. > We could consider even passing a default interval as another > argument to prepare_timer(), and using that in add_timer(), > but that would in those cases that have a constant interval > (maybe about half of the users from) and would be a bit surprising > to readers that are only familiar with the existing interfaces. That seems rather ugly to me. > One final option would be a larger-scale replacement of > the API by mirroring the hrtimer style where possible while > staying compatible with the existing calls, e.g. timer_prepare(), > timer_add_expires(), timer_start(), ... I'd chose timer_* for an entirely new API, but at this point this seems a bit too much churn to me.
Re: [PATCH 6/6] staging/lustre: Use generic range rwlock
On May 15, 2017, at 11:07, Davidlohr Bueso wrote:
>
> This replaces the in-house version, which is also derived
> from Jan's interval tree implementation.
>
> Cc: oleg.dro...@intel.com
> Cc: andreas.dil...@intel.com
> Cc: jsimm...@infradead.org
> Cc: lustre-de...@lists.lustre.org
> Signed-off-by: Davidlohr Bueso
Repeating my request that the whole patch series should be CC'd to the
linux-fsdevel list,
since I only got this last patch and this makes it difficult to review the
whole series.
> ---
> diff --git a/drivers/staging/lustre/lustre/llite/file.c
> b/drivers/staging/lustre/lustre/llite/file.c
> index 67c4b9cc6e75..bd020bdaf85d 100644
> --- a/drivers/staging/lustre/lustre/llite/file.c
> +++ b/drivers/staging/lustre/lustre/llite/file.c
> @@ -1083,10 +1083,10 @@ ll_file_io_generic(const struct lu_env *env, struct
> vvp_io_args *args,
> if (((iot == CIT_WRITE) ||
>(iot == CIT_READ && (file->f_flags & O_DIRECT))) &&
> !(vio->vui_fd->fd_flags & LL_FILE_GROUP_LOCKED)) {
> - CDEBUG(D_VFSTRACE, "Range lock [%llu, %llu]\n",
> -range.rl_node.in_extent.start,
> -range.rl_node.in_extent.end);
> - rc = range_lock(&lli->lli_write_tree, &range);
> + CDEBUG(D_VFSTRACE, "Range lock [%lu, %lu]\n",
> +range.node.start,
> +range.node.last);
> + rc =
> range_write_lock_interruptible(&lli->lli_write_tree, &range);
> if (rc < 0)
> goto out;
>
> @@ -1096,10 +1096,10 @@ ll_file_io_generic(const struct lu_env *env, struct
> vvp_io_args *args,
> rc = cl_io_loop(env, io);
> ll_cl_remove(file, env);
> if (range_locked) {
> - CDEBUG(D_VFSTRACE, "Range unlock [%llu, %llu]\n",
> -range.rl_node.in_extent.start,
> -range.rl_node.in_extent.end);
> - range_unlock(&lli->lli_write_tree, &range);
> + CDEBUG(D_VFSTRACE, "Range unlock [%lu, %lu]\n",
> +range.node.start,
> +range.node.last);
> + range_write_unlock(&lli->lli_write_tree, &range);
> }
> } else {
> /* cl_io_rw_init() handled IO */
I'm not against this patch, but it does expose an implementation difference
between the
Lustre version of this code and the in-tree version. Preferred kernel coding
style is to
have a struct-unique prefix for struct members (e.g. using "rl_" for struct
range_lock,
using "in_" for struct interval_tree_node). That allows tags to work properly,
instead
of trying to locate generic struct names like "start", "node" etc.
In an unexpected twist of fate, the Lustre version of this code is following
preferred
coding style and the in-tree (interval_tree) and submitted (range_rwlock) code
does not.
Cheers, Andreas
[PATCH v2 2/3] EDAC: mv64x60: Fix pdata->name
Change this from mpc85xx_pci_err to mv64x60_pci_err. The former is likely a hangover from when this driver was created. Signed-off-by: Chris Packham --- drivers/edac/mv64x60_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c index 454e1e26ee7c..ddc5082f7577 100644 --- a/drivers/edac/mv64x60_edac.c +++ b/drivers/edac/mv64x60_edac.c @@ -116,7 +116,7 @@ static int mv64x60_pci_err_probe(struct platform_device *pdev) pdata = pci->pvt_info; pdata->pci_hose = pdev->id; - pdata->name = "mpc85xx_pci_err"; + pdata->name = "mv64x60_pci_err"; platform_set_drvdata(pdev, pci); pci->dev = &pdev->dev; pci->dev_name = dev_name(&pdev->dev); -- 2.11.0.24.ge6920cf
Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure
On Thu, May 18, 2017 at 10:12:04AM +0200, Florian Weimer wrote: > On 05/18/2017 09:40 AM, Peter Zijlstra wrote: > > OK, so how do I get those tests build? > > > > I did a checkout of glibc.git > > > > glibc$ mkdir build; cd build > > build$ ../configure --disable-sanity-checks ; make -j40 > > build$ ./nptl/tst-robustpi8 > > -bash: ./nptl/tst-robustpi8: No such file or directory > > > > "make tests" doesn't seem to work either even though its a build target > > listed in the Makefiles. > > This builds the nptl test: > > make subdirs=nptl run-built-tests=no That more or less worked, it still failed: /usr/bin/ld: /usr/local/src/glibc/build/nptl/tst-once5.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status But it does that after building the tst-robustpi8 thing, so I seem to have all I need here. > To run a single test, use this: > > bash -x testrun.sh nptl/tst-robustpi8 > > This is required because the test might not be compatible with the > installed glibc (some nptl tests are whitebox tests). You can feed the > command line printed due to “bash -x” into strace or a debugger. The > environment variable settings aren't necessary for most tests. Indeed, that seems to work: $ ./elf/ld-linux-x86-64.so.2 --library-path .:./math:./elf:./dlfcn:./nss:./nis:./rt:./resolv:./crypt:./mathvec:./support:./nptl ./nptl/tst-robustpi8 tst-robustpi8: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full: Assertion `INTERNAL_SYSCALL_ERRNO (e, __err) != ESRCH || !robust' failed.
[PATCH v2 0/3] EDAC: mv64x60: updates
I'm looking at making use of the mv64x60_edac driver for the armada processors. It appears that at least the DRAM ECC error reporting is the same block from the old Marvell Discovery class of processors. On the ARM side I need to get the error interrupts exposed first before I can send my second set of changes for this driver but this first set is just a series of cleanups. Chris Packham (3): EDAC: mv64x60: remove unused variable EDAC: mv64x60: Fix pdata->name EDAC: mv64x60: replace in_le32/out_le32 with readl/writel drivers/edac/mv64x60_edac.c | 88 ++--- 1 file changed, 43 insertions(+), 45 deletions(-) -- 2.11.0.24.ge6920cf
[PATCH v2 1/3] EDAC: mv64x60: remove unused variable
Signed-off-by: Chris Packham
---
drivers/edac/mv64x60_edac.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
index 14b7e7b71eaa..454e1e26ee7c 100644
--- a/drivers/edac/mv64x60_edac.c
+++ b/drivers/edac/mv64x60_edac.c
@@ -853,8 +853,6 @@ static struct platform_driver * const drivers[] = {
static int __init mv64x60_edac_init(void)
{
- int ret = 0;
-
printk(KERN_INFO "Marvell MV64x60 EDAC driver " MV64x60_REVISION "\n");
printk(KERN_INFO "\t(C) 2006-2007 MontaVista Software\n");
/* make sure error reporting method is sane */
--
2.11.0.24.ge6920cf
[PATCH v2 3/3] EDAC: mv64x60: replace in_le32/out_le32 with readl/writel
To allow this driver to be used on non-powerpc platforms it needs to use
io accessors suitable for all platforms.
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- use readl/writel as suggested.
drivers/edac/mv64x60_edac.c | 84 ++---
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
index ddc5082f7577..d38538242e9c 100644
--- a/drivers/edac/mv64x60_edac.c
+++ b/drivers/edac/mv64x60_edac.c
@@ -32,21 +32,21 @@ static void mv64x60_pci_check(struct edac_pci_ctl_info *pci)
struct mv64x60_pci_pdata *pdata = pci->pvt_info;
u32 cause;
- cause = in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
+ cause = readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
if (!cause)
return;
printk(KERN_ERR "Error in PCI %d Interface\n", pdata->pci_hose);
printk(KERN_ERR "Cause register: 0x%08x\n", cause);
printk(KERN_ERR "Address Low: 0x%08x\n",
- in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
+ readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
printk(KERN_ERR "Address High: 0x%08x\n",
- in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
+ readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
printk(KERN_ERR "Attribute: 0x%08x\n",
- in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
+ readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
printk(KERN_ERR "Command: 0x%08x\n",
- in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
- out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE, ~cause);
+ readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
+ writel(~cause, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
if (cause & MV64X60_PCI_PE_MASK)
edac_pci_handle_pe(pci, pci->ctl_name);
@@ -61,7 +61,7 @@ static irqreturn_t mv64x60_pci_isr(int irq, void *dev_id)
struct mv64x60_pci_pdata *pdata = pci->pvt_info;
u32 val;
- val = in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
+ val = readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
if (!val)
return IRQ_NONE;
@@ -93,7 +93,7 @@ static int __init mv64x60_pci_fixup(struct platform_device
*pdev)
if (!pci_serr)
return -ENOMEM;
- out_le32(pci_serr, in_le32(pci_serr) & ~0x1);
+ writel(readl(pci_serr) & ~0x1, pci_serr);
iounmap(pci_serr);
return 0;
@@ -161,10 +161,10 @@ static int mv64x60_pci_err_probe(struct platform_device
*pdev)
goto err;
}
- out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE, 0);
- out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_MASK, 0);
- out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_MASK,
-MV64X60_PCIx_ERR_MASK_VAL);
+ writel(0, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
+ writel(0, pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
+ writel(MV64X60_PCIx_ERR_MASK_VAL,
+ pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
if (edac_pci_add_device(pci, pdata->edac_idx) > 0) {
edac_dbg(3, "failed edac_pci_add_device()\n");
@@ -233,23 +233,23 @@ static void mv64x60_sram_check(struct
edac_device_ctl_info *edac_dev)
struct mv64x60_sram_pdata *pdata = edac_dev->pvt_info;
u32 cause;
- cause = in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
+ cause = readl(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
if (!cause)
return;
printk(KERN_ERR "Error in internal SRAM\n");
printk(KERN_ERR "Cause register: 0x%08x\n", cause);
printk(KERN_ERR "Address Low: 0x%08x\n",
- in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_LO));
+ readl(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_LO));
printk(KERN_ERR "Address High: 0x%08x\n",
- in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_HI));
+ readl(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_HI));
printk(KERN_ERR "Data Low: 0x%08x\n",
- in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_LO));
+ readl(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_LO));
printk(KERN_ERR "Data High: 0x%08x\n",
- in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_HI));
+ readl(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_HI));
printk(KERN_ERR "Parity: 0x%08x\n",
- in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_PARITY));
- out_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE, 0);
+ readl(pdata->sram_vbase + MV64X60_SRAM_ERR_PARITY));
+ writel(0, pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
edac_device_handle_ue(edac_dev, 0, 0, edac_dev->ctl_name);
}
@@ -260,7 +260,7 @@ static irqreturn_t mv64x60_sram_isr(int irq, void *dev_id
[PATCH] scsi: smartpqi: mark PM functions as __maybe_unused
The newly added suspend/resume support causes harmless warnings
when CONFIG_PM is disabled:
smartpqi/smartpqi_init.c:5147:12: error: 'pqi_ctrl_wait_for_pending_io' defined
but not used [-Werror=unused-function]
smartpqi/smartpqi_init.c:2019:13: error: 'pqi_wait_until_lun_reset_finished'
defined but not used [-Werror=unused-function]
smartpqi/smartpqi_init.c:2013:13: error: 'pqi_wait_until_scan_finished' defined
but not used [-Werror=unused-function]
We can avoid the warnings by removing the #ifdef around the
handlers and instead marking them as __maybe_unused, which will
let gcc drop the unused code silently.
Fixes: f44d210312a6 ("scsi: smartpqi: add suspend and resume support")
Signed-off-by: Arnd Bergmann
---
drivers/scsi/smartpqi/smartpqi_init.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/smartpqi/smartpqi_init.c
b/drivers/scsi/smartpqi/smartpqi_init.c
index 0b11ae7e96dc..cb8f886e705c 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -6213,8 +6213,6 @@ static int pqi_ctrl_init(struct pqi_ctrl_info *ctrl_info)
return 0;
}
-#if defined(CONFIG_PM)
-
static void pqi_reinit_queues(struct pqi_ctrl_info *ctrl_info)
{
unsigned int i;
@@ -6321,8 +6319,6 @@ static int pqi_ctrl_init_resume(struct pqi_ctrl_info
*ctrl_info)
return 0;
}
-#endif /* CONFIG_PM */
-
static inline int pqi_set_pcie_completion_timeout(struct pci_dev *pci_dev,
u16 timeout)
{
@@ -6696,9 +6692,7 @@ static void pqi_process_module_params(void)
pqi_process_lockup_action_param();
}
-#if defined(CONFIG_PM)
-
-static int pqi_suspend(struct pci_dev *pci_dev, pm_message_t state)
+static __maybe_unused int pqi_suspend(struct pci_dev *pci_dev, pm_message_t
state)
{
struct pqi_ctrl_info *ctrl_info;
@@ -6728,7 +6722,7 @@ static int pqi_suspend(struct pci_dev *pci_dev,
pm_message_t state)
return 0;
}
-static int pqi_resume(struct pci_dev *pci_dev)
+static __maybe_unused int pqi_resume(struct pci_dev *pci_dev)
{
int rc;
struct pqi_ctrl_info *ctrl_info;
@@ -6759,8 +6753,6 @@ static int pqi_resume(struct pci_dev *pci_dev)
return pqi_ctrl_init_resume(ctrl_info);
}
-#endif /* CONFIG_PM */
-
/* Define the PCI IDs for the controllers that we support. */
static const struct pci_device_id pqi_pci_id_table[] = {
{
--
2.9.0
Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure
On 05/18/2017 10:31 AM, Peter Zijlstra wrote: > That more or less worked, it still failed: > > /usr/bin/ld: /usr/local/src/glibc/build/nptl/tst-once5.o: relocation > R_X86_64_32 against `.text' can not be used when making a shared object; > recompile with -fPIC > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: error: ld returned 1 exit status I think this is a bug in the binutils version shipping with Debian jessie. > But it does that after building the tst-robustpi8 thing, so I seem to > have all I need here. Great, have fun figuring out what's going on. :-/ Thanks, Florian
[PATCH v3 1/2] lib/btree.c: optimise the code by previously getpos function
Rework the getpos() helper function and use it to remove various
open-coded implemetnations of its funtionality.
v2 -> v3:
- getfill() returns no entry if not found the fill position
v1 -> v2:
- getpos() returns no entry if not found the key
Reviewed-by: Andy Shevchenko
Signed-off-by: Leno Hou
---
lib/btree.c | 79 +
1 file changed, 37 insertions(+), 42 deletions(-)
diff --git a/lib/btree.c b/lib/btree.c
index f93a945..a532f30 100644
--- a/lib/btree.c
+++ b/lib/btree.c
@@ -238,6 +238,18 @@ static int keyzero(struct btree_geo *geo, unsigned long
*key)
return 1;
}
+static int getpos(struct btree_geo *geo, unsigned long *node,
+ unsigned long *key)
+{
+ unsigned int i;
+
+ for (i = 0; i < geo->no_pairs; i++) {
+ if (keycmp(geo, node, i, key) <= 0)
+ break;
+ }
+ return i;
+}
+
void *btree_lookup(struct btree_head *head, struct btree_geo *geo,
unsigned long *key)
{
@@ -248,10 +260,8 @@ void *btree_lookup(struct btree_head *head, struct
btree_geo *geo,
return NULL;
for ( ; height > 1; height--) {
- for (i = 0; i < geo->no_pairs; i++)
- if (keycmp(geo, node, i, key) <= 0)
- break;
- if (i == geo->no_pairs)
+ i = getpos(geo, node, key);
+ if (i < 0)
return NULL;
node = bval(geo, node, i);
if (!node)
@@ -278,10 +288,8 @@ int btree_update(struct btree_head *head, struct btree_geo
*geo,
return -ENOENT;
for ( ; height > 1; height--) {
- for (i = 0; i < geo->no_pairs; i++)
- if (keycmp(geo, node, i, key) <= 0)
- break;
- if (i == geo->no_pairs)
+ i = getpos(geo, node, key);
+ if (i < 0)
return -ENOENT;
node = bval(geo, node, i);
if (!node)
@@ -326,10 +334,8 @@ void *btree_get_prev(struct btree_head *head, struct
btree_geo *geo,
node = head->node;
for (height = head->height ; height > 1; height--) {
- for (i = 0; i < geo->no_pairs; i++)
- if (keycmp(geo, node, i, key) <= 0)
- break;
- if (i == geo->no_pairs)
+ i = getpos(geo, node, key);
+ if (i < 0)
goto miss;
oldnode = node;
node = bval(geo, node, i);
@@ -360,26 +366,17 @@ void *btree_get_prev(struct btree_head *head, struct
btree_geo *geo,
}
EXPORT_SYMBOL_GPL(btree_get_prev);
-static int getpos(struct btree_geo *geo, unsigned long *node,
- unsigned long *key)
-{
- int i;
-
- for (i = 0; i < geo->no_pairs; i++) {
- if (keycmp(geo, node, i, key) <= 0)
- break;
- }
- return i;
-}
-
static int getfill(struct btree_geo *geo, unsigned long *node, int start)
{
- int i;
+ unsigned int i;
+
+ if (unlikely(start < 0))
+ return -ENOENT;
for (i = start; i < geo->no_pairs; i++)
if (!bval(geo, node, i))
- break;
- return i;
+ return i;
+ return -ENOENT;
}
/*
@@ -392,11 +389,9 @@ static unsigned long *find_level(struct btree_head *head,
struct btree_geo *geo,
int i, height;
for (height = head->height; height > level; height--) {
- for (i = 0; i < geo->no_pairs; i++)
- if (keycmp(geo, node, i, key) <= 0)
- break;
+ i = getpos(geo, node, key);
- if ((i == geo->no_pairs) || !bval(geo, node, i)) {
+ if ((i < 0) || !bval(geo, node, i)) {
/* right-most key is too large, update it */
/* FIXME: If the right-most key on higher levels is
* always zero, this wouldn't be necessary. */
@@ -466,7 +461,7 @@ static int btree_insert_level(struct btree_head *head,
struct btree_geo *geo,
/* two identical keys are not allowed */
BUG_ON(pos < fill && keycmp(geo, node, pos, key) == 0);
- if (fill == geo->no_pairs) {
+ if (fill < 0) {
/* need to split node */
unsigned long *new;
@@ -474,27 +469,27 @@ static int btree_insert_level(struct btree_head *head,
struct btree_geo *geo,
if (!new)
return -ENOMEM;
err = btree_insert_level(head, geo,
- bkey(geo, node, fill / 2 - 1),
+ bkey(geo, node, geo->no_pairs / 2 - 1),
new, level + 1, gfp);
if (err) {
[PATCH v3 2/2] lib/btree.c: add testcase for in-memory b+ tree
Signed-off-by: Leno Hou
---
lib/btree_test.c | 77
1 file changed, 77 insertions(+)
create mode 100644 lib/btree_test.c
diff --git a/lib/btree_test.c b/lib/btree_test.c
new file mode 100644
index 000..90d9048
--- /dev/null
+++ b/lib/btree_test.c
@@ -0,0 +1,77 @@
+#include
+#include
+#include
+#include
+#include
+
+#define NODES 24
+
+struct test_node {
+ u32 key;
+ u32 val;
+};
+
+static struct btree_head32 bh;
+static struct test_node nodes[NODES];
+
+static void init(void)
+{
+ int i;
+
+ for (i = 0; i < NODES; i++) {
+ nodes[i].key = i;
+ nodes[i].val = i;
+ }
+}
+static int __init btree_test_init(void)
+{
+ u32 key = 0;
+ u32 *val = NULL;
+ int i, rc;
+
+ pr_alert("btree testing\n");
+
+ init();
+ rc = btree_init32(&bh);
+
+ if (rc)
+ pr_alert("Unable initialize btree memory\n");
+
+ for (i = 0; i < NODES; i++) {
+ rc = btree_insert32(&bh,
+ nodes[i].key,
+ &nodes[i].val,
+ GFP_ATOMIC);
+
+ if (rc)
+ pr_alert("Unable to insert key into btree\n");
+ }
+
+ pr_alert("\n");
+
+ btree_for_each_safe32(&bh, key, val) {
+ pr_alert("val %d\n", *val);
+ }
+
+ btree_remove32(&bh, 11);
+
+ pr_alert("\n");
+ btree_for_each_safe32(&bh, key, val) {
+ pr_alert("val %d\n", *val);
+ }
+
+ return 0;
+}
+static void __exit btree_test_exit(void)
+{
+ pr_alert("test exit\n");
+ btree_destroy32(&bh);
+
+}
+
+module_init(btree_test_init);
+module_exit(btree_test_exit);
+
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("Leno Hou ");
+MODULE_DESCRIPTION("Simple In-memory B+ Tree test");
--
2.7.4
Re: [RESEND PATCH] llist: Provide a safe version for llist_for_each
OK, picked up all 4: patches/byungchul_park-llist-provide_a_safe_version_for_llist_for_each.patch patches/byungchul_park-sched-don_t_reinvent_the_wheel_but_use_existing_llist_api.patch patches/byungchul_park-sched_rt-remove_unnecessary_condition_in_push_rt_task.patch patches/byungchul_park-sched_deadline-remove_unnecessary_condition_in_push_dl_task.patch
[PATCH] staging: iio: light: Replace symbolic permissions as per coding style
From: Surender Polsani Fixed the following checkpatch.pl warnings: octal permissions are more preferable than symbolic permissions Signed-off-by: Surender Polsani --- drivers/staging/iio/light/tsl2x7x_core.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/staging/iio/light/tsl2x7x_core.c b/drivers/staging/iio/light/tsl2x7x_core.c index af3910b..c63fe6a 100644 --- a/drivers/staging/iio/light/tsl2x7x_core.c +++ b/drivers/staging/iio/light/tsl2x7x_core.c @@ -1498,34 +1498,34 @@ static int tsl2x7x_write_raw(struct iio_dev *indio_dev, return 0; } -static DEVICE_ATTR(power_state, S_IRUGO | S_IWUSR, +static DEVICE_ATTR(power_state, 0644, tsl2x7x_power_state_show, tsl2x7x_power_state_store); -static DEVICE_ATTR(in_proximity0_calibscale_available, S_IRUGO, +static DEVICE_ATTR(in_proximity0_calibscale_available, 0444, tsl2x7x_prox_gain_available_show, NULL); -static DEVICE_ATTR(in_illuminance0_calibscale_available, S_IRUGO, +static DEVICE_ATTR(in_illuminance0_calibscale_available, 0444, tsl2x7x_gain_available_show, NULL); -static DEVICE_ATTR(in_illuminance0_integration_time, S_IRUGO | S_IWUSR, +static DEVICE_ATTR(in_illuminance0_integration_time, 0644, tsl2x7x_als_time_show, tsl2x7x_als_time_store); -static DEVICE_ATTR(in_illuminance0_target_input, S_IRUGO | S_IWUSR, +static DEVICE_ATTR(in_illuminance0_target_input, 0644, tsl2x7x_als_cal_target_show, tsl2x7x_als_cal_target_store); -static DEVICE_ATTR(in_illuminance0_calibrate, S_IWUSR, NULL, +static DEVICE_ATTR(in_illuminance0_calibrate, 0200, NULL, tsl2x7x_do_calibrate); -static DEVICE_ATTR(in_proximity0_calibrate, S_IWUSR, NULL, +static DEVICE_ATTR(in_proximity0_calibrate, 0200, NULL, tsl2x7x_do_prox_calibrate); -static DEVICE_ATTR(in_illuminance0_lux_table, S_IRUGO | S_IWUSR, +static DEVICE_ATTR(in_illuminance0_lux_table, 0644, tsl2x7x_luxtable_show, tsl2x7x_luxtable_store); -static DEVICE_ATTR(in_intensity0_thresh_period, S_IRUGO | S_IWUSR, +static DEVICE_ATTR(in_intensity0_thresh_period, 0644, tsl2x7x_als_persistence_show, tsl2x7x_als_persistence_store); -static DEVICE_ATTR(in_proximity0_thresh_period, S_IRUGO | S_IWUSR, +static DEVICE_ATTR(in_proximity0_thresh_period, 0644, tsl2x7x_prox_persistence_show, tsl2x7x_prox_persistence_store); /* Use the default register values to identify the Taos device */ -- 1.9.1
[PATCH v3] perf report: fix off-by-one for non-activation frames
As the documentation for dwfl_frame_pc says, frames that
are no activation frames need to have their program counter
decremented by one to properly find the function of the caller.
This fixes many cases where perf report currently attributes
the cost to the next line. I.e. I have code like this:
~~~
#include
#include
using namespace std;
int main()
{
this_thread::sleep_for(chrono::milliseconds(1000));
this_thread::sleep_for(chrono::milliseconds(100));
this_thread::sleep_for(chrono::milliseconds(10));
return 0;
}
~~~
Now compile and record it:
~~~
g++ -std=c++11 -g -O2 test.cpp
echo 1 | sudo tee /proc/sys/kernel/sched_schedstats
perf record \
--event sched:sched_stat_sleep \
--event sched:sched_process_exit \
--event sched:sched_switch --call-graph=dwarf \
--output perf.data.raw \
./a.out
echo 0 | sudo tee /proc/sys/kernel/sched_schedstats
perf inject --sched-stat --input perf.data.raw --output perf.data
~~~
Before this patch, the report clearly shows the off-by-one issue.
Most notably, the last sleep invocation is incorrectly attributed
to the "return 0;" line:
~~~
Overhead Source:Line
...
100.00% core.c:0
|
---__schedule core.c:0
schedule
do_nanosleep hrtimer.c:0
hrtimer_nanosleep
sys_nanosleep
entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
__nanosleep_nocancel .:0
std::this_thread::sleep_for >
thread:323
|
|--90.08%--main test.cpp:9
| __libc_start_main
| _start
|
|--9.01%--main test.cpp:10
| __libc_start_main
| _start
|
--0.91%--main test.cpp:13
__libc_start_main
_start
~~~
With this patch here applied, the issue is fixed. The report becomes
much more usable:
~~~
Overhead Source:Line
...
100.00% core.c:0
|
---__schedule core.c:0
schedule
do_nanosleep hrtimer.c:0
hrtimer_nanosleep
sys_nanosleep
entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
__nanosleep_nocancel .:0
std::this_thread::sleep_for >
thread:323
|
|--90.08%--main test.cpp:8
| __libc_start_main
| _start
|
|--9.01%--main test.cpp:9
| __libc_start_main
| _start
|
--0.91%--main test.cpp:10
__libc_start_main
_start
~~~
Similarly it works for signal frames:
~~~
#include
#include
#include
#define __noinline __attribute__((noinline))
__noinline void bar(void)
{
volatile long cnt = 0;
for (cnt = 0; cnt < 1; cnt++);
}
__noinline void foo(void)
{
bar();
}
void sig_handler(int sig)
{
foo();
}
int main(void)
{
signal(SIGUSR1, sig_handler);
raise(SIGUSR1);
foo();
return 0;
}
Before, the report wrongly points to `signal.c:29` after raise():
$ perf report --stdio --no-children -g srcline -s srcline
...
100.00% signal.c:11
|
---bar signal.c:11
|
|--50.49%--main signal.c:29
| __libc_start_main
| _start
|
--49.51%--0x33a8f
raise .:0
main signal.c:29
__libc_start_main
_start
With this patch in, the issue is fixed and we instead get:
100.00% signal signal[.] bar
|
---bar signal.c:11
|
|--50.49%--main signal.c:29
| __libc_start_main
| _start
|
--49.51%--0x33a8f
raise .:0
main signal.c:27
__libc_start_main
_start
Note how this patch fixes this issue for both unwinding methods, i.e.
both dwfl and libunwind. The former case is straight-forward thanks
to dwfl_frame_pc. For libunwind, we replace the functionality via
unw_is_signal_frame for any but the very first frame.
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Yao Jin
Signed-off-by: Milian Wolff
---
tools/perf/util/unwind-libdw.c | 6 +-
tools/perf/util/unwind-libunwind-local.c | 11 +++
2 files cha
[PATCH v2] perf report: fix memory leak in addr2line when called by addr2inlines
When a filename was found in addr2line it was duplicated via strdup
but never freed. Now we pass NULL and handle this gracefully in
addr2line.
Detected by Valgrind:
==16331== 1,680 bytes in 21 blocks are definitely lost in loss record 148 of 220
==16331==at 0x4C2AF1F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16331==by 0x672FA69: strdup (in /usr/lib/libc-2.25.so)
==16331==by 0x52769F: addr2line (srcline.c:256)
==16331==by 0x52769F: addr2inlines (srcline.c:294)
==16331==by 0x52769F: dso__parse_addr_inlines (srcline.c:502)
==16331==by 0x574D7A: inline__fprintf (hist.c:41)
==16331==by 0x574D7A: ipchain__fprintf_graph (hist.c:147)
==16331==by 0x57518A: __callchain__fprintf_graph (hist.c:212)
==16331==by 0x5753CF: callchain__fprintf_graph.constprop.6 (hist.c:337)
==16331==by 0x57738E: hist_entry__fprintf (hist.c:628)
==16331==by 0x57738E: hists__fprintf (hist.c:882)
==16331==by 0x44A20F: perf_evlist__tty_browse_hists (builtin-report.c:399)
==16331==by 0x44A20F: report__browse_hists (builtin-report.c:491)
==16331==by 0x44A20F: __cmd_report (builtin-report.c:624)
==16331==by 0x44A20F: cmd_report (builtin-report.c:1054)
==16331==by 0x4A49CE: run_builtin (perf.c:296)
==16331==by 0x4A4CC0: handle_internal_command (perf.c:348)
==16331==by 0x434371: run_argv (perf.c:392)
==16331==by 0x434371: main (perf.c:530)
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Yao Jin
Signed-off-by: Milian Wolff
---
tools/perf/util/srcline.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
v2:
- keep behavior of old function when strdup failed
- set ret to 1 if we found any inline node
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index df051a52393c..5e376d64d59e 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -230,7 +230,10 @@ static int addr2line(const char *dso_name, u64 addr,
bfd_map_over_sections(a2l->abfd, find_address_in_section, a2l);
- if (a2l->found && unwind_inlines) {
+ if (!a2l->found)
+ return 0;
+
+ if (unwind_inlines) {
int cnt = 0;
while (bfd_find_inliner_info(a2l->abfd, &a2l->filename,
@@ -243,6 +246,8 @@ static int addr2line(const char *dso_name, u64 addr,
a2l->line, node,
dso) != 0)
return 0;
+ // found at least one inline frame
+ ret = 1;
}
}
@@ -252,14 +257,14 @@ static int addr2line(const char *dso_name, u64 addr,
}
}
- if (a2l->found && a2l->filename) {
- *file = strdup(a2l->filename);
- *line = a2l->line;
-
- if (*file)
- ret = 1;
+ if (file) {
+ *file = a2l->filename ? strdup(a2l->filename) : NULL;
+ ret = *file ? 1 : 0;
}
+ if (line)
+ *line = a2l->line;
+
return ret;
}
@@ -278,8 +283,6 @@ void dso__free_a2l(struct dso *dso)
static struct inline_node *addr2inlines(const char *dso_name, u64 addr,
struct dso *dso)
{
- char *file = NULL;
- unsigned int line = 0;
struct inline_node *node;
node = zalloc(sizeof(*node));
@@ -291,7 +294,7 @@ static struct inline_node *addr2inlines(const char
*dso_name, u64 addr,
INIT_LIST_HEAD(&node->val);
node->addr = addr;
- if (!addr2line(dso_name, addr, &file, &line, dso, TRUE, node))
+ if (!addr2line(dso_name, addr, NULL, NULL, dso, TRUE, node))
goto out_free_inline_node;
if (list_empty(&node->val))
--
2.13.0
Re: [PATCH v2 1/5] pinctrl: qcom: Add ipq8074 pinctrl driver
On 5/18/2017 1:17 AM, Bjorn Andersson wrote:
On Mon 15 May 04:24 PDT 2017, Varadarajan Narayanan wrote:
On 5/15/2017 2:35 PM, Varadarajan Narayanan wrote:
On 5/14/2017 9:53 AM, Bjorn Andersson wrote:
On Thu 11 May 03:33 PDT 2017, Varadarajan Narayanan wrote:
On 5/11/2017 4:13 AM, Bjorn Andersson wrote:
On Thu 04 May 04:53 PDT 2017, Varadarajan Narayanan wrote:
[..]
+enum ipq8074_functions {
Please keep these sorted alphabetically.
Ok
+msm_mux_gpio,
+msm_mux_qpic_pad,
+msm_mux_blsp5_i2c,
+msm_mux_blsp5_spi,
+msm_mux_wci20,
What does "20" mean here?
This is for Wireless Coex Interface. The same functionality can
be muxed on
to different GPIOs. WCI2, is the 2nd edition of the WCI standard
and 0, 1
are for the muxing to different GPIOs (alternate muxes).
In other Qualcomm platforms the alternative muxes are denoted by letters
(a,b,c...). Would you mind picking up this naming scheme, or do you see
any problems with that? (E.g. wci2a in this case)
Ok
Btw, do you need any additional configuration for selecting alternative
muxing or is that automagical these days?
No additional configuration is needed.
+msm_mux_blsp3_spi3,
+msm_mux_burn0,
+msm_mux_pcm_zsi0,
+msm_mux_blsp5_uart,
+msm_mux_mac12,
What does "12" mean here?
The SoC has three MAC cores. Each core has two pins for the
smart antenna
feature. macXY indicates the function select for MAC no. X and
smart antenna
no. Y.
Ok
+msm_mux_blsp3_spi0,
+msm_mux_burn1,
+msm_mux_mac01,
+msm_mux_qdss_cti_trig_out_b0,
+msm_mux_qdss_cti_trig_in_b0,
+msm_mux_qpic_pad4,
What are qpic_pad and qpic_pad0 through qpic_pad8? Different functions,
alternative muxings...?
This is for the NAND and LCD display. The pins listed are the 9
data pins.
Then you can describe them all as "qpic_pad" (or simply "qpic"?). (It's
possible to reference a partial group in the DTS, if that's necessary)
There are two sets of 9 pins, either of which can go to NAND or LCD.
Will rename qpic_pad as qpic_a and qpic_pad[0-8] as qpic_b.
Is that ok?
+msm_mux_blsp4_uart0,
+msm_mux_blsp4_i2c0,
+msm_mux_blsp4_spi0,
+msm_mux_mac21,
+msm_mux_qdss_cti_trig_out_b1,
+msm_mux_qpic_pad5,
+msm_mux_qdss_cti_trig_in_b1,
+msm_mux_qpic_pad6,
+msm_mux_qpic_pad7,
+msm_mux_cxc0,
+msm_mux_mac13,
+msm_mux_qdss_cti_trig_in_a1,
+msm_mux_qdss_cti_trig_out_a1,
+msm_mux_wci22,
+msm_mux_qdss_cti_trig_in_a0,
+msm_mux_qpic_pad1,
+msm_mux_qdss_cti_trig_out_a0,
+msm_mux_qpic_pad2,
+msm_mux_qpic_pad3,
+msm_mux_qdss_traceclk_b,
+msm_mux_qpic_pad0,
+msm_mux_qdss_tracectl_b,
+msm_mux_qpic_pad8,
+msm_mux_pcm_zsi1,
+msm_mux_qdss_tracedata_b,
+msm_mux_led0,
+msm_mux_pwm04,
What does "04" mean here?
There are 4 Pulse Width Modulation channels, pwmXY is pwm
channel X and pin
Y.
So Y is alternative mux? Can we use letters for this as well?
Ok
Sorry, actually they are not alternative muxes. There are 4 different PWM
instances. Each PWM instance can handle 'n' different GPIOs (for example,
that can be connected to LED etc.).
So we have 4 PWMs and the output from a single PWM can muxed to drive
the output of 4 pins?
Then skip the last digit and just go pwm0, ... pwm3 and include all four
pins that can be part of each instance. As the pingroup configuration is
per pin in the TLMM it's possible to configure subsets of the pins in a
group.
Ok
Thanks
Varada
Regards,
Bjorn
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project
[PATCH v2] perf report: always honor callchain order for inlined nodes
So far, the inlined nodes where only reversed when we built perf
against libbfd. If that was not available, the addr2line fallback
code path was missing the inline_list__reverse call.
Now we always add the nodes in the correct order within
inline_list__append. This removes the need to reverse the list
and also ensures that all callers construct the list in the right
order.
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Yao Jin
Signed-off-by: Milian Wolff
---
tools/perf/util/srcline.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
v2:
- directly create list in correct order as suggested by Namhyung
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 5e376d64d59e..bbba9c69cfec 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -56,7 +56,10 @@ static int inline_list__append(char *filename, char
*funcname, int line_nr,
}
}
- list_add_tail(&ilist->list, &node->val);
+ if (callchain_param.order == ORDER_CALLEE)
+ list_add_tail(&ilist->list, &node->val);
+ else
+ list_add(&ilist->list, &node->val);
return 0;
}
@@ -200,14 +203,6 @@ static void addr2line_cleanup(struct a2l_data *a2l)
#define MAX_INLINE_NEST 1024
-static void inline_list__reverse(struct inline_node *node)
-{
- struct inline_list *ilist, *n;
-
- list_for_each_entry_safe_reverse(ilist, n, &node->val, list)
- list_move_tail(&ilist->list, &node->val);
-}
-
static int addr2line(const char *dso_name, u64 addr,
char **file, unsigned int *line, struct dso *dso,
bool unwind_inlines, struct inline_node *node)
@@ -250,11 +245,6 @@ static int addr2line(const char *dso_name, u64 addr,
ret = 1;
}
}
-
- if ((node != NULL) &&
- (callchain_param.order != ORDER_CALLEE)) {
- inline_list__reverse(node);
- }
}
if (file) {
@@ -497,12 +487,15 @@ char *get_srcline(struct dso *dso, u64 addr, struct
symbol *sym,
struct inline_node *dso__parse_addr_inlines(struct dso *dso, u64 addr)
{
const char *dso_name;
+ struct inline_node *node;
dso_name = dso__name(dso);
if (dso_name == NULL)
return NULL;
- return addr2inlines(dso_name, addr, dso);
+ node = addr2inlines(dso_name, addr, dso);
+
+ return node;
}
void inline_node__delete(struct inline_node *node)
--
2.13.0
[PATCH v2] perf report: do not drop last inlined frame
The very last inlined frame, i.e. the one furthest away from the
non-inlined frame, was silently dropped. This is apparent when
comparing the output of `perf script` and `addr2line`:
~~
$ perf script --inline
...
a.out 26722 80836.309329: 72425 cycles:
21493 __hypot_finite (/usr/lib/libm-2.25.so)
a4a std::abs (inline) (/tmp/a.out)
a4a std::_Norm_helper::_S_do_it (inline)
(/tmp/a.out)
a4a std::norm (inline) (/tmp/a.out)
a4a main (/tmp/a.out)
20510 __libc_start_main (/usr/lib/libc-2.25.so)
bd9 _start (/tmp/a.out)
$ addr2line -a -f -i -e /tmp/a.out a4a | c++filt
0x0a4a
std::__complex_abs(doublecomplex )
/usr/include/c++/6.3.1/complex:589
double std::abs(std::complex const&)
/usr/include/c++/6.3.1/complex:597
double std::_Norm_helper::_S_do_it(std::complex const&)
/usr/include/c++/6.3.1/complex:654
double std::norm(std::complex const&)
/usr/include/c++/6.3.1/complex:664
main
/tmp/inlining.cpp:14
~
Note how `std::__complex_abs` is missing from the `perf script`
output. This is similarly showing up in `perf report`. The patch
here fixes this issue, and the output becomes:
~
a.out 26722 80836.309329: 72425 cycles:
21493 __hypot_finite (/usr/lib/libm-2.25.so)
ace3 hypot (/usr/lib/libm-2.25.so)
a4a std::__complex_abs (inline) (/tmp/a.out)
a4a std::abs (inline) (/tmp/a.out)
a4a std::_Norm_helper::_S_do_it (inline)
(/tmp/a.out)
a4a std::norm (inline) (/tmp/a.out)
a4a main (/tmp/a.out)
20510 __libc_start_main (/usr/lib/libc-2.25.so)
bd9 _start (/tmp/a.out)
~
Cc: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Yao Jin
Signed-off-by: Milian Wolff
---
tools/perf/util/srcline.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
v2:
- rebase against patch fixing memleak in addr2lines
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index bbba9c69cfec..168285d37cd2 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -203,6 +203,16 @@ static void addr2line_cleanup(struct a2l_data *a2l)
#define MAX_INLINE_NEST 1024
+static int inline_list__append_dso_a2l(struct dso *dso,
+ struct inline_node *node)
+{
+ struct a2l_data *a2l = dso->a2l;
+ char *funcname = a2l->funcname ? strdup(a2l->funcname) : NULL;
+ char *filename = a2l->filename ? strdup(a2l->filename) : NULL;
+
+ return inline_list__append(filename, funcname, a2l->line, node, dso);
+}
+
static int addr2line(const char *dso_name, u64 addr,
char **file, unsigned int *line, struct dso *dso,
bool unwind_inlines, struct inline_node *node)
@@ -231,15 +241,15 @@ static int addr2line(const char *dso_name, u64 addr,
if (unwind_inlines) {
int cnt = 0;
+ if (node && inline_list__append_dso_a2l(dso, node))
+ return 0;
+
while (bfd_find_inliner_info(a2l->abfd, &a2l->filename,
&a2l->funcname, &a2l->line) &&
cnt++ < MAX_INLINE_NEST) {
if (node != NULL) {
- if (inline_list__append(strdup(a2l->filename),
- strdup(a2l->funcname),
- a2l->line, node,
- dso) != 0)
+ if (inline_list__append_dso_a2l(dso, node))
return 0;
// found at least one inline frame
ret = 1;
--
2.13.0
Re: [PATCH v2 1/5] pinctrl: qcom: Add ipq8074 pinctrl driver
On 5/18/2017 1:03 AM, Bjorn Andersson wrote: On Mon 15 May 02:05 PDT 2017, Varadarajan Narayanan wrote: On 5/14/2017 9:53 AM, Bjorn Andersson wrote: On Thu 11 May 03:33 PDT 2017, Varadarajan Narayanan wrote: On 5/11/2017 4:13 AM, Bjorn Andersson wrote: On Thu 04 May 04:53 PDT 2017, Varadarajan Narayanan wrote: [..] + msm_mux_qpic_pad4, What are qpic_pad and qpic_pad0 through qpic_pad8? Different functions, alternative muxings...? This is for the NAND and LCD display. The pins listed are the 9 data pins. Then you can describe them all as "qpic_pad" (or simply "qpic"?). (It's possible to reference a partial group in the DTS, if that's necessary) There are two sets of 9 pins, either of which can go to NAND or LCD. Will rename qpic_pad as qpic_a and qpic_pad[0-8] as qpic_b. Is that ok? So you have NAND and LCD hardware muxed to either "a" or "b" and then you mux either "a" or "b" out onto actual pins? How is this first mux configured? I think the a/b scheme sounds reasonable, if above is how it works. Sorry, I was wrong. I had misread the documentation. There are 18 pins. 15 pins are common between LCD and NAND. The QPIC controller arbitrates between LCD and NAND. Of the remaining 4, 2 are for NAND and 2 are for LCD exclusively. We plan to group the qpic pins into 3 groups namely, qpic_common, qpic_nand and qpic_lcd. Is that ok? Thanks Varada Regards, Bjorn ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: USB TYPE-C support and the power-supply subsys (was Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support)
On Wed, May 17, 2017 at 04:47:14PM +0200, Hans de Goede wrote: > Hi, > > On 17-05-17 13:45, Heikki Krogerus wrote: > > Hi, > > > > On Wed, May 17, 2017 at 12:24:52AM +0200, Hans de Goede wrote: > > > Hi, > > > > > > On 05/16/2017 02:07 PM, Heikki Krogerus wrote: > > > But we don't really have multiple sources here, we have only > > > one source, the USB-C cable hooked to an external power-supply. > > > Just because 2 different pieces of hardware may be involved in > > > determining the current limit does not mean that we should > > > model this as 2 different sources. Just as you rightfully > > > pointed out that me using 2 extcon devices for the single > > > Type-C connector is wrong, modelling it as 2 sources is > > > wrong too. > > > > The power supply devices don't represent the port like the extcon > > device would. The power supply devices represent the two types > > of external chargers we support. So BC1.2 and Type-C/PD source. > > Which are both USB chargers, and the TI bq24290 driver itself > also registers itself as a USB charger, continued below ... > > > > > 1. Tell the BC1.2 detection to start from fusb302 driver > > > > 2. Deliver the power limits to the discrete charger ic or battery driver > > > > 3. Tell what ever regulates VBUS to start driving VBUS. > > > > > > > The second problem definitely needs to be handled using psy framework. > > > > The psy framework provides already everything needed for that. > > > > > > So above you're talking about sources to the bq24190, which if > > > I understand you correctly suggest that you want the tcpm code to > > > register a power-supply device per Type-C port ? > > > > No, the underlying device driver (so fusb302) needs to register the > > power supply at this point. We just notify the psy framework if the > > limits we get from tcpm to the set_current_limit hook change. > > > > > I'm not sure that > > > is a good idea, any registered power-supply devices will show up > > > under /sys/class/power_supply, currently on a typical system > > > there will be 2 entries under /sys/class/power_supply one for > > > the "Mains" or USB power input and one for the battery, adding > > > more entries there is likely to confuse userspace. > > > > The userspace uses the type attribute to differentiate the supplies. > > Otherwise it would not be able to tell even which is the Battery and > > which is Mains. Having more power supplies is not a problem. > > I disagree yes power-supply devices have a type, so if we do > as you suggest we end up with 3 power-supplies with type USB under > /sys/class/power_supply suggesting to userspace that the device > may be supplied with power through 3 different USB connectors. > > This is simply just wrong. I understand that you want to decouple > the different drivers from each-other and I agree with that as > a goal. > > But using the power-supply subsys in the way you suggests means > that the way we end up solving a problem which is purely > about different pieces of code in the kernel talking to each > other gets leaked to userspace and once we've done this userspace > may start depending on this and we cannot change things later. > > TL;DR: I'm against the FUSB302 and the BC1.2 drivers each > registering a power-supply because: > > 1) There should be only one power-supply device registered > not 3, since there is only one power-input to the board, not 3. > > 2) Ideally the in kernel interface should not be visible to > userspace at all, we are still figuring all of this out and > we may need to change things later leaking internal kernel > details to userspace in something which will become an ABI > is not a good idea. > > I've added Sebastian Reichel, the power-supply subsys > maintainer to the Cc so that he can weigh in on this. > > > > More in general having 2 power-supply devices for what is > > > in essence one power-input feels wrong. > > > > > > We can still use the power-supply framework, but I would > > > envision this working like this: > > > > > > The platform code which enumerates the type-c controller > > > sets a "input-current-power-supply-name" string device-property > > > on the tcpm's (parent)device. When this is set the tpcm code > > > will do a power_supply_get_by_name and set the input > > > current on the returned power_supply by setting the > > > POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT property. > > > > The psy framework is probable a bit messy at them moment. It > > definitely does not do much protecting and in many cases one driver > > registers a power supply and an other just takes it over, but that > > should be avoided as it makes things difficult (painful) to maintain. > > It also poses risks IMO. There certainly almost never seems to be a > > real need for that. > > > > In this case the driver for fusb302 registers a power supply that > > provides properties like POWER_SUPPLY_PROP_VOLTAGE_MAX, etc. and > > simply calls power_supply_changed() when ever needed (when we kno
Re: [PATCH 2/9] timers: provide a "modern" variant of timers
On Thu, May 18, 2017 at 10:24:48AM +0200, Christoph Hellwig wrote:
> > b) give the union a name (breaks any reference to timer_list->func in C
> > code):
> >
> > + union {
> > + void(*func)(struct timer_list *timer);
> > + void(*function)(unsigned long);
> > + } u;
>
> I'll look into that, as it seems a lot safer, and places outside
> the timer code shouldn't really touch it (although I bet they do,
> so more fixes for this series..)
Meh. All the old init_timer users set function directly, so
I guess we need to use the other approach.
Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure
On Thu, May 18, 2017 at 10:34:34AM +0200, Florian Weimer wrote: > On 05/18/2017 10:31 AM, Peter Zijlstra wrote: > > That more or less worked, it still failed: > > > > /usr/bin/ld: /usr/local/src/glibc/build/nptl/tst-once5.o: relocation > > R_X86_64_32 against `.text' can not be used when making a shared object; > > recompile with -fPIC > > /usr/bin/ld: final link failed: Nonrepresentable section on output > > collect2: error: ld returned 1 exit status > > I think this is a bug in the binutils version shipping with Debian jessie. I am indeed on debian/testing (which is jessie just now I think), I'll apt-get upgrade to see if its fixed, otherwise, I'll just have to live with it for now.
Re: [Patch v3 2/3] PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC
On Thu, May 18, 2017 at 9:45 AM, Song Xiaowei wrote: > Hisilicon PCIe Driver shares the common functions fo PCIe dw-host > > The poweron functions is developed on hi3660 SoC, while Others Functions > are common for Kirin series SoCs. > > Lowpower(L1ss and SR), hotplug and MSI feature are not supported > currently. > > Cc: Guodong Xu > Signed-off-by: Song Xiaowei Acked-by: Arnd Bergmann
Re: commit cfafcd117 "futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()" causes glibc nptl/tst-robustpi8 failure
On 05/18/2017 10:41 AM, Peter Zijlstra wrote: > On Thu, May 18, 2017 at 10:34:34AM +0200, Florian Weimer wrote: >> On 05/18/2017 10:31 AM, Peter Zijlstra wrote: >>> That more or less worked, it still failed: >>> >>> /usr/bin/ld: /usr/local/src/glibc/build/nptl/tst-once5.o: relocation >>> R_X86_64_32 against `.text' can not be used when making a shared object; >>> recompile with -fPIC >>> /usr/bin/ld: final link failed: Nonrepresentable section on output >>> collect2: error: ld returned 1 exit status >> >> I think this is a bug in the binutils version shipping with Debian jessie. > > I am indeed on debian/testing (which is jessie just now I think), I'll > apt-get upgrade to see if its fixed, otherwise, I'll just have to live > with it for now. Careful. It's fixed in *current* debian/testing (stretch), so a very large upgrade might be waiting for you. Florian
[PATCH v2 0/2] dt-bindings: mfd: Add max7360 mfd driver and DT documentation
This series add initial support of mfd core driver for max7360 chip Andrei Dranitca (1): mfd: max7360: Add mfd core device driver Valentin Sitdikov (1): dt-bindings: Add DT bindings documentation for the max7360 mfd driver Documentation/devicetree/bindings/mfd/max7360.txt | 72 drivers/mfd/Kconfig | 16 + drivers/mfd/Makefile | 1 + drivers/mfd/max7360.c | 397 ++ include/linux/mfd/max7360.h | 130 +++ 5 files changed, 616 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/max7360.txt create mode 100644 drivers/mfd/max7360.c create mode 100644 include/linux/mfd/max7360.h -- 2.9.3
Re: Question regarding RT patches for ARM
Hi Eric, On 17 May 2017 at 16:45, Eric Nelson wrote: > Hi Fawad, > > On 05/17/2017 06:40 AM, Fawad Lateef wrote: >> >> On 15 May 2017 at 16:20, Fawad Lateef wrote: >>> >>> Hi Eric, >>> On 15 May 2017 at 16:12, Eric Nelson wrote: Hi Fawad, > 发自网易邮箱大师 > On 05/15/2017 20:44, Fawad Lateef wrote: > > Hi All, > > I am working on custom i.MX6 quad hardware and using RT patches for > almost latest stable kernel 4.9 and facing some weird system stall OR > 'unhandled page fault - exceptions'. > I'm not sure about the unhandled page fault, but the stalls may be because of the SDMA driver. See this patch in the Freescale/NXP community for kernel 4.1: https://github.com/Freescale/meta-freescale/blob/master/recipes-kernel/linux/linux-fslc-imx-rt/0003-Work-around-CPU-stalls-in-the-imx-sdma-driver.patch >>> >>> Thanks for the patch link. I will give it a try. >> >> >> Talked to hardware manufacturer and they applied the patch. >> >> Still that SDMA is only used for NOR flash and only u-boot and its >> environment are stored in nor flash. So not sure if that is going to >> help in any case. >> > > SDMA is used for much more than NOR flash (SSI, USB, and sometimes > UARTs). > Yes SDMA can be used for many devices but in our case its only set to use for NOR (to confirm I also checked sdma interrupts in system and they just 21 or so which happened during boot time). >> So I would really like few more suggestions OR confirmations about ARM >> (cortex-A9 based imx6) (preemept)-RT support/patches are stable and >> can be used for final products. >> > > I don't have any experience with the RT patches on 4.9 or later > kernels, but do know that they're being used on i.MX6 with the > vendor kernels (3.10.x, 4.1.x). > > I believe Alison Chaiken mentioned using them with 4.9 kernels: > http://elinux.org/images/4/42/IRQs-_the_Hard%2C_the_Soft%2C_the_Threaded_and_the_Preemptible.pdf > https://www.youtube.com/watch?v=-pehAzaP1eg&feature=youtu.be&list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q > Thanks for the video/link. Seems like very informative. Will check it soon. > Regards, > > > Eric Regards, Fawad Lateef
[PATCH 2/2] mfd: max7360: Add mfd core device driver
From: Andrei Dranitca
This patch adds core/irq driver to support MAX7360 i2c chip
which contains keypad, gpio, pwm, gpo and rotary encoder submodules.
Signed-off-by: Valentin Sitdikov
Signed-off-by: Andrei Dranitca
---
drivers/mfd/Kconfig | 16 ++
drivers/mfd/Makefile| 1 +
drivers/mfd/max7360.c | 397
include/linux/mfd/max7360.h | 130 +++
4 files changed, 544 insertions(+)
create mode 100644 drivers/mfd/max7360.c
create mode 100644 include/linux/mfd/max7360.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3eb5c93..894c2e9 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -721,6 +721,22 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MAX7360
+ tristate "Maxim Semiconductor MAX7360 support"
+ depends on I2C && OF
+ select MFD_CORE
+ select REGMAP_I2C
+ select IRQ_DOMAIN
+ help
+ Say yes here to add support for Maxim Semiconductor MAX7360.
+ This provides microprocessors with management of up to 64 key
switches,
+ with an additional eight LED drivers/GPIOs that feature
constant-current,
+ PWM intensity control, and rotary switch control options.
+
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
config MFD_MT6397
tristate "MediaTek MT6397 PMIC Support"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c16bf1e..9e721c0 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -137,6 +137,7 @@ obj-$(CONFIG_MFD_DA9063)+= da9063.o
obj-$(CONFIG_MFD_DA9150) += da9150-core.o
obj-$(CONFIG_MFD_MAX14577) += max14577.o
+obj-$(CONFIG_MFD_MAX7360) += max7360.o
obj-$(CONFIG_MFD_MAX77620) += max77620.o
obj-$(CONFIG_MFD_MAX77686) += max77686.o
obj-$(CONFIG_MFD_MAX77693) += max77693.o
diff --git a/drivers/mfd/max7360.c b/drivers/mfd/max7360.c
new file mode 100644
index 000..566434e
--- /dev/null
+++ b/drivers/mfd/max7360.c
@@ -0,0 +1,397 @@
+/*
+ * Copyright (C) 2017 Mentor Graphics
+ *
+ * Author: Valentin Sitdikov
+ * Author: Andrei Dranitca
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+int max7360_request_pin(struct max7360 *max7360, u8 pin)
+{
+ struct i2c_client *client = max7360->i2c;
+ int ret = 0;
+
+ spin_lock(&max7360->lock);
+ if (max7360->gpio_pins & BIT(pin)) {
+ dev_err(&client->dev, "pin %d already requested, mask %x",
+ pin, max7360->gpio_pins);
+ spin_unlock(&max7360->lock);
+ return -EBUSY;
+ }
+ max7360->gpio_pins |= BIT(pin);
+ dev_dbg(&client->dev, "pin %d requested successfully", pin);
+ spin_unlock(&max7360->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(max7360_request_pin);
+
+void max7360_free_pin(struct max7360 *max7360, u8 pin)
+{
+ spin_lock(&max7360->lock);
+ max7360->gpio_pins &= ~BIT(pin);
+ spin_unlock(&max7360->lock);
+}
+EXPORT_SYMBOL_GPL(max7360_free_pin);
+
+static const struct mfd_cell max7360_devices[] = {
+ {
+ .name = "max7360-gpio",
+ .of_compatible = "maxim,max7360-gpio",
+ },
+ {
+ .name = "max7360-keypad",
+ .of_compatible = "maxim,max7360-keypad",
+ },
+ {
+ .name = "max7360-pwm",
+ .of_compatible = "maxim,max7360-pwm",
+ },
+ {
+ .name = "max7360-rotary",
+ .of_compatible = "maxim,max7360-rotary",
+ },
+};
+
+static irqreturn_t max7360_irq(int irq, void *data)
+{
+ struct max7360 *max7360 = data;
+ int virq;
+
+ virq = irq_find_mapping(max7360->domain, MAX7360_INT_GPIO);
+ handle_nested_irq(virq);
+ virq = irq_find_mapping(max7360->domain, MAX7360_INT_KEYPAD);
+ handle_nested_irq(virq);
+ virq = irq_find_mapping(max7360->domain, MAX7360_INT_ROTARY);
+ handle_nested_irq(virq);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t max7360_irqi(int irq, void *data)
+{
+ struct max7360 *max7360 = data;
+
Re: [PATCH] mm,oom: fix oom invocation issues
On Thu 18-05-17 07:03:36, Tetsuo Handa wrote:
> Roman Gushchin wrote:
> > On Wed, May 17, 2017 at 06:14:46PM +0200, Michal Hocko wrote:
> > > On Wed 17-05-17 16:26:20, Roman Gushchin wrote:
> > > [...]
> > > > [ 25.781882] Out of memory: Kill process 492 (allocate) score 899 or
> > > > sacrifice child
> > > > [ 25.783874] Killed process 492 (allocate) total-vm:2052368kB,
> > > > anon-rss:1894576kB, file-rss:4kB, shmem-rss:0kB
> > >
> > > Are there any oom_reaper messages? Could you provide the full kernel log
> > > please?
> >
> > Sure. Sorry, it was too bulky, so I've cut the line about oom_reaper by
> > mistake.
> > Here it is:
> >
> > [ 25.721494] allocate invoked oom-killer:
> > gfp_mask=0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null),
> > order=0, oom_score_adj=0
> > [ 25.725658] allocate cpuset=/ mems_allowed=0
>
> > [ 25.759892] Node 0 DMA32 free:44700kB min:44704kB low:55880kB
> > high:67056kB active_anon:1944216kB inactive_anon:204kB active_file:592kB
> > inactive_file:0kB unevictable:0kB writepending:304kB present:2080640kB
> > managed:2031972kB mlocked:0kB slab_reclaimable:11336kB
> > slab_unreclaimable:9784kB kernel_stack:1776kB pagetables:6932kB bounce:0kB
> > free_pcp:0kB local_pcp:0kB free_cma:0kB
>
> > [ 25.781882] Out of memory: Kill process 492 (allocate) score 899 or
> > sacrifice child
> > [ 25.783874] Killed process 492 (allocate) total-vm:2052368kB,
> > anon-rss:1894576kB, file-rss:4kB, shmem-rss:0kB
>
> > [ 25.785680] allocate: page allocation failure: order:0,
> > mode:0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null)
> > [ 25.786797] allocate cpuset=/ mems_allowed=0
>
> This is a side effect of commit 9a67f6488eca926f ("mm: consolidate GFP_NOFAIL
> checks in the allocator slowpath") which I noticed at
> http://lkml.kernel.org/r/e7f932bf-313a-917d-6304-81528aca5...@i-love.sakura.ne.jp
> .
Hmm, I guess you are right. I haven't realized that pagefault_out_of_memory
can race and pick up another victim. For some reason I thought that the
page fault would break out on fatal signal pending but we don't do that (we
used to in the past). Now that I think about that more we should
probably remove out_of_memory out of pagefault_out_of_memory completely.
It is racy and it basically doesn't have any allocation context so we
might kill a task from a different domain. So can we do this instead?
There is a slight risk that somebody might have returned VM_FAULT_OOM
without doing an allocation but from my quick look nobody does that
currently.
---
>From f9970881fe11249e090bf959f32d5893c0c78e6c Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Thu, 18 May 2017 10:35:09 +0200
Subject: [PATCH] mm, oom: do not trigger out_of_memory from
pagefault_out_of_memory
Roman Gushchin has noticed that we kill two tasks when the memory hog
killed from page fault path:
[ 25.721494] allocate invoked oom-killer:
gfp_mask=0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0,
oom_score_adj=0
[ 25.725658] allocate cpuset=/ mems_allowed=0
[ 25.727033] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
[ 25.729215] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 25.729598] Call Trace:
[ 25.729598] dump_stack+0x63/0x82
[ 25.729598] dump_header+0x97/0x21a
[ 25.729598] ? do_try_to_free_pages+0x2d7/0x360
[ 25.729598] ? security_capable_noaudit+0x45/0x60
[ 25.729598] oom_kill_process+0x219/0x3e0
[ 25.729598] out_of_memory+0x11d/0x480
[ 25.729598] __alloc_pages_slowpath+0xc84/0xd40
[ 25.729598] __alloc_pages_nodemask+0x245/0x260
[ 25.729598] alloc_pages_vma+0xa2/0x270
[ 25.729598] __handle_mm_fault+0xca9/0x10c0
[ 25.729598] handle_mm_fault+0xf3/0x210
[ 25.729598] __do_page_fault+0x240/0x4e0
[ 25.729598] trace_do_page_fault+0x37/0xe0
[ 25.729598] do_async_page_fault+0x19/0x70
[ 25.729598] async_page_fault+0x28/0x30
which can lead VM_FAULT_OOM and so to another out_of_memory when bailing
out from the #PF
[ 25.817589] allocate invoked oom-killer: gfp_mask=0x0(), nodemask=(null),
order=0, oom_score_adj=0
[ 25.818821] allocate cpuset=/ mems_allowed=0
[ 25.819259] CPU: 1 PID: 492 Comm: allocate Not tainted 4.12.0-rc1-mm1+ #181
[ 25.819847] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 25.820549] Call Trace:
[ 25.820733] dump_stack+0x63/0x82
[ 25.820961] dump_header+0x97/0x21a
[ 25.820961] ? security_capable_noaudit+0x45/0x60
[ 25.820961] oom_kill_process+0x219/0x3e0
[ 25.820961] out_of_memory+0x11d/0x480
[ 25.820961] pagefault_out_of_memory+0x68/0x80
[ 25.820961] mm_fault_error+0x8f/0x190
[ 25.820961] ? handle_mm_fault+0xf3/0x210
[ 25.820961] __do_page_fault+0x4b2/0x4e0
[ 25.820961] trace_do_page_fault+0x37/0xe0
[ 25.820961] do_async_page_fault+0x19/0x70
[ 25.82
Re: [PATCH v3 2/2] powerpc/mm/hugetlb: Add support for 1G huge pages
"Aneesh Kumar K.V" writes: > On Thursday 18 May 2017 10:51 AM, Michael Ellerman wrote: >> "Aneesh Kumar K.V" writes: >> >>> POWER9 supports hugepages of size 2M and 1G in radix MMU mode. This patch >>> enables the usage of 1G page size for hugetlbfs. This also update the helper >>> such we can do 1G page allocation at runtime. >>> >>> We still don't enable 1G page size on DD1 version. This is to avoid doing >>> workaround mentioned in commit: 6d3a0379ebdc8 (powerpc/mm: Add >>> radix__tlb_flush_pte_p9_dd1() >>> >>> Signed-off-by: Aneesh Kumar K.V >>> --- >>> arch/powerpc/include/asm/book3s/64/hugetlb.h | 10 ++ >>> arch/powerpc/mm/hugetlbpage.c| 7 +-- >>> arch/powerpc/platforms/Kconfig.cputype | 1 + >>> 3 files changed, 16 insertions(+), 2 deletions(-) >> >> I think this patch is OK, but it's very confusing because it doesn't >> mention that it's only talking about *generic* gigantic page support. > > What you mean by generic gigantic page ? what is supported here is the > gigantic page with size 1G alone ? What about 16G pages on pseries. And all the other gigantic page sizes that Book3E supports? cheers
[PATCH 1/2] dt-bindings: mfd: Add DT bindings documentation for the max7360 mfd driver
This patch adds documentation for the max7360 bindings.
The max7360 is multifunctional device containing gpio, keypad, pwm and rotary
encoder submodules.
Signed-off-by: Valentin Sitdikov
Signed-off-by: Andrei Dranitca
---
Documentation/devicetree/bindings/mfd/max7360.txt | 72 +++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max7360.txt
diff --git a/Documentation/devicetree/bindings/mfd/max7360.txt
b/Documentation/devicetree/bindings/mfd/max7360.txt
new file mode 100644
index 000..fd83227
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max7360.txt
@@ -0,0 +1,72 @@
+* Maxim MAX7360 multi-function device
+
+The Maxim MAX7360 is a multifunction device which includes
+64 key switches, eight LED drivers/GPIOs, PWM intensity control,
+and rotary switch control.
+
+Required properties:
+- compatible: Should be the following: "maxim,max7360"
+- reg: Specifies the i2c slave address of the max7360 block. It can be 0x38,
0x3a, 0x3c or 0x3e IIUC.
+
+Optional properties:
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+ the interrupts from MAX7360 are routed to.
+- interrupt-names: list of "inti" and "intk"
+- interrupt-controller: Identifies the device as an interrupt controller.
+- #interrupt-cells : Number of cells to encode an interrupt source, shall be
1.
+
+Examples:
+
+Without subnodes:
+ max7360@38 {
+ compatible = "maxim,max7360";
+ reg = <0x38>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <23 IRQ_TYPE_LEVEL_LOW>, <23 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "inti", "intk";
+ interrupt-controller;
+ #interrupt-cells = <0x1>;
+
+ };
+
+With subnodes:
+ max7360@38 {
+ compatible = "maxim,max7360";
+ reg = <0x38>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "int-shared";
+ interrupt-controller;
+ #interrupt-cells = <0x1>;
+
+ gpio {
+ compatible = "maxim,max7360-gpio";
+ gpio-controller;
+ #gpio-cells = <0x2>;
+ interrupt-controller;
+ #interrupt-cells = <0x2>;
+ interrupts = <0>;
+ };
+
+ keypad {
+ compatible = "maxim,max7360-keypad";
+ maxim,debounce_reg = /bits/ 8 <0xef>;
+ maxim,ports_reg = /bits/ 8 <0xae>;
+ linux,keymap = < MATRIX_KEY(0, 0, KEY_F5)
+MATRIX_KEY(1, 0, KEY_F4) >;
+ keypad,num-rows = <2>;
+ keypad,num-columns = <1>;
+ interrupts = <1>;
+ };
+
+ pwm {
+ compatible = "maxim,max7360-pwm";
+ #pwm-cells = <0x2>;
+ };
+
+ rotary_encoder {
+ compatible = "maxim,max7360-rotary";
+ interrupts = <2>;
+ };
+
+ };
--
2.9.3
