Re: [RFT v3] eata: Convert eata driver as normal PCI and platform device drivers

[Arthur Marsh]

Jiang Liu wrote on 24/09/15 13:58:


Hi James,
Thanks for review. How about the attached patch which addresses
the three suggestions from you?
Thanks!
Gerry


I've applied the patch, rebuilt the kernel and verified that it allows 
unloading of the eata module and reloading it, as well as a successful 
kexec.


Regards,

Arthur.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Staging: rtl8712: rtl871x_io.h: Coding style warning fix for block comments

[Sudip Mukherjee]

On Thu, Sep 24, 2015 at 01:22:33AM +0530, Punit Vara wrote:
> This patch is to the rtl871x_io.h file that fixes up following warning
> reported by checkpatch.pl :
> 
> Signed-off-by: Punit Vara 
> ---
You missed copying the warning after mentioning "following warning" in
your commit message.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/9] ARM: dts: Move all Cygnus peripherals into soc bus

[Ray Jui]

On 9/23/2015 2:55 PM, Ray Jui wrote:
> 
> 
> On 9/23/2015 2:29 PM, Arnd Bergmann wrote:
>> On Friday 18 September 2015 15:11:27 Ray Jui wrote:
>>> On 9/18/2015 2:34 PM, Arnd Bergmann wrote:
 On Friday 18 September 2015 14:24:10 Ray Jui wrote:
> +   soc {
> +   compatible = "simple-bus";
> +   ranges;
> +   #address-cells = <1>;
> +   #size-cells = <1>;

> +   pinctrl: pinctrl@0301d0c8 {
>

 Similarly to the core bus, this seems to have address ranges 0x03xx and
 0x18xx on it, so put those into the ranges.

>>>
>>> Okay we have an issue here. For whatever reason, the Cygnus ASIC team
>>> decided to put registers for the same block in random locations. We see
>>> similar issues in all of our other iProc based SoCs. We have
>>> communicated this to our ASIC team, and hopefully they can revert the
>>> trend for the next SoC.
>>>
>>> For example, the gpio_ccm has registers in the following regions:
>>>
>>> gpio_ccm: gpio@1800a000 {
>>> compatible = "brcm,cygnus-ccm-gpio";
>>> reg = <0x1800a000 0x50>,
>>>   <0x0301d164 0x20>;
>>>
>>> NAND is worse, it has registers in 3 different separate regions:
>>>
>>> nand: nand@18046000 {
>>> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1",
>>>  "brcm,brcmnand";
>>> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
>>>   <0x18046f00 0x20>;
>>>
>>> As you can see, this makes it impossible to define a proper address
>>> range for the bus; therefore, I'll have to keep the ranges undefined and
>>> a simple 1:1 mapping under this bus.
>>
>> Hmm, you could still try to list them as non-overlapping with other
>> buses on the root node like
>>
>>  ranges = <0x0300 0x0300 0x0100>,
>>   <0x1800 0x1800 0x0100>,
>>   <0xf800 0xf800 0x0100>;
>>
>> which clarifies how the bus is wired up in hardware.
>>
>> Alternatively, you could make a more elaborate mapping, if there
>> are in fact multiple hardware ranges, like
>>
>>  #address-cells = <2>; # space:offset
>>  ranges = <1 0  0x0300 0x0100>,
>>   <2 0  0x1800 0x0100>,
>>   <3 0  0xf800 0x0100>;
>>
>> It really depends on what the hardware designers were thinking. If
>> the AXI bus actually decodes the entire 32-bit address range and devices
>> are just located at random addresses in there, your current scheme is
>> probably closest to reality.
>>
> 
> I see. Let me talk to our ASIC team to get this clarified. If in the end
> the AXI bus decodes the entire 32-bit address space, no change will be
> made. Otherwise, I'll submit another patch to list the actual address
> space that the AXI bus decodes.
> 
> Thanks for the review. It's very helpful!
> 
> Ray
> 

I just got feedback from our ASIC team. The NIC-301 is the main AXI
fabric that decodes the entire 32-bit address space on Cygnus.

I'll keep this as it is for now.

Thanks,

Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] ASoC: atmel-classd: add the Audio Class D Amplifier

[Songjun Wu]

Add driver for the digital imput to PWM output stereo
class D amplifier. It comes with filter, digitally
controlled gain, an equalizer and a dmphase filter.

Signed-off-by: Songjun Wu 
---

Changes in v2:
- Change the "Mono", "Swap" and "Deemphasis" controls to
  "Mono Switch", "Swap Switch" and "Deemphasis Switch".
- Merge "EQ Bass", "EQ Medium" and "EQ Treble" controls
  into one "EQ" control.
- Change the "single-ended" and "differential" to
  "Single ended", "Differential".
- Merge separate left and right controls into one single
  stereo control.
- Add a warning if the user trys to specify an invalid
  value in function "atmel_classd_codec_probe".
- Use the "dev_get_regmap()" in function
  "atmel_classd_codec_get_remap".
- Check for errors when invoking the "clk_prepare_enable".
- Remove the "dev_info" in function "atmel_classd_probe".
- Add some code to create a sound card in function
  "atmel_classd_probe".
- Remove the DT node "Sound" and the related code.

 sound/soc/atmel/Kconfig|9 +
 sound/soc/atmel/Makefile   |2 +
 sound/soc/atmel/atmel-classd.c |  680 
 sound/soc/atmel/atmel-classd.h |  120 +++
 4 files changed, 811 insertions(+)
 create mode 100644 sound/soc/atmel/atmel-classd.c
 create mode 100644 sound/soc/atmel/atmel-classd.h

diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 1489cd4..2d30464 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -59,4 +59,13 @@ config SND_AT91_SOC_SAM9X5_WM8731
help
  Say Y if you want to add support for audio SoC on an
  at91sam9x5 based board that is using WM8731 codec.
+
+config SND_ATMEL_SOC_CLASSD
+   tristate "Atmel ASoC driver for boards using CLASSD"
+   depends on ARCH_AT91 || COMPILE_TEST
+   select SND_ATMEL_SOC_DMA
+   select REGMAP_MMIO
+   help
+ Say Y if you want to add support for Atmel ASoC driver for boards 
using
+ CLASSD.
 endif
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index b327e5c..f6f7db4 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -11,7 +11,9 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
 snd-atmel-soc-wm8904-objs := atmel_wm8904.o
 snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
+snd-atmel-soc-classd-objs := atmel-classd.o
 
 obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
 obj-$(CONFIG_SND_ATMEL_SOC_WM8904) += snd-atmel-soc-wm8904.o
 obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
+obj-$(CONFIG_SND_ATMEL_SOC_CLASSD) += snd-atmel-soc-classd.o
diff --git a/sound/soc/atmel/atmel-classd.c b/sound/soc/atmel/atmel-classd.c
new file mode 100644
index 000..ab630b3
--- /dev/null
+++ b/sound/soc/atmel/atmel-classd.c
@@ -0,0 +1,680 @@
+/* Atmel ALSA SoC Audio Class D Amplifier (CLASSD) driver
+ *
+ * Copyright (C) 2015 Atmel
+ *
+ * Author: Songjun Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 or later
+ * as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "atmel-classd.h"
+
+struct atmel_classd_pdata {
+   bool non_overlap_enable;
+   int non_overlap_time;
+   int pwm_type;
+   const char *card_name;
+};
+
+struct atmel_classd {
+   dma_addr_t phy_base;
+   struct regmap *regmap;
+   struct clk *pclk;
+   struct clk *gclk;
+   struct clk *aclk;
+   int irq;
+   const struct atmel_classd_pdata *pdata;
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id atmel_classd_of_match[] = {
+   {
+   .compatible = "atmel,sama5d2-classd",
+   }, {
+   /* sentinel */
+   }
+};
+MODULE_DEVICE_TABLE(of, atmel_classd_of_match);
+
+static struct atmel_classd_pdata *atmel_classd_dt_init(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct atmel_classd_pdata *pdata;
+   const char *pwm_type;
+   int ret;
+
+   if (!np) {
+   dev_err(dev, "device node not found\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return ERR_PTR(-ENOMEM);
+
+   ret = of_property_read_string(np, "atmel,pwm-type", _type);
+   if ((ret == 0) && (strcmp(pwm_type, "diff") == 0))
+   pdata->pwm_type = CLASSD_MR_PWMTYP_DIFF;
+   else
+   pdata->pwm_type = CLASSD_MR_PWMTYP_SINGLE;
+
+   ret = of_property_read_u32(np,
+   "atmel,non-overlap-time", >non_overlap_time);
+   if (ret)
+   pdata->non_overlap_enable = false;
+   else
+   pdata->non_overlap_enable = true;
+
+   ret = of_property_read_string(np, "atmel,model", 

[PATCH v2 0/2] ASoC: atmel-classd: add driver for Atmel CLASSD

[Songjun Wu]

The Audio Class D Amplifier driver includes two parts.
1) Driver code to implement the Audio Class D Amplifier function.
2) Device tree binding document, it describes how to add the Audio
   Class D Amplifier in device tree.

Changes in v2:
- Change the "Mono", "Swap" and "Deemphasis" controls to
  "Mono Switch", "Swap Switch" and "Deemphasis Switch".
- Merge "EQ Bass", "EQ Medium" and "EQ Treble" controls
  into one "EQ" control.
- Change the "single-ended" and "differential" to
  "Single ended", "Differential".
- Merge separate left and right controls into one single
  stereo control.
- Add a warning if the user trys to specify an invalid
  value in function "atmel_classd_codec_probe".
- Use the "dev_get_regmap()" in function
  "atmel_classd_codec_get_remap".
- Check for errors when invoking the "clk_prepare_enable".
- Remove the "dev_info" in function "atmel_classd_probe".
- Add some code to create a sound card in function
  "atmel_classd_probe".
- Remove the DT node "Sound" and the related code.
- Delete the device node "Sound".

Songjun Wu (2):
  ASoC: atmel-classd: add the Audio Class D Amplifier
  ASoC: atmel-classd: DT binding for Class D audio amplifier driver

 .../devicetree/bindings/sound/atmel-classd.txt |   52 ++
 sound/soc/atmel/Kconfig|9 +
 sound/soc/atmel/Makefile   |2 +
 sound/soc/atmel/atmel-classd.c |  680 
 sound/soc/atmel/atmel-classd.h |  120 
 5 files changed, 863 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-classd.txt
 create mode 100644 sound/soc/atmel/atmel-classd.c
 create mode 100644 sound/soc/atmel/atmel-classd.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problems with printk logs and my driver

[Jiri Kosina]

On Wed, 23 Sep 2015, Alan Stern wrote:

> Your mistake was thinking that the driver for your keyboard is usbkbd.  
> It isn't.  It's usbhid, as you can see in the "lsusb -t" output above.

As Eric is absolutely not the first person ever who got confused by this 
(and I can certainly understand the reasons for this confusion), I've been 
thinking for quite some time already about renaming this driver (and 
usbmouse as well). We'd probably want to make obvious from the name that 
this isn't regular usb keyboard driver.

Any opinions on usbkbd-simple or usbkbd-dummy? The most accurate would of 
course be usbkbd-boot, but that might be equally confusing.

The drawback I can see in renaming the driver is various embedded folks 
having he name hardcoded in their scripts.

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver

[Songjun Wu]

DT binding documentation for this new ASoC driver.

Signed-off-by: Songjun Wu 
---

Changes in v2:
- Delete the device node "Sound".

 .../devicetree/bindings/sound/atmel-classd.txt |   52 
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-classd.txt

diff --git a/Documentation/devicetree/bindings/sound/atmel-classd.txt 
b/Documentation/devicetree/bindings/sound/atmel-classd.txt
new file mode 100644
index 000..0018451
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel-classd.txt
@@ -0,0 +1,52 @@
+* Atmel ClassD driver under ALSA SoC architecture
+
+Required properties:
+- compatible
+   Should be "atmel,sama5d2-classd".
+- reg
+   Should contain ClassD registers location and length.
+- interrupts
+   Should contain the IRQ line for the ClassD.
+- dmas
+   One DMA specifiers as described in atmel-dma.txt and dma.txt files.
+- dma-names
+   Must be "tx".
+- clock-names
+   Tuple listing input clock names.
+   Required elements: "pclk", "gclk" and "aclk".
+- clocks
+   Please refer to clock-bindings.txt.
+
+Optional properties:
+- pinctrl-names, pinctrl-0
+   Please refer to pinctrl-bindings.txt.
+- atmel,model
+   The user-visible name of this sound complex.
+   The default value is "CLASSD".
+- atmel,pwm-type
+   PWM modulation type, "single" or "diff".
+   The default value is "single".
+- atmel,non-overlap-time
+   Set non-overlapping time, the unit is nanosecond(ns).
+   There are four values,
+   <5>, <10>, <15>, <20>, the default value is <10>.
+   Non-overlapping will be disabled if not specified.
+
+Example:
+classd: classd@fc048000 {
+   compatible = "atmel,sama5d2-classd";
+   reg = <0xfc048000 0x100>;
+   interrupts = <59 IRQ_TYPE_LEVEL_HIGH 7>;
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
+   | AT91_XDMAC_DT_PERID(47))>;
+   dma-names = "tx";
+   clocks = <_clk>, <_gclk>, <_pll_pmc>;
+   clock-names = "pclk", "gclk", "aclk";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_classd_default>;
+   atmel,model = "classd @ SAMA5D2-Xplained";
+   atmel,pwm-type = "diff";
+   atmel,non-overlap-time = <10>;
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] gpio:Fix error checking in the function device_pca957x_init

[Alexandre Courbot]

On Thu, Sep 24, 2015 at 11:42 AM, Nicholas Krause  wrote:
> This fixes error checking in the function device_pca957x_init
> to properly check and return error code values from the calls
> to the function pca953x_write_regs if they fail as to properly
> signal callers when a error occurs due a failure when writing
> registers for this gpio based device.

I gave a Reviewed-by to the previous iteration of this patch but you
have not included it in this one.

Besides I also asked you to add a space after "gpio:" in your subject
line, but you have ignored this as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] BNX2: fix a Null Pointer for stats_blk

[David Miller]

From: Weidong Wang 
Date: Thu, 24 Sep 2015 10:00:45 +0800

> It does affect the intention. Although, the problem exists then makes the
> system panic within some case.
> 
> Do you have any idea about it?

Allocate the statistics block at probe time so that this problem is
impossible.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Sep 24

[Stephen Rothwell]

Hi all,

Changes since 20150923:

The berlin tree lost its build failure.

I used the h8300 tree from next-20150828 since the current tree has been
rebased onto something very old :-(

The drm-intel tree gained a conflict aaginst the drm-intel-fixes tree.

Non-merge commits (relative to Linus' tree): 2789
 2394 files changed, 126112 insertions(+), 35818 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final
link) and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 226 trees (counting Linus' and 33 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (bcee19f424a0 Merge branch 'for-4.3-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup)
Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (7ae85dc7687c ARM: 8425/1: kgdb: Don't try to stop 
the machine when setting breakpoints)
Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather 
than duplicating its implementation)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (793b8bf9ca17 powerpc: Wire up sys_membarrier())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (7bbe33ff1896 geneve: use network byte order for destination 
port config parameter)
Merging ipsec/master (04a6b8bfee06 xfrm6: Fix ICMPv6 and MH header checks in 
_decode_session6)
Merging sound-current/for-linus (5ee20bc79246 ALSA: usb-audio: Change internal 
PCM order)
Merging pci-current/for-linus (6044546d5ee6 PCI: Clear IORESOURCE_UNSET when 
clipping a bridge window)
Merging wireless-drivers/master (c2e7204d180f tcp_cubic: do not set epoch_start 
in the future)
Merging driver-core.current/driver-core-linus (2110d70c5e58 cpu/cacheinfo: Fix 
teardown path)
Merging tty.current/tty-linus (f7a7651fcd40 tty: serial: Add missing module 
license for 8250_base.ko)
Merging usb.current/usb-linus (cbb4be652d37 USB: whiteheat: fix potential 
null-deref at probe)
Merging usb-gadget-fixes/fixes (a66c275b3d5d usb: dwc3: gadget: Fix BUG in RT 
config)
Merging usb-serial-fixes/usb-linus (19ab6bc5674a USB: option: add ZTE PIDs)
Merging staging.current/staging-linus (74c600e36455 MAINTAINERS: Update email 
address for Martyn Welch)
Merging char-misc.current/char-misc-linus (50314035d6b1 Merge tag 
'extcon-fixes-for-4.3-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into 
char-misc-linus)
Merging input-current/for-linus (72d4736253af Input: uinput - fix crash when 
using ABS events)
Merging crypto-current/master (09185e2756a8 hwrng: xgene - fix handling 
platform_get_irq)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (ae7858180510 selftests: exec: revert to default 
emit rule)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e bac

Re: crisv32 runtime failure in -next due to 'page-flags: define behavior SL*B-related flags on compound pages'

[Paul E. McKenney]

On Wed, Sep 23, 2015 at 08:02:44AM -0700, Guenter Roeck wrote:
> On 09/23/2015 03:53 AM, Kirill A. Shutemov wrote:
> >On Tue, Sep 22, 2015 at 08:40:14AM -0700, Paul E. McKenney wrote:
> >>On Tue, Sep 22, 2015 at 06:31:04PM +0300, Kirill A. Shutemov wrote:
> >>>On Tue, Sep 22, 2015 at 08:18:35AM -0700, Paul E. McKenney wrote:
> On Tue, Sep 22, 2015 at 03:57:06PM +0200, Hans-Peter Nilsson wrote:
> >I guess you hit the right spot, but I'd think people would be
> >more comfortable with aligning to sizeof (void *).
> 
> I would indeed prefer sizeof(void *).
> >>>
> >>>Do you prefer to have the attribute set for whole structure or for ->next?
> >>>I think attribute on ->next is more appropriate from documentation POV.
> >
> >I retract this claim: we have requirement about pointee alignment, not
> >pointer alignment.
> >
> >>From edbab9e89f5e4ad42e63d93ab05519e6a5f4d552 Mon Sep 17 00:00:00 2001
> >From: "Kirill A. Shutemov" 
> >Date: Wed, 23 Sep 2015 13:39:28 +0300
> >Subject: [PATCH] rcu: force alignment on struct callback_head/rcu_head
> >
> >This patch makes struct callback_head aligned to size of pointer. On
> >most architectures it happens naturally due ABI requirements, but some
> >architectures (like CRIS) have weird ABI and we need to ask it
> >explicitly.
> >
> >The alignment is required to guarantee that bits 0 and 1 of @next will
> >be clear under normal conditions -- as long as we use call_rcu(),
> >call_rcu_bh(), call_rcu_sched(), or call_srcu() to queue callback.
> >
> >This guarantee is important for few reasons:
> >  - future call_rcu_lazy() will make use of lower bits in the pointer;
> >  - the structure shares storage spacer in struct page with @compound_head,
> >which encode PageTail() in bit 0. The guarantee is needed to avoid
> >false-positive PageTail().
> >
> >False postive PageTail() caused crash on crisv32[1]. It happend due
> >misaligned task_struct->rcu, which was byte-aligned.
> >
> >[1] http://lkml.kernel.org/r/55faea67.9000...@roeck-us.net
> >
> >Signed-off-by: Kirill A. Shutemov 
> >Reported-by: Guenter Roeck 
> 
> Tested-by: Guenter Roeck 
> 
> Hope the patch won't get lost since it was attached to an e-mail.
> Can it be added to the branch introducing the problem ?

Andrew Morton picked it up.  No idea where the problem was introduced.

Thanx, Paul

> Thanks,
> Guenter
> 
> >---
> >  include/linux/types.h | 16 +++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> >
> >diff --git a/include/linux/types.h b/include/linux/types.h
> >index c314989d9158..70d8500bddf1 100644
> >--- a/include/linux/types.h
> >+++ b/include/linux/types.h
> >@@ -205,11 +205,25 @@ struct ustat {
> >   * struct callback_head - callback structure for use with RCU and task_work
> >   * @next: next update requests in a list
> >   * @func: actual update function to call after the grace period.
> >+ *
> >+ * The struct is aligned to size of pointer. On most architectures it 
> >happens
> >+ * naturally due ABI requirements, but some architectures (like CRIS) have
> >+ * weird ABI and we need to ask it explicitly.
> >+ *
> >+ * The alignment is required to guarantee that bits 0 and 1 of @next will be
> >+ * clear under normal conditions -- as long as we use call_rcu(),
> >+ * call_rcu_bh(), call_rcu_sched(), or call_srcu() to queue callback.
> >+ *
> >+ * This guarantee is important for few reasons:
> >+ *  - future call_rcu_lazy() will make use of lower bits in the pointer;
> >+ *  - the structure shares storage spacer in struct page with 
> >@compound_head,
> >+ *which encode PageTail() in bit 0. The guarantee is needed to avoid
> >+ *false-positive PageTail().
> >   */
> >  struct callback_head {
> > struct callback_head *next;
> > void (*func)(struct callback_head *head);
> >-};
> >+} __attribute__((aligned(sizeof(void *;
> >  #define rcu_head callback_head
> >
> >  typedef void (*rcu_callback_t)(struct rcu_head *head);
> >
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch V1 3/3] x86, mce: Account for offline CPUs during MCE rendezvous.

[Ashok Raj]

Linux has logical CPU offline, supported as shown below.

#echo 0 > /sys/devices/system/cpu/cpuX/online

Hardware doesn't know about CPUs offlined by the OS, hence hardware will
continue broadcast any MCE to all CPUs in the system, which includes
CPUs offlined.  Hence mce_start() and mce_end() should use cpu_present_map to
count CPUs in rendezvous. CPUs Offlined by OS are also in the MCE domain,
so they also have to process int18 handlers. Since current code only accounts
for CPUs online.  This will result in cpu_callin being higher by the number
of of CPUs offined.

The main benefit is in the odd case the offline CPU is the source of
the MCE, kernel will be able to capture logs properly even for offline
CPUs.

This patch does the following.

- Allow offline CPUs to participate in the MCE rendezvous process.
- Ensure the offline CPU will not be choosen as the rendezvous master CPU
- Collect logs from the offline cpu and report them via rendezvous master.

Signed-off-by: Ashok Raj 
Reviewed-by: Tony Luck 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 2df073d..080eefe 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -195,8 +195,6 @@ static void mce_log_add(struct mce *mce)
 
 void mce_log(struct mce *mce)
 {
-   unsigned next, entry;
-
/* Emit the trace record: */
trace_mce_record(mce);
 
@@ -756,8 +754,14 @@ static void mce_reign(void)
 * This CPU is the Monarch and the other CPUs have run
 * through their handlers.
 * Grade the severity of the errors of all the CPUs.
+* Intel CPUs broadcast MCEs to all CPUs booted. Even if they are
+* parked in idle due to logical CPU offline. Hence we should count
+* all CPUs to process MCEs.
+* Intel CPUs broadcsat MCEs to all CPUs booted. Even if they are
+* parked in idle due to logical CPU offline. Hence we should count
+* all CPUs to process MCEs.
 */
-   for_each_possible_cpu(cpu) {
+   for_each_present_cpu(cpu) {
int severity = mce_severity(_cpu(mces_seen, cpu),
mca_cfg.tolerant,
, true);
@@ -809,8 +813,9 @@ static atomic_t global_nwo;
 static int mce_start(int *no_way_out)
 {
int order;
-   int cpus = num_online_cpus();
+   int cpus = num_present_cpus();
u64 timeout = (u64)mca_cfg.monarch_timeout * NSEC_PER_USEC;
+   unsigned int this_cpu = smp_processor_id();
 
if (!timeout)
return -1;
@@ -820,6 +825,16 @@ static int mce_start(int *no_way_out)
 * global_nwo should be updated before mce_callin
 */
smp_wmb();
+
+   /*
+* If this cpu is offline, make sure it won't be elected as
+* the rendezvous master
+*/
+   if (cpu_is_offline(this_cpu)) {
+   while (!atomic_read(_callin))
+   ndelay(SPINUNIT);
+   }
+
order = atomic_inc_return(_callin);
 
/*
@@ -890,7 +905,7 @@ static int mce_end(int order)
 
if (order == 1) {
/* CHECKME: Can this race with a parallel hotplug? */
-   int cpus = num_online_cpus();
+   int cpus = num_present_cpus();
 
/*
 * Monarch: Wait for everyone to go through their scanning
@@ -984,6 +999,8 @@ void do_machine_check(struct pt_regs *regs, long error_code)
int i;
int worst = 0;
int severity;
+   unsigned int cpu = smp_processor_id();
+
/*
 * Establish sequential order between the CPUs entering the machine
 * check handler.
@@ -1098,7 +1115,10 @@ void do_machine_check(struct pt_regs *regs, long 
error_code)
m.severity = severity;
m.usable_addr = mce_usable_address();
 
-   mce_log();
+   if (cpu_is_offline(cpu))
+   mce_log_add();
+   else
+   mce_log();
 
if (severity > worst) {
*final = m;
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch V1 2/3] x86, mce: Refactor parts of mce_log() to reuse when logging from offline CPUs

[Ashok Raj]

Simply refactoring part of mce_log() to facilitate logging from offline
CPUs.

Signed-off-by: Ashok Raj 
Reviewed-by: Tony Luck 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 48bd244..2df073d 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -152,16 +152,10 @@ static struct mce_log mcelog = {
.recordlen  = sizeof(struct mce),
 };
 
-void mce_log(struct mce *mce)
+static void mce_log_add(struct mce *mce)
 {
unsigned next, entry;
 
-   /* Emit the trace record: */
-   trace_mce_record(mce);
-
-   if (!mce_gen_pool_add(mce))
-   irq_work_queue(_irq_work);
-
mce->finished = 0;
wmb();
for (;;) {
@@ -199,6 +193,19 @@ void mce_log(struct mce *mce)
set_bit(0, _need_notify);
 }
 
+void mce_log(struct mce *mce)
+{
+   unsigned next, entry;
+
+   /* Emit the trace record: */
+   trace_mce_record(mce);
+
+   if (!mce_gen_pool_add(mce))
+   irq_work_queue(_irq_work);
+
+   mce_log_add(mce);
+}
+
 void mce_inject_log(struct mce *m)
 {
mutex_lock(_chrdev_read_mutex);
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch V1 1/3] x86, mce: MCE log size not enough for high core parts

[Ashok Raj]

MCE_LOG_LEN appears to be short for high core count parts. Especially when
handling fatal errors, we don't clear MCE banks. Socket level MC banks
are visible to all CPUs that share banks.

Assuming 18 core part, 2 threads per core 2 banks per thread and couple uncore
MSRs. Rounding to 128 with some fudge to grow in future.

Signed-off-by: Ashok Raj 
Suggested-by: Tony Luck 
---
 arch/x86/include/asm/mce.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 2dbc0bf..4293ae7 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -88,7 +88,7 @@
 #define MCE_EXTENDED_BANK  128
 #define MCE_THERMAL_BANK   (MCE_EXTENDED_BANK + 0)
 
-#define MCE_LOG_LEN 32
+#define MCE_LOG_LEN128
 #define MCE_LOG_SIGNATURE  "MACHINECHECK"
 
 /*
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH tip/core/rcu 3/4] md/bitmap: Fix list_entry_rcu usage

[Paul E. McKenney]

On Wed, Sep 23, 2015 at 07:57:53PM +0200, Patrick Marlier wrote:
> 
> On 09/22/2015 10:50 PM, Paul E. McKenney wrote:
> >On Sun, Sep 13, 2015 at 09:10:24AM -0700, Paul E. McKenney wrote:
> >>On Sun, Sep 13, 2015 at 12:06:33PM +0200, Patrick Marlier wrote:
> >
> >[ . . . ]
> >
> >>>Paul,
> >>>
> >>>This sounds good to me. It should fix the performance issue (will
> >>>check with my benchmark).
> >>
> >>Thank you, looking forward to seeing the results!
> >
> >Just following up -- how is the benchmarking going?
> 
> Note that in my module I am using the kernel version 3.16.0-31 (I
> ported your change).
> Here the results of my benchmark that tests rculist in the case of
> read only.
> 
> # 1st column : The number of threads
> # 2nd : ops/s the original version
> # 3rd : ops/s your version with lockless_dereference
> 1 883923 1747554
> 2 1741441 3543062
> 3 2462360 5103647
> 4 3437273 7176608
> 6 5155803 9812348
> 8 6718111 13330050
> 10 8519227 17458294
> 12 9773632 20298897
> 14 11555198 23191424
> 16 11643264 25125712
> 
> I get same performance with my patch.
> So indeed it fixes the performance problem I was seeing.

Nice, thank you!!!

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT v3] eata: Convert eata driver as normal PCI and platform device drivers

[Jiang Liu]

On 2015/9/23 22:40, James Bottomley wrote:
> On Wed, 2015-09-23 at 20:14 +0930, Arthur Marsh wrote:
>>
>> Jiang Liu wrote on 23/09/15 14:54:
>>
>>> Hi Arthur,
>>> I have found the cause of the warning messages, it's caused
>>> by a flaw in the conversion. But according to my understanding,
>>> it isn't related to the kexec/kdump failure. Could you please help
>>> to test the attached new version?
>>> Thanks!
>>> Gerry
>>>
>>
>> Thanks, the patch worked, I could successfully unload and reload the 
>> eata module, and perform a kexec reboot with the eata module loading 
>> successfully afterwards.
> 
> Great, so the bug was unconditionally unregistering the platform driver
> when it would fail to attach if none of the legacy IO ports were
> detected.
> 
> I think the driver needs a bit of a tidy up.  There's no need at all to
> use ida_get_simple(): the only reason for a dense array of numbers was
> for storing the hba private data in the array you got rid of; we can now
> simply use shost->host_no ... it's more useful anyway because the
> numbers match those SCSI is using.
> 
> Also, if you insist on converting the printk's to dev warn, you no
> longer need to print out the driver name ... dev_printk already prints
> out the device and driver name as the prefix.
> 
> The if (error == 0) is usually written as if (!error) but that's minor.
Hi James,
Thanks for review. How about the attached patch which addresses
the three suggestions from you?
Thanks!
Gerry


> 
> Thanks for doing the conversion,
> 
> James
> 
> 
>From aeb4859ff2c86434814cfc88f1a36481f3dcbc86 Mon Sep 17 00:00:00 2001
From: Jiang Liu 
Date: Thu, 24 Sep 2015 12:24:33 +0800
Subject: [PATCH]


Signed-off-by: Jiang Liu 
---
 drivers/scsi/eata.c |  234 +--
 1 file changed, 97 insertions(+), 137 deletions(-)

diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 11813a72c2e9..ceeba4d7b4ff 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -487,7 +487,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -818,7 +817,6 @@ struct hostdata {
 	unsigned int cp_stat[MAX_MAILBOXES];	/* FREE, IN_USE, LOCKED, IN_RESET */
 	unsigned int last_cp_used;	/* Index of last mailbox used */
 	unsigned int iocount;	/* Total i/o done for this board */
-	int board_number;	/* Number of this board */
 	char board_name[16];	/* Name of this board */
 	int in_reset;		/* True if board is doing a reset */
 	int target_to[MAX_TARGET][MAX_CHANNEL];	/* N. of timeout errors on target */
@@ -835,7 +833,6 @@ struct hostdata {
 };
 
 static const char *driver_name = "EATA";
-static DEFINE_IDA(eata2x_ida);
 static struct platform_device *eata2x_platform_devs[MAX_BOARDS];
 static bool eata2x_platform_driver_registered;
 
@@ -864,6 +861,10 @@ static unsigned long io_port[] = {
 #define DEV2H(x)   be32_to_cpu(x)
 #define H2DEV16(x) cpu_to_be16(x)
 #define DEV2H16(x) be16_to_cpu(x)
+#define dev_warn_on(dev, cond, fmt, ...)	\
+	if (cond) dev_warn(dev, fmt, ##__VA_ARGS__)
+#define dev_info_on(dev, cond, fmt, ...)	\
+	if (cond) dev_info(dev, fmt, ##__VA_ARGS__)
 
 /* But transfer orientation from the 16 bit data register is Little Endian */
 #define REG2H(x)   le16_to_cpu(x)
@@ -1029,47 +1030,32 @@ static int port_detect(unsigned long port_base, struct device *dev)
 	unsigned char dma_channel_table[4] = { 5, 6, 7, 0 };
 	struct Scsi_Host *shost;
 	struct hostdata *ha;
-	char name[16];
-	int idx, ret = -ENODEV;
-
-	idx = ida_simple_get(_ida, 0, MAX_BOARDS, GFP_KERNEL);
-	if (idx < 0) {
-		ret = idx;
-		goto fail;
-	}
+	int ret = -ENODEV;
 
 	shost = scsi_host_alloc(_template, sizeof(struct hostdata));
 	if (shost == NULL) {
-		dev_warn(dev, "%s: unable to alloc host, detaching.\n",
-			 driver_name);
+		dev_warn(dev, "unable to alloc host, detaching.\n");
 		ret = -ENOMEM;
-		goto freeid;
+		goto fail;
 	}
 
-	sprintf(name, "%s%d", driver_name, idx);
-
 	if (!request_region(port_base, REGION_SIZE, driver_name)) {
-#if defined(DEBUG_DETECT)
-		printk("%s: address 0x%03lx in use, skipping probe.\n", name,
-		   port_base);
-#endif
+		dev_warn_on(dev, config_enabled(DEBUG_DETECT),
+			"address 0x%03lx in use, skipping probe.\n",
+			port_base);
 		goto freeshost;
 	}
 
 	if (do_dma(port_base, 0, READ_CONFIG_PIO)) {
-#if defined(DEBUG_DETECT)
-		printk("%s: detect, do_dma failed at 0x%03lx.\n", name,
-		   port_base);
-#endif
+		dev_warn_on(dev, config_enabled(DEBUG_DETECT),
+			"detect, do_dma failed at 0x%03lx.\n", port_base);
 		goto freelock;
 	}
 
 	/* Read the info structure */
 	if (read_pio(port_base, (ushort *) & info, (ushort *) & info.ipad[0])) {
-#if defined(DEBUG_DETECT)
-		printk("%s: detect, read_pio failed at 0x%03lx.\n", name,
-		   port_base);
-#endif
+		dev_warn_on(dev, config_enabled(DEBUG_DETECT),
+			"detect, read_pio failed at 0x%03lx.\n", port_base);
 		goto freelock;
 	}
 
@@ -1083,16 +1069,15 @@ static int port_detect(unsigned long 

Re: [PATCH] mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a fault

[Naoya Horiguchi]

On Tue, Sep 22, 2015 at 04:49:38PM +0100, Mel Gorman wrote:
> On Tue, Sep 22, 2015 at 01:31:51PM +0100, Mel Gorman wrote:
> > SunDong reported the following on 
> > https://bugzilla.kernel.org/show_bug.cgi?id=103841
> > 
> 
> Michal Hocko correctly pointed out privately that this should have
> checked VM_MAYSHARE for the reasons outlined in commit f83a275dbc5c ("mm:
> account for MAP_SHARED mappings using VM_MAYSHARE and not VM_SHARED in
> hugetlbfs"). Please take this version instead if it passes testing
> 
> ---8<---
> mm: hugetlbfs: Skip shared VMAs when unmapping private pages to satisfy a 
> fault
> 
> SunDong reported the following on 
> https://bugzilla.kernel.org/show_bug.cgi?id=103841
> 
>   I think I find a linux bug, I have the test cases is constructed. I
>   can stable recurring problems in fedora22(4.0.4) kernel version,
>   arch for x86_64.  I construct transparent huge page, when the parent
>   and child process with MAP_SHARE, MAP_PRIVATE way to access the same
>   huge page area, it has the opportunity to lead to huge page copy on
>   write failure, and then it will munmap the child corresponding mmap
>   area, but then the child mmap area with VM_MAYSHARE attributes, child
>   process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
>   functions (vma - > vm_flags & VM_MAYSHARE).
> 
> There were a number of problems with the report (e.g. it's hugetlbfs that
> triggers this, not transparent huge pages) but it was fundamentally correct
> in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that looks
> like this
> 
>vma 8804651fd0d0 start 7fc474e0 end 7fc475e0
>next 8804651fd018 prev 8804651fd188 mm 88046b1b1800
>prot 8027 anon_vma   (null) vm_ops 8182a7a0
>pgoff 0 file 88106bdb9800 private_data   (null)
>flags: 
> 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
>
>kernel BUG at mm/hugetlb.c:462!
>SMP
>Modules linked in: xt_pkttype xt_LOG xt_limit iscsi_ibft 
> iscsi_boot_sysfs af_packet ip6t_REJECT nf_reject_ipv6
> xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT 
> nf_reject_ipv4 iptable_raw xt_CT iptable_filter ip6table_mangle
> nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 
> nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter
> ip6_tables x_tables intel_powerclamp coretemp kvm_intel kvm mgag200 ttm 
> drm_kms_helper drm crct10dif_pclmul crc32_pclmul crc32c_intel
> ghash_clmulni_intel aesni_intel aes_x86_64 lrw ipmi_devintf gf128mul iTCO_wdt 
> gpio_ich iTCO_vendor_support glue_helper ablk_helper
> dcdbas i7core_edac cryptd syscopyarea sysfillrect bnx2 sysimgblt lpc_ich 
> serio_raw edac_core i2c_algo_bit shpchp mfd_core ipmi_si
> tpm_tis tpm ipmi_msghandler wmi acpi_power_meter button acpi_cpufreq 
> processor dm_mod sr_mod cdrom ata_generic hid_generic usbhid hid
> uhci_hcd ehci_pci ehci_hcd usbcore ata_piix usb_common megaraid_sas sg
>CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
>Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
>task: 88085ed10490 ti: 88085ed14000 task.ti: 88085ed14000
>set_vma_resv_flags+0x2d/0x30
> 
> The VM_BUG_ON is correct because private and shared mappings have different
> reservation accounting but the warning clearly shows that the VMA is shared.
> 
> When a private COW fails to allocate a new page then only the process that
> created the VMA gets the page -- all the children unmap the page. If the
> children access that data in the future then they get killed.
> 
> The problem is that the same file is mapped shared and private. During
> the COW, the allocation fails, the VMAs are traversed to unmap the other
> private pages but a shared VMA is found and the bug is triggered. This
> patch identifies such VMAs and skips them.
> 
> Signed-off-by: Mel Gorman 
> Reported-by: SunDong 

Looks good to me.

Reviewed-by: Naoya Horiguchi 

> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 999fb0aef8f1..9cc773483624 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3202,6 +3202,14 @@ static void unmap_ref_private(struct mm_struct *mm, 
> struct vm_area_struct *vma,
>   continue;
>  
>   /*
> +  * Shared VMAs have their own reserves and do not affect
> +  * MAP_PRIVATE accounting but it is possible that a shared
> +  * VMA is using the same page so check and skip such VMAs.
> +  */
> + if (iter_vma->vm_flags & VM_MAYSHARE)
> + continue;
> +
> + /*
>* Unmap the page from other VMAs without their own reserves.
>* They get marked to be SIGKILLed if they fault in these
>* areas. This is because a future no-page fault on this 

Re: [PATCH 13/13] Staging: rtl8712: Coding style warning fix for block comment

[Sudip Mukherjee]

On Wed, Sep 23, 2015 at 11:22:09PM +0530, punit vara wrote:
> On Wed, Sep 23, 2015 at 10:25 PM, punit vara  wrote:
> > Thank you very much sir I will definitely follow that. I have seen so
> > many people fixing patches over here. Now I know process of submitting
> > patches.I am able to fix several patches created by checkpatch.pl .
> > But can you suggest me any driver to fix API or another small TODO
> > task. I have seen so many TODO but confuse where to start . Can you
> > give me some initial idea or though or any driver to fix bugs  ? :-)
> 
> 
> Dear Sudip sir,
> 
> I have used git format-patch master..my_local_branch But It also
> produce numbers in subject of patch.
> Now I have used git format-patch master..my_local_branch -N ..It does
> not generate any number in patch even if you have previous patches
Usually I will not diff between the master and my local branch. I will
sync my local branch with the master in the morning and commit my
changes there. Now while generating the patch if I want to generate my
last patch then I just use git format-patch -1. If you want last 2
patches then use git format-patch -2. If you want to have them in series
with the numbering in the subject use git format-patch -2 -n.
And please dont use "sir".

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-next] khugepaged inconsistent lock state

[Sergey Senozhatsky]

On (09/23/15 16:22), Kirill A. Shutemov wrote:
[..]
> khugepaged does swap in during collapse under anon_vma lock. It causes
> complain from lockdep. The trace below shows following scenario:
> 
>  - khugepaged tries to swap in a page under mmap_sem and anon_vma lock;
>  - do_swap_page() calls swapin_readahead() with GFP_HIGHUSER_MOVABLE;
>  - __read_swap_cache_async() tries to allocate the page for swap in;
>  - lockdep_trace_alloc() in __alloc_pages_nodemask() notices that with
>given gfp_mask we could end up in direct relaim.
>  - Lockdep already knows that reclaim sometimes (e.g. in case of
>split_huge_page()) wants to take anon_vma lock on its own.
> 
> Therefore deadlock is possible.
[..]

Gave it some testing on my box. Works fine on my side.

I guess you can add (if needed)
Tested-by: Sergey Senozhatsky 

-ss

> Signed-off-by: Kirill A. Shutemov 
> Reported-by: Sergey Senozhatsky 
> ---
>  mm/huge_memory.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index dd58ecfcafe6..06c8f6d8fee2 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2725,10 +2725,10 @@ static void collapse_huge_page(struct mm_struct *mm,
>   goto out;
>   }
>  
> - anon_vma_lock_write(vma->anon_vma);
> -
>   __collapse_huge_page_swapin(mm, vma, address, pmd);
>  
> + anon_vma_lock_write(vma->anon_vma);
> +
>   pte = pte_offset_map(pmd, address);
>   pte_ptl = pte_lockptr(mm, pmd);
>  
> -- 
>  Kirill A. Shutemov
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/1] USB DWC2 parity fix in isochronous mode

[John Youn]

On 9/10/2015 6:14 PM, Scott Branden wrote:
> This patch contains a fix for a real world interop problem found
> when using the Synopsis DWC2 USB controller with isochronous audio as
> detailed in the commit message.
> 
> Changes from v2:
>  - created s2c_hsotg_chage_ep_iso_parity function to call function in 3 
> places in code
>  - used hsotg->num_of_eps instead of MAX_EPS_CHANNELS
> 
> Changes from v1:
>  - Address code review comments as per previous responses:
>  - renamed parity_set to has_correct_parity and reorder some logic
> 
> 
> Roman Bacik (1):
>   usb: dwc2: gadget: parity fix in isochronous mode
> 
>  drivers/usb/dwc2/core.h   |  1 +
>  drivers/usb/dwc2/gadget.c | 58 
> ++-
>  drivers/usb/dwc2/hw.h |  1 +
>  3 files changed, 54 insertions(+), 6 deletions(-)
> 

This seems to break slave mode on my platform. It seems to be
dropping a lot of packets. I tried bInterval=4,5,6, ISO OUT.
I'll need to take a closer look to determine why. Probably later
this week.

Are you able to run in slave mode on your platform? If so can you
try it out?

Regards,
John

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] PCI: Unassigned Expansion ROM BARs

[Alex Williamson]

On Wed, 2015-09-23 at 20:21 -0700, Yinghai Lu wrote:
> On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe  wrote:
> >
> > The kernel expects device Expansion ROM BARs to be programmed with valid
> > values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the
> > device’s expansion ROM address space is disabled).  This seems to be the
> > main contention point with said BIOS engineers.  If an Expansion ROM BAR is
> > not programmed, the kernel will attempt to find available resources and, if
> > successful, program it.  As this occurs various 'dmesg' entries
> > related to kernel's actions are output.
> ...
> > There is a kernel boot parameter, pci=norom, that is intended to disable the
> > kernel's resource assignment actions for Expansion ROMs that do not already
> > have BIOS assigned address ranges.  Note however, if I remember correctly,
> > that this only works if the Expansion ROM BAR is set to "0" by the BIOS
> > before hand-off.
> 
> option rom is used by legacy bios to enable booting from external device.
> usually BIOS call the option rom, so the firmware will be loaded to
> add on cards.
> and firmware get started.
> Also option rom would include tools that is used to configure behavior of 
> cards
> like add/remove raid.
> 
> Also there is some use case that kernel driver try to get some parameters from
> BIOS. like intel soft raid ? --- bad practice !
> 
> I would like to treat option rom BAR as optional resources during
> resource allocation.
> 
> https://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/patch/?id=7f689da33302e4871fd18aee2c19abb5e3ea5261
> 
> Subject: PCI: Treat ROM resource as optional during realloc
> 
> Current on realloc path, we just ignore ROM resource if we can not assign
> them in first try.
> 
> Treat ROM resources as optional resources,so try to allocate them together
> with required ones, if can not assign them, could go with other required
> resources only, and try to allocate them second time in expand path.

Don't forget that the physical system boot may not be the only "boot" of
the PCI device.  We can assign a PCI device to a VM running on top of
the bare-metal OS, at which point the option ROM of the device may be
re-executed and the device re-initialized by the VM BIOS.  A BIOS
engineer that argues that the option ROM is unnecessary after bare-metal
BIOS boot is completely disregarding this use case.  We do have ways to
make this be a soft requirement, we can pass the option ROM as a file to
the VM, but we need to be able to rip the option ROM from the device in
order to do that, likely from a better behaved platform wrt option ROM
mapping.  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] [git pull] drm for 4.3

[da...@codemonkey.org.uk]

On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote:
 > Hey,
 > 
 > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]:
 > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
 > >  > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
 > >  > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
 > >  > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one of
 > >  > > > their recent patches.
 > >  > 
 > >  > Sounds like this showed up before my recent work, but I think I might
 > >  > have seen similar problems while working on atomic watermarks; the
 > >  > issues I was seeing were because the initial hardware readout could
 > >  > leave primary->visible set to true even when the CRTC was off.  My
 > >  > series (which is still under development) contains this patch to fix
 > >  > that:
 > >  > 
 > >  > http://patchwork.freedesktop.org/patch/59564/
 > >  > 
 > >  > Does applying that help with the problems reported here?
 > > 
 > > No difference at all for me.
 > Looks like a (reopened) dup of 91952?
 > 
 > Can you apply "[PATCH] drm/i915: Add primary plane to mask if it's
 > visible", and get me the results?

This doesn't apply on top of Linus' current tree.
If you let me know what it's dependant on, I'll do a build with
those patches tomorrow.

Dave
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + zsmalloc-add-comments-for-inuse-to-zspage.patch added to -mm tree

[Sergey Senozhatsky]

On (09/23/15 14:53), a...@linux-foundation.org wrote:
> --
> From: Hui Zhu 
> Subject: zsmalloc: add comments for ->inuse to zspage
> 
> Signed-off-by: Hui Zhu 
> Cc: Sergey Senozhatsky 
> Cc: Dan Streetman 
> Cc: Minchan Kim 
> Signed-off-by: Andrew Morton 
> ---
> 
>  mm/zsmalloc.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff -puN mm/zsmalloc.c~zsmalloc-add-comments-for-inuse-to-zspage 
> mm/zsmalloc.c
> --- a/mm/zsmalloc.c~zsmalloc-add-comments-for-inuse-to-zspage
> +++ a/mm/zsmalloc.c
> @@ -38,6 +38,7 @@
>   *   page->lru: links together first pages of various zspages.
>   *   Basically forming list of zspages in a fullness group.
>   *   page->mapping: class index and fullness group of the zspage
> + *   page->inuse: the pages number that is used in this zspage

Probably arrived last night to my another mailbox, so haven't
seen this one.


The comment is wrong. page ->inuse represents the number of objects
in use in this zspage; not "the pages number".

usage example:

zspage_full() : page->inuse == page->objects
obj_malloc() : first_page->inuse++
obj_free() : first_page->inuse--

-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] netlink: Replace rhash_portid with bound

[Herbert Xu]

On Wed, Sep 23, 2015 at 11:43:21PM -0400, Tejun Heo wrote:
> On Thu, Sep 24, 2015 at 11:42:14AM +0800, Herbert Xu wrote:
> > Well I disagree so let's leave it at that.
> 
> Leaving things disagreed is fine but there's still a patch to commit
> here, so I get that you're still dead against just applying the
> pattern?

Honestly I don't care anymore.  Feel free to do whatever you
want.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] netlink: Replace rhash_portid with bound

[Tejun Heo]

On Thu, Sep 24, 2015 at 11:42:14AM +0800, Herbert Xu wrote:
> Well I disagree so let's leave it at that.

Leaving things disagreed is fine but there's still a patch to commit
here, so I get that you're still dead against just applying the
pattern?

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] netlink: Replace rhash_portid with bound

[Herbert Xu]

On Wed, Sep 23, 2015 at 11:41:16PM -0400, Tejun Heo wrote:
> On Thu, Sep 24, 2015 at 11:31:17AM +0800, Herbert Xu wrote:
> > No this isn't what happened.  My error was trying to see if there
> > is a way to do it without barriers.  In the end there wasn't.  This
> > has nothing to do with using primitives.
> 
> Hmmm... yeah, you can say that, but it still was a failure to
> recognize and apply the common pattern and what you're suggesting is
> deviating for no good reason.  It demands a lot of cognitive overhead
> for something which should be routine and makes the code a lot more
> fragile as a result.  Things like this make barrier usages difficult
> to understand and verify because it takes away a lot of ready-made
> cognitive tools.  So, let's please stick to the known pattern.

Well I disagree so let's leave it at that.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/9] dt-bindings: add documentation of rk3036 clock controller

[Xing Zheng]

On 2015年09月17日 23:09, Heiko Stübner wrote:

Am Donnerstag, 17. September 2015, 18:32:49 schrieb Xing Zheng:

Add the devicetree binding for the cru on the rk3036 which quite similar
structured as previous clock controllers.

Signed-off-by: Xing Zheng
---

Changes in v2: None

  .../bindings/clock/rockchip,rk3036-cru.txt |   60
 1 file changed, 60 insertions(+)
  create mode 100644
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt new file
mode 100644
index 000..ac3037a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
@@ -0,0 +1,60 @@
+* Rockchip RK3036 Clock and Reset Unit
+
+The RK3036 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: should be "rockchip,rk3036-cru"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing pll rates are not changable, due to the missing pll lock
status. +
+Each clock is assigned an identifier and client nodes can use this
identifier +to specify the clock which they consume. All available clocks
are defined as +preprocessor macros in the dt-bindings/clock/rk3036-cru.h
headers and can be +used in device tree sources. Similar macros exist for
the reset sources in +these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,

The rk3036 does not seem to use a rtc clock, so this should probably go away

Done.

+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_hsadc" - external HSADC clock - optional,
+ - "ext_vip" - external VIP clock - optional,
+ - "ext_isp" - external ISP clock - optional,
+ - "ext_jtag" - external JTAG clock - optional

There do not seem to exist external clock sources for hsadc, vip, isp and jtag
in your clock tree?

missing here:
- ext_gmac

Yes, done.

+
+Example: Clock controller node:
+
+   cru: cru@2000 {
+   compatible = "rockchip,rk3036-cru";
+   reg =<0x2000 0x1000>;
+   rockchip,grf =<>;
+
+   #clock-cells =<1>;
+   #reset-cells =<1>;
+   };
+
+Example: UART controller node that consumes the clock generated by the
clock +  controller:
+
+   uart0: serial@2006 {
+   compatible = "snps,dw-apb-uart";
+   reg =<0x2006 0x100>;
+   interrupts =;
+   reg-shift =<2>;
+   reg-io-width =<4>;
+   clocks =< SCLK_UART0>;
+   };

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] netlink: Replace rhash_portid with bound

[Tejun Heo]

On Thu, Sep 24, 2015 at 11:31:17AM +0800, Herbert Xu wrote:
> No this isn't what happened.  My error was trying to see if there
> is a way to do it without barriers.  In the end there wasn't.  This
> has nothing to do with using primitives.

Hmmm... yeah, you can say that, but it still was a failure to
recognize and apply the common pattern and what you're suggesting is
deviating for no good reason.  It demands a lot of cognitive overhead
for something which should be routine and makes the code a lot more
fragile as a result.  Things like this make barrier usages difficult
to understand and verify because it takes away a lot of ready-made
cognitive tools.  So, let's please stick to the known pattern.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/9] clk: rockchip: add clock controller for rk3036

[Xing Zheng]

On 2015年09月24日 11:04, Xing Zheng wrote:


  #define RK3066_PLL_RATE(_rate, _nr, _nf, _no)\
@@ -95,12 +106,31 @@ enum rockchip_pll_type {
  .nb = _nb,\
  }

+#define RK3036_PLL_RATE(_rate, _refdiv, _fbdiv, _postdiv1,\
+_postdiv2, _dsmpd, _frac)\
+{\
+.rate= _rate##U,\
+.fbdiv = _fbdiv,\
+.postdiv1 = _postdiv1,\
+.refdiv = _refdiv,\
+.postdiv2 = _postdiv2,\
+.dsmpd = _dsmpd,\
+.frac = _frac,\
+}
+
  struct rockchip_pll_rate_table {
  unsigned long rate;
  unsigned int nr;
  unsigned int nf;
  unsigned int no;
  unsigned int nb;
+/* for RK3036 */
+unsigned int fbdiv;
+unsigned int postdiv1;
+unsigned int refdiv;
+unsigned int postdiv2;
+unsigned int dsmpd;
+unsigned int frac;

same for these 2 ... should be part of the pll addition itself

  };
Done.


Sorry, I have one question:
The "struct rockchip_pll_rate_table" is called in "rockchip/clk-pll.c" 
on many functions, I think I could add a struct like:

struct rk3036_pll_rate_table {
unsigned int fbdiv;
unsigned int postdiv1;
unsigned int refdiv;
unsigned int postdiv2;
unsigned int dsmpd;
unsigned int frac;
};
but, it will add many redundancy codes in "rockchip/clk-pll.c" just for 
call "struct rk3036_pll_rate_table".


Thanks.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] netlink: Replace rhash_portid with bound

[Herbert Xu]

On Wed, Sep 23, 2015 at 11:29:28PM -0400, Tejun Heo wrote:
> 
> So, while that also has been a common failure mode that we've been
> seeing with barrier usages, what you're suggesting isn't the right
> balance either.  It's error-prone in a different way as amply
> exemplified in this very thread.  It ended up making what should have
> been a straight-forward writer-reader interlocking into a maze in
> which one can easily be lost.  I think you should be able to see that
> after this thread.

No this isn't what happened.  My error was trying to see if there
is a way to do it without barriers.  In the end there wasn't.  This
has nothing to do with using primitives.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] netlink: Replace rhash_portid with bound

[Tejun Heo]

Hello,

On Thu, Sep 24, 2015 at 11:21:00AM +0800, Herbert Xu wrote:
> Well we'll have to agree to disagree on that one.  I have seen too
> many instances over the years where people post patches that use
> primitives such as RCU and think that they must be safe because
> it compiles with no warnings (and probably even runs).

So, while that also has been a common failure mode that we've been
seeing with barrier usages, what you're suggesting isn't the right
balance either.  It's error-prone in a different way as amply
exemplified in this very thread.  It ended up making what should have
been a straight-forward writer-reader interlocking into a maze in
which one can easily be lost.  I think you should be able to see that
after this thread.

Both misusages can be solved by understanding and sticking to
established patterns and making exceptions only when explicitly
justifiable and with ample explanation.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] KVM: x86: fix bogus warning about reserved bits

[Xiao Guangrong]

On 09/23/2015 05:36 PM, Paolo Bonzini wrote:



On 23/09/2015 09:56, Borislav Petkov wrote:

On Tue, Sep 22, 2015 at 11:04:38PM +0200, Paolo Bonzini wrote:

Let's add more debugging output:


Here you go:

[   50.474002] walk_shadow_page_get_mmio_spte: detect reserved bits on spte, 
addr 0xb8000 (level 4, 0xf00f8)
[   50.484249] walk_shadow_page_get_mmio_spte: detect reserved bits on spte, 
addr 0xb8000 (level 3, 0xf0078)
[   50.494492] walk_shadow_page_get_mmio_spte: detect reserved bits on spte, 
addr 0xb8000 (level 2, 0xf0078)


And another patch, which both cranks up the debugging a bit and
tries another fix:

diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
index dd05b9cef6ae..b2f49bb15ba1 100644
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -105,8 +105,15 @@ static inline bool guest_cpuid_has_x2apic(struct kvm_vcpu 
*vcpu)
  static inline bool guest_cpuid_is_amd(struct kvm_vcpu *vcpu)
  {
struct kvm_cpuid_entry2 *best;
+   static bool first;

best = kvm_find_cpuid_entry(vcpu, 0, 0);
+   if (first && best) {
+   printk("cpuid(0).ebx = %x\n", best->ebx);
+   first = false;
+   } else if (first)
+   printk_ratelimited("cpuid(0) not initialized yet\n");
+
return best && best->ebx == X86EMUL_CPUID_VENDOR_AuthenticAMD_ebx;
  }

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index bf1122e9c7bf..f50b280ffee1 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3625,7 +3625,7 @@ static void
  __reset_rsvds_bits_mask(struct kvm_vcpu *vcpu,
struct rsvd_bits_validate *rsvd_check,
int maxphyaddr, int level, bool nx, bool gbpages,
-   bool pse)
+   bool pse, bool amd)
  {
u64 exb_bit_rsvd = 0;
u64 gbpages_bit_rsvd = 0;
@@ -3642,7 +3642,7 @@ __reset_rsvds_bits_mask(struct kvm_vcpu *vcpu,
 * Non-leaf PML4Es and PDPEs reserve bit 8 (which would be the G bit for
 * leaf entries) on AMD CPUs only.
 */
-   if (guest_cpuid_is_amd(vcpu))
+   if (amd)
nonleaf_bit8_rsvd = rsvd_bits(8, 8);

switch (level) {
@@ -3710,7 +3710,7 @@ static void reset_rsvds_bits_mask(struct kvm_vcpu *vcpu,
__reset_rsvds_bits_mask(vcpu, >guest_rsvd_check,
cpuid_maxphyaddr(vcpu), context->root_level,
context->nx, guest_cpuid_has_gbpages(vcpu),
-   is_pse(vcpu));
+   is_pse(vcpu), guest_cpuid_is_amd(vcpu));
  }

  static void
@@ -3760,13 +3760,25 @@ static void reset_rsvds_bits_mask_ept(struct kvm_vcpu 
*vcpu,
  void
  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
  {
+   /*
+* Passing "true" to the last argument is okay; it adds a check
+* on bit 8 of the SPTEs which KVM doesn't use anyway.
+*/
__reset_rsvds_bits_mask(vcpu, >shadow_zero_check,
boot_cpu_data.x86_phys_bits,
context->shadow_root_level, context->nx,
-   guest_cpuid_has_gbpages(vcpu), is_pse(vcpu));
+   guest_cpuid_has_gbpages(vcpu), is_pse(vcpu),
+   true);
  }
  EXPORT_SYMBOL_GPL(reset_shadow_zero_bits_mask);

+static inline bool
+boot_cpu_is_amd(void)
+{
+   WARN_ON_ONCE(!tdp_enabled);
+   return shadow_x_mask != 0;


shadow_x_mask != 0 is Intel's CPU.

Borislav, could you please check shadow_x_mask == 0 instead and test it again?

Further more, use guest_cpuid_is_amd() to detect hardware CPU vendor is wrong
as usespace can fool KVM. Should test host CPUID or introduce intel/amd callback
instead.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Do not reserve crashkernel high memory if crashkernel low memory reserving failed

[Baoquan He]

People reported that when allocating crashkernel memory using
",high" and ",low" syntax, there were cases where the reservation
of the "high" portion succeeds, but the reservation of the "low"
portion fails. Then kexec can load kdump kernel successfully, but
the boot of kdump kernel fails as there's no low memory. This is
because allocation of low memory for kdump kernel can fail on large
systems for reasons. E.g it could be manually specified crashkernel
low memory is too large to find in memblock region.

In this patch add return value for reserve_crashkernel_low. Then
try to reserve crashkernel low memory after crashkernel high memory
has been allocated. If crashkernel low memory reservation failed
free crashkernel high memory and return. User can take measures
when they found kdump kernel cann't be loaded successfully.

Signed-off-by: Baoquan He 
---
v1->v2:
  Boris commented that error value EINVAL is negative, should
  use "return -EINVAL".

v2->v3:
  Yinghai pointed out that during memblock_reserve, we could double
  the memblock reserve array. New memblock reserve could be overlapped
  with range for crashkernel high. So we have to reserve crashkernel
  high firstly, then free it if crashkernel low memory allocation
  failed.

v3->v4:
  Dave suggested using "return -ENOMEM" when low memory reservation
  failed and printing failure message anyway.

v4->v5:
  Andrew suggested changing the content of failure message and taking
  higher severity KERN_ERR.

 arch/x86/kernel/setup.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index fdb7f2a..e510e61 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -493,7 +493,7 @@ static void __init 
memblock_x86_reserve_range_setup_data(void)
 # define CRASH_KERNEL_ADDR_HIGH_MAXMAXMEM
 #endif
 
-static void __init reserve_crashkernel_low(void)
+static int __init reserve_crashkernel_low(void)
 {
 #ifdef CONFIG_X86_64
const unsigned long long alignment = 16<<20;/* 16M */
@@ -522,17 +522,16 @@ static void __init reserve_crashkernel_low(void)
} else {
/* passed with crashkernel=0,low ? */
if (!low_size)
-   return;
+   return 0;
}
 
low_base = memblock_find_in_range(low_size, (1ULL<<32),
low_size, alignment);
 
if (!low_base) {
-   if (!auto_set)
-   pr_info("crashkernel low reservation failed - No 
suitable area found.\n");
-
-   return;
+   pr_err("Failed to reserve %ldMB of low memory for crashkernel, 
please try smaller size.\n",
+   (unsigned long)(low_size >> 20));
+   return -ENOMEM;
}
 
memblock_reserve(low_base, low_size);
@@ -544,6 +543,7 @@ static void __init reserve_crashkernel_low(void)
crashk_low_res.end   = low_base + low_size - 1;
insert_resource(_resource, _low_res);
 #endif
+   return 0;
 }
 
 static void __init reserve_crashkernel(void)
@@ -595,6 +595,11 @@ static void __init reserve_crashkernel(void)
}
memblock_reserve(crash_base, crash_size);
 
+   if (crash_base >= (1ULL<<32) && reserve_crashkernel_low()) {
+   memblock_free(crash_base, crash_size);
+   return;
+   }
+
printk(KERN_INFO "Reserving %ldMB of memory at %ldMB "
"for crashkernel (System RAM: %ldMB)\n",
(unsigned long)(crash_size >> 20),
@@ -604,9 +609,6 @@ static void __init reserve_crashkernel(void)
crashk_res.start = crash_base;
crashk_res.end   = crash_base + crash_size - 1;
insert_resource(_resource, _res);
-
-   if (crash_base >= (1ULL<<32))
-   reserve_crashkernel_low();
 }
 #else
 static void __init reserve_crashkernel(void)
-- 
2.4.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: OMAP2+: PM: Denote the cpuidle tracepoints as _rcuidle()

[Jisheng Zhang]

Dear Tony,

On Wed, 23 Sep 2015 11:08:15 -0700
Tony Lindgren  wrote:

> * Kevin Hilman  [150923 11:03]:
> > Jisheng Zhang  writes:
> > 
> > > The cpuidle tracepoints are called within a rcu_idle_exit() section, and
> > > must be denoted with the _rcuidle() version of the tracepoint.
> > >
> > > Signed-off-by: Jisheng Zhang 
> >  
> > Acked-by: Kevin Hilman 
> 
> Hmm is this needed as a fix for the -rc cycle or can this wait
> for v4.4?

IMHO, this is a fix. But it can wait for v4.4 merge window.

Thanks,
Jisheng

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] blk-mq: Fix the queue freezing mechanism

[Ming Lei]

On Wed, 23 Sep 2015 15:14:10 -0700
Bart Van Assche  wrote:

> Ensure that blk_mq_queue_enter() waits if mq_freeze_depth is not
> zero. Ensure that the update of mq_freeze_depth by blk_mq_freeze_queue()
> is visible by all CPU cores before that function waits on
> mq_usage_counter.
> 
> It is unfortunate that this patch introduces an smp_mb() in the
> hot path (blk_mq_queue_enter()) but I have not yet found a way to
> avoid this.
> 
> I came across this code while analyzing a lockup triggered by
> deleting a SCSI host created by the SRP initiator immediately
> followed by a relogin.
> 
> Signed-off-by: Bart Van Assche 
> Cc: Christoph Hellwig 
> Cc: Tejun Heo 
> Cc: 
> ---
>  block/blk-mq.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 2077f0d..e3ad411 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -83,8 +83,13 @@ static int blk_mq_queue_enter(struct request_queue *q, 
> gfp_t gfp)
>   while (true) {
>   int ret;
>  
> - if (percpu_ref_tryget_live(>mq_usage_counter))
> - return 0;
> + if (percpu_ref_tryget_live(>mq_usage_counter)) {
> + /* Order mq_use_counter and mq_freeze_depth accesses */
> + smp_mb();
> + if (!atomic_read(>mq_freeze_depth))
> + return 0;
> + percpu_ref_put(>mq_usage_counter);
> + }

IMO, mq_freeze_depth should only be accessed in slow path, and looks
the race just happens during the small window between increasing
'mq_freeze_depth' and killing the percpu counter.

One solution I thought of is the following patch, which depends on
Akinobu's patch (blk-mq: fix freeze queue race
http://marc.info/?l=linux-kernel=143723697010781=2).

---
diff --git a/block/blk-mq.c b/block/blk-mq.c
index f774f67..1c71c04 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -77,6 +77,17 @@ static void blk_mq_hctx_clear_pending(struct blk_mq_hw_ctx 
*hctx,
clear_bit(CTX_TO_BIT(hctx, ctx), >word);
 }
 
+static inline int blk_mq_read_freeze_depth(struct request_queue *q)
+{
+   int  depth;
+
+   mutex_lock(>mq_freeze_lock);
+   depth = q->mq_freeze_depth;
+   mutex_unlock(>mq_freeze_lock);
+
+   return depth;
+}
+
 static int blk_mq_queue_enter(struct request_queue *q, gfp_t gfp)
 {
while (true) {
@@ -89,7 +100,7 @@ static int blk_mq_queue_enter(struct request_queue *q, gfp_t 
gfp)
return -EBUSY;
 
ret = wait_event_interruptible(q->mq_freeze_wq,
-   !atomic_read(>mq_freeze_depth) ||
+   !blk_mq_read_freeze_depth(q) ||
blk_queue_dying(q));
if (blk_queue_dying(q))
return -ENODEV;
@@ -113,12 +124,9 @@ static void blk_mq_usage_counter_release(struct percpu_ref 
*ref)
 
 void blk_mq_freeze_queue_start(struct request_queue *q)
 {
-   int freeze_depth;
-
mutex_lock(>mq_freeze_lock);
 
-   freeze_depth = atomic_inc_return(>mq_freeze_depth);
-   if (freeze_depth == 1) {
+   if (!q->mq_freeze_depth++) {
percpu_ref_kill(>mq_usage_counter);
blk_mq_run_hw_queues(q, false);
}
@@ -149,7 +157,7 @@ void blk_mq_unfreeze_queue(struct request_queue *q)
 
mutex_lock(>mq_freeze_lock);
 
-   freeze_depth = atomic_dec_return(>mq_freeze_depth);
+   freeze_depth = --q->mq_freeze_depth;
WARN_ON_ONCE(freeze_depth < 0);
if (!freeze_depth) {
percpu_ref_reinit(>mq_usage_counter);
@@ -2084,7 +2092,7 @@ void blk_mq_free_queue(struct request_queue *q)
 /* Basically redo blk_mq_init_queue with queue frozen */
 static void blk_mq_queue_reinit(struct request_queue *q)
 {
-   WARN_ON_ONCE(!atomic_read(>mq_freeze_depth));
+   WARN_ON_ONCE(!ACCESS_ONCE(q->mq_freeze_depth));
 
blk_mq_sysfs_unregister(q);
 
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 6cdf2b7..86fedcc 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -436,7 +436,7 @@ struct request_queue {
struct mutexsysfs_lock;
 
int bypass_depth;
-   atomic_tmq_freeze_depth;
+   int mq_freeze_depth;
 
 #if defined(CONFIG_BLK_DEV_BSG)
bsg_job_fn  *bsg_job_fn;



>  
>   if (!(gfp & __GFP_WAIT))
>   return -EBUSY;
> @@ -136,6 +141,11 @@ static void blk_mq_freeze_queue_wait(struct 
> request_queue *q)
>  void blk_mq_freeze_queue(struct request_queue *q)
>  {
>   blk_mq_freeze_queue_start(q);
> + /*
> +  * Ensure that the mq_freeze_depth update is visiable before
> +  * mq_use_counter is read.
> +  */
> + smp_mb();
>   blk_mq_freeze_queue_wait(q);
>  }
>  EXPORT_SYMBOL_GPL(blk_mq_freeze_queue);

--
To 

Re: [PATCH v2] netlink: Replace rhash_portid with bound

[Herbert Xu]

On Wed, Sep 23, 2015 at 11:06:09PM -0400, Tejun Heo wrote:
> 
> I think this is where we're not agreeing.  My point is that better
> understanding and lower likelihood of bug doesn't equate specializing
> each usage site.  That's a lot more likely to lead to unnecessary
> cognition overhead and naturally errors.  There's no reason to require
> such error-prone and specific understanding of each usage site when we
> can have agreed-upon abstractions which yield invariants which are a
> lot easier for people to wrap their heads around.

Well we'll have to agree to disagree on that one.  I have seen too
many instances over the years where people post patches that use
primitives such as RCU and think that they must be safe because
it compiles with no warnings (and probably even runs).

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] PCI: Unassigned Expansion ROM BARs

[Yinghai Lu]

On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe  wrote:
>
> The kernel expects device Expansion ROM BARs to be programmed with valid
> values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the
> device’s expansion ROM address space is disabled).  This seems to be the
> main contention point with said BIOS engineers.  If an Expansion ROM BAR is
> not programmed, the kernel will attempt to find available resources and, if
> successful, program it.  As this occurs various 'dmesg' entries
> related to kernel's actions are output.
...
> There is a kernel boot parameter, pci=norom, that is intended to disable the
> kernel's resource assignment actions for Expansion ROMs that do not already
> have BIOS assigned address ranges.  Note however, if I remember correctly,
> that this only works if the Expansion ROM BAR is set to "0" by the BIOS
> before hand-off.

option rom is used by legacy bios to enable booting from external device.
usually BIOS call the option rom, so the firmware will be loaded to
add on cards.
and firmware get started.
Also option rom would include tools that is used to configure behavior of cards
like add/remove raid.

Also there is some use case that kernel driver try to get some parameters from
BIOS. like intel soft raid ? --- bad practice !

I would like to treat option rom BAR as optional resources during
resource allocation.

https://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/patch/?id=7f689da33302e4871fd18aee2c19abb5e3ea5261

Subject: PCI: Treat ROM resource as optional during realloc

Current on realloc path, we just ignore ROM resource if we can not assign
them in first try.

Treat ROM resources as optional resources,so try to allocate them together
with required ones, if can not assign them, could go with other required
resources only, and try to allocate them second time in expand path.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND] CMA: fix CONFIG_CMA_SIZE_MBYTES overflow in 64bit

[Tan Xiaojun]

In 64bit system, if you set CONFIG_CMA_SIZE_MBYTES>=2048, it will
overflow and size_bytes will be a big wrong number.

Set CONFIG_CMA_SIZE_MBYTES=2048 and you will get an info below
during system boot:

*
cma: Failed to reserve 17592186042368 MiB
*

Signed-off-by: Tan Xiaojun 
---
 drivers/base/dma-contiguous.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 950fff9..426ba27 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -46,7 +46,7 @@ struct cma *dma_contiguous_default_area;
  * Users, who want to set the size of global CMA area for their system
  * should use cma= kernel parameter.
  */
-static const phys_addr_t size_bytes = CMA_SIZE_MBYTES * SZ_1M;
+static const phys_addr_t size_bytes = (phys_addr_t)CMA_SIZE_MBYTES * SZ_1M;
 static phys_addr_t size_cmdline = -1;
 static phys_addr_t base_cmdline;
 static phys_addr_t limit_cmdline;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

[David Ahern]

On 9/23/15 6:37 PM, Huang Ying wrote:


I take it you have CONFIG_NET_VRF enabled. correct?

With it disabled I see no relevant change in performance between
8f58336d3f78 and 192132b9a034. Can you confirm?


The kconfig file is attached with the mail.  It appears that
CONFIG_NET_VRF is disabled.



Something is not adding up. I anticipate access to a multi-socket numa 
system in the next few days. Until then a couple of questions:


1. do you take patches to run your tests?

2. do you have a wiki/web page with all of the tests run? I'd like to 
know what other networking tests have been run. Only this one was 
flagged, so I presume it means other tests did not hit the threshold. I 
would like to know what other tests are run.


Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5][RESEND] perf, x86: Fix multi-segment problem of perf_event_intel_uncore

[Taku Izumi]

In multi-segment system, uncore devices may belong to buses whose segment
number is other than 0.

  
  :ff:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7 
Scratchpad & Semaphore Registers (rev 03)
  ...
  0001:7f:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7 
Scratchpad & Semaphore Registers (rev 03)
  ...
  0001:bf:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7 
Scratchpad & Semaphore Registers (rev 03)
  ...
  0001:ff:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7 
Scratchpad & Semaphore Registers (rev 03
  ...

In that case, relation of bus number and physical id may be broken
because "uncore_pcibus_to_physid" doesn't take account of PCI segment.
For example, bus :ff and 0001:ff uses the same entry of
"uncore_pcibus_to_physid" array.

This patch fixes ths problem by introducing segment-aware pci2phy_map instead.

 v4 -> v5:
   - Add initializaton code of pci2phy_map when newly alloced at 
__find_pci2phy_map()

 v3 -> v4:
   - avoid GFP_ATOMIC allocation at __find_pci2phy_map()
   - Add missing pci_dev_put at snb_pci2phy_map_init()
   - Add missing raw_spin_unlock at snbep_pci2phy_map_init()

Signed-off-by: Taku Izumi 
---
 arch/x86/kernel/cpu/perf_event_intel_uncore.c  | 61 --
 arch/x86/kernel/cpu/perf_event_intel_uncore.h  | 12 -
 arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c  | 16 --
 .../x86/kernel/cpu/perf_event_intel_uncore_snbep.c | 32 +---
 4 files changed, 106 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c 
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 560e525..61215a6 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -7,7 +7,8 @@ struct intel_uncore_type **uncore_pci_uncores = empty_uncore;
 static bool pcidrv_registered;
 struct pci_driver *uncore_pci_driver;
 /* pci bus to socket mapping */
-int uncore_pcibus_to_physid[256] = { [0 ... 255] = -1, };
+DEFINE_RAW_SPINLOCK(pci2phy_map_lock);
+struct list_head pci2phy_map_head = LIST_HEAD_INIT(pci2phy_map_head);
 struct pci_dev 
*uncore_extra_pci_dev[UNCORE_SOCKET_MAX][UNCORE_EXTRA_PCI_DEV_MAX];
 
 static DEFINE_RAW_SPINLOCK(uncore_box_lock);
@@ -20,6 +21,59 @@ static struct event_constraint uncore_constraint_fixed =
 struct event_constraint uncore_constraint_empty =
EVENT_CONSTRAINT(0, 0, 0);
 
+int uncore_pcibus_to_physid(struct pci_bus *bus)
+{
+   struct pci2phy_map *map;
+   int phys_id = -1;
+
+   raw_spin_lock(_map_lock);
+   list_for_each_entry(map, _map_head, list) {
+   if (map->segment == pci_domain_nr(bus)) {
+   phys_id = map->pbus_to_physid[bus->number];
+   break;
+   }
+   }
+   raw_spin_unlock(_map_lock);
+
+   return phys_id;
+}
+
+struct pci2phy_map *__find_pci2phy_map(int segment)
+{
+   struct pci2phy_map *map, *alloc = NULL;
+   int i;
+
+   lockdep_assert_held(_map_lock);
+
+lookup:
+   list_for_each_entry(map, _map_head, list) {
+   if (map->segment == segment)
+   goto end;
+   }
+
+   if (!alloc) {
+   raw_spin_unlock(_map_lock);
+   alloc = kmalloc(sizeof(struct pci2phy_map), GFP_KERNEL);
+   raw_spin_lock(_map_lock);
+
+   if (!alloc)
+   return NULL;
+
+   goto lookup;
+   }
+
+   map = alloc;
+   alloc = NULL;
+   map->segment = segment;
+   for (i = 0; i < 256; i++)
+   map->pbus_to_physid[i] = -1;
+   list_add_tail(>list, _map_head);
+
+end:
+   kfree(alloc);
+   return map;
+}
+
 ssize_t uncore_event_show(struct kobject *kobj,
  struct kobj_attribute *attr, char *buf)
 {
@@ -809,7 +863,7 @@ static int uncore_pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *id
int phys_id;
bool first_box = false;
 
-   phys_id = uncore_pcibus_to_physid[pdev->bus->number];
+   phys_id = uncore_pcibus_to_physid(pdev->bus);
if (phys_id < 0)
return -ENODEV;
 
@@ -856,9 +910,10 @@ static void uncore_pci_remove(struct pci_dev *pdev)
 {
struct intel_uncore_box *box = pci_get_drvdata(pdev);
struct intel_uncore_pmu *pmu;
-   int i, cpu, phys_id = uncore_pcibus_to_physid[pdev->bus->number];
+   int i, cpu, phys_id;
bool last_box = false;
 
+   phys_id = uncore_pcibus_to_physid(pdev->bus);
box = pci_get_drvdata(pdev);
if (!box) {
for (i = 0; i < UNCORE_EXTRA_PCI_DEV_MAX; i++) {
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.h 
b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
index 72c54c2..2f0a4a9 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.h
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
@@ -117,6 +117,15 @@ struct uncore_event_desc {
const char *config;

Re: [PATCH v2] netlink: Replace rhash_portid with bound

[Tejun Heo]

Hello,

On Thu, Sep 24, 2015 at 10:54:36AM +0800, Herbert Xu wrote:
> What I am concerned about is the next guy who comes along and
> does a rewrite like the one that introduced the netlink_bind
> bug.  That person needs to fully understand what each primitive
> is protecting against.
> 
> Using primitives where they're not needed can lead to misunderstandings
> which may end up causing bugs.

I think this is where we're not agreeing.  My point is that better
understanding and lower likelihood of bug doesn't equate specializing
each usage site.  That's a lot more likely to lead to unnecessary
cognition overhead and naturally errors.  There's no reason to require
such error-prone and specific understanding of each usage site when we
can have agreed-upon abstractions which yield invariants which are a
lot easier for people to wrap their heads around.

This isn't an isolated one-off barrier hack.  This is a
well-established pattern and sure there are cases we wanna deconstruct
that and make exceptions but that needs to be justifiable.  The
overhead gotta buy us something.  Here it just doesn't.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/9] clk: rockchip: add clock controller for rk3036

[Xing Zheng]

On 2015年09月17日 17:47, Heiko Stübner wrote:

Hi,

Am Donnerstag, 17. September 2015, 16:28:54 schrieb Xing Zheng:

Add the clock tree definition for the new rk3036 SoC.

Signed-off-by: Xing Zheng

missing a dt-bindings document in a separate patch. See "dt-bindings: add
documentation of rk3668 clock controller"
(http://lists.infradead.org/pipermail/linux-rockchip/2015-July/003396.html)
for comparison.

Yes, I sent a dt-bindings document in patch 5:
"dt-bindings: add documentation of rk3036 clock controller",
and I think I will adjust the order of document before "Add the clock 
tree..."

for rk3036.


---

Changes in v2: None

  drivers/clk/rockchip/Makefile |1 +
  drivers/clk/rockchip/clk-rk3036.c |  504
+ drivers/clk/rockchip/clk.h|
30 +++
  3 files changed, 535 insertions(+)
  create mode 100644 drivers/clk/rockchip/clk-rk3036.c

diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index b27edd6..d599829 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -10,6 +10,7 @@ obj-y += clk-inverter.o
  obj-y += clk-mmc-phase.o
  obj-$(CONFIG_RESET_CONTROLLER)+= softrst.o

+obj-y  += clk-rk3036.o
  obj-y += clk-rk3188.o
  obj-y += clk-rk3288.o
  obj-y += clk-rk3368.o
diff --git a/drivers/clk/rockchip/clk-rk3036.c
b/drivers/clk/rockchip/clk-rk3036.c new file mode 100644
index 000..724d467
--- /dev/null
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -0,0 +1,504 @@
+/*
+ * Copyright (c) 2014 MundoReader S.L.
+ * Author: Heiko Stuebner
+ *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng
+ *
+ * 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 "clk.h"
+
+enum rk3036_plls {
+   apll, dpll, gpll,
+};
+
+static struct rockchip_pll_rate_table rk3036_pll_rates[] = {
+   /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
+   RK3036_PLL_RATE(160800, 1, 67, 1, 1, 1, 0),
+   RK3036_PLL_RATE(158400, 1, 66, 1, 1, 1, 0),
+   RK3036_PLL_RATE(156000, 1, 65, 1, 1, 1, 0),
+   RK3036_PLL_RATE(153600, 1, 64, 1, 1, 1, 0),
+   RK3036_PLL_RATE(151200, 1, 63, 1, 1, 1, 0),
+   RK3036_PLL_RATE(148800, 1, 62, 1, 1, 1, 0),
+   RK3036_PLL_RATE(146400, 1, 61, 1, 1, 1, 0),
+   RK3036_PLL_RATE(144000, 1, 60, 1, 1, 1, 0),
+   RK3036_PLL_RATE(141600, 1, 59, 1, 1, 1, 0),
+   RK3036_PLL_RATE(139200, 1, 58, 1, 1, 1, 0),
+   RK3036_PLL_RATE(136800, 1, 57, 1, 1, 1, 0),
+   RK3036_PLL_RATE(134400, 1, 56, 1, 1, 1, 0),
+   RK3036_PLL_RATE(132000, 1, 55, 1, 1, 1, 0),
+   RK3036_PLL_RATE(129600, 1, 54, 1, 1, 1, 0),
+   RK3036_PLL_RATE(127200, 1, 53, 1, 1, 1, 0),
+   RK3036_PLL_RATE(124800, 1, 52, 1, 1, 1, 0),
+   RK3036_PLL_RATE(12, 1, 50, 1, 1, 1, 0),
+   RK3036_PLL_RATE(118800, 2, 99, 1, 1, 1, 0),
+   RK3036_PLL_RATE(110400, 1, 46, 1, 1, 1, 0),
+   RK3036_PLL_RATE(11, 12, 550, 1, 1, 1, 0),
+   RK3036_PLL_RATE(100800, 1, 84, 2, 1, 1, 0),
+   RK3036_PLL_RATE(10, 6, 500, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 98400, 1, 82, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 96000, 1, 80, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 93600, 1, 78, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 91200, 1, 76, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 9, 4, 300, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 88800, 1, 74, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 86400, 1, 72, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 84000, 1, 70, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 81600, 1, 68, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 8, 6, 400, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 7, 6, 350, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 69600, 1, 58, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 6, 1, 75, 3, 1, 1, 0),
+   RK3036_PLL_RATE( 59400, 2, 99, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 50400, 1, 63, 3, 1, 1, 0),
+   RK3036_PLL_RATE( 5, 6, 250, 2, 1, 1, 0),
+   RK3036_PLL_RATE( 40800, 1, 68, 2, 2, 1, 0),
+   RK3036_PLL_RATE( 31200, 1, 52, 2, 2, 1, 0),
+   RK3036_PLL_RATE( 21600, 1, 72, 4, 2, 1, 0),
+   RK3036_PLL_RATE(  9600, 1, 64, 4, 4, 1, 0),
+   RK3036_PLL_RATE(0, 1, 0, 1, 1, 1, 0),

you shouldn't need a "0" rate entry I guess

Done.

+   { /* sentinel */ },
+};
+
+#define RK3036_DIV_CPU_MASK0x1f
+#define RK3036_DIV_CPU_SHIFT   

Re: [PATCH] dax: fix deadlock in __dax_fault

[Dave Chinner]

On Wed, Sep 23, 2015 at 02:40:00PM -0600, Ross Zwisler wrote:
> Fix the deadlock exposed by xfstests generic/075.  Here is the sequence
> that was causing us to deadlock:
> 
> 1) enter __dax_fault()
> 2) page = find_get_page() gives us a page, so skip
>   i_mmap_lock_write(mapping)
> 3) if (!buffer_mapped() && !buffer_unwritten() && !vmf->cow_page)
>   passes, enter this block
> 4) if (vmf->flags & FAULT_FLAG_WRITE) fails, so do the else case and
>   i_mmap_unlock_write(mapping);
>   return dax_load_hole(mapping, page, vmf);
> 
> This causes us to up_write() a semaphore that we weren't holding.
> 
> The up_write() on a semaphore we didn't down_write() happens twice in
> a row, and then the next time we try and i_mmap_lock_write(), we hang.
> 
> Signed-off-by: Ross Zwisler 
> Reported-by: Dave Chinner 
> ---
>  fs/dax.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index 7ae6df7..df1b0ac 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -405,7 +405,8 @@ int __dax_fault(struct vm_area_struct *vma, struct 
> vm_fault *vmf,
>   if (error)
>   goto unlock;
>   } else {
> - i_mmap_unlock_write(mapping);
> + if (!page)
> + i_mmap_unlock_write(mapping);
>   return dax_load_hole(mapping, page, vmf);
>   }
>   }

I can't review this properly because I can't work out how this
locking is supposed to work.  Captain, we have a Charlie Foxtrot
situation here:

page = find_get_page(mapping, vmf->pgoff)
if (page) {

} else {
i_mmap_lock_write(mapping);
}

So if there's no page in the page cache, we lock the i_mmap_lock.
The we have the case the above patch fixes. Then later:

if (vmf->cow_page) {
.
if (!page) {
/* can fall through */
}
return VM_FAULT_LOCKED;
}

Which means __dax_fault() can also return here with the
i_mmap_lock_write() held. There's no documentation to indicate why
this is valid, and only by looking about 4 function calls higher up
the stack can I see that there's some attempt to handle this
*specific return condition* (in do_cow_fault()). That also is
lacking in documentation explaining the circumstances where we might
have the i_mmap_lock_write() held and have to release it. (Not to
mention the beautiful copy-n-waste of the unlock code, either.)

The above code in __dax_fault() is then followed by this gem:

/* Check we didn't race with a read fault installing a new page */
if (!page && major)
page = find_lock_page(mapping, vmf->pgoff);

if (page) {
/* mapping invalidation  */
}
.

if (!page)
i_mmap_unlock_write(mapping);

Which means that if we had a race with another read fault, we'll
remove the page from the page cache, insert the new direct mapped
pfn into the mapping, and *then fail to unlock the i_mmap lock*.

Is this supposed to work this way? Or is it another bug?

Another difficult question this change of locking raised that I
can't answer: is it valid to call into the filesystem via getblock()
or complete_unwritten() while holding the i_mmap_rwsem? This puts
filesystem transactions and locks inside the scope of i_mmap_rwsem,
which may have impact on the fact that we already have an inode lock
order dependency w.r.t. i_mmap_rwsem through truncate (and probably
other paths, too).

So, please document the locking model, explain the corner cases and
the intricacies like why *unbalanced, return value conditional
locking* is necessary, and update the charts of lock order
dependencies in places like mm/filemap.c, and then we might have
some idea of how much of a train-wreck this actually is

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] netlink: Replace rhash_portid with bound

[Herbert Xu]

On Wed, Sep 23, 2015 at 10:46:08PM -0400, Tejun Heo wrote:
> 
> Hmm... It looks like I'm failing at communicating.  Lemme try again.
> There are two situations where we do this.
> 
> 1. When there are different locking contexts.  In this case, the write
>path is.  It's already protected by the spinlock so the barrier
>isn't necessary.
> 
> 2. When the path is hot enough for the cost of smp_rmb() to matter and
>the specifics of individual deref allows for micro optimization and
>justifies the added overhead in terms of increased fragility,
>complexity and need for documentation.
> 
> In both cases, we want to make reasonable trade-offs like any other
> choices we make.  We don't go off and run to one extreme or the other
> just because barriers are involved.  One good measure to use is
> whether the extra documentation necessary is justifiable.  In this
> case, on each unprotected derefs, we want to explain why the
> unprotected deref is okay and justified.

What I am concerned about is the next guy who comes along and
does a rewrite like the one that introduced the netlink_bind
bug.  That person needs to fully understand what each primitive
is protecting against.

Using primitives where they're not needed can lead to misunderstandings
which may end up causing bugs.

Honestly I don't care whether you have a barrier there or not as
I only use x86.  But you very much should add a comment at least
saying that the barrier isn't needed for the cases where I left it
out so that future developers don't get confused.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] PCI: Unassigned Expansion ROM BARs

[Myron Stowe]

I've encountered numerous bugzilla reports related to platform BIOS' not
programming valid values into a PCI device's Type 0 Configuration space
"Expansion ROM Base Address" field (a.k.a. Expansion ROM BAR).  The main
observed consequence being 'dmesg' entries like the following that get
customers excited enough to file reports against the kernel.

  pci :01:00.0: can't claim BAR 6 [mem 0xfff0-0x pref]:
no compatible bridge window
  pci :04:03.0: can't claim BAR 6 [mem 0x-0x pref]:
no compatible bridge window

After I've provided an analysis similar to [1] the respective BIOS response
(teams from two of the major vendors) is typically:
   "The OS has no business touching the Expansion ROM BARs and it
provides no value to the equation here.  The Expansion ROM BAR
is only useful in pre-boot for the BIOS to get boot code from
a device."

This scenario has occurred enough times now that I'd like to attempt to
"raise the bar" and invite a technically merit based discussion concerning
this topic - via a public forum that is archived and provides a source of
reference for use upon future occurrences - and see if a consensus can be
reached between the various vendor's BIOS engineers and kernel engineers.


A little more background context -

The kernel expects device Expansion ROM BARs to be programmed with valid
values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the
device’s expansion ROM address space is disabled).  This seems to be the
main contention point with said BIOS engineers.  If an Expansion ROM BAR is
not programmed, the kernel will attempt to find available resources and, if
successful, program it.  As this occurs various 'dmesg' entries
related to kernel's actions are output.

Note that for devices that share decoders between the Expansion ROM BAR and
other BARs the firmware (probably) should not enable the Expansion ROM BAR
at hand-off to the operating system (see the last paragraph of the PCI
Firmware Specification, Rev 3.2, Section 3.5 "Device State at
Firmware/Operating System Handoff").

There is a kernel boot parameter, pci=norom, that is intended to disable the
kernel's resource assignment actions for Expansion ROMs that do not already
have BIOS assigned address ranges.  Note however, if I remember correctly,
that this only works if the Expansion ROM BAR is set to "0" by the BIOS
before hand-off.


I've opened https://bugzilla.kernel.org/show_bug.cgi?id=104931 and attached
the full 'dmesg' that exhibits a typical occurrence as an example.  I'd like
to use the bugzilla to archive any discussion that takes place.   I'll copy all
relevant discussion that takes place here into the bugzilla as "Additional
Comments".

Please continue with this thread, adding your views in these regards.  Citing's
from pertinent specifications that back up your position would be appreciated.

Thanks,
 Myron



[1]  Annotated 'dmesg' log concerning Expansion ROM BARs not setup by BIOS

The "can't claim" messages of interest are:
  pci :01:00.0: can't claim BAR 6 [mem 0xfff0-0x pref]:
  no compatible bridge window
  pci :04:03.0: can't claim BAR 6 [mem 0x-0x pref]:
  no compatible bridge window

The PCI devices of interest are a device at PCI Bus 1, Device 0, Function
0 (01:00.0) and another device at PCI Bus 4, Device 3, Function 0 (04:03.0).

The "root bridge" that leads to PCI buses 1 and 4 - the buses of interest -
is "PCI0" and its I/O Port space and Memory Mapped I/O (MMIO) space are:

 ACPI: PCI Root Bridge [PCI0] (domain  [bus 00-fe])
 PCI host bridge to bus :00
 pci_bus :00: root bus resource [bus 00-fe]
 pci_bus :00: root bus resource [io  0x-0x0cf7]
 pci_bus :00: root bus resource [io  0x0d00-0x]
 pci_bus :00: root bus resource [mem 0x000a-0x000b]
 pci_bus :00: root bus resource [mem 0xc000-0xfeaf]

It's helpful to gather up all the resource related information pertaining to
the devices of interest in one place.  Concentrating on the PCI-to-PCI
bridges and individual PCI devices that lead to 01:00.0, the first device
exhibiting the "can't claim" message (everything that is consuming resources
on PCI bus 0 and PCI bus 1):

pci :00:1a.0: [8086:1c2d] type 00 class 0x0c0320
pci :00:1a.0: reg 0x10: [mem 0xc1305000-0xc13053ff]

pci :00:1d.0: [8086:1c26] type 00 class 0x0c0320
pci :00:1d.0: reg 0x10: [mem 0xc1304000-0xc13043ff]

pci :00:1f.2: [8086:1c00] type 00 class 0x01018f
pci :00:1f.2: reg 0x10: [io  0x3078-0x307f]
pci :00:1f.2: reg 0x14: [io  0x308c-0x308f]
pci :00:1f.2: reg 0x18: [io  0x3070-0x3077]
pci :00:1f.2: reg 0x1c: [io  0x3088-0x308b]
pci :00:1f.2: reg 0x20: [io  0x3050-0x305f]
pci :00:1f.2: reg 0x24: [io  0x3040-0x304f]

pci :00:1f.3: [8086:1c22] type 00 class 0x0c0500
pci :00:1f.3: reg 0x10: [mem 0xc1302000-0xc13020ff 64bit]
pci 

Re: [PATCH v2] netlink: Replace rhash_portid with bound

[Tejun Heo]

Hello, Herbert.

On Thu, Sep 24, 2015 at 10:30:11AM +0800, Herbert Xu wrote:
> Well if someone provided helpers which
> 
> 1) uses smp_wmb and smp_rmb instead of full barriers;

This part is fine.

> 2) provides raw variants for the cases that barriers aren't needed

Hmm... It looks like I'm failing at communicating.  Lemme try again.
There are two situations where we do this.

1. When there are different locking contexts.  In this case, the write
   path is.  It's already protected by the spinlock so the barrier
   isn't necessary.

2. When the path is hot enough for the cost of smp_rmb() to matter and
   the specifics of individual deref allows for micro optimization and
   justifies the added overhead in terms of increased fragility,
   complexity and need for documentation.

In both cases, we want to make reasonable trade-offs like any other
choices we make.  We don't go off and run to one extreme or the other
just because barriers are involved.  One good measure to use is
whether the extra documentation necessary is justifiable.  In this
case, on each unprotected derefs, we want to explain why the
unprotected deref is okay and justified.

> then I'm more than happy to use them.
> 
> Having reviewed the situation again I'm even more convincend
> now that smp_load_acquire/smp_store_release aren't the appropriate
> primitives for us.  They are meant for situations that are similar
> to spin lock/unlock where you need to prevent all reads/writes from
> floating above or below the load/store, respectively.
>
> For our situation we only need write or read ordering, so they are
> literally the wrong tool for the job and will only cause confusion
> in future when someone tries to do a major rewrite of the code and
> they will be scratching their head as to why we needed locking-like
> semantics here.

store_release/load_acquire vs. wmb/rmb is a separate issue.  I no
longer have objections against using wmb/rmb pairs here although I do
wanna note that eventually I think release/acquire are likely to be
more prevalent but that's a separate discussion.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv4] arm64: dts: Add base stratix 10 dtsi

[dinguyen]

From: Dinh Nguyen 

Add the base DTS for Altera's SoCFPGA Stratix 10 platform.

Signed-off-by: Dinh Nguyen 
---
v4: Add a non-zero ranges property for /soc node
v3: change #address-cells and #size-cells to <2>
change the GIC address to 0xfffc1000
update the GIC virtual CPU reg length to 0x2000
v2: use interrupt-affinity for pmu node
---
 arch/arm64/Kconfig.platforms   |   5 +
 arch/arm64/boot/dts/Makefile   |   1 +
 arch/arm64/boot/dts/altera/Makefile|   5 +
 arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi  | 358 +
 .../boot/dts/altera/socfpga_stratix10_socdk.dts|  39 +++
 arch/arm64/configs/defconfig   |   1 +
 6 files changed, 409 insertions(+)
 create mode 100644 arch/arm64/boot/dts/altera/Makefile
 create mode 100644 arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
 create mode 100644 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 23800a1..36303c8 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -66,6 +66,11 @@ config ARCH_SEATTLE
help
  This enables support for AMD Seattle SOC Family
 
+config ARCH_STRATIX10
+   bool "Altera's Stratix 10 SoCFPGA Family"
+   help
+ This enables support for Altera's Stratix 10 SoCFPGA Family.
+
 config ARCH_TEGRA
bool "NVIDIA Tegra SoC Family"
select ARCH_HAS_RESET_CONTROLLER
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index d9f8833..f585606 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dts-dirs += altera
 dts-dirs += amd
 dts-dirs += apm
 dts-dirs += arm
diff --git a/arch/arm64/boot/dts/altera/Makefile 
b/arch/arm64/boot/dts/altera/Makefile
new file mode 100644
index 000..d7a6416
--- /dev/null
+++ b/arch/arm64/boot/dts/altera/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_STRATIX10) += socfpga_stratix10_socdk.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi 
b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
new file mode 100644
index 000..445aa67
--- /dev/null
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -0,0 +1,358 @@
+/*
+ * Copyright Altera Corporation (C) 2015. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+/dts-v1/;
+
+/ {
+   compatible = "altr,socfpga-stratix10";
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x0>;
+   };
+
+   cpu1: cpu@1 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x1>;
+   };
+
+   cpu2: cpu@2 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x2>;
+   };
+
+   cpu3: cpu@3 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   enable-method = "psci";
+   reg = <0x3>;
+   };
+   };
+
+   pmu {
+   compatible = "arm,armv8-pmuv3";
+   interrupts = <0 120 8>,
+<0 121 8>,
+<0 122 8>,
+<0 123 8>;
+   interrupt-affinity = <>,
+<>,
+<>,
+<>;
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   intc: intc@fffc1000 {
+   compatible = "arm,gic-400", "arm,cortex-a15-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x0 0xfffc1000 0x1000>,

Re: [PATCH v2] netlink: Replace rhash_portid with bound

[Herbert Xu]

On Wed, Sep 23, 2015 at 11:54:40AM -0400, Tejun Heo wrote:
> 
> Hmm... lemme try again.  When using barriers or RCU, it's desirable to
> establish certain invariants because it usually is extremely easy to
> miss corner cases.  It is helpful to have an abstraction, even if just
> conceptual, where people can go "this thing is barrier / RCU protected
> to guarantee XYZ".  Going more towards RCU example, this is why we
> annotate variables as RCU protected to detect incorrect usages.  There
> sure are exceptions but most are of the sort "this is write path and
> protected by something else which is annotated differently".  Doing
> things this way makes it a lot easier to get right.

Well if someone provided helpers which

1) uses smp_wmb and smp_rmb instead of full barriers;
2) provides raw variants for the cases that barriers aren't needed

then I'm more than happy to use them.

Having reviewed the situation again I'm even more convincend
now that smp_load_acquire/smp_store_release aren't the appropriate
primitives for us.  They are meant for situations that are similar
to spin lock/unlock where you need to prevent all reads/writes from
floating above or below the load/store, respectively.

For our situation we only need write or read ordering, so they are
literally the wrong tool for the job and will only cause confusion
in future when someone tries to do a major rewrite of the code and
they will be scratching their head as to why we needed locking-like
semantics here.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/9] ARM: dts: rockchip: add core rk3036 dts

[Xing Zheng]

On 2015年09月17日 17:18, Heiko Stübner wrote:

Am Donnerstag, 17. September 2015, 16:28:52 schrieb Xing Zheng:

Initial release for rk3036, node definitions rk3036 sdk board.

Signed-off-by: Xing Zheng
---

Changes in v2: None

  arch/arm/boot/dts/Makefile   |1 +
  arch/arm/boot/dts/rk3036-sdk.dts |   62 +++
  arch/arm/boot/dts/rk3036.dtsi|  381
++ 3 files changed, 444 insertions(+)
  create mode 100644 arch/arm/boot/dts/rk3036-sdk.dts
  create mode 100644 arch/arm/boot/dts/rk3036.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d39ce4b..48260c4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -502,6 +502,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
+   rk3036-sdk.dtb \

ordering ... please put the rk3036 above rk3066 boards

Done.



rk3188-radxarock.dtb \
rk3288-evb-act8846.dtb \
rk3288-evb-rk808.dtb \
diff --git a/arch/arm/boot/dts/rk3036-sdk.dts
b/arch/arm/boot/dts/rk3036-sdk.dts new file mode 100644
index 000..9187f93
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036-sdk.dts

or "rk3036-evb.dts"? What is the actual board named?

Done, use rk3036-evb.dts

@@ -0,0 +1,62 @@
+/*
+ * Copyright (c)  2015 Xing Zheng

this probably wants a Rockchip copyright notice?

Yes, remove this notice.

+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include "rk3036.dtsi"
+
+/ {
+   model = "SDK-RK3036";
+   compatible = "sdk,sdk-rk3036", "rockchip,rk3036";

model = "Rockchip RK3036-SDK";
compatible = "rockchip,rk3036-sdk", "rockchip,rk3036";

or

model = "Rockchip RK3036 Evaluation board";
compatible = "rockchip,rk3036-evb", "rockchip,rk3036";

depending on what the real board is labeled

Done.

+};
+
+ {
+   status = "okay";
+
+hym8563: hym8563@51 {
+   compatible = "haoyu,hym8563";
+   reg =<0x51>;
+   #clock-cells =<0>;
+   clock-frequency =<32768>;
+   clock-output-names = "xin32k";
+   };
+};
\ No newline at end of file

missing newline as stated above

Done.

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
new file mode 100644
index 000..b7459c0
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -0,0 +1,381 @@
+/*
+ * 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
+ *   

Re: [PATCH v2 2/9] clk: rockchip: add dt-binding header for rk3036

[Xing Zheng]

On 2015年09月17日 17:25, Heiko Stübner wrote:

Am Donnerstag, 17. September 2015, 16:28:53 schrieb Xing Zheng:

Add the dt-bindings header for the rk3036, that gets shared between
the clock controller and the clock references in the dts.

Signed-off-by: Xing Zheng
---

Changes in v2: None

  include/dt-bindings/clock/rk3036-cru.h |  198
 1 file changed, 198 insertions(+)
  create mode 100644 include/dt-bindings/clock/rk3036-cru.h

diff --git a/include/dt-bindings/clock/rk3036-cru.h
b/include/dt-bindings/clock/rk3036-cru.h new file mode 100644
index 000..b0033ef
--- /dev/null
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -0,0 +1,198 @@
+/*
+ * Copyright (c) 2014 MundoReader S.L.
+ * Author: Heiko Stuebner

you can probably drop that copyright line ... I didn't do anything here ;-)

OK, done. :)



+ *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
+
+/* core clocks */
+#define PLL_APLL   1
+#define PLL_DPLL   2
+#define PLL_GPLL   3
+#define ARMCLK 4
+
+/* sclk gates (special clocks) */

you have a lot of gaps in the numbering ... intentional?
Oh, I think I referenced to "rk3288-cru.h" and cut some useless 
numbering from it for rk3036


otherwise
Reviewed-by: Heiko Stuebner

Done.

+#define SCLK_GPU   64
+#define SCLK_SPI   65
+#define SCLK_SDMMC 68
+#define SCLK_SDIO  69
+#define SCLK_EMMC  71
+#define SCLK_NANDC 76
+#define SCLK_UART0 77
+#define SCLK_UART1 78
+#define SCLK_UART2 79
+#define SCLK_I2S   82
+#define SCLK_SPDIF 83
+#define SCLK_TIMER085
+#define SCLK_TIMER186
+#define SCLK_TIMER287
+#define SCLK_TIMER388
+#define SCLK_OTGPHY0   93
+#define SCLK_OTGPHY1   94
+#define SCLK_LCDC  100
+#define SCLK_HDMI  109
+#define SCLK_HEVC  111
+#define SCLK_I2S_OUT   113
+#define SCLK_SDMMC_DRV 114
+#define SCLK_SDIO_DRV  115
+#define SCLK_EMMC_DRV  117
+#define SCLK_SDMMC_SAMPLE  118
+#define SCLK_SDIO_SAMPLE   119
+#define SCLK_EMMC_SAMPLE   121
+#define SCLK_PVTM_CORE  123
+#define SCLK_PVTM_GPU   124
+#define SCLK_PVTM_VIDEO 125
+#define SCLK_MAC   151
+#define SCLK_MACREF152
+#define SCLK_SFC   160
+
+#define DCLK_LCDC  190
+
+/* aclk gates */
+#define ACLK_DMAC2 194
+#define ACLK_LCDC  197
+#define ACLK_VIO   203
+#define ACLK_VCODEC208
+#define ACLK_CPU   209
+#define ACLK_PERI  210
+
+/* pclk gates */
+#define PCLK_GPIO0 320
+#define PCLK_GPIO1 321
+#define PCLK_GPIO2 322
+#define PCLK_GRF   329
+#define PCLK_I2C0  332
+#define PCLK_I2C1  333
+#define PCLK_I2C2  334
+#define PCLK_SPI   338
+#define PCLK_UART0 341
+#define PCLK_UART1 342
+#define PCLK_UART2 343
+#define PCLK_PWM   350
+#define PCLK_TIMER 353
+#define PCLK_HDMI  360
+#define PCLK_CPU   362
+#define PCLK_PERI  363
+#define PCLK_DDRUPCTL  364
+#define PCLK_WDT   368
+
+/* hclk gates */
+#define HCLK_OTG0  449
+#define HCLK_OTG1  450
+#define HCLK_NANDC 453
+#define HCLK_SDMMC 456
+#define HCLK_SDIO  457
+#define HCLK_EMMC  459
+#define HCLK_I2S   462
+#define HCLK_LCDC  465
+#define HCLK_ROM   467
+#define HCLK_VIO_BUS   472
+#define HCLK_VCODEC476
+#define HCLK_CPU   477
+#define HCLK_PERI  478
+
+#define CLK_NR_CLKS(HCLK_PERI + 1)
+
+/* soft-reset indices */
+#define SRST_CORE0 0
+#define SRST_CORE1 1
+#define SRST_CORE0_DBG 4
+#define SRST_CORE1_DBG 5
+#define SRST_CORE0_POR 8
+#define SRST_CORE1_POR 9
+#define SRST_L2C   12
+#define SRST_TOPDBG13
+#define SRST_STRC_SYS_A14
+#define SRST_PD_CORE_NIU   15
+
+#define SRST_TIMER216

Re: [PATCH] staging: rtl8192u: ieee80211_rx: Fix incorrect type in assignments

[Gaston Gonzalez]

On Fri, Jun 26, 2015 at 01:36:14PM -0300, Gaston Gonzalez wrote:
> On Thu, Jun 25, 2015 at 02:06:44PM +0200, Arnd Bergmann wrote:
> > On Wednesday 24 June 2015 13:34:58 Gaston Gonzalez wrote:
> > > On Tue, Jun 23, 2015 at 12:13:47PM +0200, Arnd Bergmann wrote:
> > > > On Sunday 21 June 2015 19:12:09 Gaston Gonzalez wrote:
> > > > > /* WMM spec P.11: The minimum value for AIFSN shall 
> > > > > be 2 */
> > > > > qos_param->aifs[aci] = (qos_param->aifs[aci] < 2) ? 
> > > > > 2:qos_param->aifs[aci];
> > > > >  
> > > > > -   qos_param->cw_min[aci] = ac_params->ecw_min_max & 
> > > > > 0x0F;
> > > > > +   qos_param->cw_min[aci] =
> > > > > +   cpu_to_le16(ac_params->ecw_min_max & 0x0F);
> > > > >  
> > > > > -   qos_param->cw_max[aci] = (ac_params->ecw_min_max & 
> > > > > 0xF0) >> 4;
> > > > > +   qos_param->cw_max[aci] =
> > > > > +   cpu_to_le16((ac_params->ecw_min_max & 0xF0) 
> > > > > >> 4);
> > > > >  
> > > > > qos_param->flag[aci] =
> > > > > (ac_params->aci_aifsn & 0x10) ? 0x01 : 0x00;
> > > > > -   qos_param->tx_op_limit[aci] = 
> > > > > le16_to_cpu(ac_params->tx_op_limit);
> > > > > +   qos_param->tx_op_limit[aci] = ac_params->tx_op_limit;
> > > > > }
> > > > > return 0;
> > > > 
> > > > This certainly needs a more thorough description of how you determined 
> > > > that
> > > > the byte swaps that you add are in fact required. Did you test it on
> > > > a big-endian machine?
> > > > 
> > > > Arnd
> > > 
> > > Hello Arnd,
> > > 
> > > Thank you for reviewing this.
> > > After your email and reviwing this again I'm getting a bit suspicious
> > > myself, but this is what I saw:
> > > 
> > > -- First warning:
> > > 
> > > qos_param->cw_min[aci] is defined as __le16() in ieee80211.h
> > > (ieee80211_qos_parameters structure)
> > > 
> > > ac_params-> ecw_min_max is defined as u8 in ieee80211.h
> > > (ieee80211_qos_ac_parameter structure)
> > > 
> > > So the assignment is: __le16 = u8 & 0x0F;
> > > 
> > > -- Second warning:
> > > 
> > > qos_param->cw_max[aci] is __le16()
> > > ac_params-> ecw_min_max is u8
> > > 
> > > The assignment is: __le16 = (u8 & 0xF0) >> 4;
> > > 
> > > Thus, for the warning 1 and 2, I understand that the result won't be the
> > > same if the machine is big-endian or little-endian, and that's why we
> > > need a cpu_to_le16. Am I missing something?
> > 
> > I think your analysis is right, as long as the __le16 annotation is
> > actually correct. It usually helps to look at the git history to
> > see what the intent of the patch was that introduced the assignment
> > and the patch that introduced the __le16 type. Presumably one of them
> > was incorrect, and it would be good to figure out where it went wrong,
> > and to add a 'Fixes:' tag in your patch description that pinpoints
> > the exact mistake.
> > 
> 
> Ok, will do.
> 
> > > -- Third warning:
> > > 
> > > In this case both sides of the assignment are already defined as __le16:
> > > 
> > > qos_param->tx_op_limit[aci] (ieee80211_qos_parameters structure defined
> > > in ieee80211.h))
> > > 
> > > ac_params->tx_op_limit (ieee80211_qos_ac_parameter structure defined in
> > > ieee80211.h)
> > > 
> > > So the assignment is: __le16() = le16_to_cpu(__le16)
> > > 
> > > Im getting suspicious now, but it sounded wrong to me.
> > > In the case the right part is correct, I guess the left part should be
> > > u16 type?
> > 
> > Again, your logic sounds good: there is clearly something wrong here, but
> > it's not obvious to conclude whether it is an incorrect annotation or
> > an extraneous byte swap. Besides looking at the git history, it also
> > helps to look at all other uses of the two sides of the assignment:
> > 
> > See if qos_param->tx_op_limit is in fact used as a little-endian
> > value (e.g. by copying to memory or a register), and if the value that
> > got written to ac_params->tx_op_limit was byte-swapped already at
> > the time of assignment.
> > 
> Ok, I'll do it too.
> 
> > > Regarding the test: I tested it on my machine, but is of course little-
> > > endian :( I could built a qemu virtual machine to test it on a
> > > big-endian emulated platform. Should that work?
> > 
> > Yes, that would work: you can assign the USB device to the qemu machine
> > and run a kernel in there. The easiest emulation to try is probably
> > a PowerPC PAPR machine with a file system from
> > https://people.debian.org/~aurel32/qemu/powerpc/.
> > MIPS should work as well.
> > 
> 
> Ok, thanks a lot for all the pointers.
> 
> Gaston
> > Arnd

So more than two months have passed without any reply from my side.

The thing is I'm struggling to get a new hardware with this chipset. Today I
received my fourth rtl8192cu device to my collection of wrong devices, which
also comprises one ralink and some other chip. All of them specified as

[PATCH] perf/probe: Search both .eh_frame and .debug_frame sections for probe location

[Hemant Kumar]

perf probe through debuginfo__find_probes() in util/probe-finder.c
checks for the functions' frame descriptions in either .eh_frame section
of an ELF or the .debug_frame. The check is based on whether either one
of these sections is present. But sometimes, it may happen that,
.eh_frame, even if present, may not be complete and may miss some
descriptions. For e.g., in powerpc, this may happen :
 $ gcc -g bin.c -o bin

 $ objdump --dwarf ./bin
 <1><145>: Abbrev Number: 7 (DW_TAG_subprogram)
<146>   DW_AT_external: 1
<146>   DW_AT_name: (indirect string, offset: 0x9e): main
<14a>   DW_AT_decl_file   : 1
<14b>   DW_AT_decl_line   : 39
<14c>   DW_AT_prototyped  : 1
<14c>   DW_AT_type: <0x57>
<150>   DW_AT_low_pc  : 0x17b8

If the .eh_frame and .debug_frame are checked for the same binary, we
will find that, .eh_frame (although present) doesn't contain a
description for "main" function.
But, .debug_frame has a description :

00d8 0024  FDE cie= pc=17b8..1838
  DW_CFA_advance_loc: 16 to 17c8
  DW_CFA_def_cfa_offset: 144
  DW_CFA_offset_extended_sf: r65 at cfa+16
...

Due to this (since, perf checks whether .eh_frame is present and goes on
searching for that address inside that frame), perf is unable to process
the probes :
 # perf probe -x ./bin main
Failed to get call frame on 0x17b8
  Error: Failed to add events.

To avoid this issue, we need to check both the sections (.eh_frame and
.debug_frame), which is done in this patch.

Note that, we can always force everything into both .eh_frame and
.debug_frame by :
 $ gcc bin.c -fasynchronous-unwind-tables  -fno-dwarf2-cfi-asm -g -o bin

Signed-off-by: Hemant Kumar 
---
 tools/perf/util/probe-finder.c | 59 +-
 1 file changed, 35 insertions(+), 24 deletions(-)

diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 2da65a7..7ce02b9 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -1022,9 +1022,8 @@ static int pubname_search_cb(Dwarf *dbg, Dwarf_Global 
*gl, void *data)
return DWARF_CB_OK;
 }
 
-/* Find probe points from debuginfo */
-static int debuginfo__find_probes(struct debuginfo *dbg,
- struct probe_finder *pf)
+static int debuginfo__find_probe_location(struct debuginfo *dbg,
+ struct probe_finder *pf)
 {
struct perf_probe_point *pp = >pev->point;
Dwarf_Off off, noff;
@@ -1032,27 +1031,6 @@ static int debuginfo__find_probes(struct debuginfo *dbg,
Dwarf_Die *diep;
int ret = 0;
 
-#if _ELFUTILS_PREREQ(0, 142)
-   Elf *elf;
-   GElf_Ehdr ehdr;
-   GElf_Shdr shdr;
-
-   /* Get the call frame information from this dwarf */
-   elf = dwarf_getelf(dbg->dbg);
-   if (elf == NULL)
-   return -EINVAL;
-
-   if (gelf_getehdr(elf, ) == NULL)
-   return -EINVAL;
-
-   if (elf_section_by_name(elf, , , ".eh_frame", NULL) &&
-   shdr.sh_type == SHT_PROGBITS) {
-   pf->cfi = dwarf_getcfi_elf(elf);
-   } else {
-   pf->cfi = dwarf_getcfi(dbg->dbg);
-   }
-#endif
-
off = 0;
pf->lcache = intlist__new(NULL);
if (!pf->lcache)
@@ -1115,6 +1093,39 @@ found:
return ret;
 }
 
+/* Find probe points from debuginfo */
+static int debuginfo__find_probes(struct debuginfo *dbg,
+ struct probe_finder *pf)
+{
+   int ret = 0;
+
+#if _ELFUTILS_PREREQ(0, 142)
+   Elf *elf;
+   GElf_Ehdr ehdr;
+   GElf_Shdr shdr;
+
+   /* Get the call frame information from this dwarf */
+   elf = dwarf_getelf(dbg->dbg);
+   if (elf == NULL)
+   return -EINVAL;
+
+   if (gelf_getehdr(elf, ) == NULL)
+   return -EINVAL;
+
+   if (elf_section_by_name(elf, , , ".eh_frame", NULL) &&
+   shdr.sh_type == SHT_PROGBITS) {
+   pf->cfi = dwarf_getcfi_elf(elf);
+   ret = debuginfo__find_probe_location(dbg, pf);
+   if (ret >= 0)
+   return ret;
+   }
+   pf->cfi = dwarf_getcfi(dbg->dbg);
+#endif
+
+   ret = debuginfo__find_probe_location(dbg, pf);
+   return ret;
+}
+
 struct local_vars_finder {
struct probe_finder *pf;
struct perf_probe_arg *args;
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kselftest: using built-in rule when delete file

[long.wanglong]

On 2015/9/24 9:46, Michael Ellerman wrote:
> On Wed, 2015-09-23 at 09:40 +, Wang Long wrote:
>> Use make's built-in rules to when delete a file
>> or delete files.
> 
> It's not a built-in rule, it's a variable.

Sorry，I did not describe clearly. It is a variable used as
name of program in built-in rules.

> 
> Personally I think using rm directly is clearer, but I guess this is fine. Do
> you actually want to override $RM ?
> 

So far, I do not want to override $(RM). But I found that some test's Makefile
using *$(RM)* while the other's using *rm -f*, I think it is better to use one
of them in all unit tests.

Do you think which one is better?

Best Regards
Wang Long

> cheers
> 
> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kselftest: using built-in rule when delete file

[Michael Ellerman]

On Thu, 2015-09-24 at 10:05 +0800, long.wanglong wrote:
> On 2015/9/24 9:46, Michael Ellerman wrote:
> > On Wed, 2015-09-23 at 09:40 +, Wang Long wrote:
> >> Use make's built-in rules to when delete a file
> >> or delete files.
> > 
> > It's not a built-in rule, it's a variable.
> 
> Sorry，I did not describe clearly. It is a variable used as
> name of program in built-in rules.
> 
> > Personally I think using rm directly is clearer, but I guess this is fine. 
> > Do
> > you actually want to override $RM ?
> 
> So far, I do not want to override $(RM). But I found that some test's Makefile
> using *$(RM)* while the other's using *rm -f*, I think it is better to use one
> of them in all unit tests.
> 
> Do you think which one is better?

I prefer just using rm -f, because it's less magic, everyone knows what it does.

cheers



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf probe: Fix module probing with shortname

[Arnaldo Carvalho de Melo]

Em Wed, Sep 23, 2015 at 10:50:08PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Sep 23, 2015 at 01:03:19PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Tue, Sep 22, 2015 at 11:49:02PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Wed, Sep 23, 2015 at 09:14:44AM +0800, Wangnan (F) escreveu:
> > > > On 2015/9/22 21:35, Arnaldo Carvalho de Melo wrote:
> > > > >Em Tue, Sep 22, 2015 at 03:34:32AM +, Wang Nan escreveu:
> > > > >>This is caused by a misunderstood of dso->kernel in 
> > > > >>kernel_get_module_dso()
> > > > >>that, for kernel module, dso->kernel is DSO_TYPE_USER. dso->kernel is 
> > > > >>DSO_TYPE_KERNEL
> > > > >>iff dso is vmlinux.
> > > > >Kernel modules having DSO_TYPE_USER seems to be the bug, no? I'll try 
> > > > >to
> > > > >check that...
> 
> > > > I also noticed this problem when I working on commit
> > > > 1f121b03d058dd07199d8924373d3c52a207f63b ("perf tools: Deal with
> > > > kernel module names in '[]' correctly") ;)
> 
> > > Thanks for working on this, it is an area that needs cleaning up, too
> > > many ways to say what a dso is, will study your findings and try to come
> > > up with a patch proposal tomorrow.
> > > > So care must be taken.
> > 
> > So, yes, there are multiple uses for this dso->kernel thing, we need to
> > look at each one and go on clarifying it so that this gets corrected and
> > sane, but I think we need some helpers to clarify all this, namely:
> > 
> > Adding DSO_TYPE_KMODULE and DSO_TYPE_GUEST_KMODULE, setting
> > dso->kernel with it when loading host and guest kernel modules and
> > adding:
> > 
> > bool dso__is_host_kernel(struct dso *dso)
> > bool dso__is_host_kmodule(struct dso *dso)
> > 
> > bool dso__is_guest_kernel(struct dso *dso)
> 
> So I tried this, ended up basically using __map__is_kernel(), in several
> places, which I think is right, and I've stashed in my tmp.perf/core
> branch so that you can take a look.
> 
> But then I realized that we already have a better way to achieve what is
> needed in that function, see the patch below, fixed things for me:

Using it:


[root@zoo ~]# perf probe -v -m usbnet --add usbnet_start_xmit
probe-definition(0): usbnet_start_xmit
symbol:usbnet_start_xmit file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /lib/modules/4.3.0-rc1+/kernel/drivers/net/usb/usbnet.ko
Try to find probe point from debuginfo.
Matched function: usbnet_start_xmit
Probe point found: usbnet_start_xmit+0
Found 1 probe_trace_events.
Opening /sys/kernel/debug/tracing//kprobe_events write=1
Writing event: p:probe/usbnet_start_xmit usbnet:usbnet_start_xmit+0
Added new event:
  probe:usbnet_start_xmit (on usbnet_start_xmit in usbnet)

You can now use it in all perf tools, such as:

perf record -e probe:usbnet_start_xmit -aR sleep 1

[root@zoo ~]#

ot@zoo ~]# perf probe -m kvm --add apic_has_pending_timer
Added new event:
  probe:apic_has_pending_timer (on apic_has_pending_timer in kvm)

You can now use it in all perf tools, such as:

perf record -e probe:apic_has_pending_timer -aR sleep 1

[root@zoo ~]#

[root@zoo ~]# perf probe -m kvm -F ioapic*
ioapic_mmio_read
ioapic_mmio_write
ioapic_service
ioapic_set_irq
[root@zoo ~]# 

[root@zoo ~]# perf probe -m mac80211 -F 'i*_tx_*' | head -10
ieee80211_add_tx_ts
ieee80211_agg_tx_operational
ieee80211_clear_tx_pending
ieee80211_del_tx_ts
ieee80211_get_key_tx_seq
ieee80211_get_tx_power
ieee80211_get_tx_rates
ieee80211_init_tx_queue
ieee80211_mgd_conn_tx_status
ieee80211_mgmt_tx_cancel_wait
[root@zoo ~]# 

- Arnaldo

 
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 2b78e8f19b45..7fb0533ab18c 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -269,12 +269,13 @@ static int kernel_get_module_dso(const char *module, 
> struct dso **pdso)
>   int ret = 0;
>  
>   if (module) {
> - list_for_each_entry(dso, _machine->dsos.head, node) {
> - if (!dso->kernel)
> - continue;
> - if (strncmp(dso->short_name + 1, module,
> - dso->short_name_len - 2) == 0)
> - goto found;
> + char module_name[128];
> +
> + snprintf(module_name, sizeof(module_name), "[%s]", module);
> + map = map_groups__find_by_name(_machine->kmaps, 
> MAP__FUNCTION, module_name);
> + if (map) {
> + dso = map->dso;
> + goto found;
>   }
>   pr_debug("Failed to find module %s.\n", module);
>   return -ENOENT;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] selftests/userfaultfd: improve syscall number definition

[Michael Ellerman]

On Wed, 2015-09-23 at 14:11 +0100, Andre Przywara wrote:
> Hi Michael,
> 
> On 23/09/15 10:55, Michael Ellerman wrote:
> > On Tue, 2015-09-22 at 18:15 +0100, Andre Przywara wrote:
> >> On 22/09/15 15:06, Andrea Arcangeli wrote:
> >>> Andre, could you see if linux-next (which includes -mm) works for you
> >>> by just running "cd tools/testing/selftests/vm/ && make"? If there's
> >>> any further change required could you diff it against linux-next?
> >>
> >> This doesn't compile now for me, because it looks into
> >> /usr/include/asm/unistd.h, which I keep to the distribution copy of it.
> >> Also linux/userfaultfd.h is missing, because it's brand new.
> > ...
> >> I guess the right solution would be to hack the Makefile to set the
> >> include path to the kernel's copy of include/uapi, though I am not sure
> >> this works cleanly for different architectures and separate build
> >> directories. I will give this a try ...
> > 
> > Not that's not the right solution.
> > 
> > The right solution is to export the kernel headers, the Makefile will pick 
> > them
> > up (at least in linux-next):
> 
> Actually that was I was hoping for, I just missed the possibility of
> headers_install to put the files back into the kernel tree (I usually
> use it with INSTALL_HDR_PATH for packaging).

OK great.

It does seem that folks are struggling to work out how to do this, so maybe we
can come up with a way to have it automated.

> >   $ cd linux
> >   $ make headers_install
> >   $ ls usr/include/
> >   asm/  asm-generic/  drm/  linux/  misc/  mtd/  rdma/  scsi/  sound/  
> > uapi/  video/  xen/
> >   $ make -C tools/testing/selftests TARGETS=vm
> >   ...
> >   $ ls tools/testing/selftests/vm/userfaultfd
> >   tools/testing/selftests/vm/userfaultfd*
> 
> Yes, that works. Now I have just to figure out how to arrange this with
> out-of-tree build directories.

Right, I think it doesn't work at the moment.

The makefiles that look for the kernel headers use ../../../../usr/include,
which probably isn't what you want for an out of tree build.

Maybe we should do something like the below.

It allows you to do:

  $ make O=~/work/build/ headers_install
  $ ls ~/work/build/usr/include/
  asm/  asm-generic/  drm/  linux/  misc/  mtd/  rdma/  scsi/  sound/  uapi/  
video/  xen/
  $ ls usr/include
  ls: cannot access usr/include: No such file or directory
  $ make -C tools/testing/selftests KERNEL_HEADERS=~/work/build/usr/include/ 
TARGEST=vm
  $ ls tools/testing/selftests/vm/userfaultfd
  tools/testing/selftests/vm/userfaultfd*

cheers


diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 8922c2155a47..617a76be3889 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -41,6 +41,9 @@ override LDFLAGS =
 override MAKEFLAGS =
 endif
 
+KERNEL_HEADERS ?= $(abspath ../../../usr/include)
+export KERNEL_HEADERS
+
 all:
for TARGET in $(TARGETS); do \
make -C $$TARGET; \
diff --git a/tools/testing/selftests/vm/Makefile 
b/tools/testing/selftests/vm/Makefile
index e4bb1de1d526..4f45b9c8dd75 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -1,6 +1,6 @@
 # Makefile for vm selftests
 
-CFLAGS = -Wall -I ../../../../usr/include $(EXTRA_CFLAGS)
+CFLAGS = -Wall -I $(KERNEL_HEADERS) $(EXTRA_CFLAGS)
 BINARIES = compaction_test
 BINARIES += hugepage-mmap
 BINARIES += hugepage-shm
@@ -14,12 +14,9 @@ BINARIES += userfaultfd
 all: $(BINARIES)
 %: %.c
$(CC) $(CFLAGS) -o $@ $^ -lrt
-userfaultfd: userfaultfd.c ../../../../usr/include/linux/kernel.h
+userfaultfd: userfaultfd.c $(KERNEL_HEADERS)/linux/kernel.h
$(CC) $(CFLAGS) -O2 -o $@ $< -lpthread
 
-../../../../usr/include/linux/kernel.h:
-   make -C ../../../.. headers_install
-
 TEST_PROGS := run_vmtests
 TEST_FILES := $(BINARIES)
 




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] net: add Hisilicon Network Subsystem support (config and documents)

[huangdaode]

On 2015/9/21 22:52, Rob Herring wrote:

On 09/17/2015 01:51 AM, huangdaode wrote:

The Hisilicon Network Subsystem is a long term evolution IP which is
supposed to be used in Hisilicon ICT SoC. The IP, which is called hns
for short, is a TCP/IP acceleration engine, which can directly decode
TCP/IP stream and distribute them to different ring buffers.

HNS can be configured to work on different mode for different scenario.
This patch make use only some of the mode to make it as standard
ethernet NIC. The other mode will be added soon.

The whole function has 4 kernel sub-modules:

hnae: the HNS acceleration engine framework. It provides a abstract
interface between the engine and the upper layers which make use of the
engine by ring buffer.

hns_enet_drv: a standard ethernet driver that base on the ring buffer.

hns_dsaf: one of the implementation of HNS acceleration engine, which is
applied on Hililicon hip05, Hi1610 and other later-on SoCs

hns_mdio: the mdio control to the PHY, used by acceleration engine

This submit add basic config and documents

Signed-off-by: huangdaode 
Signed-off-by: Kenneth Lee 
Signed-off-by: Yisen Zhuang 
---
  .../bindings/net/hisilicon-hip04-net.txt   |   4 +-
  .../devicetree/bindings/net/hisilicon-hns-dsaf.txt |  49 ++
  .../devicetree/bindings/net/hisilicon-hns-mdio.txt |  22 +++
  .../devicetree/bindings/net/hisilicon-hns-nic.txt  |  47 +
  arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi   | 193 +
  5 files changed, 313 insertions(+), 2 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
  create mode 100644 
Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
  create mode 100644 Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
  create mode 100644 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi

diff --git a/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt 
b/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
index 988fc69..d1df8a0 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt
@@ -32,13 +32,13 @@ Required properties:
  
  Required properties:
  
-- compatible: should be "hisilicon,hip04-mdio".

+- compatible: should be "hisilicon,mdio".

Why are you removing the old one? Please use more specific compatible
strings, not less specific.



we have unified the hip04_mdio.c and hip05_mdio.c  into hns_mdio.c, so 
we plan use
"hisilicon,mdio", "hisilicon,hns-mdio" "hisilicon,hns-mdio Vx", in this 
case, "hisilicon, mdio "
is more suitable for us, meanwhile, we will upstream hip04 dts file 
later, and will apply the

compatible property with "hisilicon,mdio".


  - Inherits from MDIO bus node binding [2]
  [2] Documentation/devicetree/bindings/net/phy.txt
  
  Example:

mdio {
-   compatible = "hisilicon,hip04-mdio";
+   compatible = "hisilicon,mdio";
reg = <0x28f1000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt 
b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
new file mode 100644
index 000..80411b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
@@ -0,0 +1,49 @@
+Hisilicon DSA Fabric device controller
+
+Required properties:
+- compatible: should be "hisilicon,hns-dsaf-v1" or "hisilicon,hns-dsaf-v2".
+  "hisilicon,hns-dsaf-v1" is for hip05.
+  "hisilicon,hns-dsaf-v2" is for Hi1610 and Hi1612.
+- dsa-name: dsa fabric name who provide this interface.
+  should be "dsafX", X is the dsaf id.

What is this for? Find a different way to distinguish instances other
than an index.


our driver support multi dsaf, so X in dsafX is the dsaf id.
the enet driver interface use the dsa-name to match the dsaf engine, 
then get it's handle.
when there are 2 dsafs ,we use dsaf0 and dsaf1 to distinguish them. The 
default is dsaf0.



+- mode: dsa fabric mode string. only support one of dsaf modes like these:
+   "2port-64vf",
+   "6port-16rss",
+   "6port-16vf".
+- interrupt-parent: the interrupt parent of this device.
+- interrupts: should contain the DSA Fabric and rcb interrupt.
+- reg: specifies base physical address(es) and size of the device registers.
+  The first region is external interface control register base and size.
+  The second region is SerDes base register and size.
+  The third region is the PPE register base and size.
+  The fourth region is dsa fabric base register and size.
+  The fifth region is cpld base register and size, it is not required if do 
not use cpld.
+- phy-handle: phy handle of physicl port, 0 if not any phy device. see 
ethernet.txt [1].
+- buf-size: rx buffer size, should be 16-1024.

This is a h/w property?


yes. it's.


+- desc-num: number of description in TX and RX queue, should be 512, 

Re: [PATCH net-next] BNX2: fix a Null Pointer for stats_blk

[Weidong Wang]

On 2015/9/24 6:31, David Miller wrote:
> From: Weidong Wang 
> Date: Tue, 22 Sep 2015 20:42:40 +0800
> 
>> @@ -880,6 +882,7 @@ bnx2_alloc_mem(struct bnx2 *bp)
>>  }
>>  }
>>
>> +spin_lock(>stats64_lock);
>>  bp->stats_blk = status_blk + status_blk_size;
>>
>>  bp->stats_blk_mapping = bp->status_blk_mapping + status_blk_size;
>> @@ -894,20 +897,23 @@ bnx2_alloc_mem(struct bnx2 *bp)
>>  >ctx_blk_mapping[i],
>>  GFP_KERNEL);
>>  if (bp->ctx_blk[i] == NULL)
>> -goto alloc_mem_err;
>> +goto free_stats64_lock;
>>  }
>>  }
>>
>>  err = bnx2_alloc_rx_mem(bp);
>>  if (err)
>> -goto alloc_mem_err;
>> +goto free_stats64_lock;
> 
> You're holding a spinlock while doing GFP_KERNEL allocations.
> 

hm, yep, I should move it after the allocations. Like this:

@@ -880,7 +882,9 @@ bnx2_alloc_mem(struct bnx2 *bp)
}
}

+   spin_lock(>stats64_lock);
bp->stats_blk = status_blk + status_blk_size;
+   spin_unlock(>stats64_lock);

the allocations won't use the stats_blk, so I shouldn't hold the
lock while doing allocations.

> Second of all, taking a spinlock in get_stats64() defeats the whole
> intention of making statistics acquisition as fast and as SMP scalable
> as possible.
> 

It does affect the intention. Although, the problem exists then makes the
system panic within some case.

Do you have any idea about it?

Best Regards,
Weidong

> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[lkp] [sched/fair] 98d8fd8126: -20.8% hackbench.throughput

[kernel test robot]

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
commit 98d8fd8126676f7ba6e133e65b2ca4b17989d32c ("sched/fair: Initialize task 
load and utilization before placing task on rq")


=
tbox_group/testcase/rootfs/kconfig/compiler/nr_threads/mode/ipc:
  
lkp-ws02/hackbench/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/1600%/process/pipe

commit: 
  231678b768da07d19ab5683a39eeb0c250631d02
  98d8fd8126676f7ba6e133e65b2ca4b17989d32c

231678b768da07d1 98d8fd8126676f7ba6e133e65b 
 -- 
 %stddev %change %stddev
 \  |\  
188818 ±  1% -20.8% 149585 ±  1%  hackbench.throughput
  81712173 ±  4%+211.8%  2.548e+08 ±  1%  
hackbench.time.involuntary_context_switches
  21611286 ±  0% -19.2%   17453366 ±  1%  hackbench.time.minor_page_faults
  2226 ±  0%  +1.3%   2255 ±  0%  
hackbench.time.percent_of_cpu_this_job_got
 12445 ±  0%  +2.1%  12704 ±  0%  hackbench.time.system_time
 2.494e+08 ±  3%+118.5%  5.448e+08 ±  1%  
hackbench.time.voluntary_context_switches
   1097790 ±  0% +50.6%1653664 ±  1%  softirqs.RCU
554877 ±  3%+137.8%1319318 ±  1%  vmstat.system.cs
 89017 ±  4%+187.8% 256235 ±  1%  vmstat.system.in
 1.312e+08 ±  1% -16.0%  1.102e+08 ±  4%  numa-numastat.node0.local_node
 1.312e+08 ±  1% -16.0%  1.102e+08 ±  4%  numa-numastat.node0.numa_hit
 1.302e+08 ±  1% -34.9%   84785305 ±  5%  numa-numastat.node1.local_node
 1.302e+08 ±  1% -34.9%   84785344 ±  5%  numa-numastat.node1.numa_hit
302.00 ±  1% -19.2% 244.00 ±  1%  time.file_system_outputs
  81712173 ±  4%+211.8%  2.548e+08 ±  1%  time.involuntary_context_switches
  21611286 ±  0% -19.2%   17453366 ±  1%  time.minor_page_faults
 2.494e+08 ±  3%+118.5%  5.448e+08 ±  1%  time.voluntary_context_switches
 92.88 ±  0%  +1.3%  94.13 ±  0%  turbostat.%Busy
  2675 ±  0%  +1.8%   2723 ±  0%  turbostat.Avg_MHz
  4.44 ±  1% -24.9%   3.34 ±  2%  turbostat.CPU%c1
  0.98 ±  2% -32.2%   0.66 ±  3%  turbostat.CPU%c3
  2.79e+08 ±  4% -25.2%  2.086e+08 ±  6%  cpuidle.C1-NHM.time
 1.235e+08 ±  4% -28.6%   88251264 ±  7%  cpuidle.C1E-NHM.time
243525 ±  4% -21.9% 190252 ±  8%  cpuidle.C1E-NHM.usage
 1.819e+08 ±  2% -25.8%   1.35e+08 ±  1%  cpuidle.C3-NHM.time
260585 ±  1% -20.4% 207474 ±  2%  cpuidle.C3-NHM.usage
266207 ±  1% -39.4% 161453 ±  3%  cpuidle.C6-NHM.usage
493467 ±  0% +26.5% 624337 ±  0%  meminfo.Active
395397 ±  0% +33.0% 525811 ±  0%  meminfo.Active(anon)
372719 ±  1% +34.2% 500207 ±  1%  meminfo.AnonPages
   4543041 ±  1% +37.5%6248687 ±  1%  meminfo.Committed_AS
185265 ±  1% +16.3% 215373 ±  0%  meminfo.KernelStack
302233 ±  1% +37.1% 414289 ±  1%  meminfo.PageTables
333827 ±  0% +18.6% 396038 ±  0%  meminfo.SUnreclaim
380340 ±  0% +16.6% 443518 ±  0%  meminfo.Slab
 51154 ±143%-100.0%   5.00 ±100%  
latency_stats.avg.call_rwsem_down_write_failed.copy_process._do_fork.SyS_clone.entry_SYSCALL_64_fastpath
  0.00 ± -1%  +Inf%  30679 ±100%  
latency_stats.avg.proc_cgroup_show.proc_single_show.seq_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
  7795 ±100%   +1304.6% 109497 ± 93%  
latency_stats.max.blk_execute_rq.scsi_execute.scsi_execute_req_flags.ses_recv_diag.[ses].ses_get_page2_descriptor.[ses].ses_get_power_status.[ses].ses_enclosure_data_process.[ses].ses_intf_add.[ses].class_interface_register.scsi_register_interface.0xa0006013.do_one_initcall
297190 ±117%-100.0%  23.00 ±100%  
latency_stats.max.call_rwsem_down_write_failed.copy_process._do_fork.SyS_clone.entry_SYSCALL_64_fastpath
  0.00 ± -1%  +Inf%  97905 ±109%  
latency_stats.max.proc_cgroup_show.proc_single_show.seq_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
 12901 ±131% -78.9%   2717 ±135%  
latency_stats.max.wait_on_page_bit.wait_on_page_read.do_read_cache_page.read_cache_page_gfp.btrfs_scan_one_device.[btrfs].btrfs_control_ioctl.[btrfs].do_vfs_ioctl.SyS_ioctl.entry_SYSCALL_64_fastpath
392778 ±128%-100.0%  75.50 ±100%  
latency_stats.sum.call_rwsem_down_write_failed.copy_process._do_fork.SyS_clone.entry_SYSCALL_64_fastpath
 13678 ± 75% -68.1%   4368 ± 67%  
latency_stats.sum.flush_work.__cancel_work_timer.cancel_delayed_work_sync.disk_block_events.__blkdev_get.blkdev_get.blkdev_get_by_path.btrfs_scan_one_device.[btrfs].btrfs_control_ioctl.[btrfs].do_vfs_ioctl.SyS_ioctl.entry_SYSCALL_64_fastpath
 19088 ±101%-100.0%   8.67 ±110%  
latency_stats.sum.path_openat.do_filp_open.do_sys_open.SyS_open.entry_SYSCALL_64_fastpath
  0.00 

Re: [PATCH 1/3] BTRFS: support NFSv2 export

[Neil Brown]

David Sterba  writes:

> On Fri, May 08, 2015 at 10:16:23AM +1000, NeilBrown wrote:
>> The "fh_len" passed to ->fh_to_* is not guaranteed to be that same as
>> that returned by encode_fh - it may be larger.
>> 
>> With NFSv2, the filehandle is fixed length, so it may appear longer
>> than expected and be zero-padded.
>> 
>> So we must test that fh_len is at least some value, not exactly equal
>> to it.
>> 
>> Signed-off-by: NeilBrown 
>
> Acked-by: David Sterba 

Thanks.  However I just checked mainline and this still hasn't been
applied.
Should I resend it to someone?  Who?

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH] perf probe: Fix module probing with shortname

[Arnaldo Carvalho de Melo]

Em Wed, Sep 23, 2015 at 01:03:19PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Sep 22, 2015 at 11:49:02PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Wed, Sep 23, 2015 at 09:14:44AM +0800, Wangnan (F) escreveu:
> > > On 2015/9/22 21:35, Arnaldo Carvalho de Melo wrote:
> > > >Em Tue, Sep 22, 2015 at 03:34:32AM +, Wang Nan escreveu:
> > > >>This is caused by a misunderstood of dso->kernel in 
> > > >>kernel_get_module_dso()
> > > >>that, for kernel module, dso->kernel is DSO_TYPE_USER. dso->kernel is 
> > > >>DSO_TYPE_KERNEL
> > > >>iff dso is vmlinux.
> > > >Kernel modules having DSO_TYPE_USER seems to be the bug, no? I'll try to
> > > >check that...

> > > I also noticed this problem when I working on commit
> > > 1f121b03d058dd07199d8924373d3c52a207f63b ("perf tools: Deal with
> > > kernel module names in '[]' correctly") ;)

> > Thanks for working on this, it is an area that needs cleaning up, too
> > many ways to say what a dso is, will study your findings and try to come
> > up with a patch proposal tomorrow.
> > > So care must be taken.
> 
> So, yes, there are multiple uses for this dso->kernel thing, we need to
> look at each one and go on clarifying it so that this gets corrected and
> sane, but I think we need some helpers to clarify all this, namely:
> 
>   Adding DSO_TYPE_KMODULE and DSO_TYPE_GUEST_KMODULE, setting
> dso->kernel with it when loading host and guest kernel modules and
> adding:
> 
>   bool dso__is_host_kernel(struct dso *dso)
>   bool dso__is_host_kmodule(struct dso *dso)
> 
>   bool dso__is_guest_kernel(struct dso *dso)

So I tried this, ended up basically using __map__is_kernel(), in several
places, which I think is right, and I've stashed in my tmp.perf/core
branch so that you can take a look.

But then I realized that we already have a better way to achieve what is
needed in that function, see the patch below, fixed things for me:

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 2b78e8f19b45..7fb0533ab18c 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -269,12 +269,13 @@ static int kernel_get_module_dso(const char *module, 
struct dso **pdso)
int ret = 0;
 
if (module) {
-   list_for_each_entry(dso, _machine->dsos.head, node) {
-   if (!dso->kernel)
-   continue;
-   if (strncmp(dso->short_name + 1, module,
-   dso->short_name_len - 2) == 0)
-   goto found;
+   char module_name[128];
+
+   snprintf(module_name, sizeof(module_name), "[%s]", module);
+   map = map_groups__find_by_name(_machine->kmaps, 
MAP__FUNCTION, module_name);
+   if (map) {
+   dso = map->dso;
+   goto found;
}
pr_debug("Failed to find module %s.\n", module);
return -ENOENT;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kselftest: using built-in rule when delete file

[Michael Ellerman]

On Wed, 2015-09-23 at 09:40 +, Wang Long wrote:
> Use make's built-in rules to when delete a file
> or delete files.

It's not a built-in rule, it's a variable.

Personally I think using rm directly is clearer, but I guess this is fine. Do
you actually want to override $RM ?

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ASoC: mediatek: Increase periods_min in capture

[Koro Chen]

On Wed, 2015-09-23 at 09:12 -0700, Mark Brown wrote:
> On Wed, Sep 23, 2015 at 06:03:19PM +0800, Koro Chen wrote:
> > Any suggestion for this patch?
> > 
> > On Mon, 2015-09-14 at 14:51 +0800, Koro Chen wrote:
> > > In capture, there is chance that hw_ptr reported at IRQ is
> > > a little smaller than period_size due to internal AFE buffer.
> > > In the case of ping-pong buffer:
> 
> Please don't top post or send content free pings.  I'm not entirely sure
> what you're asking for here - the patch has been applied, what further
> suggestions were you looking for?
I am sorry about the top posting ping... will never do this again. 
OK thank you, now I see the patch is already in the tree, but I am sure
I didn't get the mail titled "Applied xxx to the asoc tree", so I didn't
know the patch status. Maybe something was wrong with the mail system?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/3] usb: gadget: f_midi: free usb request when done

[Peter Chen]

On Wed, Sep 23, 2015 at 01:01:44PM +0100, Felipe F. Tonello wrote:
> req->actual == req->length means that there is no data left to enqueue,
> so free the request.
> 
> Signed-off-by: Felipe F. Tonello 
> ---
> 
> Changes in v2:
>  * Re enqueue not fully completed requests, instead of read ALSA buffers.
> 
>  drivers/usb/gadget/function/f_midi.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index edb84ca..62356cf 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -256,10 +256,12 @@ f_midi_complete(struct usb_ep *ep, struct usb_request 
> *req)
>   /* We received stuff. req is queued again, below */
>   f_midi_handle_out_data(ep, req);
>   } else if (ep == midi->in_ep) {
> - /* Our transmit completed. See if there's more to go.
> -  * f_midi_transmit eats req, don't queue it again. */
> - f_midi_transmit(midi, req);
> - return;
> + /* Our transmit completed. If there is no more to go,
> +don't queue it again. */
> + if (req->actual == req->length) {
> + free_ep_req(ep, req);
> + return;
> + }

I find f_midi_transmit will judge if there are more data, if without
data, it will free the request.

Besides, does one trigger only do one transfer? Sorry, I can't make my
aplaymidi to receive data, probably due to hardware without midi
support?

root@imx6qpsabreauto:~# aplaymidi
ALSA lib
/var/lib/jenkins/workspace/fido-3.14.28-X11-consolidated_new/temp_build_dir/build_all/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/alsa-lib/1.0.28-r0/alsa-lib-1.0.28/src/seq/seq_hw.c:457:(snd_seq_hw_open)
open /dev/snd/seq failed: No such file or directory
Cannot open sequencer - No such file or directory

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed

[Inha Song]

Hi, Charles,

On Wed, 23 Sep 2015 15:43:12 +0100
Charles Keepax  wrote:

> On Wed, Sep 23, 2015 at 11:04:04AM +0900, Inha Song wrote:
> >  Hi, Charles,
> > 
> > I saw the log with LOG_DEVICE in regmap. But, I'm not sure the reason that 
> > suspend noirq failed is IRQ occuring.
> > 
> > Here is my log:
> > --
> > root@localhost:~# aplay test.wav 
> > [   41.049072] s3c64xx_spi_runtime_suspend
> > [   41.056043] arizona spi1.0: ASRC underclocked
> > 
> > [   72.308238] arizona spi1.0: Suspend, disabling IRQ
> > [   72.320286] arizona spi1.0: 400 <= 0
> > [   72.320310] s3c64xx_spi_runtime_resume
> > [   72.336047] arizona spi1.0: 51a <= 0
> > [   72.336217] arizona spi1.0: 101 <= 8604
> > [   72.336401] arizona spi1.0: 171 <= 3
> > [   72.336425] arizona spi1.0: 171 <= 2
> > [   72.336731] arizona spi1.0: 171 <= 0
> > [   72.336751] arizona spi1.0: SYSCLK cleared
> > [   72.338584] arizona spi1.0: SYSCLK cleared
> 
> This bit looks likely related to your problem, it looks like the
> FLL is being turned off. My guess here would be that you haven't
> called snd_soc_dapm_ignore_suspend from your machine driver, you
> need to call this for all end points that may want to stay
> powered up during system suspend and also set the ignore_suspend
> flag on any DAI links you want to remain active during system
> suspend.

But, We should call the trigger callback with SNDRV_PCM_TRIGGER_SUSPEND and 
*_RESUME command
for support senarios what suspend during the playback and resume.
So, I can't set the "ignore_suspend" in playback DAI.

For this reason, I would have called the runtime_suspend manually in 
arizona-core when suspend.

Best Reagrds,
Inha Song.

> 
> Likely what is happening here is that you are disabling the FLL
> and this is causing some IRQ which is then causing a wake event
> thus aborting the suspend.
> 
> Thanks,
> Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD

[Grant Grundler]

MMC_IOC_CMD and MMC_IOC_MULTI_CMD ioctl() code currently bails on
any eMMC errors. However, in case there is any resp[] data, we
should attempt to copy resp[] back to user space. The user app
can then determine which command(s) failed in the MMC_IOC_MULTI_CMD
case AND/OR report better diagnostics in both cases.

Gwendal Grignou provided the idea and it was previously implemented
and tested on v3.18 ChromeOS kernel:
https://chromium-review.googlesource.com/#/c/299956

Signed-off-by: Grant Grundler 
Reviewed-by: Hyung Taek Ryoo 
Reviewed-by: Gwendal Grignou 
Tested-by: David Riley 
---
I believe the patch applied correctly to Ulf's mmc.git on linaro.org.
I would have warm fuzzies if Jon or Hyung (Nvidia) could review/test this.

I made one change from the chromium.org version:
  initialize err and ioc_err to zero in mmc_blk_ioctl_cmd()

 drivers/mmc/card/block.c | 27 +--
 1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index f6acf0f..23b6c8e 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -595,7 +595,7 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
struct mmc_blk_ioc_data *idata;
struct mmc_blk_data *md;
struct mmc_card *card;
-   int err;
+   int err = 0, ioc_err = 0;
 
idata = mmc_blk_ioctl_copy_from_user(ic_ptr);
if (IS_ERR(idata))
@@ -615,19 +615,18 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
 
mmc_get_card(card);
 
-   err = __mmc_blk_ioctl_cmd(card, md, idata);
+   ioc_err = __mmc_blk_ioctl_cmd(card, md, idata);
 
mmc_put_card(card);
 
-   if (!err)
-   err = mmc_blk_ioctl_copy_to_user(ic_ptr, idata);
+   err = mmc_blk_ioctl_copy_to_user(ic_ptr, idata);
 
 cmd_done:
mmc_blk_put(md);
 cmd_err:
kfree(idata->buf);
kfree(idata);
-   return err;
+   return ioc_err ? ioc_err : err;
 }
 
 static int mmc_blk_ioctl_multi_cmd(struct block_device *bdev,
@@ -637,7 +636,7 @@ static int mmc_blk_ioctl_multi_cmd(struct block_device 
*bdev,
struct mmc_ioc_cmd __user *cmds = user->cmds;
struct mmc_card *card;
struct mmc_blk_data *md;
-   int i, err = -EFAULT;
+   int i, err = 0, ioc_err = 0;
__u64 num_of_cmds;
 
if (copy_from_user(_of_cmds, >num_of_cmds,
@@ -672,22 +671,14 @@ static int mmc_blk_ioctl_multi_cmd(struct block_device 
*bdev,
 
mmc_get_card(card);
 
-   for (i = 0; i < num_of_cmds; i++) {
-   err = __mmc_blk_ioctl_cmd(card, md, idata[i]);
-   if (err) {
-   mmc_put_card(card);
-   goto cmd_done;
-   }
-   }
+   for (i = 0; i < num_of_cmds && !ioc_err; i++)
+   ioc_err = __mmc_blk_ioctl_cmd(card, md, idata[i]);
 
mmc_put_card(card);
 
/* copy to user if data and response */
-   for (i = 0; i < num_of_cmds; i++) {
+   for (i = 0; i < num_of_cmds && !err; i++)
err = mmc_blk_ioctl_copy_to_user([i], idata[i]);
-   if (err)
-   break;
-   }
 
 cmd_done:
mmc_blk_put(md);
@@ -697,7 +688,7 @@ cmd_err:
kfree(idata[i]);
}
kfree(idata);
-   return err;
+   return ioc_err ? ioc_err : err;
 }
 
 static int mmc_blk_ioctl(struct block_device *bdev, fmode_t mode,
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/intel_display.c

between commit:

  721a09f7393d ("drm/i915: Add primary plane to mask if it's visible")

from the drm-intel-fixes tree and commit:

  f9cd7b881a04 ("drm/i915: Move sprite/cursor plane disable to 
intel_sanitize_crtc()")

from the drm-intel tree.

I fixed it up (I have no idea what do to here, so I just used the version
from the drm-intel tree) and can carry the fix as necessary (no action
is required - unless there is a better fix).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] usb: gadget: f_midi: free request when usb_ep_queue fails

[Peter Chen]

On Wed, Sep 23, 2015 at 12:40:46PM +0100, Felipe Tonello wrote:
> Hi Peter,
> 
> On Wed, Sep 23, 2015 at 8:09 AM, Peter Chen  wrote:
> > On Tue, Sep 22, 2015 at 07:59:10PM +0100, Felipe F. Tonello wrote:
> >> This fix a memory leak that will occur in this case.
> >>
> >> Signed-off-by: Felipe F. Tonello 
> >> ---
> >>  drivers/usb/gadget/function/f_midi.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/usb/gadget/function/f_midi.c 
> >> b/drivers/usb/gadget/function/f_midi.c
> >> index e92aff5..e6a114b 100644
> >> --- a/drivers/usb/gadget/function/f_midi.c
> >> +++ b/drivers/usb/gadget/function/f_midi.c
> >> @@ -550,9 +550,11 @@ static void f_midi_transmit(struct f_midi *midi, 
> >> struct usb_request *req)
> >>   int err;
> >>
> >>   err = usb_ep_queue(ep, req, GFP_ATOMIC);
> >> - if (err < 0)
> >> + if (err < 0) {
> >>   ERROR(midi, "%s queue req: %d\n",
> >> midi->in_ep->name, err);
> >> + free_ep_req(ep, req);
> >> + }
> >>   } else {
> >>   free_ep_req(ep, req);
> >>   }
> >> --
> >> 2.1.4
> >>
> >
> > I may know your problem, current midi library, alsa and this driver
> > allow device sends as much data as possible, but without block the
> > sending until host reads data, it only allocates the request buffer
> > (using midi_alloc_ep_req), but without free, so after you send
> > enough data, it is out of memory.
> 
> Yes. Also there is the case where the usb cable is not conected, thus
> failing to hardware enqueue the request, causing a memory leak on this
> request.
> 

If the usb cable is not connected, the related endpoints should be
not enabled. Would you really observe enqueue the request without
cable connected?

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] usb: chipidea: core: fix when building without CONFIG_PM support

[Peter Chen]

On Wed, Sep 23, 2015 at 12:56:58PM +0100, Felipe F. Tonello wrote:
> If CONFIG_PM or CONFIG_PM_SLEEP is not set, driver will not compile
> properly.
> 

Would you post the warning or error messages?

I just tried at v4.3-rc1 (v4.2 should be same), without any problems.

Peter
> Signed-off-by: Felipe F. Tonello 
> ---
> 
> Changes for v2:
>  * removed unnecessary #ifdef CONFIG_PM_SLEEP.
> 
>  drivers/usb/chipidea/core.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 3ad48e1..382b4af 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -1009,18 +1009,20 @@ static int ci_runtime_resume(struct device *dev)
>   return ci_controller_resume(dev);
>  }
>  
> -#endif /* CONFIG_PM */
>  static const struct dev_pm_ops ci_pm_ops = {
>   SET_SYSTEM_SLEEP_PM_OPS(ci_suspend, ci_resume)
>   SET_RUNTIME_PM_OPS(ci_runtime_suspend, ci_runtime_resume, NULL)
>  };
> +#endif /* CONFIG_PM */
>  
>  static struct platform_driver ci_hdrc_driver = {
>   .probe  = ci_hdrc_probe,
>   .remove = ci_hdrc_remove,
>   .driver = {
>   .name   = "ci_hdrc",
> +#ifdef CONFIG_PM
>   .pm = _pm_ops,
> +#endif
>   },
>  };
>  
> -- 
> 2.1.4
> 

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fuse scalability part 1

[Ashish Samant]

On 05/18/2015 08:13 AM, Miklos Szeredi wrote:

This part splits out an "input queue" and a "processing queue" from the
monolithic "fuse connection", each of those having their own spinlock.

The end of the patchset adds the ability to "clone" a fuse connection.  This
means, that instead of having to read/write requests/answers on a single fuse
device fd, the fuse daemon can have multiple distinct file descriptors open.
Each of those can be used to receive requests and send answers, currently the
only constraint is that a request must be answered on the same fd as it was read
from.

This can be extended further to allow binding a device clone to a specific CPU
or NUMA node.

Patchset is available here:

   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-next

Libfuse patches adding support for "clone_fd" option:

   git://git.code.sf.net/p/fuse/fuse clone_fd

Thanks,
Miklos


We did some performance testing without these patches and with these 
patches (with -o clone_fd  option specified). Sorry for the delay in 
getting these done. We did 2 types of tests:


1. Throughput test : We did some parallel dd tests to read/write to FUSE 
based database fs on a system with 8 numa nodes and 288 cpus. The 
performance here is almost equal to the the per-numa patches we 
submitted a while back.


1) Writes to single mount

dd processesthroughput(without patchset) throughput(with 
patchset)

in parallel

4633 
Mb/s   606 Mb/s
8   583.2 
Mb/s 561.6 Mb/s
16 436 
Mb/s640.6 Mb/s
32 500.5 
Mb/s 718.1 Mb/s
64 440.7 Mb/s
 1276.8 Mb/s
128   526.2 
Mb/s 2343.4 Mb/s


2) Reading from single mount

dd processes throughput(without patchset) 
throughput(with patchset)

in parallel

41171 
Mb/s  1059 Mb/s
81626 
Mb/s  677 Mb/s
16  1014 
Mb/s  2240.6 Mb/s
32  807.6 
Mb/s 2512.9 Mb/s
64  985.8 
Mb/s 2870.3 Mb/s
1281355 
Mb/s  2996.5 Mb/s




2. Spinlock access times test: We also ran some tests within the kernel 
to check the time spent in accessing the spinlocks per request in both 
cases. As can be seen, the time taken per request to access the spinlock 
in the kernel code throughout the lifetime of the request is 30X to 100X 
better in the 2nd case (with patchset)



dd processes  Time/req(without patchset) Time/req(with 
patchset)

in parallel

4 0.025 ms 
0.00685 ms
8 0.174 ms  
0.0071 ms
16   0.9825 
ms0.0115 ms
32   2.4965 ms   
 0.0315 ms

64   4.8335 ms  0.071 ms
128 5.972 ms 
0.1812 ms


In conclusion, splitting of fc->lock into multiple locks and splitting 
the request queues definitely helps performance.


Thanks,
Ashish
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] locking/rwsem: Use acquire/release semantics

[Davidlohr Bueso]

From: Davidlohr Bueso 

As such, weakly ordered archs can benefit from more relaxed use
of barriers when locking/unlocking.

Signed-off-by: Davidlohr Bueso 
---

Changes from v1:
 Fix bogus acquire in generic lock downgrade (Linus)

 include/asm-generic/rwsem.h | 21 ++---
 kernel/locking/rwsem-xadd.c |  5 +++--
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/include/asm-generic/rwsem.h b/include/asm-generic/rwsem.h
index d48bf5a..d01e313 100644
--- a/include/asm-generic/rwsem.h
+++ b/include/asm-generic/rwsem.h
@@ -33,7 +33,7 @@
  */
 static inline void __down_read(struct rw_semaphore *sem)
 {
-   if (unlikely(atomic_long_inc_return((atomic_long_t *)>count) <= 0))
+   if (unlikely(atomic_long_inc_return_acquire((atomic_long_t *)>count) 
<= 0))
rwsem_down_read_failed(sem);
 }
 
@@ -42,7 +42,7 @@ static inline int __down_read_trylock(struct rw_semaphore *sem)

long tmp;
 
 	while ((tmp = sem->count) >= 0) {

-   if (tmp == cmpxchg(>count, tmp,
+   if (tmp == cmpxchg_acquire(>count, tmp,
   tmp + RWSEM_ACTIVE_READ_BIAS)) {
return 1;
}
@@ -57,7 +57,7 @@ static inline void __down_write_nested(struct rw_semaphore 
*sem, int subclass)
 {
long tmp;
 
-	tmp = atomic_long_add_return(RWSEM_ACTIVE_WRITE_BIAS,

+   tmp = atomic_long_add_return_acquire(RWSEM_ACTIVE_WRITE_BIAS,
 (atomic_long_t *)>count);
if (unlikely(tmp != RWSEM_ACTIVE_WRITE_BIAS))
rwsem_down_write_failed(sem);
@@ -72,7 +72,7 @@ static inline int __down_write_trylock(struct rw_semaphore 
*sem)
 {
long tmp;
 
-	tmp = cmpxchg(>count, RWSEM_UNLOCKED_VALUE,

+   tmp = cmpxchg_acquire(>count, RWSEM_UNLOCKED_VALUE,
  RWSEM_ACTIVE_WRITE_BIAS);
return tmp == RWSEM_UNLOCKED_VALUE;
 }
@@ -84,7 +84,7 @@ static inline void __up_read(struct rw_semaphore *sem)
 {
long tmp;
 
-	tmp = atomic_long_dec_return((atomic_long_t *)>count);

+   tmp = atomic_long_dec_return_release((atomic_long_t *)>count);
if (unlikely(tmp < -1 && (tmp & RWSEM_ACTIVE_MASK) == 0))
rwsem_wake(sem);
 }
@@ -94,7 +94,7 @@ static inline void __up_read(struct rw_semaphore *sem)
  */
 static inline void __up_write(struct rw_semaphore *sem)
 {
-   if (unlikely(atomic_long_sub_return(RWSEM_ACTIVE_WRITE_BIAS,
+   if (unlikely(atomic_long_sub_return_release(RWSEM_ACTIVE_WRITE_BIAS,
 (atomic_long_t *)>count) < 0))
rwsem_wake(sem);
 }
@@ -114,7 +114,14 @@ static inline void __downgrade_write(struct rw_semaphore 
*sem)
 {
long tmp;
 
-	tmp = atomic_long_add_return(-RWSEM_WAITING_BIAS,

+   /*
+* When downgrading from exclusive to shared ownership,
+* anything inside the write-locked region cannot leak
+* into the read side. In contrast, anything in the
+* read-locked region is ok to be re-ordered into the
+* write side. As such, use RELEASE semantics.
+*/
+   tmp = atomic_long_add_return_release(-RWSEM_WAITING_BIAS,
 (atomic_long_t *)>count);
if (tmp < 0)
rwsem_downgrade_wake(sem);
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 0f18971..a4d4de0 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -262,7 +262,7 @@ static inline bool rwsem_try_write_lock(long count, struct 
rw_semaphore *sem)
 * to reduce unnecessary expensive cmpxchg() operations.
 */
if (count == RWSEM_WAITING_BIAS &&
-   cmpxchg(>count, RWSEM_WAITING_BIAS,
+   cmpxchg_acquire(>count, RWSEM_WAITING_BIAS,
RWSEM_ACTIVE_WRITE_BIAS) == RWSEM_WAITING_BIAS) {
if (!list_is_singular(>wait_list))
rwsem_atomic_update(RWSEM_WAITING_BIAS, sem);
@@ -285,7 +285,8 @@ static inline bool rwsem_try_write_lock_unqueued(struct 
rw_semaphore *sem)
if (!(count == 0 || count == RWSEM_WAITING_BIAS))
return false;
 
-		old = cmpxchg(>count, count, count + RWSEM_ACTIVE_WRITE_BIAS);

+   old = cmpxchg_acquire(>count, count,
+ count + RWSEM_ACTIVE_WRITE_BIAS);
if (old == count) {
rwsem_set_owner(sem);
return true;
--
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] scsi_dh: avoid allowing dh_state to pass format specs when requesting a module

[Sasha Levin]

A malicious string passed from userspace might contain format specifiers which
request_module() might try to handle, which is bad.

Signed-off-by: Sasha Levin 
---
 drivers/scsi/scsi_dh.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_dh.c b/drivers/scsi/scsi_dh.c
index edb044a..24be260 100644
--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -111,7 +111,7 @@ static struct scsi_device_handler *scsi_dh_lookup(const 
char *name)
 
dh = __scsi_dh_lookup(name);
if (!dh) {
-   request_module(name);
+   request_module("%s", name);
dh = __scsi_dh_lookup(name);
}
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] locking/rtmutex: Use acquire/release semantics

[Davidlohr Bueso]

From: Davidlohr Bueso 

As such, weakly ordered archs can benefit from more relaxed use
of barriers when locking/unlocking.

Signed-off-by: Davidlohr Bueso 
---

Changes from v1:
 - fix bogus acquire in unlock_rt_mutex_safe() (tglx)

 kernel/locking/rtmutex.c | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 35e9bfc..8251e75 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -74,14 +74,23 @@ static void fixup_rt_mutex_waiters(struct rt_mutex *lock)
  * set up.
  */
 #ifndef CONFIG_DEBUG_RT_MUTEXES
-# define rt_mutex_cmpxchg(l,c,n)   (cmpxchg(>owner, c, n) == c)
+# define rt_mutex_cmpxchg_relaxed(l,c,n) (cmpxchg_relaxed(>owner, c, n) == 
c)
+# define rt_mutex_cmpxchg_acquire(l,c,n) (cmpxchg_acquire(>owner, c, n) == 
c)
+# define rt_mutex_cmpxchg_release(l,c,n) (cmpxchg_release(>owner, c, n) == 
c)
+
+/*
+ * Callers must hold the ->wait_lock -- which is the whole purpose as we force
+ * all future threads that attempt to [Rmw] the lock to the slowpath. As such
+ * relaxed semantics suffice.
+ */
 static inline void mark_rt_mutex_waiters(struct rt_mutex *lock)
 {
unsigned long owner, *p = (unsigned long *) >owner;
 
 	do {

owner = *p;
-   } while (cmpxchg(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner);
+   } while (cmpxchg_relaxed(p, owner,
+owner | RT_MUTEX_HAS_WAITERS) != owner);
 }
 
 /*

@@ -121,11 +130,14 @@ static inline bool unlock_rt_mutex_safe(struct rt_mutex 
*lock)
 *  lock(wait_lock);
 *  acquire(lock);
 */
-   return rt_mutex_cmpxchg(lock, owner, NULL);
+   return rt_mutex_cmpxchg_release(lock, owner, NULL);
 }
 
 #else

-# define rt_mutex_cmpxchg(l,c,n)   (0)
+# define rt_mutex_cmpxchg_relaxed(l,c,n)   (0)
+# define rt_mutex_cmpxchg_acquire(l,c,n)   (0)
+# define rt_mutex_cmpxchg_release(l,c,n)   (0)
+
 static inline void mark_rt_mutex_waiters(struct rt_mutex *lock)
 {
lock->owner = (struct task_struct *)
@@ -1322,7 +1334,7 @@ rt_mutex_fastlock(struct rt_mutex *lock, int state,
struct hrtimer_sleeper *timeout,
enum rtmutex_chainwalk chwalk))
 {
-   if (likely(rt_mutex_cmpxchg(lock, NULL, current))) {
+   if (likely(rt_mutex_cmpxchg_acquire(lock, NULL, current))) {
rt_mutex_deadlock_account_lock(lock, current);
return 0;
} else
@@ -1338,7 +1350,7 @@ rt_mutex_timed_fastlock(struct rt_mutex *lock, int state,
  enum rtmutex_chainwalk chwalk))
 {
if (chwalk == RT_MUTEX_MIN_CHAINWALK &&
-   likely(rt_mutex_cmpxchg(lock, NULL, current))) {
+   likely(rt_mutex_cmpxchg_acquire(lock, NULL, current))) {
rt_mutex_deadlock_account_lock(lock, current);
return 0;
} else
@@ -1349,7 +1361,7 @@ static inline int
 rt_mutex_fasttrylock(struct rt_mutex *lock,
 int (*slowfn)(struct rt_mutex *lock))
 {
-   if (likely(rt_mutex_cmpxchg(lock, NULL, current))) {
+   if (likely(rt_mutex_cmpxchg_acquire(lock, NULL, current))) {
rt_mutex_deadlock_account_lock(lock, current);
return 1;
}
@@ -1363,7 +1375,7 @@ rt_mutex_fastunlock(struct rt_mutex *lock,
 {
WAKE_Q(wake_q);
 
-	if (likely(rt_mutex_cmpxchg(lock, current, NULL))) {

+   if (likely(rt_mutex_cmpxchg_release(lock, current, NULL))) {
rt_mutex_deadlock_account_unlock(current);
 
 	} else {

@@ -1485,7 +1497,7 @@ EXPORT_SYMBOL_GPL(rt_mutex_unlock);
 bool __sched rt_mutex_futex_unlock(struct rt_mutex *lock,
   struct wake_q_head *wqh)
 {
-   if (likely(rt_mutex_cmpxchg(lock, current, NULL))) {
+   if (likely(rt_mutex_cmpxchg_release(lock, current, NULL))) {
rt_mutex_deadlock_account_unlock(current);
return false;
}
--
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Multiple potential races on vma->vm_flags

[Sasha Levin]

On 09/23/2015 09:08 AM, Andrey Konovalov wrote:
> On Wed, Sep 23, 2015 at 3:39 AM, Hugh Dickins  wrote:
>> > This is totally untested, and one of you may quickly prove me wrong;
>> > but I went in to fix your "Bad page state (mlocked)" by holding pte
>> > lock across the down_read_trylock of mmap_sem in try_to_unmap_one(),
>> > then couldn't see why it would need mmap_sem at all, given how mlock
>> > and munlock first assert intention by setting or clearing VM_LOCKED
>> > in vm_flags, then work their way up the vma, taking pte locks.
>> >
>> > Calling mlock_vma_page() under pte lock may look suspicious
>> > at first: but what it does is similar to clear_page_mlock(),
>> > which we regularly call under pte lock from page_remove_rmap().
>> >
>> > I'd rather wait to hear whether this appears to work in practice,
>> > and whether you agree that it should work in theory, before writing
>> > the proper description.  I'd love to lose that down_read_trylock.
> No, unfortunately it doesn't work, I still see "Bad page state (mlocked)".
> 
> It seems that your patch doesn't fix the race from the report below, since pte
> lock is not taken when 'vma->vm_flags &= ~VM_LOCKED;' (mlock.c:425)
> is being executed. (Line numbers are from kernel with your patch applied.)

I've fired up my HZ_1 patch, and this seems to be a real race that is
somewhat easy to reproduce under those conditions.

Here's a fresh backtrace from my VMs:

[1935109.882343] BUG: Bad page state in process trinity-subchil  pfn:3ca200
[1935109.884000] page:ea000f288000 count:0 mapcount:0 mapping:  
(null) index:0x1e00 compound_mapcount: 0
[1935109.885772] flags: 0x22f80144008(uptodate|head|swapbacked|mlocked)
[1935109.887174] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
[1935109.888197] bad because of flags:
[1935109.888759] flags: 0x10(mlocked)
[1935109.889525] Modules linked in:
[1935109.890165] CPU: 8 PID: 2615 Comm: trinity-subchil Not tainted 
4.3.0-rc2-next-20150923-sasha-00079-gec04207-dirty #2569
[1935109.891876]  16445448 e5dca494 8803f7657708 
a70402da
[1935109.893504]  ea000f288000 8803f7657738 a56e522b 
022f80144008
[1935109.894947]  ea000f288020 ea000f288000  
8803f76577a8
[1935109.896413] Call Trace:
[1935109.899102]  [] dump_stack+0x4e/0x84
[1935109.899821]  [] bad_page+0x17b/0x210
[1935109.900469]  [] free_pages_prepare+0xb48/0x1110
[1935109.902127]  [] __free_pages_ok+0x21/0x260
[1935109.904435]  [] free_compound_page+0x63/0x80
[1935109.905614]  [] free_transhuge_page+0x6e/0x80
[1935109.906752]  [] __put_compound_page+0x76/0xa0
[1935109.907884]  [] release_pages+0x4d5/0x9f0
[1935109.913027]  [] tlb_flush_mmu_free+0x8a/0x120
[1935109.913957]  [] unmap_page_range+0xe73/0x1460
[1935109.915737]  [] unmap_single_vma+0x126/0x2f0
[1935109.916646]  [] unmap_vmas+0xdd/0x190
[1935109.917454]  [] exit_mmap+0x221/0x430
[1935109.921176]  [] mmput+0xb1/0x240
[1935109.921919]  [] do_exit+0x732/0x27c0
[1935109.928561]  [] do_group_exit+0xf9/0x300
[1935109.929786]  [] SyS_exit_group+0x1d/0x20
[1935109.930617]  [] entry_SYSCALL_64_fastpath+0x16/0x7a


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problems with printk logs and my driver

[Alan Stern]

On Thu, 24 Sep 2015, Eric Curtin wrote:

> Hi Guys,
> 
> Just wondering what I am doing wrong. I can't see my logs. I figured
> out what driver is used for my keyboard and started adding logging:
> 
> [curtine@localhost ~]$ sudo lsusb -v | grep eyboard -B 13
> Bus 001 Device 003: ID 04ca:008d Lite-On Technology Corp.

...

> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
> |__ Port 4: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
> |__ Port 4: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
> |__ Port 7: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
> |__ Port 7: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
> |__ Port 7: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M

...

> So, first I added a little logging and then some more, but I can't see
> any of it (see patch at bottom of email, I used KERN_EMERG, it's just
> temporary logging).
> 
> I'm think I'm doing most things right, this is how I compile my code I
> wrote a little script (I'm on fedora):

...

> I reboot, load new kernel, blah blah. When I type keys I don't see my
> logs in dmesg, I don't see them in /var/log/messages either, I don't
> see them in /home/curtine/log.log either when I do a:
> 
> sudo killall klogd
> sudo /sbin/klogd -f /home/curtine/log.log
> 
> What am I doing wrong here?

You made a very simple mistake.  See below.

> Also, as regards etiquette on these mailing lists, is it ok to
> regularly cc linux-kernel@vger.kernel.org?

It's okay.  But there's no need to do it if your topic is limited to a 
single subsystem.

> diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
> index 9a332e6..2038d94 100644
> --- a/drivers/hid/usbhid/usbkbd.c
> +++ b/drivers/hid/usbhid/usbkbd.c
> @@ -112,6 +112,7 @@ struct usb_kbd {
> 
>  static void usb_kbd_irq(struct urb *urb)
>  {
> +   printk(KERN_EMERG "usb_kbd_irq");
> struct usb_kbd *kbd = urb->context;
> int i;
> 
...

Your mistake was thinking that the driver for your keyboard is usbkbd.  
It isn't.  It's usbhid, as you can see in the "lsusb -t" output above.

Even though the source code for usbkbd is located in the usbhid 
directory, they are separate drivers.  Look at the Kconfig file in 
drivers/hid/usbhid and you'll see.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/2] PCI: Add support for PCI Enhanced Allocation "BARs"

[David Daney]

Hi Sean,

Thanks for doing this, I think we will use it for Cavium ThunderX.  A 
couple of questions...



On 09/23/2015 03:27 PM, Sean O. Stalley wrote:

PCI Enhanced Allocation is a new method of allocating MMIO & IO
resources for PCI devices & bridges. It can be used instead
of the traditional PCI method of using BARs.

EA entries are hardware-initialized to a fixed address.
Unlike BARs, regions described by EA are cannot be moved.
Because of this, only devices which are permanently connected to
the PCI bus can use EA. A removable PCI card must not use EA.

This patchset adds support for using EA entries instead of BARs
on Root Complex Integrated Endpoints.

The Enhanced Allocation ECN is publicly available here:
https://www.pcisig.com/specifications/conventional/ECN_Enhanced_Allocation_23_Oct_2014_Final.pdf


Changes from V1:
- Use generic PCI resource claim functions (instead of EA-specific 
functions)
- Only add support for RCiEPs (instead of all devices).


Why not all devices?  The spec. allows for EA on devices behind bridges.



- Removed some debugging messages leftover from early testing.


Sean O. Stalley (2):
   PCI: Add Enhanced Allocation register entries
   PCI: Add support for Enhanced Allocation devices

  drivers/pci/pci.c | 174 ++
  drivers/pci/pci.h |   1 +
  drivers/pci/probe.c   |   3 +
  include/uapi/linux/pci_regs.h |  40 +-
  4 files changed, 217 insertions(+), 1 deletion(-)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: ext4: performance regression introduced by the cgroup writeback support

[Dexuan Cui]

> -Original Message-
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo
> Sent: Thursday, September 24, 2015 2:54
> To: Chris Mason ; Dexuan Cui ;
> Theodore Ts'o ; Andreas Dilger ;
> linux-e...@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: ext4: performance regression introduced by the cgroup writeback
> support
> 
> On Wed, Sep 23, 2015 at 12:13:59PM -0400, Chris Mason wrote:
> > > The issue is: under high CPU and disk I/O pressure, *some* processes can
> suffer from a very slow write speed (e.g., <1MB/s or even only 20KB/s), while
> the normal write speed should be at least dozens of MB/s.
> 
> So, I think I know what caused this regression.  Separate wb domains
> shouldn't have been enabled on traditional hierarchies.  It doesn't
> work there and leads to multiple wb domains competing on the same
> blkcg and the bw estimation would go completely haywire.  Will update
> soon.
> 
> Thanks.
> 
> --
> tejun

Thanks a lot for the quick fix, Tejun!

I'll test the fix.
I'll report back in case it can't fix the issue --I think this is unlikely. :-)

-- Dexuan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/2] PCI: Add support for PCI Enhanced Allocation "BARs"

[Yinghai Lu]

On Wed, Sep 23, 2015 at 4:51 PM, Sean O. Stalley  wrote:
> IORESOURCE_PCI_FIXED is set in pci_ea_set_flags():
>
> +static unsigned long pci_ea_set_flags(struct pci_dev *dev, u8 prop)
> +{
> +   unsigned long flags = IORESOURCE_PCI_FIXED;
> +
> +
>
> Which is called in pci_ea_read(), and passed to res->flags (if there aren't 
> any errors):

ok.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] fsl-ifc: fix compilation error on 42 bit VA

[Lijun Pan]

Need to include sched.h to fix the following compilation error
if FSL_IFC is enabled on ARM64 machine.

In file included from include/linux/mmzone.h:9:0,
 from include/linux/gfp.h:5,
 from include/linux/kmod.h:22,
 from include/linux/module.h:13,
 from drivers/memory/fsl_ifc.c:22:
drivers/memory/fsl_ifc.c: In function ‘check_nand_stat’:
include/linux/wait.h:165:35: error: ‘TASK_NORMAL’ undeclared (first use in this 
function)
 #define wake_up(x)   __wake_up(x, TASK_NORMAL, 1, NULL)
   ^
drivers/memory/fsl_ifc.c:136:3: note: in expansion of macro ‘wake_up’
   wake_up(>nand_wait);
   ^
include/linux/wait.h:165:35: note: each undeclared identifier is reported only 
once for each function it appears in
 #define wake_up(x)   __wake_up(x, TASK_NORMAL, 1, NULL)
   ^
drivers/memory/fsl_ifc.c:136:3: note: in expansion of macro ‘wake_up’
   wake_up(>nand_wait);
   ^
make[2]: *** [drivers/memory/fsl_ifc.o] Error 1
make[1]: *** [drivers/memory] Error 2
make[1]: *** Waiting for unfinished jobs

Signed-off-by: Lijun Pan 
---
 drivers/memory/fsl_ifc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
index e87459f..8d90de6 100644
--- a/drivers/memory/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev;
 EXPORT_SYMBOL(fsl_ifc_ctrl_dev);
-- 
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [website PATCH v3] 4.1 is a longterm kernel.

[Konstantin Ryabitsev]

On 23/09/15 07:14 PM, Greg Kroah-Hartman wrote:
> I'll be maintaining 4.1 for the next two years, proving that after a
> decade of doing stable kernels, I still do not know any better.
> 
> Signed-off-by: Greg Kroah-Hartman 

v3 applied and live. Good luck!

Best,
-- 
Konstantin Ryabitsev
Linux Foundation Collab Projects
Montréal, Québec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] mmc: debugfs: implement ios show for SDR12 and SDR25

[Shawn Lin]

This patch add MMC_TIMING_UHS_SDR12 and MMC_TIMING_UHS_SDR25
for mmc_ios_show to show the ios->timing if mmc card runs under
these two modes.

Signed-off-by: Shawn Lin 

---

Changes in v2:
- replace "mmc uhs sdr12" with "sd uhs sdr12"
  replace "mmc uhs sdr25" with "sd uhs sdr25"

 drivers/mmc/core/debugfs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 9adba8d..f4db93e 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -126,6 +126,12 @@ static int mmc_ios_show(struct seq_file *s, void *data)
case MMC_TIMING_SD_HS:
str = "sd high-speed";
break;
+   case MMC_TIMING_UHS_SDR12:
+   str = "sd uhs SDR12";
+   break;
+   case MMC_TIMING_UHS_SDR25:
+   str = "sd uhs SDR25";
+   break;
case MMC_TIMING_UHS_SDR50:
str = "sd uhs SDR50";
break;
-- 
2.3.7


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: ext4: performance regression introduced by the cgroup writeback support

[Dexuan Cui]

> -Original Message-
> From: Chris Mason [mailto:c...@fb.com]
> Sent: Thursday, September 24, 2015 0:14
> To: Dexuan Cui 
> Cc: Theodore Ts'o ; Andreas Dilger ;
> Tejun Heo ; linux-e...@vger.kernel.org; linux-
> fsde...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: ext4: performance regression introduced by the cgroup writeback
> support
> 
> On Wed, Sep 23, 2015 at 01:49:31PM +, Dexuan Cui wrote:
> > Hi all,
> > Since some point between July and Sep, I have been suffered from a strange
> "very slow write" issue and on Sep 9 I reported it to LKML (but got no reply):
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flkml.org%
> 2flkml%2f2015%2f9%2f9%2f290=01%7c01%7cdecui%40064d.mgd.micros
> oft.com%7c8001aa10249f41a0363608d2c432042d%7c72f988bf86f141af91ab2
> d7cd011db47%7c1=oJBsP55jdg86TNt2X71s0gfPlwbMTzaJN9QIcsXsSmA%
> 3d
> >
> > The issue is: under high CPU and disk I/O pressure, *some* processes can
> suffer from a very slow write speed (e.g., <1MB/s or even only 20KB/s), while
> the normal write speed should be at least dozens of MB/s.
> >
> > I think I identified the commit which introduced the regression:
> > ext4: implement cgroup writeback support
> (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit.kernel.
> org%2fcgit%2flinux%2fkernel%2fgit%2fnext%2flinux-
> next.git%2fcommit%2f%3fid%3d001e4a8775f6e8ad52a89e0072f09aee47d5d25
> 2=01%7c01%7cdecui%40064d.mgd.microsoft.com%7c8001aa10249f41a0
> 363608d2c432042d%7c72f988bf86f141af91ab2d7cd011db47%7c1=QIcX
> R%2flZMqkK2afIxV%2fYxZDug26vj5yx%2bkoh6ugJB2A%3d)
> >
> > This commit is already in the mainline tree, so I can reproduce the issue 
> > there
> too:
> > With the latest mainline,  I can reproduce the issue; after I revert the 
> > patch, I
> can't reproduce the issue.
> >
> > When the issue happens:
> > 1. the read speed is pretty normal, e.g.. it's still >100MB/s.
> > 2. 'top' shows both the 'user' and 'sys' utilization is about 0%, but the 
> > IO-wait is
> always about 100%.
> > 3. 'iotop' shows the read speed is 0 (this is correct because there is 
> > indeed no
> read request)  and the write speed is pretty slow (the average is <1MB/s or 
> even
> 20KB/s).
> > 4. when the issue happens, sometimes any new process suffers from the slow
> write issue, but sometimes it looks not all the new processes suffers from the
> issue.
> > 5. The " WARNING: CPU: 7 PID: 6782 at fs/inode.c:390 ihold+0x30/0x40() " in
> my Sep-9 mail may be another different issue.
> > 6. To reproduce the issue, I need to run my workload for enough long time
> (see the below).
> >
> > My workload is simple: I just repeatedly build the kernel source ("make 
> > clean;
> make -j16"). My kernel config is attached FYI.
> >
> > I can reproduce the issue on a physical machine: e.g., in my kernel 
> > building test
> with my .config, it took only ~5 minutes in the first 176 runs, but since the 
> 177th
> run, it could take from 10 hours to 5 minutes - very unstable.
> >
> > It looks it's easier to reproduce the issue in a Hyper-V VM: usually I can
> reproduce the issue within the first 10 or 20 runs.
> >
> > Any idea?
> 
> Are you using cgroups?  That patch really shouldn't impact load unless
> there are actual IO controls in place.
> 
> -chris

I'm not using cgroups here.

Tejun just now found the root cause: "Separate wb domains
shouldn't have been enabled on traditional hierarchies " and supplied a fix.

Thanks,
-- Dexuan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Revert "KVM: x86: zero kvmclock_offset when vcpu0 initializes kvmclock system MSR"

[Marcelo Tosatti]

On Tue, Sep 22, 2015 at 09:52:49PM +0200, Paolo Bonzini wrote:
> 
> 
> On 22/09/2015 21:01, Marcelo Tosatti wrote:
> > On Fri, Sep 18, 2015 at 05:54:30PM +0200, Radim Krčmář wrote:
> >> Shifting pvclock_vcpu_time_info.system_time on write to KVM system time
> >> MSR is a change of ABI.  Probably only 2.6.16 based SLES 10 breaks due
> >> to its custom enhancements to kvmclock, but KVM never declared the MSR
> >> only for one-shot initialization.  (Doc says that only one write is
> >> needed.)
> >>
> >> This reverts commit b7e60c5aedd2b63f16ef06fde4f81ca032211bc5.
> >> And adds a note to the definition of PVCLOCK_COUNTS_FROM_ZERO.
> >>
> >> Signed-off-by: Radim Krčmář 
> >> ---
> >>  arch/x86/include/asm/pvclock-abi.h | 1 +
> >>  arch/x86/kvm/x86.c | 4 
> >>  2 files changed, 1 insertion(+), 4 deletions(-)
> >>
> >> diff --git a/arch/x86/include/asm/pvclock-abi.h 
> >> b/arch/x86/include/asm/pvclock-abi.h
> >> index 655e07a48f6c..67f08230103a 100644
> >> --- a/arch/x86/include/asm/pvclock-abi.h
> >> +++ b/arch/x86/include/asm/pvclock-abi.h
> >> @@ -41,6 +41,7 @@ struct pvclock_wall_clock {
> >>  
> >>  #define PVCLOCK_TSC_STABLE_BIT(1 << 0)
> >>  #define PVCLOCK_GUEST_STOPPED (1 << 1)
> >> +/* PVCLOCK_COUNTS_FROM_ZERO broke ABI and can't be used anymore. */
> >>  #define PVCLOCK_COUNTS_FROM_ZERO (1 << 2)
> >>  #endif /* __ASSEMBLY__ */
> >>  #endif /* _ASM_X86_PVCLOCK_ABI_H */
> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> >> index 18d59b584dee..34d33f4757d2 100644
> >> --- a/arch/x86/kvm/x86.c
> >> +++ b/arch/x86/kvm/x86.c
> >> @@ -1707,8 +1707,6 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
> >>vcpu->pvclock_set_guest_stopped_request = false;
> >>}
> >>  
> >> -  pvclock_flags |= PVCLOCK_COUNTS_FROM_ZERO;
> >> -
> >>/* If the host uses TSC clocksource, then it is stable */
> >>if (use_master_clock)
> >>pvclock_flags |= PVCLOCK_TSC_STABLE_BIT;
> >> @@ -2006,8 +2004,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
> >> msr_data *msr_info)
> >>>requests);
> >>  
> >>ka->boot_vcpu_runs_old_kvmclock = tmp;
> >> -
> >> -  ka->kvmclock_offset = -get_kernel_ns();
> >>}
> >>  
> >>vcpu->arch.time = data;
> >> -- 
> >> 2.5.2
> > 
> > ACK
> 
> So I suppose you changed your mind :) but can you explain the reasoning?
> 
> Paolo

The patch is correct. Overflow (issue raised) is only an issue 
without PVCLOCK_TSC_STABLE_BIT.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linux v4.2] workqueue: llvmlinux: acpid: BUG: sleeping function called from invalid context at kernel/workqueue.c:2680

[Sedat Dilek]

On Thu, Sep 10, 2015 at 3:04 AM, Lai Jiangshan  wrote:
> Hi, TJ
>
> I think we need to add might_sleep() on the top of __cancel_work_timer().
> The might_sleep() on the start_flush_work() doesn't cover all the
> paths of __cancel_work_timer().
> And it can help to narrow the area of this bug.
>

I moved the might_sleep() from start_flush_work() to
__cancel_work_timer() (see attached patch).

[   23.444152] BUG: sleeping function called from invalid context at
kernel/workqueue.c:2767
[   23.444217] in_atomic(): 0, irqs_disabled(): 1, pid: 1423, name: acpid
[   23.444265] 3 locks held by acpid/1423:
[   23.444266]  #0:  (>mutex){+.+...}, at: []
evdev_release+0xbc/0xf0
[   23.444276]  #1:  (>mutex#2){+.+...}, at: []
input_close_device+0x27/0x70
[   23.444283]  #2:  (hid_open_mut){+.+...}, at: []
usbhid_close+0x28/0xb0 [usbhid]
[   23.444291] irq event stamp: 7850
[   23.444293] hardirqs last  enabled at (7849): []
_raw_spin_unlock_irq+0x32/0x60
[   23.444298] hardirqs last disabled at (7850): []
del_timer_sync+0x37/0x110
[   23.444303] softirqs last  enabled at (7164): []
local_bh_enable+0x9/0x20
[   23.444307] softirqs last disabled at (7162): []
local_bh_disable+0x9/0x20
[   23.444312] CPU: 2 PID: 1423 Comm: acpid Not tainted
4.3.0-rc2-3-llvmlinux-amd64 #2
[   23.444314] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[   23.444316]  8800d2e82948 0096 
8800bcc4fbf8
[   23.444320]  8149a4ad 8800bcc4fc28 810cd53a
81c56fcc
[   23.444324]  8800c69f0040  0acf
8800bcc4fc68
[   23.444328] Call Trace:
[   23.444332]  [] dump_stack+0x7d/0xa0
[   23.444336]  [] ___might_sleep+0x28a/0x2a0
[   23.444338]  [] __might_sleep+0x4f/0xc0
[   23.444342]  [] __cancel_work_timer+0x2e/0x270
[   23.444345]  [] ? _raw_spin_unlock_irqrestore+0x52/0x80
[   23.444348]  [] ? try_to_del_timer_sync+0xad/0xc0
[   23.444351]  [] cancel_work_sync+0x18/0x20
[   23.444354]  [] usbhid_close+0x75/0xb0 [usbhid]
[   23.444360]  [] hidinput_close+0x31/0x40 [hid]
[   23.444364]  [] ? hidinput_open+0x40/0x40 [hid]
[   23.444367]  [] input_close_device+0x48/0x70
[   23.444370]  [] evdev_release+0xd6/0xf0
[   23.444373]  [] __fput+0x107/0x240
[   23.444375]  [] fput+0x16/0x20
[   23.444378]  [] task_work_run+0x6c/0xe0
[   23.444383]  [] prepare_exit_to_usermode+0x13a/0x140
[   23.444386]  [] syscall_return_slowpath+0x281/0x2f0
[   23.444389]  [] ? filp_close+0x65/0x90
[   23.444392]  [] ? trace_hardirqs_on_thunk+0x17/0x19
[   23.444396]  [] int_ret_from_sys_call+0x25/0x9f

Can you look at this?

- Sedat -

> Hi Sedat Dilek
>
> [   24.705704] irq event stamp: 19968
> [   24.705706] hardirqs last  enabled at (19967): []
> _raw_spin_unlock_irq+0x32/0x60
> [   24.705713] hardirqs last disabled at (19968): []
> del_timer_sync+0x37/0x110
>
> Is it means the irq-disabled-event is leak by del_timer_sync()? It is
> impossible.
>
> usbhid_close()
>   mutex_lock(); // it has might_sleep() check. So the problem seems to be
> // hidden at one of the following statements
>   del_timer_sync();
>   cancel_work_sync();
>
>
> On Wed, Sep 9, 2015 at 6:24 PM, Sedat Dilek  wrote:
>> [ TO WORKQUEUE maintainers ]
>>
>> Hi,
>>
>> I encountered a BUG with a llvmlinux compiled kernel here on
>> Ubuntu/precise AMD64 touching the workqueue area.
>>
>> [   24.705463] BUG: sleeping function called from invalid context at
>> kernel/workqueue.c:2680
>> [   24.705576] in_atomic(): 0, irqs_disabled(): 1, pid: 1447, name: acpid
>> [   24.705662] 3 locks held by acpid/1447:
>> [   24.705664]  #0:  (>mutex){+.+...}, at: []
>> evdev_release+0xbc/0xf0
>> [   24.705678]  #1:  (>mutex#2){+.+...}, at: []
>> input_close_device+0x27/0x70
>> [   24.705691]  #2:  (hid_open_mut){+.+...}, at: []
>> usbhid_close+0x28/0xb0 [usbhid]
>> [   24.705704] irq event stamp: 19968
>> [   24.705706] hardirqs last  enabled at (19967): []
>> _raw_spin_unlock_irq+0x32/0x60
>> [   24.705713] hardirqs last disabled at (19968): []
>> del_timer_sync+0x37/0x110
>> [   24.705720] softirqs last  enabled at (18890): []
>> local_bh_enable+0x9/0x20
>> [   24.705726] softirqs last disabled at (1): []
>> local_bh_disable+0x9/0x20
>> [   24.705734] CPU: 2 PID: 1447 Comm: acpid Not tainted
>> 4.2.0-2-llvmlinux-small #2
>> [   24.705737] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> [   24.705741]  8800d57ea948 0092 
>> 8800bb3e3aa8
>> [   24.705748]  8149287d 8800bb3e3ad8 810cbf7a
>> 81c51a34
>> [   24.705754]  8800d3095000  0a78
>> 8800bb3e3b18
>> [   24.705761] Call Trace:
>> [   24.705767]  [] dump_stack+0x7d/0xa0
>> [   24.705774]  [] ___might_sleep+0x28a/0x2a0
>> [   24.705779]  [] __might_sleep+0x4f/0xc0
>> [   24.705784]  [] start_flush_work+0x2f/0x290
>> [   

Re: [PATCH v2 0/2] PCI: Add support for PCI Enhanced Allocation "BARs"

[Sean O. Stalley]

On Wed, Sep 23, 2015 at 04:26:56PM -0700, Yinghai Lu wrote:
> On Wed, Sep 23, 2015 at 3:27 PM, Sean O. Stalley  
> wrote:
> > PCI Enhanced Allocation is a new method of allocating MMIO & IO
> > resources for PCI devices & bridges. It can be used instead
> > of the traditional PCI method of using BARs.
> >
> > EA entries are hardware-initialized to a fixed address.
> > Unlike BARs, regions described by EA are cannot be moved.
> > Because of this, only devices which are permanently connected to
> > the PCI bus can use EA. A removable PCI card must not use EA.
> 
> As it is fixed, can you put IORESOURCE_PCI_FIXED in the res->flags?
> 
> Thanks
> 
> Yinghai

IORESOURCE_PCI_FIXED is set in pci_ea_set_flags():
 
+static unsigned long pci_ea_set_flags(struct pci_dev *dev, u8 prop)
+{
+   unsigned long flags = IORESOURCE_PCI_FIXED;
+
+

Which is called in pci_ea_read(), and passed to res->flags (if there aren't any 
errors):

+
+   /* Try to use primary properties, otherwise fall back to 
secondary */
+   flags = pci_ea_set_flags(dev, PCI_EA_PP(dw0));
+   if (!flags)
+   flags = pci_ea_set_flags(dev, PCI_EA_SP(dw0));
+

...

+   res->flags = flags;


-Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] dma: Add Freescale qDMA engine driver support

[Li Yang]

On Fri, Sep 11, 2015 at 12:53 AM, Yuan Yao  wrote:
> Add Freescale Queue Direct Memory Access(qDMA) controller support.
> This module can be found on LS-1 and LS-2 SoCs.
>
> This add the legacy mode support for qDMA.
>
> Signed-off-by: Yuan Yao 
> ---
>  Documentation/devicetree/bindings/dma/fsl-qdma.txt |  43 ++
>  MAINTAINERS|   7 +
>  drivers/dma/Kconfig|  10 +
>  drivers/dma/Makefile   |   1 +
>  drivers/dma/fsl-qdma.c | 521 
> +
>  5 files changed, 582 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/fsl-qdma.txt
>  create mode 100644 drivers/dma/fsl-qdma.c
>
> diff --git a/Documentation/devicetree/bindings/dma/fsl-qdma.txt 
> b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
> new file mode 100644
> index 000..cdae71c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
> @@ -0,0 +1,43 @@
> +* Freescale queue Direct Memory Access Controller(qDMA) Controller
> +
> +  The qDMA controller transfers blocks of data between one source and one or 
> more
> +destinations. The blocks of data transferred can be represented in memory as 
> contiguous
> +or non-contiguous using scatter/gather table(s). Channel virtualization is 
> supported
> +through enqueuing of DMA jobs to, or dequeuing DMA jobs from, different work
> +queues.
> +  Legacy mode is primarily included for software requiring the earlier
> +QorIQ DMA programming model. This mode provides a simple programming
> +model not utilizing the datapath architecture. In legacy mode, DMA
> +operations are directly configured through a set of architectural
> +registers per channel.

Is this binding only covering the legacy mode?  The binding should
describe the whole IP block no matter if we have driver for all the
features.

> +
> +* qDMA Controller
> +Required properties:
> +- compatible :
> +   - "fsl,ls-qdma" for qDMA used similar to that on LS SoC

Compatible need to be specific like "fsl,ls1021a-qdma".  See
http://www.devicetree.org/Device_Tree_Usage.

> +- reg : Specifies base physical address(s) and size of the qDMA registers.
> +   The region is qDMA control register's address and size.
> +- interrupts : A list of interrupt-specifiers, one for each entry in
> +   interrupt-names.
> +- interrupt-names : Should contain:
> +   "qdma-tx" - the  interrupt
> +   "qdma-err" - the error interrupt
> +- channels : Number of channels supported by the controller
> +
> +Optional properties:
> +- big-endian: If present registers and hardware scatter/gather descriptors
> +   of the qDMA are implemented in big endian mode, otherwise in little

Endian
> +   mode.
> +
> +
> +Examples:
> +
> +   qdma: qdma@839 {
> +   compatible = "fsl,ls-qdma";
> +   reg = <0x0 0x838 0x0 0x2>;
> +   interrupts = ,
> +   ;
> +   interrupt-names = "qdma-tx", "qdma-err";
> +   big-endian;
> +   channels = <1>;
> +   };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5772ccf..a4d1b52 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4357,6 +4357,13 @@ L:   linuxppc-...@lists.ozlabs.org
>  S: Maintained
>  F: drivers/dma/fsldma.*
>
> +FREESCALE qDMA DRIVER
> +M: Yuan Yao 
> +L: linux-arm-ker...@lists.infradead.org

Interestingly you listed arm mailing list instead of dmaengine mailing list.

> +S: Maintained
> +F: Documentation/devicetree/bindings/dma/fsl-qdma.txt
> +F: drivers/dma/fsl-qdma.c
> +
>  FREESCALE I2C CPM DRIVER
>  M: Jochen Friedrich 
>  L: linuxppc-...@lists.ozlabs.org
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index b458475..e29e985 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -193,6 +193,16 @@ config FSL_EDMA
>   multiplexing capability for DMA request sources(slot).
>   This module can be found on Freescale Vybrid and LS-1 SoCs.
>
> +config FSL_QDMA
> +   tristate "Freescale qDMA engine support"
> +   select DMA_ENGINE
> +   select DMA_VIRTUAL_CHANNELS
> +   help
> + Support the Freescale qDMA engine with command queue and legacy 
> mode.
> + Channel virtualization is supported through enqueuing of DMA jobs 
> to,
> + or dequeuing DMA jobs from, different work queues.
> + This module can be found on Freescale LS SoCs.

Better to spell out Layerscape

> +
>  config FSL_RAID
>  tristate "Freescale RAID engine Support"
>  depends on FSL_SOC && !ASYNC_TX_ENABLE_CHANNEL_SWITCH
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index 7711a71..8de7526 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_DW_DMAC_CORE) += dw/
>  obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
>  obj-$(CONFIG_FSL_DMA) += fsldma.o
>  

Problems with printk logs and my driver

[Eric Curtin]

Hi Guys,

Just wondering what I am doing wrong. I can't see my logs. I figured
out what driver is used for my keyboard and started adding logging:

[curtine@localhost ~]$ sudo lsusb -v | grep eyboard -B 13
Bus 001 Device 003: ID 04ca:008d Lite-On Technology Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize032
  idVendor   0x04ca Lite-On Technology Corp.
  idProduct  0x008d
  bcdDevice0.39
  iManufacturer   1 Lite-On Technology Corp.
  iProduct2 HP Wireless Keyboard Kit
--
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  1 Keyboard
[curtine@localhost ~]$ sudo lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
|__ Port 4: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 4: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 7: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 7: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 7: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 9: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 9: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M

So, first I added a little logging and then some more, but I can't see
any of it (see patch at bottom of email, I used KERN_EMERG, it's just
temporary logging).

I'm think I'm doing most things right, this is how I compile my code I
wrote a little script (I'm on fedora):

#!/bin/sh

find /boot -name '*4.3*' | xargs sudo rm -rf
find /lib/modules -name '*4.3*' | xargs sudo rm -rf

set -e

cd $HOME/git/linux
# make -j5 oldconfig
printf "completed 1\n"
make -j5 bzImage
printf "completed 2\n"
make -j5 modules
printf "completed 3\n"
sudo make -j5 modules_install
printf "completed 4\n"
sudo make -j5 install

I reboot, load new kernel, blah blah. When I type keys I don't see my
logs in dmesg, I don't see them in /var/log/messages either, I don't
see them in /home/curtine/log.log either when I do a:

sudo killall klogd
sudo /sbin/klogd -f /home/curtine/log.log

What am I doing wrong here?

Also, as regards etiquette on these mailing lists, is it ok to
regularly cc linux-kernel@vger.kernel.org?

diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
index 9a332e6..2038d94 100644
--- a/drivers/hid/usbhid/usbkbd.c
+++ b/drivers/hid/usbhid/usbkbd.c
@@ -112,6 +112,7 @@ struct usb_kbd {

 static void usb_kbd_irq(struct urb *urb)
 {
+   printk(KERN_EMERG "usb_kbd_irq");
struct usb_kbd *kbd = urb->context;
int i;

@@ -166,6 +167,7 @@ resubmit:
 static int usb_kbd_event(struct input_dev *dev, unsigned int type,
 unsigned int code, int value)
 {
+   printk(KERN_EMERG "usb_kbd_event");
unsigned long flags;
struct usb_kbd *kbd = input_get_drvdata(dev);

@@ -202,6 +204,7 @@ static int usb_kbd_event(struct input_dev *dev,
unsigned int type,

 static void usb_kbd_led(struct urb *urb)
 {
+   printk(KERN_EMERG "usb_kbd_led");
unsigned long flags;
struct usb_kbd *kbd = urb->context;

@@ -230,6 +233,7 @@ static void usb_kbd_led(struct urb *urb)

 static int usb_kbd_open(struct input_dev *dev)
 {
+   printk(KERN_EMERG "usb_kbd_open");
struct usb_kbd *kbd = input_get_drvdata(dev);

kbd->irq->dev = kbd->usbdev;
@@ -241,6 +245,7 @@ static int usb_kbd_open(struct input_dev *dev)

 static void usb_kbd_close(struct input_dev *dev)
 {
+   printk(KERN_EMERG "usb_kbd_close");
struct usb_kbd *kbd = input_get_drvdata(dev);

usb_kill_urb(kbd->irq);
@@ -248,6 +253,7 @@ static void usb_kbd_close(struct input_dev *dev)

 static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd)
 {
+   printk(KERN_EMERG "usb_kbd_alloc_mem");
if (!(kbd->irq = usb_alloc_urb(0, GFP_KERNEL)))
return -1;
if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL)))
@@ -264,6 +270,7 @@ static int usb_kbd_alloc_mem(struct usb_device
*dev, struct usb_kbd *kbd)

 static void usb_kbd_free_mem(struct usb_device *dev, struct usb_kbd *kbd)
 {
+   printk(KERN_EMERG "usb_kbd_free_mem");
usb_free_urb(kbd->irq);

PIDs Controller Limit

[Aleksa Sarai]

Does it make sense for the PIDs controller to allow a user to set a
limit of 0? Since we don't cancel attaches, a limit of 0 doesn't
affect anything (nothing stops attaches, and you need to have a
process in the PIDs cgroup in order for fork()s to be affected by the
limit). So I think that attempting to set pid.limit to 0 should return
an -EINVAL.

-- 
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4] mmc: block: Add new ioctl to send multi commands

[Grant Grundler]

On Wed, Sep 23, 2015 at 3:26 PM, Ulf Hansson  wrote:
...
>> Ulf,
>> is the git repo visible publicly?
>
> git://git.linaro.org/people/ulf.hansson/mmc.git

Sorry - my bad : I had looked at mmc.git and saw "2014-10-15" as the
last commit.

Scrolling down to the bottom of the page shows the "next" branch as
active. I'll work from that branch. :)

thanks!
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/15] mm, dax, pmem: introduce __pfn_t

[Williams, Dan J]

[ adding k...@vger.kernel.org ]

On Wed, 2015-09-23 at 09:02 -0700, Dave Hansen wrote:
> On 09/22/2015 09:42 PM, Dan Williams wrote:
> >  /*
> > + * __pfn_t: encapsulates a page-frame number that is optionally backed
> > + * by memmap (struct page).  Whether a __pfn_t has a 'struct page'
> > + * backing is indicated by flags in the low bits of the value;
> > + */
> > +typedef struct {
> > +   unsigned long val;
> > +} __pfn_t;
> > +
> > +/*
> > + * PFN_SG_CHAIN - pfn is a pointer to the next scatterlist entry
> > + * PFN_SG_LAST - pfn references a page and is the last scatterlist entry
> > + * PFN_DEV - pfn is not covered by system memmap by default
> > + * PFN_MAP - pfn has a dynamic page mapping established by a device driver
> > + */
> > +enum {
> > +   PFN_SHIFT = 4,
> > +   PFN_MASK = (1UL << PFN_SHIFT) - 1,
> > +   PFN_SG_CHAIN = (1UL << 0),
> > +   PFN_SG_LAST = (1UL << 1),
> > +   PFN_DEV = (1UL << 2),
> > +   PFN_MAP = (1UL << 3),
> > +};
> 
> Please forgive a little bikeshedding here...
> 
> Why __pfn_t?  Because the KVM code has a pfn_t?  If so, I think we
> should rescue pfn_t from KVM and give them a kvm_pfn_t.

Sounds good, once 0day has a chance to chew on the conversion I'll send
it out.

> I think you should do one of two things:  Make PFN_SHIFT 12 so that a
> physical addr can be stored in a __pfn_t with no work.  Or, use the
> *high* 12 bits of __pfn_t.val.
> 

pfn to pfn_t conversions are more likely, so the high bits sounds
better.

> If you use the high bits, *and* make it store a plain pfn when all the
> bits are 0, then you get a zero-cost pfn<->__pfn_t conversion which will
> hopefully generate the exact same code which is there today.
> 
> The one disadvantage here is that it makes it more likely that somebody
> that's just setting __pfn_t.val=foo will get things subtly wrong
> somehow, but that it will work most of the time.
> 
> Also, about naming...  PFN_SHIFT is pretty awful name for this.  It
> probably needs to be __PFN_T_SOMETHING.  We don't want folks doing
> craziness like:
> 
>   unsigned long phys_addr = pfn << PFN_SHIFT.
> 
> Which *looks* OK.

Heh, true.  It's now PFN_FLAGS_MASK in the reworked patch...


8<---
Subject: mm, dax, pmem: introduce pfn_t

From: Dan Williams 

In preparation for enabling get_user_pages() operations on dax mappings,
introduce a type that encapsulates a page-frame-number that can also be
used to encode other information.  This other information is the
historical "page_link" encoding in a scatterlist, but can also denote
"device memory".  Where "device memory" is a set of pfns that are not
part of the kernel's linear mapping by default, but are accessed via the
same memory controller as ram.  The motivation for this new type is
large capacity persistent memory that optionally has struct page entries
in the 'memmap'.

When a driver, like pmem, has established a devm_memremap_pages()
mapping it needs to communicate to upper layers that the pfn has a page
backing.  This property will be leveraged in a later patch to enable
dax-gup.  For now, update all the ->direct_access() implementations to
communicate whether the returned pfn range is mapped.

Cc: Christoph Hellwig 
Cc: Dave Hansen 
Cc: Andrew Morton 
Cc: Ross Zwisler 
Signed-off-by: Dan Williams 
---
 arch/powerpc/sysdev/axonram.c |8 ++---
 drivers/block/brd.c   |4 +--
 drivers/nvdimm/pmem.c |   27 +
 drivers/s390/block/dcssblk.c  |   10 +++---
 fs/block_dev.c|2 +
 fs/dax.c  |   23 ---
 include/linux/blkdev.h|4 +--
 include/linux/mm.h|   65 +
 include/linux/pfn.h   |9 ++
 9 files changed, 112 insertions(+), 40 deletions(-)

diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index 24ffab2572e8..ec3b072d20cf 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -141,15 +141,13 @@ axon_ram_make_request(struct request_queue *queue, struct 
bio *bio)
  */
 static long
 axon_ram_direct_access(struct block_device *device, sector_t sector,
-  void __pmem **kaddr, unsigned long *pfn)
+  void __pmem **kaddr, pfn_t *pfn)
 {
struct axon_ram_bank *bank = device->bd_disk->private_data;
loff_t offset = (loff_t)sector << AXON_RAM_SECTOR_SHIFT;
-   void *addr = (void *)(bank->ph_addr + offset);
-
-   *kaddr = (void __pmem *)addr;
-   *pfn = virt_to_phys(addr) >> PAGE_SHIFT;
 
+   *kaddr = (void __pmem __force *) bank->io_addr + offset;
+   *pfn = phys_to_pfn_t(bank->ph_addr + offset, PFN_DEV);
return bank->size - offset;
 }
 
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index f645a71ae827..796112e9174b 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -374,7 +374,7 @@ static int brd_rw_page(struct block_device *bdev, sector_t 
sector,
 
 #ifdef CONFIG_BLK_DEV_RAM_DAX
 static long 

Re: [PATCH 1/3] Make /dev/urandom scalable

[Andi Kleen]

> I'd almost say that making the partitioning level configurable at
> build time might be useful.  I can see possible value to being able
> to at least partition down to physical cores (so, shared between
> HyperThreads on Intel processors, and between Compute Module cores
> on AMD processors), as that could potentially help people running
> large numbers of simulations in parallel.

I don't like build time size configurations. It doesn't make sense
for simulations to use urandom. It may make sense to have
some run time tunable, but for now that's too much complexity.
So I'll stay with the simpler per node pool for now.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [c++std-parallel-2008] Re: Compilers and RCU readers: Once more unto the breach!

[Paul E. McKenney]

On Wed, Sep 23, 2015 at 03:30:34PM -0700, Hans Boehm wrote:
> I'd really like this to converge.  It's great that it tries to focus on a
> couple of alternatives.  But I'm not sure they're the right ones.
> 
> I kind of like the 7.9 approach of restricting dependency chain to those
> case in which no sane existing optimization break the dependency anyway.
> The hope would then be that we can restrict future optimizations to not do
> so either without too much cost.  But I'm again very concerned as to
> whether this can be specified acceptably.
> 
> The paper discusses the problem with pointer comparisons that effectively
> allow the compiler to remove a dependency by inferring the identity of a
> pointer.  I don't see how to describe the set of all such cases in a way
> that's comprehensible and acceptable in a standard.
> 
> Consider:
> 
> p = x;
> y = p -> a;
> if (x == well_known_pointer) {
>  foo(well_known_pointer -> a);
>  z = true;
> } else {
>  y = 2;
>  z = false;
> }
> 
> Clearly if z = true, the load of y should have depended on that of x.  But
> this should be transformed to:
> 
> p = x;
> if (x == well_known_pointer) {
>  foo(y = well_known_pointer -> a);
>  z = true;
> } else {
>  y = 2;
>  z = false;
> }
> 
> which no longer has that property.  And I suspect we can construct examples
> in which the conditional is in a subsequent inlined function call, and
> entirely invisible to the programmer.  And there are probably issues with
> compilers using more complicated chains of reasoning to infer that pointers
> must be equal, e.g. because anything else would result in undefined
> behavior.  I'm once again being doubtful that we can pull off anything
> along these lines.

Indeed, the first paragraph of "Equality comparisons" on page 32 says
"This dependency-chain breakage can back-propagate to earlier uses of
the pointer".  The "Narrowing magnitude comparisons" paragraph on that
same page makes this same point for sequences of inequality comparisons
that allow the compiler to deduce the exact value of the pointer.
The comparisons currently in the Linux kernel are against compile-time
initialized constant-value structures, in which case breaking the
dependency chain is OK.

I agree that the compiler could legally introduce a pointer comparison,
as noted in the "Equality comparisons" section, for example, when using
feedback-directed profiling.  Do you see other reasons why the compiler
would do this?

> 7.10 looks like a good direction, but it seems to me that we need to say
> more about handling expression temporaries and function results.
> Presumably at least ordinary expression temporaries implicitly carry
> dependencies?  Thus if both x and y are marked with _Carries_dependency,
> then
> 
> y = ((x ^ x) & 0) * 0
> 
> carries a dependency from x to y?

Yes, but a high-quality implementation would be capable of issuing a
warning in this case.  After all, the developer presumably used
memory_order_consume to gain better performance, but in this case
that added performance is reduced or perhaps even eliminated completely
by the additional code required to maintain the dependency chain.

The reason for carrying the dependency in this case is instead to make
it easier on the people producing tooling.

> I'm leaning again towards something similar to what we attempted to specify
> in the current standard, but restricted to temporaries, maybe function
> locals, and explicitly annotated locations.  This would be some combination
> of 7.10 and maybe 7.5.  It has the down side that it will likely require a
> bunch of explicit attributes (or some kind of C equivalent, though I'm not
> sure storage class works well for function arguments and results).  But it
> should avoid the kill-dependency proliferation required by the current
> standard.  And we could start to actually clean up the remaining problems
> with carries_dependency.

The nice thing about having some sort of marking is that it helps in
generation of good diagnostics.  We also need dependency chains to pass
into and out of functions, and this need will become more acute as
link-time optimization becomes more mainstream, which can remove the
function-call overhead from calls to external functions.  We need the
compiler to know for sure whether or not a given formal parameter or
return value carries a dependency, so some sort of marking is required.
In addition, where structures (as opposed to pointers/references to
structures) are passed into and out of functions, we will very likely
need some way to mark the fields of those structures that are expected
to carry dependencies.  (The Linux kernel tends to avoid this, which
I like, but other projects are likely to make other choices, regardless
of my opinions.)

That marking could be the [[carries_dependency]] attribute (at least
assuming that C adds attributes), a type modifier (which might or might
not go over well in Core), a variable modifier (which I don't 

Re: [PATCH v2 0/2] PCI: Add support for PCI Enhanced Allocation "BARs"

[Yinghai Lu]

On Wed, Sep 23, 2015 at 3:27 PM, Sean O. Stalley  wrote:
> PCI Enhanced Allocation is a new method of allocating MMIO & IO
> resources for PCI devices & bridges. It can be used instead
> of the traditional PCI method of using BARs.
>
> EA entries are hardware-initialized to a fixed address.
> Unlike BARs, regions described by EA are cannot be moved.
> Because of this, only devices which are permanently connected to
> the PCI bus can use EA. A removable PCI card must not use EA.

As it is fixed, can you put IORESOURCE_PCI_FIXED in the res->flags?

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/9] Phy, mdiobus, and netdev struct device fixes

[David Miller]

From: Russell King - ARM Linux 
Date: Tue, 22 Sep 2015 17:17:10 +0100

> This is the second version of the series, with the comments David had
> on the first patch fixed up.  Original series description with updated
> diffstat below.

This needs some build fixes:

drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 
‘xgene_enet_phy_connect’:
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:694:20: error: too few arguments 
to function ‘of_phy_connect’
   pdata->phy_dev = of_phy_connect(ndev, phy_np,
^
In file included from drivers/net/ethernet/apm/xgene/xgene_enet_main.h:31:0,
 from drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:22:
include/linux/of_mdio.h:18:27: note: declared here
 extern struct phy_device *of_phy_connect(struct net_device *dev,
   ^

[website PATCH v3] 4.1 is a longterm kernel.

[Greg Kroah-Hartman]

I'll be maintaining 4.1 for the next two years, proving that after a
decade of doing stable kernels, I still do not know any better.

Signed-off-by: Greg Kroah-Hartman 

---
v3 - use the 4.1 release date, not 4.2, thanks rmk.

v2 - 4.1 was released in 2015, not 2014, thanks to kees for pointing
 that out.

diff --git a/content/releases.rst b/content/releases.rst
index b0dd13311c92..672ae51a5f72 100644
--- a/content/releases.rst
+++ b/content/releases.rst
@@ -40,6 +40,7 @@ Longterm
    ==
 Version  Maintainer   Released Projected EOL
    ==
+4.1  Greg Kroah-Hartman   2015-06-21   Sep, 2017
 3.18 Sasha Levin  2014-12-07   Jan, 2017
 3.14 Greg Kroah-Hartman   2014-03-30   Aug, 2016
 3.12 Jiri Slaby   2013-11-03   2016
diff --git a/pelicanconf.py b/pelicanconf.py
index f0ca020f531b..0bebac28bab3 100644
--- a/pelicanconf.py
+++ b/pelicanconf.py
@@ -24,7 +24,7 @@ import sys
 sys.path.append('./')
 from plugins import releases
 
-LONGTERM_KERNELS = ('3.18', '3.14', '3.12', '3.10', '3.4', '3.2', '2.6.34', 
'2.6.32')
+LONGTERM_KERNELS = ('4.1', '3.18', '3.14', '3.12', '3.10', '3.4', '3.2', 
'2.6.34', '2.6.32')
 EOL_KERNELS = ('2.6.34', '3.0', '3.7', '3.8', '3.9', '3.11', '3.13', '3.15', 
'3.16', '3.17', '3.19', '4.0')
 
 GIT_MAINLINE = 
'/mnt/git-repos/repos/pub/scm/linux/kernel/git/torvalds/linux.git'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[website PATCH v2] 4.1 is a longterm kernel.

[Greg Kroah-Hartman]

I'll be maintaining 4.1 for the next two years, proving that after a
decade of doing stable kernels, I still do not know any better.

Signed-off-by: Greg Kroah-Hartman 

---
v2 - 4.1 was released in 2015, not 2014, thanks to kees for pointing
 that out.

diff --git a/content/releases.rst b/content/releases.rst
index b0dd13311c92..be33e9289cb1 100644
--- a/content/releases.rst
+++ b/content/releases.rst
@@ -40,6 +40,7 @@ Longterm
    ==
 Version  Maintainer   Released Projected EOL
    ==
+4.1  Greg Kroah-Hartman   2015-08-30   Sep, 2017
 3.18 Sasha Levin  2014-12-07   Jan, 2017
 3.14 Greg Kroah-Hartman   2014-03-30   Aug, 2016
 3.12 Jiri Slaby   2013-11-03   2016
diff --git a/pelicanconf.py b/pelicanconf.py
index f0ca020f531b..0bebac28bab3 100644
--- a/pelicanconf.py
+++ b/pelicanconf.py
@@ -24,7 +24,7 @@ import sys
 sys.path.append('./')
 from plugins import releases
 
-LONGTERM_KERNELS = ('3.18', '3.14', '3.12', '3.10', '3.4', '3.2', '2.6.34', 
'2.6.32')
+LONGTERM_KERNELS = ('4.1', '3.18', '3.14', '3.12', '3.10', '3.4', '3.2', 
'2.6.34', '2.6.32')
 EOL_KERNELS = ('2.6.34', '3.0', '3.7', '3.8', '3.9', '3.11', '3.13', '3.15', 
'3.16', '3.17', '3.19', '4.0')
 
 GIT_MAINLINE = 
'/mnt/git-repos/repos/pub/scm/linux/kernel/git/torvalds/linux.git'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v11 3/4] add FPGA manager core

[Josh Cartwright]

On Wed, Sep 23, 2015 at 12:10:13PM -0500, atull wrote:
> On Tue, 22 Sep 2015, Josh Cartwright wrote:
[..]
> > > +struct fpga_manager *of_fpga_mgr_get(struct device_node *node)
> > > +{
> > > + struct fpga_manager *mgr;
> > > + struct device *dev;
> > > +
> > > + if (!node)
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + dev = class_find_device(fpga_mgr_class, NULL, node,
> > > + fpga_mgr_of_node_match);
> > > + if (!dev)
> > > + return ERR_PTR(-ENODEV);
> > > +
> > > + mgr = to_fpga_manager(dev);
> > > + put_device(dev);
> > 
> > Who's ensuring the FPGA manager device's lifetime between _get and _put?
> 
> Well... get_device and put_device are not sufficient?

Sorry if I was too opaque.

You've just put_device()'d the only reference to the device you had
here, so nothing is preventing from the device from being ripped away
while it's being used.

You should remove the put_device() call here, and add a corresponding
put_device() in fpga_mgr_put().

The module refcounting is also a bit strange, as you are
acquiring/releasing a reference to THIS_MODULE, but you also should care
about the lower-level driver's module refcount.

[..]
> > > + dt_label = of_get_property(mgr->dev.of_node, "label", NULL);
> > > + if (dt_label)
> > > + ret = dev_set_name(>dev, "%s", dt_label);
> > > + else
> > > + ret = dev_set_name(>dev, "fpga%d", id);
> > 
> > I'm wondering if an alias {} node is better for this.
> 
> I could look into that.  Is there an example of that you particularly
> like for this?

Look at i2c's usage of the of_alias_*() functions.

  Josh


signature.asc
Description: PGP signature

Re: Multiple potential races on vma->vm_flags

[Davidlohr Bueso]

On Wed, 23 Sep 2015, Kirill A. Shutemov wrote:


On Tue, Sep 22, 2015 at 06:39:52PM -0700, Hugh Dickins wrote:

[...]
I'd rather wait to hear whether this appears to work in practice,
and whether you agree that it should work in theory, before writing
the proper description.  I'd love to lose that down_read_trylock.

You mention how Sasha hit the "Bad page state (mlocked)" back in
November: that was one of the reasons we reverted Davidlohr's
i_mmap_lock_read to i_mmap_lock_write in unmap_mapping_range(),
without understanding why it was needed.  Yes, it would lock out
a concurrent try_to_unmap(), whose setting of PageMlocked was not
sufficiently serialized by the down_read_trylock of mmap_sem.

But I don't remember the other reasons for that revert (and
haven't looked very hard as yet): anyone else remember?


Yeah, I don't think this was ever resolved, but ultimately the patch
got reverted[1] because it exposed issues in the form of bad pages
(shmem, vmsplice) and corrupted vm_flags while in untrack_pfn() causing,
for example, vm_file to dissapear.


I hoped Davidlohr will come back with something after the revert, but it
never happend. I think the reverted patch was responsible for most of
scalability boost from rwsem for i_mmap_lock...


Actually no, the change that got reverted was something we got in very
last minute, just because it made sense and had the blessing of some
key people. The main winner of the series was migration (rmap), which
later Hugh addressed more specifically for unmapped pages:

https://lkml.org/lkml/2014/11/30/349

So I really didn't care about the reverted patch, and therefore was never
on my radar.

[1] https://lkml.org/lkml/2014/12/22/375

Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] blk-cgroup: Declare local symbols static

[Bart Van Assche]

Signed-off-by: Bart Van Assche 
Cc: Tejun Heo 
---
 block/blk-cgroup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 55512dd..46966a3 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -896,7 +896,7 @@ static int blkcg_print_stat(struct seq_file *sf, void *v)
return 0;
 }
 
-struct cftype blkcg_files[] = {
+static struct cftype blkcg_files[] = {
{
.name = "stat",
.seq_show = blkcg_print_stat,
@@ -904,7 +904,7 @@ struct cftype blkcg_files[] = {
{ } /* terminate */
 };
 
-struct cftype blkcg_legacy_files[] = {
+static struct cftype blkcg_legacy_files[] = {
{
.name = "reset_stats",
.write_u64 = blkcg_reset_stats,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 0/6] Add support for additional bq27xxx devices

[Sebastian Reichel]

[updated receiver list]

Hi,

On Wed, Sep 23, 2015 at 01:41:01PM -0500, Andrew F. Davis wrote:
> On 09/23/2015 11:42 AM, Sebastian Reichel wrote:
> >On Tue, Sep 22, 2015 at 02:35:05PM -0500, Andrew F. Davis wrote:
> >>This series adds support for several additional bq27xxx devices and
> >>makes a few related fixes.
> >
> >Thanks, I queued all remaining patches. I wonder if this driver
> >should be converted to regmap. It supports lots of chips now and
> >it might be useful to get register dumps from debugfs.
> >
> 
> I was thinking the same thing, but this driver can also communicate
> over the w1 bus which doesn't look like it has the regmap hooks yet.
> So I never really found a clean way, outside of bringing up regmap
> on w1, to convert this driver over.

Right, I assumed there was regmap support for w1 :(

Evgeniy, are there plans to add 1-wire regmap support?

-- Sebastian


signature.asc
Description: Digital signature