Re: multi-codec support for arizona-ldo1 was Re: System with multiple arizona (wm5102) codecs

[Pavel Machek]

Hi!

> > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> > > > with device that does not have dev_name initialized.
> 
> > > OK, that'll be the problem then - we're not mapping the supply into the
> > > individual child device but rather system wide, probably because that
> > > mapping is being done too early, before we've actually created the
> > > device.
> 
> > Take a look at mfd_add_device(). Yes, we do
> > regulator_bulk_register_supply_alias() before doing
> > platform_device_add().
> 
> Looking at this I suspect we need to re-add the code for matching
> regulators on the actual struct device and do that since this is going
> to be very error prone.

Well, I guess I can test the patches :-).

> > > So if you look at this just templates out some boilerplate regulator API
> > > client code which calls regulator_get() like any other client and then
> > > hooks that regulator into the audio power management.
> 
> > Ok, so SND_SOC_DAPM_REGULATOR_SUPPLY() does not work, because I have
> > two regulators, right? Is there similar macro I can use?
> 
> No?  What would make you say that?

Well.. the fact that in my setup regulators are global (by mistake as
you say?) and it still picks them up without warning?

Plus, I'd expect to see some kind of "struct device" argument to
SND_SOC_DAPM_REGULATOR_SUPPLY(). I'm selecting supply name, but I'm
not selecting on which device...

> Every single sound driver gets this right, none of them assume the name
> is global.  What makes you say that they assume names are global?

Ok, so you are saying that if I fix mfd initialization, sound will
automagically switch from global regulators to device-specific
regulators and things will start working?

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 v9 3/4] drivers: exynos-srom: Add support for bank configuration

[Pavel Fedin]

Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.

Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.

Signed-off-by: Pavel Fedin 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/Kconfig  |  2 +-
 drivers/soc/samsung/Kconfig   |  2 +-
 drivers/soc/samsung/exynos-srom.c | 61 +--
 3 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
-   select EXYNOS_SROM if PM
+   select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
 
 config EXYNOS_SROM
bool
-   depends on ARM && ARCH_EXYNOS && PM
+   depends on ARM && ARCH_EXYNOS
 
 endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c 
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump 
*exynos_srom_alloc_reg_dump(
return rd;
 }
 
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+ struct device_node *np)
+{
+   u32 bank, width, pmc;
+   u32 timing[6];
+   u32 cs, bw;
+
+   if (of_property_read_u32(np, "reg", &bank))
+   return -EINVAL;
+   if (of_property_read_u32(np, "reg-io-width", &width))
+   width = 1;
+   if (of_property_read_u32(np, "samsung,srom-page-mode", &pmc))
+   pmc = 0;
+   if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+  ARRAY_SIZE(timing)))
+   return -EINVAL;
+
+   bank *= 4; /* Convert bank into shift/offset */
+
+   cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+   if (width == 2)
+   cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+   bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+   bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+   __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+   __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+   (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+   (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+   (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+   (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+   (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+   (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+   srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+   return 0;
+}
+
 static int exynos_srom_probe(struct platform_device *pdev)
 {
-   struct device_node *np;
+   struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = &pdev->dev;
+   bool bad_bank_config = false;
 
np = dev->of_node;
if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
-   return 0;
+   for_each_child_of_node(np, child) {
+   if (exynos_srom_configure_bank(srom, child)) {
+   dev_err(dev,
+   "Could not decode bank configuration for %s\n",
+   child->name);
+   bad_bank_config = true;
+   }
+   }
+
+   /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+   if (bad_bank_config)
+   return 0;
+
+   return of_platform_populate(np, NULL, NULL, dev);
 }
 
 static int exynos_srom_remove(struct platform_device *pdev)
-- 
2.4.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 v9 2/4] ARM: dts: Add SROMc to Exynos 5410

[Pavel Fedin]

This machine uses own SoC device tree file, add missing part.

Signed-off-by: Pavel Fedin 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos5410.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
 
+   sromc: sromc@1225 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1225 0x14>;
+   };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
-- 
2.4.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 v9 4/4] ARM: dts: Add Ethernet chip to SMDK5410

[Pavel Fedin]

The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.

Signed-off-by: Pavel Fedin 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++
 arch/arm/boot/dts/exynos5410.dtsi |  6 +
 2 files changed, 47 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts 
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..a731fbe 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "exynos5410.dtsi"
+#include 
 / {
model = "Samsung SMDK5410 board based on EXYNOS5410";
compatible = "samsung,smdk5410", "samsung,exynos5410", 
"samsung,exynos5";
@@ -61,6 +62,46 @@
disable-wp;
 };
 
+&pinctrl_0 {
+   srom_ctl: srom-ctl {
+   samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+  "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+   samsung,pin-function = <2>;
+   samsung,pin-drv = <0>;
+   };
+
+   srom_ebi: srom-ebi {
+   samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+  "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+  "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+  "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+  "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+  "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <3>;
+   samsung,pin-drv = <0>;
+   };
+};
+
+&sromc {
+   pinctrl-names = "default";
+   pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
+
+   ethernet@3,0 {
+   compatible = "smsc,lan9115";
+   reg = <3 0 0x1>;
+   phy-mode = "mii";
+   interrupt-parent = <&gpx0>;
+   interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+   reg-io-width = <2>;
+   smsc,irq-push-pull;
+   smsc,force-internal-phy;
+
+   samsung,srom-page-mode = <1>;
+   samsung,srom-timing = <9 12 1 9 1 1>;
+   };
+};
+
 &uart0 {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
index e2b58f8..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -104,6 +104,12 @@
sromc: sromc@1225 {
compatible = "samsung,exynos-srom";
reg = <0x1225 0x14>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
};
 
pmu_system_controller: system-controller@1004 {
-- 
2.4.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 v9 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Pavel Fedin]

Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.

Also, fix size of SROMc mapping in the example.

Signed-off-by: Pavel Fedin 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: Rob Herring 
---
 .../bindings/arm/samsung/exynos-srom.txt   | 73 +-
 1 file changed, 71 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..e5c18df 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,77 @@ Required properties:
 
 - reg: offset and length of the register set
 
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow device address translation.
+ Address is specified as (bank#, offset).
+
+- #size-cells: Must be set to 1 to allow device size passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0  
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+   the memory mapped for the device. Note that base address will be
+   typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles and has the following
+meaning and valid range:
+Tacp : Page mode access cycle at Page mode (0 - 15)
+Tcah : Address holding time after CSn (0 - 15)
+Tcoh : Chip selection hold on OEn (0 - 15)
+Tacc : Access cycle (0 - 31, the actual time is N + 1)
+Tcos : Chip selection set-up before OEn (0 - 15)
+Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is 
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+  0 - normal (one data)
+  1 - four data
+  If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+   sromc@1257 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1257 0x14>;
+   };
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
sromc@1257 {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0 0 0x0400 0x2   // Bank0
+ 1 0 0x0500 0x2   // Bank1
+ 2 0 0x0600 0x2   // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
-   reg = <0x1257 0x10>;
+   reg = <0x1257 0x14>;
+
+   ethernet@3,0 {
+   compatible = "smsc,lan9115";
+   reg = <3 0 0x1>;   // Bank 3, offset = 0
+   phy-mode = "mii";
+   interrupt-parent = <&gpx0>;
+   interrupts = <5 8>;
+   reg-io-width = <2>;
+   smsc,irq-push-pull;
+   smsc,force-internal-phy;
+
+   samsung,srom-page-mode = <1>;
+   samsung,srom-timing = <9 12 1 9 1 1>;
+   };
};
-- 
2.4.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 v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410

[Pavel Fedin]

This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.

With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.

This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html

Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.

v8 => v9:
- Fixed node suffix in ethernet chip DT node (@3,0 instead of @3)

v7 => v8:
- More fixes to documentation

v6 => v7:
- Fixed stupid error in Tacc description in the documentation

v5 => v6:
- Even more improvements to the documentation, fixed some errors and typos.
- Separated adding bus ranges from generic SROMc support
- Some stuff renamed for even better code readability
- Stylistic cleanups in the DTS (everything in alphabetic order, use named
  constant name for interrupt config byte)

v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
  "reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation

v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
  to cleary specify dependency. If configuration fails, error will be reported
  and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.

v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now

v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation

Pavel Fedin (4):
  Documentation: dt-bindings: Describe SROMc configuration
  ARM: dts: Add SROMc to Exynos 5410
  drivers: exynos-srom: Add support for bank configuration
  ARM: dts: Add Ethernet chip to SMDK5410

 .../bindings/arm/samsung/exynos-srom.txt   | 73 +-
 arch/arm/boot/dts/exynos5410-smdk5410.dts  | 41 
 arch/arm/boot/dts/exynos5410.dtsi  | 11 
 arch/arm/mach-exynos/Kconfig   |  2 +-
 drivers/soc/samsung/Kconfig|  2 +-
 drivers/soc/samsung/exynos-srom.c  | 61 +-
 6 files changed, 184 insertions(+), 6 deletions(-)

-- 
2.4.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] sound: depend on ZONE_DMA

[Takashi Iwai]

On Sun, 15 Nov 2015 11:53:11 +0100,
Boaz Harrosh wrote:
> 
> On 11/12/2015 10:38 PM, Takashi Iwai wrote:
> > On Thu, 12 Nov 2015 21:13:57 +0100,
> > Dan Williams wrote:
> >>
> >> There are several sound drivers that 'select ZONE_DMA'.  This is
> >> backwards as ZONE_DMA is an architecture capability exported to drivers.
> >> Switch the polarity of the dependency to disable these drivers when the
> >> architecture does not support ZONE_DMA.  This was discovered in the
> >> context of testing/enabling devm_memremap_pages() which depends on
> >> ZONE_DEVICE.  ZONE_DEVICE in turn depends on !ZONE_DMA.
> > 
> > Makes sense.  I applied it now, thanks.
> > 
> 
> Please add:
> CC: Stable Tree 

Sorry, too late, already merged.


Takashi
--
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] sh-DWARF: Delete unnecessary checks before the function call "mempool_destroy"

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 16 Nov 2015 08:20:36 +0100

The mempool_destroy() function tests whether its argument is NULL
and then returns immediately. Thus the test around the calls is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/sh/kernel/dwarf.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/sh/kernel/dwarf.c b/arch/sh/kernel/dwarf.c
index 9d209a0..e1d751a 100644
--- a/arch/sh/kernel/dwarf.c
+++ b/arch/sh/kernel/dwarf.c
@@ -1009,10 +1009,8 @@ static void __init dwarf_unwinder_cleanup(void)
rbtree_postorder_for_each_entry_safe(cie, next_cie, &cie_root, node)
kfree(cie);
 
-   if (dwarf_reg_pool)
-   mempool_destroy(dwarf_reg_pool);
-   if (dwarf_frame_pool)
-   mempool_destroy(dwarf_frame_pool);
+   mempool_destroy(dwarf_reg_pool);
+   mempool_destroy(dwarf_frame_pool);
kmem_cache_destroy(dwarf_reg_cachep);
kmem_cache_destroy(dwarf_frame_cachep);
 }
-- 
2.6.2

--
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: [Bugfix] x86/PCI: Fix regression caused by commit 4d6b4e69a245

[Arthur Marsh]

Jiang Liu wrote on 16/11/15 14:57:

From: Liu Jiang 

Commit 4d6b4e69a245 ("x86/PCI/ACPI: Use common interface to support
PCI host bridge") converted x86 to use the common interface
acpi_pci_root_create, but the conversion missed on code piece in
arch/x86/pci/bus_numa.c, which causes regression on some legacy
AMD platforms as reported by Arthur Marsh .
The root causes is that acpi_pci_root_create() fails to insert
host bridge resources into iomem_resource/ioport_resource because
x86_pci_root_bus_resources() has already inserted those resources.
So change x86_pci_root_bus_resources() to not insert resources into
iomem_resource/ioport_resource.

Signed-off-by: Jiang Liu 
Reported-and-tested-by: Arthur Marsh 
Cc: Keith Busch 
Cc: Arthur Marsh 
---
  arch/x86/pci/bus_numa.c |   16 +++-
  drivers/acpi/pci_root.c |7 +++
  2 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/arch/x86/pci/bus_numa.c b/arch/x86/pci/bus_numa.c
index 7bcf06a7cd12..ce53b5b64f51 100644
--- a/arch/x86/pci/bus_numa.c
+++ b/arch/x86/pci/bus_numa.c
@@ -41,27 +41,17 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
   bus);

/* already added by acpi ? */
-   resource_list_for_each_entry(window, resources)
+   resource_list_for_each_entry(window, &info->resources)
if (window->res->flags & IORESOURCE_BUS) {
found = true;
break;
}
-
if (!found)
pci_add_resource(resources, &info->busn);

-   list_for_each_entry(root_res, &info->resources, list) {
-   struct resource *res;
-   struct resource *root;
+   list_for_each_entry(root_res, &info->resources, list)
+   pci_add_resource(resources, &root_res->res);

-   res = &root_res->res;
-   pci_add_resource(resources, res);
-   if (res->flags & IORESOURCE_IO)
-   root = &ioport_resource;
-   else
-   root = &iomem_resource;
-   insert_resource(root, res);
-   }
return;

  default_resources:
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 850d7bf0c873..ae3fe4e64203 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -768,6 +768,13 @@ static void pci_acpi_root_add_resources(struct 
acpi_pci_root_info *info)
else
continue;

+   /*
+* Some legacy x86 host bridge drivers use iomem_resource and
+* ioport_resource as default resource pool, skip it.
+*/
+   if (res == root)
+   continue;
+
conflict = insert_resource_conflict(root, res);
if (conflict) {
dev_info(&info->bridge->dev,



I have not previously seen the patch above and have not been able to 
successfully boot with it applied against the current Linus' git head.


I had booted successfully with a kernel built with the patch below from 
9 November 2015, then removed the patch below and applied the patch 
above from 16 November 2015, and when I booted the resulting kernel, 
received a lock-up:


http://www.users.on.net/~arthur.marsh/20151116611.jpg

I'd be happy to test further patches.

Arthur.

From 02818ba34bfa76d93f2a29c85660da0323b0b457 Mon Sep 17 00:00:00 2001
From: Liu Jiang 
Date: Mon, 9 Nov 2015 13:36:48 +0800
Subject: [PATCH]


Signed-off-by: Liu Jiang 
---
 arch/x86/pci/bus_numa.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/pci/bus_numa.c b/arch/x86/pci/bus_numa.c
index 7bcf06a7cd12..022d83158cdb 100644
--- a/arch/x86/pci/bus_numa.c
+++ b/arch/x86/pci/bus_numa.c
@@ -51,6 +51,8 @@ void x86_pci_root_bus_resources(int bus, struct 
list_head *resources)

pci_add_resource(resources, &info->busn);

list_for_each_entry(root_res, &info->resources, list) {
+   pci_add_resource(resources, &root_res->res);
+#if 0
struct resource *res;
struct resource *root;

@@ -61,6 +63,7 @@ void x86_pci_root_bus_resources(int bus, struct 
list_head *resources)

else
root = &iomem_resource;
insert_resource(root, res);
+#endif
}
return;

--
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] usb: gadget: Add the console support for usb-to-serial port

[Baolin Wang]

It dose not work when we want to use the usb-to-serial port based
on one usb gadget as a console. Thus this patch adds the console
initialization to support this request.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/Kconfig |6 +
 drivers/usb/gadget/function/u_serial.c |  238 
 2 files changed, 244 insertions(+)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 33834aa..be5aab9 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -127,6 +127,12 @@ config USB_GADGET_STORAGE_NUM_BUFFERS
   a module parameter as well.
   If unsure, say 2.
 
+config U_SERIAL_CONSOLE
+   bool "Serial gadget console support"
+   depends on USB_G_SERIAL
+   help
+  It supports the serial gadget can be used as a console.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/function/u_serial.c 
b/drivers/usb/gadget/function/u_serial.c
index f7771d8..4ade527 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "u_serial.h"
 
@@ -79,6 +80,16 @@
  */
 #define QUEUE_SIZE 16
 #define WRITE_BUF_SIZE 8192/* TX only */
+#define GS_BUFFER_SIZE (4096)
+#define GS_CONSOLE_BUF_SIZE(2 * GS_BUFFER_SIZE)
+
+struct gscons_info {
+   struct gs_port  *port;
+   struct tty_driver   *tty_driver;
+   struct work_struct  work;
+   int buf_tail;
+   charbuf[GS_CONSOLE_BUF_SIZE];
+};
 
 /* circular buffer */
 struct gs_buf {
@@ -118,6 +129,7 @@ struct gs_port {
 
/* REVISIT this state ... */
struct usb_cdc_line_coding port_line_coding;/* 8-N-1 etc */
+   struct usb_request  *console_req;
 };
 
 static struct portmaster {
@@ -1054,6 +1066,7 @@ gs_port_alloc(unsigned port_num, struct 
usb_cdc_line_coding *coding)
 
port->port_num = port_num;
port->port_line_coding = *coding;
+   port->console_req = NULL;
 
ports[port_num].port = port;
 out:
@@ -1143,6 +1156,227 @@ err:
 }
 EXPORT_SYMBOL_GPL(gserial_alloc_line);
 
+#ifdef CONFIG_U_SERIAL_CONSOLE
+
+static struct usb_request *gs_request_new(struct usb_ep *ep, int buffer_size)
+{
+   struct usb_request *req = usb_ep_alloc_request(ep, GFP_ATOMIC);
+
+   if (!req)
+   return NULL;
+
+   /* now allocate buffers for the requests */
+   req->buf = kmalloc(buffer_size, GFP_ATOMIC);
+   if (!req->buf) {
+   usb_ep_free_request(ep, req);
+   return NULL;
+   }
+
+   return req;
+}
+
+static void gs_request_free(struct usb_request *req, struct usb_ep *ep)
+{
+   if (req) {
+   kfree(req->buf);
+   usb_ep_free_request(ep, req);
+   }
+}
+
+static void gs_complete_out(struct usb_ep *ep, struct usb_request *req)
+{
+   if (req->status != 0 && req->status != -ECONNRESET)
+   return;
+}
+
+static struct console gserial_cons;
+static int gs_console_connect(void)
+{
+   struct gscons_info *info = gserial_cons.data;
+   int port_num = gserial_cons.index;
+   struct usb_request *req;
+   struct gs_port *port;
+   struct usb_ep *ep;
+
+   if (port_num >= MAX_U_SERIAL_PORTS || port_num < 0) {
+   pr_err("%s: port num [%d] exceeds the range.\n",
+  __func__, port_num);
+   return -ENXIO;
+   }
+
+   port = ports[port_num].port;
+   if (!port) {
+   pr_err("%s: serial line [%d] not allocated.\n",
+  __func__, port_num);
+   return -ENODEV;
+   }
+
+   if (!port->port_usb) {
+   pr_err("%s: no port usb.\n", __func__);
+   return -ENODEV;
+   }
+
+   ep = port->port_usb->in;
+   if (!ep) {
+   pr_err("%s: no usb endpoint.\n", __func__);
+   return -ENXIO;
+   }
+
+   req = port->console_req;
+   if (!req) {
+   req = gs_request_new(ep, GS_BUFFER_SIZE);
+   if (!req) {
+   pr_err("%s: request fail.\n", __func__);
+   return -ENOMEM;
+   }
+   req->complete = gs_complete_out;
+   }
+
+   info->port = port;
+
+   pr_debug("%s: port[%d] console connect!\n", __func__, port_num);
+   return 0;
+}
+
+static void gs_console_work(struct work_struct *work)
+{
+   struct gscons_info *info = container_of(work, struct gscons_info, work);
+   struct gs_port *port = info->port;
+   struct usb_request *req;
+   struct usb_ep *ep;
+   int xfer, ret, count;
+   char *p;
+
+   if (!port || !port->port_usb)
+   return;
+
+   req = port->console_req;
+   ep = port->port_usb->in;
+   if (!req || !ep)
+   return;
+
+   spin_l

Re: [PATCH] IIO: adc: xilinx-xadc-core.c: constify iio_buffer_setup_ops structure

[Jonathan Cameron]

On 15 November 2015 23:11:51 GMT+00:00, Nizam Haider  
wrote:
>structure iio_buffer_setup_ops is never modified, so declare it as
>const.
>
>Signed-off-by: Nizam Haider 
Sometimes it feels like there is something in the air...

Julia Lawal posted a patch for this yesterday.

Thanks

Jonathan
>---
> drivers/iio/adc/xilinx-xadc-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/iio/adc/xilinx-xadc-core.c
>b/drivers/iio/adc/xilinx-xadc-core.c
>index 0370624..c2b5f10 100644
>--- a/drivers/iio/adc/xilinx-xadc-core.c
>+++ b/drivers/iio/adc/xilinx-xadc-core.c
>@@ -803,7 +803,7 @@ err:
>   return ret;
> }
> 
>-static struct iio_buffer_setup_ops xadc_buffer_ops = {
>+static const struct iio_buffer_setup_ops xadc_buffer_ops = {
>   .preenable = &xadc_preenable,
>   .postenable = &iio_triggered_buffer_postenable,
>   .predisable = &iio_triggered_buffer_predisable,

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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 2/7] mm/hugetlb: is_file_hugepages can be boolean

[Yaowei Bai]

This patch makes is_file_hugepages return bool to improve
readability due to this particular function only using either
one or zero as its return value.

This patch also removed the if condition to make is_file_hugepages
return directly.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/hugetlb.h | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 685c262..204c7f5 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -265,20 +265,18 @@ struct file *hugetlb_file_setup(const char *name, size_t 
size, vm_flags_t acct,
struct user_struct **user, int creat_flags,
int page_size_log);
 
-static inline int is_file_hugepages(struct file *file)
+static inline bool is_file_hugepages(struct file *file)
 {
if (file->f_op == &hugetlbfs_file_operations)
-   return 1;
-   if (is_file_shm_hugepages(file))
-   return 1;
+   return true;
 
-   return 0;
+   return is_file_shm_hugepages(file);
 }
 
 
 #else /* !CONFIG_HUGETLBFS */
 
-#define is_file_hugepages(file)0
+#define is_file_hugepages(file)false
 static inline struct file *
 hugetlb_file_setup(const char *name, size_t size, vm_flags_t acctflag,
struct user_struct **user, int creat_flags,
-- 
1.9.1



--
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 0/7] some small improvement

[Yaowei Bai]

This patchset only performs some small improvement to mm. First, make
several functions return bool to improve readability, and then remove
unused is_unevictable_lru function and refactor memmap_valid_within
for simplicity.

No functional change.

Yaowei Bai (7):
  ipc/shm: is_file_shm_hugepages can be boolean
  mm/hugetlb: is_file_hugepages can be boolean
  mm/memblock: memblock_is_memory/reserved can be boolean
  mm/vmscan: page_is_file_cache can be boolean
  mm/lru: remove unused is_unevictable_lru function
  mm/gfp: make gfp_zonelist return directly and bool
  mm/mmzone: refactor memmap_valid_within

 include/linux/gfp.h   |  7 ++-
 include/linux/hugetlb.h   | 10 --
 include/linux/memblock.h  |  4 ++--
 include/linux/mm_inline.h |  6 +++---
 include/linux/mmzone.h| 11 +++
 include/linux/shm.h   |  6 +++---
 ipc/shm.c |  2 +-
 mm/memblock.c |  4 ++--
 mm/mmzone.c   | 10 ++
 9 files changed, 22 insertions(+), 38 deletions(-)

-- 
1.9.1



--
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 3/7] mm/memblock: memblock_is_memory/reserved can be boolean

[Yaowei Bai]

This patch makes memblock_is_memory/reserved return bool to improve
readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/memblock.h | 4 ++--
 mm/memblock.c| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 24daf8f..a25cce94 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -318,9 +318,9 @@ phys_addr_t memblock_mem_size(unsigned long limit_pfn);
 phys_addr_t memblock_start_of_DRAM(void);
 phys_addr_t memblock_end_of_DRAM(void);
 void memblock_enforce_memory_limit(phys_addr_t memory_limit);
-int memblock_is_memory(phys_addr_t addr);
+bool memblock_is_memory(phys_addr_t addr);
 int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
-int memblock_is_reserved(phys_addr_t addr);
+bool memblock_is_reserved(phys_addr_t addr);
 bool memblock_is_region_reserved(phys_addr_t base, phys_addr_t size);
 
 extern void __memblock_dump_all(void);
diff --git a/mm/memblock.c b/mm/memblock.c
index d300f13..1ab7b9e 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1509,12 +1509,12 @@ static int __init_memblock memblock_search(struct 
memblock_type *type, phys_addr
return -1;
 }
 
-int __init memblock_is_reserved(phys_addr_t addr)
+bool __init memblock_is_reserved(phys_addr_t addr)
 {
return memblock_search(&memblock.reserved, addr) != -1;
 }
 
-int __init_memblock memblock_is_memory(phys_addr_t addr)
+bool __init_memblock memblock_is_memory(phys_addr_t addr)
 {
return memblock_search(&memblock.memory, addr) != -1;
 }
-- 
1.9.1



--
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 6/7] mm/gfp: make gfp_zonelist return directly and bool

[Yaowei Bai]

This patch makes gfp_zonelist return bool due to this
particular function only using either one or zero as its return
value.

This patch also makes gfp_zonelist return directly by removing if.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/gfp.h | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 6523109..1da03f5 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -375,12 +375,9 @@ static inline enum zone_type gfp_zone(gfp_t flags)
  * virtual kernel addresses to the allocated page(s).
  */
 
-static inline int gfp_zonelist(gfp_t flags)
+static inline bool gfp_zonelist(gfp_t flags)
 {
-   if (IS_ENABLED(CONFIG_NUMA) && unlikely(flags & __GFP_THISNODE))
-   return 1;
-
-   return 0;
+   return IS_ENABLED(CONFIG_NUMA) && unlikely(flags & __GFP_THISNODE);
 }
 
 /*
-- 
1.9.1



--
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 5/7] mm/lru: remove unused is_unevictable_lru function

[Yaowei Bai]

Since commit a0b8cab3 ("mm: remove lru parameter from __pagevec_lru_add
and remove parts of pagevec API") there's no user of this function anymore,
so remove it.

Signed-off-by: Yaowei Bai 
---
 include/linux/mmzone.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index e23a9e7..9963846 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -195,11 +195,6 @@ static inline int is_active_lru(enum lru_list lru)
return (lru == LRU_ACTIVE_ANON || lru == LRU_ACTIVE_FILE);
 }
 
-static inline int is_unevictable_lru(enum lru_list lru)
-{
-   return (lru == LRU_UNEVICTABLE);
-}
-
 struct zone_reclaim_stat {
/*
 * The pageout code in vmscan.c keeps track of how many of the
-- 
1.9.1



--
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 4/7] mm/vmscan: page_is_file_cache can be boolean

[Yaowei Bai]

This patch makes page_is_file_cache return bool to improve
readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mm_inline.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h
index cf55945..af73135 100644
--- a/include/linux/mm_inline.h
+++ b/include/linux/mm_inline.h
@@ -8,8 +8,8 @@
  * page_is_file_cache - should the page be on a file LRU or anon LRU?
  * @page: the page to test
  *
- * Returns 1 if @page is page cache page backed by a regular filesystem,
- * or 0 if @page is anonymous, tmpfs or otherwise ram or swap backed.
+ * Returns true if @page is page cache page backed by a regular filesystem,
+ * or false if @page is anonymous, tmpfs or otherwise ram or swap backed.
  * Used by functions that manipulate the LRU lists, to sort a page
  * onto the right LRU list.
  *
@@ -17,7 +17,7 @@
  * needs to survive until the page is last deleted from the LRU, which
  * could be as far down as __page_cache_release.
  */
-static inline int page_is_file_cache(struct page *page)
+static inline bool page_is_file_cache(struct page *page)
 {
return !PageSwapBacked(page);
 }
-- 
1.9.1



--
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 7/7] mm/mmzone: refactor memmap_valid_within

[Yaowei Bai]

This patch makes memmap_valid_within return bool due to this
particular function only using either one or zero as its return
value.

This patch also refactors memmap_valid_within for simplicity.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mmzone.h |  6 +++---
 mm/mmzone.c| 10 ++
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 9963846..b9b59bb8 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1202,13 +1202,13 @@ unsigned long __init node_memmap_size_bytes(int, 
unsigned long, unsigned long);
  * the zone and PFN linkages are still valid. This is expensive, but walkers
  * of the full memmap are extremely rare.
  */
-int memmap_valid_within(unsigned long pfn,
+bool memmap_valid_within(unsigned long pfn,
struct page *page, struct zone *zone);
 #else
-static inline int memmap_valid_within(unsigned long pfn,
+static inline bool memmap_valid_within(unsigned long pfn,
struct page *page, struct zone *zone)
 {
-   return 1;
+   return true;
 }
 #endif /* CONFIG_ARCH_HAS_HOLES_MEMORYMODEL */
 
diff --git a/mm/mmzone.c b/mm/mmzone.c
index 7d87ebb..de0824e 100644
--- a/mm/mmzone.c
+++ b/mm/mmzone.c
@@ -72,16 +72,10 @@ struct zoneref *next_zones_zonelist(struct zoneref *z,
 }
 
 #ifdef CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
-int memmap_valid_within(unsigned long pfn,
+bool memmap_valid_within(unsigned long pfn,
struct page *page, struct zone *zone)
 {
-   if (page_to_pfn(page) != pfn)
-   return 0;
-
-   if (page_zone(page) != zone)
-   return 0;
-
-   return 1;
+   return page_to_pfn(page) == pfn && page_zone(page) == zone;
 }
 #endif /* CONFIG_ARCH_HAS_HOLES_MEMORYMODEL */
 
-- 
1.9.1



--
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/7] ipc/shm: is_file_shm_hugepages can be boolean

[Yaowei Bai]

This patch makes is_file_shm_hugepages return bool to improve
readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/shm.h | 6 +++---
 ipc/shm.c   | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/shm.h b/include/linux/shm.h
index 6fb8016..04e8818 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
@@ -52,7 +52,7 @@ struct sysv_shm {
 
 long do_shmat(int shmid, char __user *shmaddr, int shmflg, unsigned long *addr,
  unsigned long shmlba);
-int is_file_shm_hugepages(struct file *file);
+bool is_file_shm_hugepages(struct file *file);
 void exit_shm(struct task_struct *task);
 #define shm_init_task(task) INIT_LIST_HEAD(&(task)->sysvshm.shm_clist)
 #else
@@ -66,9 +66,9 @@ static inline long do_shmat(int shmid, char __user *shmaddr,
 {
return -ENOSYS;
 }
-static inline int is_file_shm_hugepages(struct file *file)
+static inline bool is_file_shm_hugepages(struct file *file)
 {
-   return 0;
+   return false;
 }
 static inline void exit_shm(struct task_struct *task)
 {
diff --git a/ipc/shm.c b/ipc/shm.c
index 4178727..ed3027d 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -459,7 +459,7 @@ static const struct file_operations 
shm_file_operations_huge = {
.fallocate  = shm_fallocate,
 };
 
-int is_file_shm_hugepages(struct file *file)
+bool is_file_shm_hugepages(struct file *file)
 {
return file->f_op == &shm_file_operations_huge;
 }
-- 
1.9.1



--
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 v6 4/4] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown 
Signed-off-by: Baolin Wang 
Acked-by: Lee Jones 
Acked-by: Charles Keepax 
Acked-by: Peter Chen 
Acked-by: Sebastian Reichel 
---
 drivers/power/wm831x_power.c |   69 ++
 include/linux/mfd/wm831x/pdata.h |3 ++
 2 files changed, 72 insertions(+)

diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index 7082301..043f1f4 100644
--- a/drivers/power/wm831x_power.c
+++ b/drivers/power/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_charger *usb_charger;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %dmA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   if (wm831x_pdata && wm831x_pdata->usb_gadget) {
+   power->usb_charger =
+   usb_charger_find_by_name(wm831x_pdata->usb_gadget);
+   if (IS_ERR(power->usb_charger)) {
+   ret = PTR_ERR(power->usb_charger);
+   dev_err(&pdev->dev,
+   "Failed to find USB gadget: %d\n", ret);
+   goto err_bat_irq;
+   }
+
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+
+   ret = usb_charger_register_notify(power->usb_charger,
+ &power->usb_notify);
+   if (ret != 0) {
+   dev_err(&pdev->dev,
+   "Failed to register notifier: %d\n", ret);
+   goto err_usb_charger;
+   }
+   }
+
return ret;
 
+err_usb_charger:
+   /* put_device on charger */
 err_bat_irq:
--i;
for (; i >= 0; i--) {
@@ -637,6 +700,12 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_charger) {
+   usb_charger_unregister_notify(wm831x_power->usb_charger,
+ &wm831x_power->usb_notify);
+   /* Free charger */
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
diff --git a/include/linux/mfd/wm831x/pdata.h b/include/linux/mfd/wm831x/pdata.h
index dcc9631..5af8399 100644
--- a/include/linux/mfd/wm831x/pdata.h
+++ b/include/linux/mfd/wm831x/pdata.h
@@ -126,6 +126,9 @@ struct wm831x_pdata {
/** The driver should initiate a power off sequence during shutdown */
bool soft_shutdown;
 
+   /** dev_name of USB charger gadget to integrate with */
+   const char *usb_gadget;
+
int irq_base;
int gpio_base;
int gpio_defaults[WM831X_GPIO_NUM];
-- 
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 r

[PATCH v6 3/4] gadget: Integrate with the usb gadget supporting for usb charger

[Baolin Wang]

When the usb gadget supporting for usb charger is ready, the usb charger
should get the type by the 'get_charger_type' callback which is implemented
by the usb gadget operations, and get the usb charger pointer from struct
'usb_gadget'.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/charger.c |   43 --
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
index 921f8e2..5d3cda6 100644
--- a/drivers/usb/gadget/charger.c
+++ b/drivers/usb/gadget/charger.c
@@ -183,7 +183,11 @@ int usb_charger_unregister_notify(struct usb_charger 
*uchger,
 enum usb_charger_type
 usb_charger_detect_type(struct usb_charger *uchger)
 {
-   if (uchger->psy) {
+   if (uchger->gadget && uchger->gadget->ops
+   && uchger->gadget->ops->get_charger_type) {
+   uchger->type =
+   uchger->gadget->ops->get_charger_type(uchger->gadget);
+   } else if (uchger->psy) {
union power_supply_propval val;
 
power_supply_get_property(uchger->psy,
@@ -385,6 +389,29 @@ usb_charger_plug_by_extcon(struct notifier_block *nb,
 int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
   unsigned long state)
 {
+   struct usb_charger *uchger = gadget->charger;
+   enum usb_charger_state uchger_state;
+
+   if (!uchger)
+   return -EINVAL;
+
+   /* Report event to power to setting the current limitation
+* for this usb charger when one usb charger state is changed
+* with detecting by usb gadget state.
+*/
+   if (uchger->old_gadget_state != state) {
+   uchger->old_gadget_state = state;
+
+   if (state >= USB_STATE_ATTACHED)
+   uchger_state = USB_CHARGER_PRESENT;
+   else if (state == USB_STATE_NOTATTACHED)
+   uchger_state = USB_CHARGER_REMOVE;
+   else
+   uchger_state = USB_CHARGER_DEFAULT;
+
+   usb_charger_notify_others(uchger, uchger_state);
+   }
+
return 0;
 }
 
@@ -540,6 +567,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
 
/* register a notifier on a usb gadget device */
uchger->gadget = ugadget;
+   ugadget->charger = uchger;
uchger->old_gadget_state = ugadget->state;
 
/* register a new usb charger */
@@ -560,7 +588,18 @@ fail:
 
 int usb_charger_exit(struct usb_gadget *ugadget)
 {
-   return 0;
+   struct usb_charger *uchger = ugadget->charger;
+
+   if (!uchger)
+   return -EINVAL;
+
+   if (uchger->extcon_dev)
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_USB, &uchger->extcon_nb.nb);
+
+   ida_simple_remove(&usb_charger_ida, uchger->id);
+
+   return usb_charger_unregister(uchger);
 }
 
 static int __init usb_charger_sysfs_init(void)
-- 
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/

[PATCH v6 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.

The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.

The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state. It also supplies the
notification mechanism to userspace When the usb charger state is changed.

Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.

This patch doesn't yet integrate with the gadget code, so some functions
which rely on the 'gadget' are not completed, that will be implemented
in the following patches.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/Kconfig  |7 +
 drivers/usb/gadget/Makefile |1 +
 drivers/usb/gadget/charger.c|  574 +++
 include/linux/usb/usb_charger.h |  162 +++
 4 files changed, 744 insertions(+)
 create mode 100644 drivers/usb/gadget/charger.c
 create mode 100644 include/linux/usb/usb_charger.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 33834aa..8d69dca 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -127,6 +127,13 @@ config USB_GADGET_STORAGE_NUM_BUFFERS
   a module parameter as well.
   If unsure, say 2.
 
+config USB_CHARGER
+   bool "USB charger support"
+   help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 598a67d..1e421c1 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -10,3 +10,4 @@ libcomposite-y:= usbstring.o config.o 
epautoconf.o
 libcomposite-y += composite.o functions.o configfs.o u_f.o
 
 obj-$(CONFIG_USB_GADGET)   += udc/ function/ legacy/
+obj-$(CONFIG_USB_CHARGER)  += charger.o
diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
new file mode 100644
index 000..921f8e2
--- /dev/null
+++ b/drivers/usb/gadget/charger.c
@@ -0,0 +1,574 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_CUR_PROTECT(50)
+#define DEFAULT_SDP_CUR_LIMIT  (500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_DCP_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_CDP_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_ACA_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define UCHGER_STATE_LENGTH(50)
+
+static DEFINE_IDA(usb_charger_ida);
+static struct bus_type usb_charger_subsys = {
+   .name   = "usb-charger",
+   .dev_name   = "usb-charger",
+};
+
+static struct usb_charger *dev_to_uchger(struct device *udev)
+{
+   return container_of(udev, struct usb_charger, dev);
+}
+
+static ssize_t cur_limit_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return scnprintf(buf, PAGE_SIZE, "%d %d %d %d\n",
+uchger->cur_limit.sdp_cur_limit,
+uchger->cur_limit.dcp_cur_limit,
+uchger->cur_limit.cdp_cur_limit,
+uchger->cur_limit.aca_cur_limit);
+}
+
+static ssize_t cur_limit_store(struct device *dev,
+  struct device_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   struct usb_charger_cur_limit cur;
+   int ret;
+
+   ret = sscanf(buf, "%d %d %d %d",
+&cur.sdp_cur_limit, &cur.dcp_cur_limit,
+&cur.cdp_cur_limit, &cur.aca_cur_limit);
+   if (ret == 0)
+   return -EINVAL;
+
+   ret = usb_charger_set_cur_limit(uchger, &cur);
+   if (ret < 0)
+   return ret;
+
+   return count;
+}
+static DEVICE_ATTR_RW(cur_limit);
+
+static stru

[PATCH v6 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not behave
as they should. Thus provide a standard framework for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger,
which is pending testing. Moreover there may be other potential users will use
it in future.

Changes since v5:
 - Remove the notifier chain things from the gadget and introduce one callback
 function to report to the usb charger when the gadget state is changed.
 - Flesh out the port type detection which combines the USB negotiation and
 PMICs detection.
 - Supply the notification mechanism to userspace when charger state is changed.
 - Integrate with the vbus staff in the gadget API.

Baolin Wang (4):
  gadget: Introduce the usb charger framework
  gadget: Support for the usb charger framework
  gadget: Integrate with the usb gadget supporting for usb charger
  power: wm831x_power: Support USB charger current limit management

 drivers/power/wm831x_power.c  |   69 +
 drivers/usb/gadget/Kconfig|7 +
 drivers/usb/gadget/Makefile   |1 +
 drivers/usb/gadget/charger.c  |  613 +
 drivers/usb/gadget/udc/udc-core.c |   11 +
 include/linux/mfd/wm831x/pdata.h  |3 +
 include/linux/usb/gadget.h|   10 +
 include/linux/usb/usb_charger.h   |  162 ++
 8 files changed, 876 insertions(+)
 create mode 100644 drivers/usb/gadget/charger.c
 create mode 100644 include/linux/usb/usb_charger.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/

[PATCH v6 2/4] gadget: Support for the usb charger framework

[Baolin Wang]

For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.

It will report to the usb charger when the gadget state is changed,
then the usb charger can do the power things.

Introduce a callback 'get_charger_type' which will implemented by
user for usb gadget operations to get the usb charger type.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/udc/udc-core.c |   11 +++
 include/linux/usb/gadget.h|   10 ++
 2 files changed, 21 insertions(+)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index f660afb..2727f01 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * struct usb_udc - describes one usb device controller
@@ -226,6 +227,9 @@ static void usb_gadget_state_work(struct work_struct *work)
struct usb_gadget *gadget = work_to_gadget(work);
struct usb_udc *udc = gadget->udc;
 
+   /* when the gadget state is changed, then report to USB charger */
+   usb_charger_plug_by_gadget(gadget, gadget->state);
+
if (udc)
sysfs_notify(&udc->dev.kobj, NULL, "state");
 }
@@ -405,8 +409,14 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
 
mutex_unlock(&udc_lock);
 
+   ret = usb_charger_init(gadget);
+   if (ret)
+   goto err5;
+
return 0;
 
+err5:
+   device_del(&udc->dev);
 err4:
list_del(&udc->list);
mutex_unlock(&udc_lock);
@@ -481,6 +491,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
flush_work(&gadget->work);
device_unregister(&udc->dev);
+   usb_charger_exit(gadget);
device_unregister(&gadget->dev);
 }
 EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3d583a1..b8a6d38 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct usb_ep;
 
@@ -560,6 +561,7 @@ struct usb_gadget_ops {
struct usb_ep *(*match_ep)(struct usb_gadget *,
struct usb_endpoint_descriptor *,
struct usb_ss_ep_comp_descriptor *);
+   enum usb_charger_type (*get_charger_type)(struct usb_gadget *);
 };
 
 /**
@@ -632,6 +634,8 @@ struct usb_gadget {
unsignedout_epnum;
unsignedin_epnum;
struct usb_otg_caps *otg_caps;
+   /* negotiate the power with the usb charger */
+   struct usb_charger  *charger;
 
unsignedsg_supported:1;
unsignedis_otg:1;
@@ -836,10 +840,16 @@ static inline int usb_gadget_vbus_connect(struct 
usb_gadget *gadget)
  * reporting how much power the device may consume.  For example, this
  * could affect how quickly batteries are recharged.
  *
+ * It will also notify the USB charger how much power the device may
+ * consume if there is a USB charger linking with the gadget.
+ *
  * Returns zero on success, else negative errno.
  */
 static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
 {
+   if (gadget->charger)
+   usb_charger_set_cur_limit_by_type(gadget->charger, mA);
+
if (!gadget->ops->vbus_draw)
return -EOPNOTSUPP;
return gadget->ops->vbus_draw(gadget, mA);
-- 
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: Re: [PATCH v2] mmc/sdhci-acpi: enable sdhci-acpi device to suspend/resume asynchronously

[Fu, Zhonghui]

On 9/21/2015 5:32 PM, Andy Shevchenko wrote:
> On Mon, 2015-09-21 at 14:51 +0800, Fu, Zhonghui wrote:
>> Now, PM core supports asynchronous suspend/resume mode for devices
>> during system suspend/resume, and the power state transition of one
>> device may be completed in separate kernel thread. PM core ensures
>> all power state transition timing dependency between devices. This
>> patch enables sdhci-acpi device to suspend/resume asynchronously.
>> This will take advantage of multicore and improve system
>> suspend/resume speed.
>>
> It would be nice I think to put here statistics you collected as well.

Sorry for replying this mail after long leave.

I have added the test result into commit message and sent the latest version of 
this patch:"[PATCH v3] mmc/sdhci-acpi: enable sdhci-acpi device to 
suspend/resume asynchronously".


Thanks,
Zhonghui

>
>> Signed-off-by: Zhonghui Fu 
>> ---
>> Changes in v2:
>> - Amend commit message.
>>
>>  drivers/mmc/host/sdhci-acpi.c |2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci
>> -acpi.c
>> index 22d929f..67e6263 100644
>> --- a/drivers/mmc/host/sdhci-acpi.c
>> +++ b/drivers/mmc/host/sdhci-acpi.c
>> @@ -379,6 +379,8 @@ static int sdhci_acpi_probe(struct 
>> platform_device *pdev)
>>  pm_runtime_enable(dev);
>>  }
>>  
>> +device_enable_async_suspend(dev);
>> +
>>  return 0;
>>  
>>  err_free:
>> -- 1.7.1
>>

--
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] mmc/sdhci-acpi: enable sdhci-acpi device to suspend/resume asynchronously

[Fu, Zhonghui]

Please review the latest version: "[PATCH v3] mmc/sdhci-acpi: enable sdhci-acpi 
device to suspend/resume asynchronously"


Thanks,
Zhonghui

On 9/21/2015 2:51 PM, Fu, Zhonghui wrote:
> Now, PM core supports asynchronous suspend/resume mode for devices
> during system suspend/resume, and the power state transition of one
> device may be completed in separate kernel thread. PM core ensures
> all power state transition timing dependency between devices. This
> patch enables sdhci-acpi device to suspend/resume asynchronously.
> This will take advantage of multicore and improve system
> suspend/resume speed.
>
> Signed-off-by: Zhonghui Fu 
> ---
> Changes in v2:
> - Amend commit message.
>
>  drivers/mmc/host/sdhci-acpi.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
> index 22d929f..67e6263 100644
> --- a/drivers/mmc/host/sdhci-acpi.c
> +++ b/drivers/mmc/host/sdhci-acpi.c
> @@ -379,6 +379,8 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
>   pm_runtime_enable(dev);
>   }
>  
> + device_enable_async_suspend(dev);
> +
>   return 0;
>  
>  err_free:
> -- 1.7.1
>

--
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 v3] mmc/sdhci-acpi: enable sdhci-acpi device to suspend/resume asynchronously

[Fu, Zhonghui]

Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables sdhci-acpi device to suspend/resume asynchronously.
This will take advantage of multicore and improve system
suspend/resume speed. After enabling the sdhci-acpi devices and all
their child devices to suspend/resume asynchronously on ASUS T100TA,
the system suspend-to-idle time is reduced from 1645ms to 1096ms, and
the system resume time is reduced from 940ms to 908ms.

Signed-off-by: Zhonghui Fu 
---
Changes in v3:
- Add test result in commit message

 drivers/mmc/host/sdhci-acpi.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index f6047fc..3d27f2d 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -388,6 +388,8 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
pm_runtime_enable(dev);
}
 
+   device_enable_async_suspend(dev);
+
return 0;
 
 err_free:
-- 1.7.1

--
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: Add lowest-priority support for vt-d posted-interrupts

[Wu, Feng]

Hi Paolo,

Any comments about this patch, thanks in advance!

Thanks,
Feng

> -Original Message-
> From: Wu, Feng
> Sent: Monday, November 9, 2015 10:47 AM
> To: pbonz...@redhat.com
> Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; Wu, Feng
> 
> Subject: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-
> interrupts
> 
> Use vector-hashing to handle lowest-priority interrupts for
> posted-interrupts. As an example, modern Intel CPUs use this
> method to handle lowest-priority interrupts.
> 
> Signed-off-by: Feng Wu 
> ---
>  arch/x86/include/asm/kvm_host.h |  2 ++
>  arch/x86/kvm/irq_comm.c | 52
> +
>  arch/x86/kvm/lapic.c| 57
> +
>  arch/x86/kvm/lapic.h|  2 ++
>  arch/x86/kvm/vmx.c  | 14 --
>  5 files changed, 125 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h
> b/arch/x86/include/asm/kvm_host.h
> index 9265196..e225106 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1258,6 +1258,8 @@ bool kvm_vcpu_is_bsp(struct kvm_vcpu *vcpu);
> 
>  bool kvm_intr_is_single_vcpu(struct kvm *kvm, struct kvm_lapic_irq *irq,
>struct kvm_vcpu **dest_vcpu);
> +struct kvm_vcpu *kvm_intr_vector_hashing_dest(struct kvm *kvm,
> +   struct kvm_lapic_irq *irq);
> 
>  void kvm_set_msi_irq(struct kvm_kernel_irq_routing_entry *e,
>struct kvm_lapic_irq *irq);
> diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
> index 84b96d3..8156e45 100644
> --- a/arch/x86/kvm/irq_comm.c
> +++ b/arch/x86/kvm/irq_comm.c
> @@ -266,6 +266,58 @@ out:
>   return r;
>  }
> 
> +/*
> + * This routine handles lowest-priority interrupts using vector-hashing
> + * mechanism. As an example, modern Intel CPUs use this method to
> handle
> + * lowest-priority interrupts.
> + *
> + * Here is the details about the vector-hashing mechanism:
> + * 1. For lowest-priority interrupts, store all the possible destination
> + *vCPUs in an array.
> + * 2. Use "guest vector % max number of destination vCPUs" to find the
> right
> + *destination vCPU in the array for the lowest-priority interrupt.
> + */
> +struct kvm_vcpu *kvm_intr_vector_hashing_dest(struct kvm *kvm,
> +   struct kvm_lapic_irq *irq)
> +
> +{
> + unsigned long
> dest_vcpu_bitmap[BITS_TO_LONGS(KVM_MAX_VCPUS)];
> + unsigned int dest_vcpus = 0;
> + struct kvm_vcpu *vcpu;
> + unsigned int i, mod, idx = 0;
> +
> + vcpu = kvm_intr_vector_hashing_dest_fast(kvm, irq);
> + if (vcpu)
> + return vcpu;
> +
> + memset(dest_vcpu_bitmap, 0, sizeof(dest_vcpu_bitmap));
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + if (!kvm_apic_present(vcpu))
> + continue;
> +
> + if (!kvm_apic_match_dest(vcpu, NULL, irq->shorthand,
> + irq->dest_id, irq->dest_mode))
> + continue;
> +
> + __set_bit(vcpu->vcpu_id, dest_vcpu_bitmap);
> + dest_vcpus++;
> + }
> +
> + if (dest_vcpus == 0)
> + return NULL;
> +
> + mod = irq->vector % dest_vcpus;
> +
> + for (i = 0; i <= mod; i++) {
> + idx = find_next_bit(dest_vcpu_bitmap, KVM_MAX_VCPUS,
> idx) + 1;
> + BUG_ON(idx >= KVM_MAX_VCPUS);
> + }
> +
> + return kvm_get_vcpu(kvm, idx - 1);
> +}
> +EXPORT_SYMBOL_GPL(kvm_intr_vector_hashing_dest);
> +
>  bool kvm_intr_is_single_vcpu(struct kvm *kvm, struct kvm_lapic_irq *irq,
>struct kvm_vcpu **dest_vcpu)
>  {
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index ecd4ea1..4937aa4 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -816,6 +816,63 @@ out:
>   return ret;
>  }
> 
> +struct kvm_vcpu *kvm_intr_vector_hashing_dest_fast(struct kvm *kvm,
> +struct kvm_lapic_irq *irq)
> +{
> + struct kvm_apic_map *map;
> + struct kvm_vcpu *vcpu = NULL;
> +
> + if (irq->shorthand)
> + return NULL;
> +
> + rcu_read_lock();
> + map = rcu_dereference(kvm->arch.apic_map);
> +
> + if (!map)
> + goto out;
> +
> + if ((irq->dest_mode != APIC_DEST_PHYSICAL) &&
> + kvm_lowest_prio_delivery(irq)) {
> + u16 cid;
> + int i, idx = 0;
> + unsigned long bitmap = 1;
> + unsigned int mod, dest_vcpus = 0;
> + struct kvm_lapic **dst = NULL;
> +
> +
> + if (!kvm_apic_logical_map_valid(map))
> + goto out;
> +
> + apic_logical_id(map, irq->dest_id, &cid, (u16 *)&bitmap);
> +
> + if (cid >= ARRAY_SIZE(map->logical_map))
> + goto out;
> +
> + dst = map->logical_ma

Re: linux-next: manual merge of the target-merge tree with the scsi tree

[Nicholas A. Bellinger]

On Mon, 2015-11-16 at 13:03 +1100, Stephen Rothwell wrote:
> Hi Nicholas,
> 
> On Fri, 13 Nov 2015 12:06:05 +1100 Stephen Rothwell  
> wrote:
> >
> > Today's linux-next merge of the target-merge tree got conflicts in
> > several files.  It looks like a newer version of all the commits in the
> > target-merge tree has been applied to the scsi tree, so I just dropped
> > the target-merge tree for today.  You might like to tidy it up with
> > respect to the current scsi tree.
> 
> In particular this series from the target-merge tree:
> 
> 8edb1554f7c2 mpt3sas: Fix unprotected list lookup in v4.3-rc0 changes
> db9e2f795915 mpt3sas: Refcount fw_events and fix unsafe list usage
> 9dab68af61d6 mpt3sas: Refcount sas_device objects and fix unsafe list usage
> 0f9b74e50d06 mpt2sas: Refcount fw_events and fix unsafe list usage
> 2757abdc85c1 mpt2sas: Refcount sas_device objects and fix unsafe list usage
> 
> conflicts with this series (now from Linus' tree):
> 
> abc01f7d54da mpt3sas: Bump mpt3sas driver version to 09.102.00.00
> c84b06a48c4d mpt3sas: Single driver module which supports both SAS 2.0 & SAS 
> 3.0 HBAs
> d0c627afb7a6 mpt2sas, mpt3sas: Update the driver versions
> 08c4d550c579 mpt3sas: setpci reset kernel oops fix
> 989e43c7ec34 mpt3sas: Added OEM Gen2 PnP ID branding names
> 146b16c8071f mpt3sas: Refcount fw_events and fix unsafe list usage
> d1cb5e495e53 mpt3sas: Refcount sas_device objects and fix unsafe list usage
> 422630955ea3 mpt3sas: sysfs attribute to report Backup Rail Monitor Status
> 7786ab6aff9c mpt3sas: Ported WarpDrive product SSS6200 support
> 16e179bda58f mpt3sas: fix for driver fails EEH, recovery from injected pci 
> bus error
> 42081173c74e mpt3sas: Manage MSI-X vectors according to HBA device type
> 45506049c7ab mpt3sas: Don't send PHYDISK_HIDDEN RAID action request on SAS2 
> HBAs
> 471ef9d4e498 mpt3sas: Build MPI SGL LIST on GEN2 HBAs and IEEE SGL LIST on 
> GEN3 HBAs
> af0094115b08 mpt2sas, mpt3sas: Remove SCSI_MPTXSAS_LOGGING entry from Kconfig
> d357e84d65df mpt3sas: Define 'hba_mpi_version_belonged' IOC variable
> 09ec55ed74eb mpt2sas: Remove .c and .h files from mpt2sas driver
> 78f97c8f612d mpt2sas: Move Gen2 HBA's device registration to a separate file
> 7497392a1193 mpt3sas: Move Gen3 HBA's device registration to a separate file
> 8a7e4c24e08f mpt3sas: Added mpt2sas driver definitions
> 
> So it would be nice if you could tidy up the target-merge tree.

Original WIP mpt3sas patches dropped.

Thanks Stephen.

--
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: [RT PATCH] sched: rt: fix two possible deadlocks in push_irq_work_func

[yjin]

Hi Thomas,

Thanks for your help.
I have tested your patch this morning, it seems well.
Could you tell me when will you send your formal patch? And please CC me 
when you send your patch.


Regards!
Yanjiang

On 2015年11月15日 19:05, Thomas Gleixner wrote:

On Sun, 15 Nov 2015, Thomas Gleixner wrote:

Which does not happen on MIPS as it uses the generic
arch_irq_work_has_interrupt() implementation which returns 'false'.

So the proper fix is to ensure that the irq safe irq work actually
happens in interrupt context. Patch below.

Thanks,

tglx

8<-

diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
index 0e427a9997f3..2543aab05daa 100644
--- a/include/linux/irq_work.h
+++ b/include/linux/irq_work.h
@@ -52,4 +52,10 @@ static inline bool irq_work_needs_cpu(void) { return false; }
  static inline void irq_work_run(void) { }
  #endif
  
+#if defined(CONFIG_IRQ_WORK) && defined(CONFIG_PREEMPT_RT_FULL)

+void irq_work_tick_soft(void);
+#else
+static inline void irq_work_tick_soft(void) { }
+#endif
+
  #endif /* _LINUX_IRQ_WORK_H */
diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 5a0f4525139c..58cf46638ca0 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -200,8 +200,17 @@ void irq_work_tick(void)
  
  	if (!llist_empty(raised) && !arch_irq_work_has_interrupt())

irq_work_run_list(raised);
+
+   if (!IS_ENABLED(CONFIG_PREEMPT_RT_FULL))
+   irq_work_run_list(this_cpu_ptr(&lazy_list));
+}
+
+#if defined(CONFIG_IRQ_WORK) && defined(CONFIG_PREEMPT_RT_FULL)
+void irq_work_tick_soft(void)
+{
irq_work_run_list(this_cpu_ptr(&lazy_list));
  }
+#endif
  
  /*

   * Synchronize against the irq_work @entry, ensures the entry is not
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index adb1d82d6631..c68ba873da3c 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1455,7 +1455,7 @@ void update_process_times(int user_tick)
scheduler_tick();
run_local_timers();
rcu_check_callbacks(user_tick);
-#if defined(CONFIG_IRQ_WORK) && !defined(CONFIG_PREEMPT_RT_FULL)
+#if defined(CONFIG_IRQ_WORK)
if (in_irq())
irq_work_tick();
  #endif
@@ -1471,9 +1471,7 @@ static void run_timer_softirq(struct softirq_action *h)
  
  	hrtimer_run_pending();
  
-#if defined(CONFIG_IRQ_WORK) && defined(CONFIG_PREEMPT_RT_FULL)

-   irq_work_tick();
-#endif
+   irq_work_tick_soft();
  
  	if (time_after_eq(jiffies, base->timer_jiffies))

__run_timers(base);


--
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 4.4-rc1

[Guenter Roeck]

On Sun, Nov 15, 2015 at 05:24:37PM -0800, Linus Torvalds wrote:
> So it's Sunday, two weeks has passed, and so 4.4-rc1 is out there and
> the merge window is closed.
> 
> As usual, the full shortlog is much too big to post, so appended is
> the usual shortlog of just my merges, which just shows who I did pulls
> from, with a very short comment on each merge.
> 
> Just looking at the patch itself, things look fairly normal at a high
> level, possibly a bit more driver-heavy than usual with about 75% of
> the patch being drivers, and 10% being architecture updates. The
> remaining 15% is documentation, filesystem, core networking (as
> opposed to network drivers), tooling and some core infrastructure.
> 
> The driver changes are all over, although staging, networking and GPU
> drivers stand out (and those three areas account for over half of the
> driver changes - roughly 40% of the whole patch).
> 
> On the architecture side, ARM (when counting both 32-bit and 64-bit)
> accounts for about half the changes, with x86, powerpc, mips, chris
> and s390 accounting for the other half.
> 
> Go out and test.
> 
Build results:
total: 144 pass: 143 fail: 1
Failed builds:
cris:allnoconfig

Qemu test results:
total: 95 pass: 94 fail: 1
Failed tests:
cris:crisv32_defconfig

cris:allnoconfig fails to build because of section mismatches, which is now
fatal with allnoconfig builds (since 47490ec141b9, "modpost: Add flag -E for
making section mismatches fatal"). Proposed patches to fix the problems are
available at [1] and [2]. Other allnoconfig builds (untested by me) probably
fail as well, though.

The cris:crisv32_defconfig qemu test crashes because of interference between
commit 7d8c70d8048c ("serial: mctrl-gpio: rename init function") and commit
7b9c5162c182 ("serial: etraxfs-uart: use mctrl_gpio helpers for handling
modem signals"). A proposed patch is available at [3].

Further details are available at http://server.roeck-us.net:8010/builders.

Guenter

---
[1] https://patchwork.kernel.org/patch/7592471/
[2] https://patchwork.kernel.org/patch/7592461/
[3] https://patchwork.kernel.org/patch/7533041/
--
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 4.4-rc1

[Ken Moffat]

On Sun, Nov 15, 2015 at 05:24:37PM -0800, Linus Torvalds wrote:
> So it's Sunday, two weeks has passed, and so 4.4-rc1 is out there and
> the merge window is closed.
> 
[...]
> 
> Go out and test.
> 
> Linus
> 
After what I picked up during the 4.3 cycle, I tried using 'xzcat |
git apply -' but I got the following (after messages about spaces
before tabs) :

error: cannot apply binary patch to
'drivers/staging/ft1000/ft1000-pcmcia/ft1000.img' without full index
line
error: drivers/staging/ft1000/ft1000-pcmcia/ft1000.img: patch does
not apply
error: cannot apply binary patch to
'drivers/staging/ft1000/ft1000-usb/ft3000.img' without full index
line
error: drivers/staging/ft1000/ft1000-usb/ft3000.img: patch does not
apply

That is with git-2.6.3.

Interestingly, using 'xzcat | patch -p1' seems to apply fine, or at
least it doesn't seem to report any errors, and I have no particular
interest in ft1000 so I'll go with that.

It boots ok on this machine (AMD K10, with my current config), but
that doesn't say a lot, so I'll shut up.

ĸen
-- 
This email was written using 100% recycled letters.
--
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] mtd: spi-nor: fsl-quadspi: add big-endian support

[Yao Yuan]

Hi Brian Norris,

Thanks for your information and the documents shared by you.
It's very helpful for me to understand the regmap.

But I think if we use:
static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
*addr) {
   if (q->big_endian)
   iowrite32be(val, addr);
   else
   iowrite32(val, addr);
 }
It looks like easier to read, use and change.
Is it?

And David Woodhouse, Xu Han, Mark Brown
is there any other comments from you?

Thank.

On Thu, Nov 12, 2015 3:04 AM Brian Norris wrote:
> On Fri, Oct 30, 2015 at 09:49:41AM +, Yao Yuan wrote:
> > Hi Fabio Estevam,
> >
> > Thanks for your suggestion.
> > We have an internal discussions for that.
> >
> > We think that:
> > According to the initial commit message of regmap, it is targeting
> > non-memory mapped buses. (regmap: Add generic non-memory mapped
> > register access API)  But in the imx2_wdt driver, it is used for
> > memory-mapped register space.  So it seems that using such a complex
> > framework just to deal with endian is an over-kill.
> 
> It is definitely useful for non-MMIO cases, but it's certainly not exclusive 
> too it.
> 
> > when it is not necessary to enable the clock every time we access the 
> > register.
> 
> You don't have to give it a clock. Just pass a NULL clk_id.
> 
> > We don't think it is obvious to us how to use it for handling
> > endianness, especially not the way imx2_wdt uses regmap.
> > __regmap_init_mmio_clk() calls regmap_mmio_gen_context() which errors
> > out if reg_format_endian is not REGMAP_ENDIAN_DEFAULT or
> > REGMAP_ENDIAN_NATIVE, and elsewhere regmap-mmio.c It seems only
> > little-endian accessors.
> >
> > Although it is possible to add the endianness support in the
> > regmap_mmio driver, we don't see too much value in using it especially
> 
> It already has DT endianness configuration support. See __regmap_init(),
> which reconfigures the endianness according to regmap_get_val_endian().
> So you don't need to do anything but just try it... I exepct it'll work just 
> fine.
> 
> > So we think:
> > static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
> > *addr) {
> >   if (q->big_endian)
> >   iowrite32be(val, addr);
> >   else
> >   iowrite32(val, addr);
> > }
> > This way is an easier, more effective solution to do the endian issue.
> >
> > How about your think?
> 
> I think there's at least one more advantage: you get pretty good tracing
> support for free. For debugging, for example, you can turn on regmap tracing
> to see all the register reads and writes done in your driver, all within the 
> nice
> tracefs event infrastructure. I'm sure there are other advantages too, but not
> all are applicable here.
> 
> Anyway, I do agree on the complexity argument. It's not actually that complex
> to use (the imx2_wdt.c example really does show you everything you need to
> know), it is a bit more complex to sort through all its features and 
> understand
> exactly what it's doing. But I'm confident it has everything you need.
> 
> So, make your choice. I just wanted to educate on several points, so that your
> decision is not just driven by lack of correct information.
> 
> For more information, a quick google search shows a few links, but no official
> docs:
> 
> http://elinux.org/images/a/a3/Regmap-
> _The_Power_of_Subsystems_and_Abstractions.pdf
> https://lwn.net/Articles/451789/
> 
> Brian
> 
> > Best Regards,
> > Yuan Yao
> >
> > On Sat, Oct 24, 2015 at 11:47 PM, Fabio Estevam 
> wrote:
> > > On Fri, Oct 23, 2015 at 5:53 AM, Yuan Yao  wrote:
> > >
> > > > +static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem
> > > > +*addr) {
> > > > +   if (q->big_endian)
> > > > +   iowrite32be(val, addr);
> > > > +   else
> > > > +   iowrite32(val, addr); }
> > >
> > > I suggest you to implement regmap support for this driver instead.
> > >
> > > Take a look at drivers/watchdog/imx2_wdt.c for a reference.
> > >
> > > Then you only need to pass 'big-endian' as a property for the qspi
> > > in the .dtsi file and regmap core will take care of endianness.
--
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/

[Bugfix] x86/PCI: Fix regression caused by commit 4d6b4e69a245

[Jiang Liu]

From: Liu Jiang 

Commit 4d6b4e69a245 ("x86/PCI/ACPI: Use common interface to support
PCI host bridge") converted x86 to use the common interface
acpi_pci_root_create, but the conversion missed on code piece in
arch/x86/pci/bus_numa.c, which causes regression on some legacy
AMD platforms as reported by Arthur Marsh .
The root causes is that acpi_pci_root_create() fails to insert
host bridge resources into iomem_resource/ioport_resource because
x86_pci_root_bus_resources() has already inserted those resources.
So change x86_pci_root_bus_resources() to not insert resources into
iomem_resource/ioport_resource.

Signed-off-by: Jiang Liu 
Reported-and-tested-by: Arthur Marsh 
Cc: Keith Busch 
Cc: Arthur Marsh 
---
 arch/x86/pci/bus_numa.c |   16 +++-
 drivers/acpi/pci_root.c |7 +++
 2 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/arch/x86/pci/bus_numa.c b/arch/x86/pci/bus_numa.c
index 7bcf06a7cd12..ce53b5b64f51 100644
--- a/arch/x86/pci/bus_numa.c
+++ b/arch/x86/pci/bus_numa.c
@@ -41,27 +41,17 @@ void x86_pci_root_bus_resources(int bus, struct list_head 
*resources)
   bus);
 
/* already added by acpi ? */
-   resource_list_for_each_entry(window, resources)
+   resource_list_for_each_entry(window, &info->resources)
if (window->res->flags & IORESOURCE_BUS) {
found = true;
break;
}
-
if (!found)
pci_add_resource(resources, &info->busn);
 
-   list_for_each_entry(root_res, &info->resources, list) {
-   struct resource *res;
-   struct resource *root;
+   list_for_each_entry(root_res, &info->resources, list)
+   pci_add_resource(resources, &root_res->res);
 
-   res = &root_res->res;
-   pci_add_resource(resources, res);
-   if (res->flags & IORESOURCE_IO)
-   root = &ioport_resource;
-   else
-   root = &iomem_resource;
-   insert_resource(root, res);
-   }
return;
 
 default_resources:
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 850d7bf0c873..ae3fe4e64203 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -768,6 +768,13 @@ static void pci_acpi_root_add_resources(struct 
acpi_pci_root_info *info)
else
continue;
 
+   /*
+* Some legacy x86 host bridge drivers use iomem_resource and
+* ioport_resource as default resource pool, skip it.
+*/
+   if (res == root)
+   continue;
+
conflict = insert_resource_conflict(root, res);
if (conflict) {
dev_info(&info->bridge->dev,
-- 
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/

Re: [4.4 regression] 46a7fd8a : pcnet32: use pci_set_dma_mask insted of pci_dma_supported

[Don Fry]

On Wed, 2015-11-11 at 12:58 +0100, Christoph Hellwig wrote:
> Can you try the patch below?

Acked-by: Don Fry 
-- 
Since pci_set_dma_mask() returns the opposite of pci_dma_supported(),
this fix is required for proper operation.  The original patch in
October was faulty.
> 
> diff --git a/drivers/net/ethernet/amd/pcnet32.c 
> b/drivers/net/ethernet/amd/pcnet32.c
> index e2afabf..7ccebae 100644
> --- a/drivers/net/ethernet/amd/pcnet32.c
> +++ b/drivers/net/ethernet/amd/pcnet32.c
> @@ -1500,10 +1500,11 @@ pcnet32_probe_pci(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   return -ENODEV;
>   }
>  
> - if (!pci_set_dma_mask(pdev, PCNET32_DMA_MASK)) {
> + err = pci_set_dma_mask(pdev, PCNET32_DMA_MASK);
> + if (err) {
>   if (pcnet32_debug & NETIF_MSG_PROBE)
>   pr_err("architecture does not support 32bit PCI 
> busmaster DMA\n");
> - return -ENODEV;
> + return err;
>   }
>   if (!request_region(ioaddr, PCNET32_TOTAL_SIZE, "pcnet32_probe_pci")) {
>   if (pcnet32_debug & NETIF_MSG_PROBE)


--
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] mtd: spi-nor: fsl-quadspi: add big-endian support

[Brian Norris]

On Mon, Nov 16, 2015 at 04:08:39AM +, Yao Yuan wrote:
> It looks like easier to read, use and change.
> Is it?

It looks fine either way, IMO.

> And David Woodhouse, Xu Han, Mark Brown
> is there any other comments from you?

FYI, Mark Brown doesn't really have much to do with this. Though he
maintains the SPI subsystem (and regmap, as a matter of fact), SPI *NOR*
code is only a user of the SPI subsystem (and, potentially, regmap). I
hear he's not interested in reviewing MTD work, given the volume of
email he already receives.

Regards,
Brian
--
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/

warning: (SERIAL_8250_MID) selects HSU_DMA_PCI which has unmet direct dependencies (DMADEVICES && ..)

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   8005c49d9aea74d382f474ce11afbbc7d7130bec
commit: ec2f1b67f526ee0b314103f7bf2846289fa0f435 dmaengine: hsu: make the UART 
driver in control of selecting this driver
date:   4 weeks ago
config: i386-randconfig-sb0-11161113 (attached as .config)
reproduce:
git checkout ec2f1b67f526ee0b314103f7bf2846289fa0f435
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

warning: (SERIAL_8250_MID) selects HSU_DMA_PCI which has unmet direct 
dependencies (DMADEVICES && HSU_DMA && PCI)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v2] dmaengine: ioatdma: constify dca_ops structures

[Vinod Koul]

On Fri, Nov 13, 2015 at 12:46:00PM +0100, Julia Lawall wrote:
> The dca_ops structure is never modified, so declare it as const.
> 
> Done with the help of Coccinelle.

Applied, thanks

-- 
~Vinod
--
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] dma: at_hdmac: use %pad format string for dma_addr_t

[Vinod Koul]

On Thu, Nov 12, 2015 at 03:18:22PM +0100, Arnd Bergmann wrote:
> dma_addr_t may be defined as 32 or 64 bit depending on configuration,
> so it cannot be printed using the normal format strings, as
> gcc correctly warns:
> 
> drivers/dma/at_hdmac.c: In function 'atc_prep_dma_interleaved':
> drivers/dma/at_hdmac.c:731:28: warning: format '%x' expects argument of type 
> 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned 
> int}' [-Wformat=]
> 
> This changes the format strings to use the special "%pad" format
> string that prints a dma_addr_t, and changes the arguments so we
> pass the address by reference as required.
> 

Applied, thanks

-- 
~Vinod
--
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] dma: at_xdmac: use %pad format string for dma_addr_t

[Vinod Koul]

On Thu, Nov 12, 2015 at 03:16:53PM +0100, Arnd Bergmann wrote:
> dma_addr_t may be defined as 32 or 64 bit depending on configuration,
> so it cannot be printed using the normal format strings, as
> gcc correctly warns:
> 
> drivers/dma/at_xdmac.c: In function 'at_xdmac_interleaved_queue_desc':
> drivers/dma/at_xdmac.c:922:51: warning: format '%x' expects argument of type 
> 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned 
> int}' [-Wformat=]
> 
> This changes the format strings to use the special "%pad" format
> string that prints a dma_addr_t, and changes the arguments so we
> pass the address by reference as required.

Applied, thanks

-- 
~Vinod
--
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/1] dmaengine: imx-sdma: remove __init annotation on sdma_event_remap

[Vinod Koul]

On Wed, Nov 11, 2015 at 05:20:49PM +0800, Jason Liu wrote:
> The sdma_probe function will call sdma_event_remap, but sdma_event_remap
> marked with the __init annotation which make the kbuild complains as the
> following log:
> 
> WARNING: drivers/dma/built-in.o(.text+0x56fc): Section mismatch in reference
> from the function sdma_probe() to the function .init.text:sdma_event_remap()
> The function sdma_probe() references
> the function __init sdma_event_remap().
> This is often because sdma_probe lacks a __init
> annotation or the annotation of sdma_event_remap is wrong.
> 
> Remove the __init annotation on sdma_event_remap to kill this build warning

Applied, thanks

-- 
~Vinod
--
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 PATCH 4/7] pinctrl: sunxi: remove redundant "depends on RESET_CONTROLLER"

[Masahiro Yamada]

Hi Linus

2015-11-05 22:40 GMT+09:00 Linus Walleij :
> On Thu, Nov 5, 2015 at 12:15 PM, Masahiro Yamada
>  wrote:
>
>> ARCH_SUNXI selects RESET_CONTROLLER.
>> The dependency "depends on RESET_CONTROLLER" is already met.
>>
>> Signed-off-by: Masahiro Yamada 
>
> NACK, this pin controller needs that as dependency, I don't worry
> that it's overspecified.
>
> They both do this:
> #include 
>
> And the object should specify its dependencies, not rely on them
> being implicitly available.
>
> The dep is there for human readers too, not just machines. And to
> them, this is helpful information.

How strict we should follow this rule?

Many drivers depend on OF, but do they all have "depends on OF"?





-- 
Best Regards
Masahiro Yamada
--
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/

Darlehen anbieten

[OCEAN FINANCE]

Guten Tag,
 
 Wir sind OCEAN FINANCE Darlehen Unternehmen geben Kredite per Post 
Anzeige. Wir bieten verschiedene Arten von Krediten (kurz- und langfristige 
Darlehen, persönliche Darlehen, Kredite an Unternehmen etc.) um 3% Zins. Wir 
geben Kredite an Menschen in Not nicht unabhängig von ihrem Standort, 
Geschlecht, Familienstand, Bildung, Job-Status, sondern muss eine rechtliche 
Mittel der Rückzahlung haben. Unsere Darlehen bewegen sich zwischen 5.000,00 zu 
10.000.000,00 US-Dollar oder Euro oder Pfund mit einer Laufzeit von maximal 20 
Jahren. Wenn Sie an weiteren Informationen interessiert sind, füllen Sie bitte 
das folgende Formular aus und schicken Sie es an unsere E-Mail-Adresse: 
oceanfina...@hotmail.com

Bitte füllen Sie:

Name:

Adresse:

Alter:

Geschlecht:

Kontakt-Telefon:

Beruf:

Monatliches Einkommen:

Die erforderliche Höhe des Darlehens:

Laufzeit des Darlehens:

Der Zweck des Darlehens:

Land:

ZIP Code:


"Wir zeigen Ihnen, einen besseren Weg, um Ihre finanzielle Freiheit"

Mit freundlichen Grüßen,

Alexander Balanoff
--
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 06/10] KVM: x86: MMU: Consolidate WARN_ON/BUG_ON checks for reverse-mapped sptes

[Takuya Yoshikawa]

On 2015/11/14 7:08, Marcelo Tosatti wrote:

On Thu, Nov 12, 2015 at 08:53:43PM +0900, Takuya Yoshikawa wrote:

At some call sites of rmap_get_first() and rmap_get_next(), BUG_ON is
placed right after the call to detect unrelated sptes which must not be
found in the reverse-mapping list.

Move this check in rmap_get_first/next() so that all call sites, not
just the users of the for_each_rmap_spte() macro, will be checked the
same way.  In addition, change the BUG_ON to WARN_ON since killing the
whole host is the last thing that KVM should try.


It should be a BUG_ON, if KVM continues it will corrupt (more) memory.


In the sense that we cannot predict what kind of corruption it will
cause, I agree with you.

But if it can only corrupt that guest's memory, it is a bit sad to
kill unrelated guests, and host, too.  Anyway, since we cannot say
for sure what a possible bug can cause, I agree with you now.

Thanks,
  Takuya

--
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] toshiba_bluetooth: Add missing newline in toshiba_bluetooth_present function

[Azael Avalos]

This patch simply adds a missing newline in the error string printed
by the toshiba_bluetooth_present function.

This is just a cosmetic change, no functionality was changed.

Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_bluetooth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/toshiba_bluetooth.c 
b/drivers/platform/x86/toshiba_bluetooth.c
index c5e4508..5db495d 100644
--- a/drivers/platform/x86/toshiba_bluetooth.c
+++ b/drivers/platform/x86/toshiba_bluetooth.c
@@ -78,7 +78,7 @@ static int toshiba_bluetooth_present(acpi_handle handle)
 */
result = acpi_evaluate_integer(handle, "_STA", NULL, &bt_present);
if (ACPI_FAILURE(result)) {
-   pr_err("ACPI call to query Bluetooth presence failed");
+   pr_err("ACPI call to query Bluetooth presence failed\n");
return -ENXIO;
} else if (!bt_present) {
pr_info("Bluetooth device not present\n");
-- 
2.6.2

--
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/1] toshiba_acpi: Propagate the hotkey value via genetlink

[Azael Avalos]

The driver uses genetlink to inform userspace of events generated by
the system, but the data passed is always zero as there is no data to
pass, except for the hotkey event.

This patch propagates the hotkey value via genetlink so userspace can
make use of it.

Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index 7f71f8f..63c231a 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -2966,7 +2966,8 @@ static void toshiba_acpi_notify(struct acpi_device 
*acpi_dev, u32 event)
 
acpi_bus_generate_netlink_event(acpi_dev->pnp.device_class,
dev_name(&acpi_dev->dev),
-   event, 0);
+   event, (event == 0x80) ?
+   dev->last_key_event : 0);
 }
 
 #ifdef CONFIG_PM_SLEEP
-- 
2.6.2

--
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] toshiba_acpi: Fix blank screen at boot if transflective backlight is supported

[Azael Avalos]

If transflective backlight is supported and the brightness is zero
(lowest brightness level), the set_lcd_brightness function will activate
the transflective backlight, making the LCD appear to be turned off.

This patch fixes the issue by incrementing the brightness level, and
by doing so, avoiding the activation of the tranflective backlight.

Cc:  # 4.3+
Reported-and-tested-by: Fabian Koester 
Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index 2ca3f91..b6a7dc9 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -2634,6 +2634,14 @@ static int toshiba_acpi_setup_backlight(struct 
toshiba_acpi_dev *dev)
brightness = __get_lcd_brightness(dev);
if (brightness < 0)
return 0;
+   /*
+* If transflective backlight is supported and the brightness is zero
+* (lowest brightness level), the set_lcd_brightness function will
+* activate the transflective backlight, making the LCD appear to be
+* turned off, simply increment the brightness level to avoid that.
+*/
+   if (dev->tr_backlight_supported && brightness == 0)
+   brightness++;
ret = set_lcd_brightness(dev, brightness);
if (ret) {
pr_debug("Backlight method is read-only, disabling backlight 
support\n");
-- 
2.6.2

--
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] dmaengine: edma: fix build without CONFIG_OF

[Vinod Koul]

On Tue, Nov 03, 2015 at 03:00:57PM +0100, Arnd Bergmann wrote:
> During the edma rework, a build error was introduced for the
> case that CONFIG_OF is disabled:
> 
> drivers/built-in.o: In function `edma_tc_set_pm_state':
> :(.text+0x43bf0): undefined reference to `of_find_device_by_node'
> 
> As the edma_tc_set_pm_state() function does nothing in case
> we are running without OF, this adds an IS_ENABLED() check
> that turns the function into an empty stub then and avoids the
> link error.

Applied, thanks

-- 
~Vinod
--
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] dmaengine: of_dma: Correct return code for of_dma_request_slave_channel in case !CONFIG_OF

[Vinod Koul]

On Tue, Nov 03, 2015 at 12:28:10PM +0200, Peter Ujfalusi wrote:
> of_dma_request_slave_channel should return either pointer for valid
> dma_chan or ERR_PTR() error code, NULL is not expected to be returned.

Applied, thanks

-- 
~Vinod
--
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 0/2] toshiba_acpi: Add WWAN support

[Azael Avalos]

These two patches add WWAN support to the driver, the first adds the actual
support functions and the second adds RFKill handler functions to set the
device status according to the killswitch.

Azael Avalos (2):
  toshiba_acpi: Add support for WWAN devices
  toshiba_acpi: Add WWAN RFKill support

 drivers/platform/x86/toshiba_acpi.c | 166 
 1 file changed, 166 insertions(+)

-- 
2.6.2

--
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/2] toshiba_acpi: Add support for WWAN devices

[Azael Avalos]

Toshiba laptops with WWAN devices installed cannot use the device unless
it is attached and powered, similar to how Toshiba Bluetooth devices
work.

This patch adds support to WWAN devices, introducing three functions,
one to query the overall status of the wireless devices (RFKill, WLAN,
BT, WWAN), the second queries WWAN support, and finally the third
(de)activates the device.

Signed-off-by: Fabian Koester 
Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 92 +
 1 file changed, 92 insertions(+)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index c013029..60d1ad9 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -114,6 +114,7 @@ MODULE_LICENSE("GPL");
 #define HCI_VIDEO_OUT  0x001c
 #define HCI_HOTKEY_EVENT   0x001e
 #define HCI_LCD_BRIGHTNESS 0x002a
+#define HCI_WIRELESS   0x0056
 #define HCI_ACCELEROMETER  0x006d
 #define HCI_KBD_ILLUMINATION   0x0095
 #define HCI_ECO_MODE   0x0097
@@ -148,6 +149,10 @@ MODULE_LICENSE("GPL");
 #define SCI_KBD_MODE_ON0x8
 #define SCI_KBD_MODE_OFF   0x10
 #define SCI_KBD_TIME_MAX   0x3c001a
+#define HCI_WIRELESS_STATUS0x1
+#define HCI_WIRELESS_WWAN  0x3
+#define HCI_WIRELESS_WWAN_STATUS   0x2000
+#define HCI_WIRELESS_WWAN_POWER0x4000
 #define SCI_USB_CHARGE_MODE_MASK   0xff
 #define SCI_USB_CHARGE_DISABLED0x00
 #define SCI_USB_CHARGE_ALTERNATE   0x09
@@ -197,12 +202,14 @@ struct toshiba_acpi_dev {
unsigned int kbd_function_keys_supported:1;
unsigned int panel_power_on_supported:1;
unsigned int usb_three_supported:1;
+   unsigned int wwan_supported:1;
unsigned int sysfs_created:1;
unsigned int special_functions;
 
bool kbd_led_registered;
bool illumination_led_registered;
bool eco_led_registered;
+   bool killswitch;
 };
 
 static struct toshiba_acpi_dev *toshiba_acpi;
@@ -1085,6 +1092,87 @@ static int toshiba_hotkey_event_type_get(struct 
toshiba_acpi_dev *dev,
return -EIO;
 }
 
+/* Wireless status (RFKill, WLAN, BT, WWAN) */
+static int toshiba_wireless_status(struct toshiba_acpi_dev *dev)
+{
+   u32 in[TCI_WORDS] = { HCI_GET, HCI_WIRELESS, 0, 0, 0, 0 };
+   u32 out[TCI_WORDS];
+   acpi_status status;
+
+   in[3] = HCI_WIRELESS_STATUS;
+   status = tci_raw(dev, in, out);
+   if (ACPI_FAILURE(status)) {
+   pr_err("ACPI call to get Wireless status failed\n");
+   } else if (out[0] == TOS_NOT_SUPPORTED) {
+   return -ENODEV;
+   } else if (out[0] == TOS_SUCCESS) {
+   dev->killswitch =
+   (out[2] & HCI_WIRELESS_STATUS) ? true : false;
+   return 0;
+   }
+
+   return -EIO;
+}
+
+/* WWAN */
+static void toshiba_wwan_available(struct toshiba_acpi_dev *dev)
+{
+   u32 in[TCI_WORDS] = { HCI_GET, HCI_WIRELESS, 0, 0, 0, 0 };
+   u32 out[TCI_WORDS];
+   acpi_status status;
+
+   dev->wwan_supported = 0;
+
+   /*
+* WWAN support can be queried by setting the in[3] value to
+* HCI_WIRELESS_WWAN (0x03).
+*
+* If supported, out[0] contains TOS_SUCCESS and out[2] contains
+* HCI_WIRELESS_WWAN_STATUS (0x2000).
+*
+* If not supported, out[0] contains TOS_INPUT_DATA_ERROR (0x8300)
+* or TOS_NOT_SUPPORTED (0x8000).
+*/
+   in[3] = HCI_WIRELESS_WWAN;
+   status = tci_raw(dev, in, out);
+   if (ACPI_FAILURE(status))
+   pr_err("ACPI call to get WWAN status failed\n");
+   else if (out[0] == TOS_SUCCESS && out[2] == HCI_WIRELESS_WWAN_STATUS)
+   dev->wwan_supported = 1;
+}
+
+static int toshiba_wwan_set(struct toshiba_acpi_dev *dev, u32 state)
+{
+   u32 in[TCI_WORDS] = { HCI_SET, HCI_WIRELESS, state, 0, 0, 0 };
+   u32 out[TCI_WORDS];
+   acpi_status status;
+
+   in[3] = HCI_WIRELESS_WWAN_STATUS;
+   status = tci_raw(dev, in, out);
+   if (ACPI_FAILURE(status)) {
+   pr_err("ACPI call to set WWAN status failed\n");
+   return -EIO;
+   } else if (out[0] == TOS_NOT_SUPPORTED) {
+   return -ENODEV;
+   } else if (out[0] != TOS_SUCCESS) {
+   return -EIO;
+   }
+
+   /*
+* Some devices only need to call HCI_WIRELESS_WWAN_STATUS to
+* (de)activate the device, but some others need the
+* HCI_WIRELESS_WWAN_POWER call as well.
+*/
+   in[3] = HCI_WIRELESS_WWAN_POWER;
+   status = tci_raw(dev, in, out);
+   if (ACPI_FAILURE(status))
+   pr_err("ACPI call to set WWAN power failed\n");
+   else if (out[0] == TOS_NOT_SUPPORTED)
+   return -ENODEV;
+
+   return out[0] == TOS_

[PATCH 2/2] toshiba_acpi: Add WWAN RFKill support

[Azael Avalos]

A previuos patch added WWAN support to the driver, allowing to query
and set the device status.

This patch adds RFKill support for the recently introduced WWAN device,
making use of the WWAN and *wireless_status functions to query the
killswitch and (de)activate the device accordingly to its status.

Signed-off-by: Fabian Koester 
Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 74 +
 1 file changed, 74 insertions(+)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index 60d1ad9..2da4dea 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -174,6 +175,7 @@ struct toshiba_acpi_dev {
struct led_classdev kbd_led;
struct led_classdev eco_led;
struct miscdevice miscdev;
+   struct rfkill *wwan_rfk;
 
int force_fan;
int last_key_event;
@@ -2330,6 +2332,67 @@ static const struct file_operations toshiba_acpi_fops = {
 };
 
 /*
+ * WWAN RFKill handlers
+ */
+static int toshiba_acpi_wwan_set_block(void *data, bool blocked)
+{
+   struct toshiba_acpi_dev *dev = data;
+   int ret;
+
+   ret = toshiba_wireless_status(dev);
+   if (ret)
+   return ret;
+
+   if (!dev->killswitch)
+   return 0;
+
+   return toshiba_wwan_set(dev, blocked ? 0 : 1);
+}
+
+static void toshiba_acpi_wwan_poll(struct rfkill *rfkill, void *data)
+{
+   struct toshiba_acpi_dev *dev = data;
+
+   if (toshiba_wireless_status(dev))
+   return;
+
+   rfkill_set_hw_state(dev->wwan_rfk, !dev->killswitch);
+}
+
+static const struct rfkill_ops wwan_rfk_ops = {
+   .set_block = toshiba_acpi_wwan_set_block,
+   .poll = toshiba_acpi_wwan_poll,
+};
+
+static int toshiba_acpi_setup_wwan_rfkill(struct toshiba_acpi_dev *dev)
+{
+   int ret = toshiba_wireless_status(dev);
+
+   if (ret)
+   return ret;
+
+   dev->wwan_rfk = rfkill_alloc("Toshiba WWAN",
+&dev->acpi_dev->dev,
+RFKILL_TYPE_WWAN,
+&wwan_rfk_ops,
+dev);
+   if (!dev->wwan_rfk) {
+   pr_err("Unable to allocate WWAN rfkill device\n");
+   return -ENOMEM;
+   }
+
+   rfkill_set_hw_state(dev->wwan_rfk, !dev->killswitch);
+
+   ret = rfkill_register(dev->wwan_rfk);
+   if (ret) {
+   pr_err("Unable to register WWAN rfkill device\n");
+   rfkill_destroy(dev->wwan_rfk);
+   }
+
+   return ret;
+}
+
+/*
  * Hotkeys
  */
 static int toshiba_acpi_enable_hotkeys(struct toshiba_acpi_dev *dev)
@@ -2827,6 +2890,8 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev)
dev->fan_supported = !ret;
 
toshiba_wwan_available(dev);
+   if (dev->wwan_supported)
+   toshiba_acpi_setup_wwan_rfkill(dev);
 
print_supported_features(dev);
 
@@ -2930,6 +2995,15 @@ static int toshiba_acpi_resume(struct device *device)
pr_info("Unable to re-enable hotkeys\n");
}
 
+   if (dev->wwan_rfk) {
+   int error = toshiba_wireless_status(dev);
+
+   if (error)
+   return error;
+
+   rfkill_set_hw_state(dev->wwan_rfk, !dev->killswitch);
+   }
+
return 0;
 }
 #endif
-- 
2.6.2

--
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 3/4] ARM: dts: Add STM32 DMA support for STM32F429 MCU

[Vinod Koul]

On Fri, Oct 16, 2015 at 03:59:15PM +0200, M'boumba Cedric Madianga wrote:
> This patch adds STM32 DMA bindings for STM32F429.

I need an ACK from ARM folks on this one, and I suspect this might need
rebase on 4.4-rc1

> 
> Signed-off-by: M'boumba Cedric Madianga 
> ---
>  arch/arm/boot/dts/stm32f429.dtsi | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi 
> b/arch/arm/boot/dts/stm32f429.dtsi
> index d78a481..037eb29 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -174,6 +174,37 @@
>   reg = <0x40023800 0x400>;
>   clocks = <&clk_hse>;
>   };
> +
> + dma1: dma-controller@40026000 {
> + compatible = "st,stm32-dma";
> + reg = <0x40026000 0x400>;
> + interrupts = <11>,
> +  <12>,
> +  <13>,
> +  <14>,
> +  <15>,
> +  <16>,
> +  <17>,
> +  <47>;
> + clocks = <&rcc 0 21>;
> + #dma-cells = <4>;
> + };
> +
> + dma2: dma-controller@40026400 {
> + compatible = "st,stm32-dma";
> + reg = <0x40026400 0x400>;
> + interrupts = <56>,
> +  <57>,
> +  <58>,
> +  <59>,
> +  <60>,
> +  <68>,
> +  <69>,
> +  <70>;
> + clocks = <&rcc 0 22>;
> + #dma-cells = <4>;
> + st,mem2mem;
> + };
>   };
>  };
>  
> -- 
> 1.9.1
> 

-- 
~Vinod
--
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 4/4] ARM: configs: Add STM32 DMA support in STM32 defconfig

[Vinod Koul]

On Fri, Oct 16, 2015 at 03:59:16PM +0200, M'boumba Cedric Madianga wrote:
> This patch adds STM32 DMA support in stm32_defconfig file

This seems okay, so went ahead and applied

-- 
~Vinod
--
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 2/4] dmaengine: Add STM32 DMA driver

[Vinod Koul]

On Fri, Oct 16, 2015 at 03:59:14PM +0200, M'boumba Cedric Madianga wrote:
> This patch adds support for the STM32 DMA controller.
> 

Applied, thanks

-- 
~Vinod
--
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 1/4] dt-bindings: Document the STM32 DMA bindings

[Vinod Koul]

On Fri, Oct 16, 2015 at 03:59:13PM +0200, M'boumba Cedric Madianga wrote:
> This patch adds documentation of device tree bindings for the STM32 dma
> controller.
> 
Applied, thanks

-- 
~Vinod
--
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 01/17] mm: support madvise(MADV_FREE)

[yalin wang]

> On Nov 16, 2015, at 10:13, Minchan Kim  wrote:
> 
> On Fri, Nov 13, 2015 at 11:46:07AM -0800, Andy Lutomirski wrote:
>> On Fri, Nov 13, 2015 at 12:13 AM, Daniel Micay  wrote:
>>> On 13/11/15 02:03 AM, Minchan Kim wrote:
 On Fri, Nov 13, 2015 at 01:45:52AM -0500, Daniel Micay wrote:
>> And now I am thinking if we use access bit, we could implment 
>> MADV_FREE_UNDO
>> easily when we need it. Maybe, that's what you want. Right?
> 
> Yes, but why the access bit instead of the dirty bit for that? It could
> always be made more strict (i.e. access bit) in the future, while going
> the other way won't be possible. So I think the dirty bit is really the
> more conservative choice since if it turns out to be a mistake it can be
> fixed without a backwards incompatible change.
 
 Absolutely true. That's why I insist on dirty bit until now although
 I didn't tell the reason. But I thought you wanted to change for using
 access bit for the future, too. It seems MADV_FREE start to bloat
 over and over again before knowing real problems and usecases.
 It's almost same situation with volatile ranges so I really want to
 stop at proper point which maintainer should decide, I hope.
 Without it, we will make the feature a lot heavy by just brain storming
 and then causes lots of churn in MM code without real bebenfit
 It would be very painful for us.
>>> 
>>> Well, I don't think you need more than a good API and an implementation
>>> with no known bugs, kernel security concerns or backwards compatibility
>>> issues. Configuration and API extensions are something for later (i.e.
>>> land a baseline, then submit stuff like sysctl tunables). Just my take
>>> on it though...
>>> 
>> 
>> As long as it's anonymous MAP_PRIVATE only, then the security aspects
>> should be okay.  MADV_DONTNEED seems to work on pretty much any VMA,
>> and there's been long history of interesting bugs there.
>> 
>> As for dirty vs accessed, an argument in favor of going straight to
>> accessed is that it means that users can write code like this without
>> worrying about whether they have a kernel that uses the dirty bit:
>> 
>> x = mmap(...);
>> *x = 1;  /* mark it present */
>> 
>> /* i'm done with it */
>> *x = 1;
>> madvise(MADV_FREE, x, ...);
>> 
>> wait a while;
>> 
>> /* is it still there? */
>> if (*x == 1) {
>>  /* use whatever was cached there */
>> } else {
>> /* reinitialize it */
>> *x = 1;
>> }
>> 
>> With the dirty bit, this will look like it works, but on occasion
>> users will lose the race where they probe *x to see if the data was
>> lost and then the data gets lost before the next write comes in.
>> 
>> Sure, that load from *x could be changed to RMW or users could do a
>> dummy write (e.g. x[1] = 1; if (*x == 1) ...), but people might forget
>> to do that, and the caching implications are a little bit worse.
> 
> I think your example is the case what people abuse MADV_FREE.
> What happens if the object(ie, x) spans multiple pages?
> User should know object's memory align and investigate all of pages
> which span the object. Hmm, I don't think it's good for API.
> 
>> 
>> Note that switching to RMW is really really dangerous.  Doing:
>> 
>> *x &= 1;
>> if (*x == 1) ...;
>> 
>> is safe on x86 if the compiler generates:
>> 
>> andl $1, (%[x]);
>> cmpl $1, (%[x]);
>> 
>> but is unsafe if the compiler generates:
>> 
>> movl (%[x]), %eax;
>> andl $1, %eax;
>> movl %eax, (%[x]);
>> cmpl $1, %eax;
>> 
>> and even worse if the write is omitted when "provably" unnecessary.
>> 
>> OTOH, if switching to the accessed bit is too much of a mess, then
>> using the dirty bit at first isn't so bad.
> 
> Thanks! I want to use dirty bit first.
> 
> About access bit, I don't want to say it to mess but I guess it would
> change a lot subtle thing for all architectures. Because we have used
> access bit as just *hint* for aging while dirty bit is really
> *critical marker* for system integrity. A example in x86, we don't
> keep accuracy of access bit for reducing TLB flush IPI. I don't know
> what technique other arches have used but they might have.
> 
> Thanks.
> 
i think use access bit is not easy to implement for ANON page in kernel.
we are sure the Anon page is always PageDirty()  if it is !PageSwapCache() ,
unless it is MADV_FREE page ,
but use access bit , how to distinguish Normal ANON page and  MADV_FREE page?
it can be implemented by Access bit , but not easy, need more code change .

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/

8250_mid.c:undefined reference to `rational_best_approximation'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   8005c49d9aea74d382f474ce11afbbc7d7130bec
commit: d9eda9bab237259b06690652b145d19e0ce37a77 serial: 8250_pci: Intel MID 
UART support to its own driver
date:   4 weeks ago
config: x86_64-randconfig-s1-11161029 (attached as .config)
reproduce:
git checkout d9eda9bab237259b06690652b145d19e0ce37a77
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `mid8250_set_termios':
>> 8250_mid.c:(.text+0xf089f): undefined reference to 
>> `rational_best_approximation'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

linux-next: Tree for Nov 16

[Stephen Rothwell]

Hi all,

Changes since 20151115:

Dropped tree: target-merge (many conflicts)

Non-merge commits (relative to Linus' tree): 556
 489 files changed, 22652 insertions(+), 7062 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, allyesconfig (this fails its final
link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 229 trees (counting Linus' and 35 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 (0ca9b67606f0 Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (25cb62b76430 Linux 4.3-rc5)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (049e6dde7e57 Linux 4.3-rc4)
Merging arm-current/fixes (38850d786a79 ARM: 8449/1: fix bug in vdsomunge 
swab32 macro)
Merging m68k-current/for-linus (95bc06ef049b m68k/defconfig: Update defconfigs 
for v4.3-rc1)
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 (977bf062bba3 powerpc/dma: dma_set_coherent_mask() 
should not be GPL only)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (2c302e7e4105 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging net/master (8863002c5acd Merge branch 'mellanox-net-fixes')
Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops)
Merging ipvs/master (086f332167d6 netfilter: nf_tables: add clone interface to 
expression operations)
Merging sound-current/for-linus (5d5563b14fe3 ALSA: dice: fix detection of Loud 
devices)
Merging pci-current/for-linus (1266963170f5 PCI: Prevent out of bounds access 
in numa_node override)
Merging wireless-drivers/master (761d4be5cf66 drivers: net: xgene: fix RGMII 
10/100Mb mode)
Merging driver-core.current/driver-core-linus (9ffecb102835 Linux 4.3-rc3)
Merging tty.current/tty-linus (f235f664a8af fbcon: initialize blink interval 
before calling fb_set_par)
Merging usb.current/usb-linus (32b88194f71d Linux 4.3-rc7)
Merging usb-gadget-fixes/fixes (ce5c2d2c256a arm64: fixup for mm renames)
Merging usb-serial-fixes/usb-linus (32b88194f71d Linux 4.3-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (f256896afdb6 usb: chipidea: otg: 
gadget module load and unload support)
Merging staging.current/staging-linus (5d50ac70fe98 Merge tag 
'xfs-for-linus-4.4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs)
Merging char-misc.current/char-misc-linus (25cb62b76430 Linux 4.3-rc5)
Merging input-current/for-linus (bbdb5c22e125 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (176155dac13f crypto: qat - don't use userspace 
pointer)
Merging ide/master (1b1050cdc5cd Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
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 backlight: pwm: 
Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have branch tracer 
use recursive f

[PATCH] KVM: powerpc: kvmppc_visible_gpa can be boolean

[Yaowei Bai]

In another patch kvm_is_visible_gfn is maken return bool due to this
function only returns zero or one as its return value, let's also make
kvmppc_visible_gpa return bool to keep consistent.

No functional change.

Signed-off-by: Yaowei Bai 
---
 arch/powerpc/kvm/book3s_pr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 64891b0..70fb08d 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -512,7 +512,7 @@ static void kvmppc_patch_dcbz(struct kvm_vcpu *vcpu, struct 
kvmppc_pte *pte)
put_page(hpage);
 }
 
-static int kvmppc_visible_gpa(struct kvm_vcpu *vcpu, gpa_t gpa)
+static bool kvmppc_visible_gpa(struct kvm_vcpu *vcpu, gpa_t gpa)
 {
ulong mp_pa = vcpu->arch.magic_page_pa;
 
@@ -521,7 +521,7 @@ static int kvmppc_visible_gpa(struct kvm_vcpu *vcpu, gpa_t 
gpa)
 
gpa &= ~0xFFFULL;
if (unlikely(mp_pa) && unlikely((mp_pa & KVM_PAM) == (gpa & KVM_PAM))) {
-   return 1;
+   return true;
}
 
return kvm_is_visible_gfn(vcpu->kvm, gpa >> PAGE_SHIFT);
-- 
1.9.1



--
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] clk: samsung: Don't build ARMv8 clock drivers on ARMv7

[Chanwoo Choi]

Hi,

On 2015년 11월 16일 10:36, Krzysztof Kozlowski wrote:
> Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
> so it is built also on ARMv7. This does not bring any kind of benefit.
> There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
> multi_v7 for ARMv7).
> 
> Instead build clock drivers only for respective SoC's architecture.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/clk/samsung/Kconfig  | 13 +
>  drivers/clk/samsung/Makefile |  4 ++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
> index 84196ecdaa12..5f138fc4d84d 100644
> --- a/drivers/clk/samsung/Kconfig
> +++ b/drivers/clk/samsung/Kconfig
> @@ -2,6 +2,7 @@ config COMMON_CLK_SAMSUNG
>   bool
>   select COMMON_CLK
>  
> +# ARMv7 SoCs:
>  config S3C2410_COMMON_CLK
>   bool
>   select COMMON_CLK_SAMSUNG
> @@ -24,3 +25,15 @@ config S3C2443_COMMON_CLK
>   bool
>   select COMMON_CLK_SAMSUNG
>  
> +# ARMv8 SoCs:
> +config EXYNOS5433_COMMON_CLK
> + bool
> + depends on ARM64 || COMPILE_TEST
> + default ARCH_EXYNOS
> + select COMMON_CLK_SAMSUNG
> +
> +config EXYNOS7_COMMON_CLK
> + bool
> + depends on ARM64 || COMPILE_TEST
> + default ARCH_EXYNOS
> + select COMMON_CLK_SAMSUNG
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index 5f6833ea355d..a31332a24ef4 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -10,11 +10,11 @@ obj-$(CONFIG_SOC_EXYNOS5250)  += clk-exynos5250.o
>  obj-$(CONFIG_SOC_EXYNOS5260) += clk-exynos5260.o
>  obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o
>  obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
> -obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos5433.o
> +obj-$(CONFIG_EXYNOS5433_COMMON_CLK)  += clk-exynos5433.o
>  obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
>  obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos-audss.o
>  obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos-clkout.o
> -obj-$(CONFIG_ARCH_EXYNOS7)   += clk-exynos7.o
> +obj-$(CONFIG_EXYNOS7_COMMON_CLK) += clk-exynos7.o
>  obj-$(CONFIG_S3C2410_COMMON_CLK)+= clk-s3c2410.o
>  obj-$(CONFIG_S3C2410_COMMON_DCLK)+= clk-s3c2410-dclk.o
>  obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
> 

Looks good to me.

Reviewed-by: Chanwoo Choi 

Regards,
Chanwoo Choi
--
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] regulator: pv88090: fix platform_no_drv_owner.cocci warnings

[kbuild test robot]

drivers/regulator/pv88090-regulator.c:471:3-8: No need to set .owner here. The 
core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: James Ban 
Signed-off-by: Fengguang Wu 
---

 pv88090-regulator.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/regulator/pv88090-regulator.c
+++ b/drivers/regulator/pv88090-regulator.c
@@ -468,7 +468,6 @@ MODULE_DEVICE_TABLE(of, pv88090_dt_ids);
 static struct i2c_driver pv88090_regulator_driver = {
.driver = {
.name = "pv88090",
-   .owner = THIS_MODULE,
.of_match_table = of_match_ptr(pv88090_dt_ids),
},
.probe = pv88090_i2c_probe,
--
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] regulator: pv88090: fix semicolon.cocci warnings

[kbuild test robot]

drivers/regulator/pv88090-regulator.c:291:2-3: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: James Ban 
Signed-off-by: Fengguang Wu 
---

 pv88090-regulator.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/regulator/pv88090-regulator.c
+++ b/drivers/regulator/pv88090-regulator.c
@@ -288,7 +288,7 @@ static struct pv88090_pdata *pv88090_par
pdata->init_data[n] = pv88090_matches[i].init_data;
pdata->reg_node[n] = pv88090_matches[i].of_node;
n++;
-   };
+   }
 
return pdata;
 }
--
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 V1] regulator: pv88090: new regulator driver

[kbuild test robot]

Hi James,

[auto build test WARNING on: regulator/for-next]
[also build test WARNING on: v4.4-rc1 next-20151115]

url:
https://github.com/0day-ci/linux/commits/James-Bans/regulator-pv88090-new-regulator-driver/20151116-102239
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
for-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/regulator/pv88090-regulator.c:471:3-8: No need to set .owner here. 
>> The core will do it.
--
>> drivers/regulator/pv88090-regulator.c:291:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
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] arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS

[Chanwoo Choi]

Hi,

On 2015년 11월 16일 10:36, Krzysztof Kozlowski wrote:
> The ARMv8 Exynos family SoCs in Linux kernel are currently:
>  - Exynos5433 (controlled by ARCH_EXYNOS),
>  - Exynos7 (controlled by ARCH_EXYNOS7).
> 
> It duplicates Kconfig symbols unnecessarily, so consolidate them into
> one ARCH_EXYNOS. Future SoCs could fall also under the ARCH_EXYNOS
> symbol.
> 
> The commit should not bring any visible functional change.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm64/Kconfig.platforms| 11 ++-
>  arch/arm64/boot/dts/exynos/Makefile |  2 +-
>  arch/arm64/configs/defconfig|  2 +-
>  3 files changed, 4 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 4043c35962cc..afa19baca94e 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -13,21 +13,14 @@ config ARCH_BERLIN
> This enables support for Marvell Berlin SoC Family
>  
>  config ARCH_EXYNOS
> - bool
> - help
> -   This enables support for Samsung Exynos SoC family
> -
> -config ARCH_EXYNOS7
> - bool "ARMv8 based Samsung Exynos7"
> - select ARCH_EXYNOS
> + bool "ARMv8 based Samsung Exynos SoC family"
>   select COMMON_CLK_SAMSUNG
>   select HAVE_S3C2410_WATCHDOG if WATCHDOG
>   select HAVE_S3C_RTC if RTC_CLASS
>   select PINCTRL
>   select PINCTRL_EXYNOS
> -
>   help
> -   This enables support for Samsung Exynos7 SoC family
> +   This enables support for Samsung Exynos ARMv8 SoC family
>  
>  config ARCH_LAYERSCAPE
>   bool "ARMv8 based Freescale Layerscape SoC family"
> diff --git a/arch/arm64/boot/dts/exynos/Makefile 
> b/arch/arm64/boot/dts/exynos/Makefile
> index 20310e5b6d6f..50c9b9383cfa 100644
> --- a/arch/arm64/boot/dts/exynos/Makefile
> +++ b/arch/arm64/boot/dts/exynos/Makefile
> @@ -1,4 +1,4 @@
> -dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb
> +dtb-$(CONFIG_ARCH_EXYNOS) += exynos7-espresso.dtb
>  
>  always   := $(dtb-y)
>  subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index bdd7aa358d2a..a396fa7c69a5 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -33,7 +33,7 @@ CONFIG_MODULE_UNLOAD=y
>  # CONFIG_IOSCHED_DEADLINE is not set
>  CONFIG_ARCH_BCM_IPROC=y
>  CONFIG_ARCH_BERLIN=y
> -CONFIG_ARCH_EXYNOS7=y
> +CONFIG_ARCH_EXYNOS=y
>  CONFIG_ARCH_LAYERSCAPE=y
>  CONFIG_ARCH_HISI=y
>  CONFIG_ARCH_MEDIATEK=y
> 

When I sent the EXYNOS5433 patch[1], we don't want to add the each config
for each Exynos SoC. So, I think this patch is good to use only one ARCH_EXYNOS 
config
for all ARMv8 Exynos SoC.
[1] https://lkml.org/lkml/2015/2/24/85

Reviewed-by: Chanwoo Choi 

Regards,
Chanwoo Choi

--
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 05/10] KVM: x86: MMU: Use for_each_rmap_spte macro instead of pte_list_walk()

[Takuya Yoshikawa]

On 2015/11/14 18:20, Marcelo Tosatti wrote:


The actual issue is this: a higher level page that had, under its children,
no out of sync pages, now, due to your addition, a child that is unsync:

initial state:
level1

final state:

level1 -x-> level2 -x-> level3

Where -x-> are the links created by this pagefault fixing round.

If _any_ page under you is unsync (not necessarily the ones this
pagefault is accessing), you have to mark parents unsync.


I understand this, but I don't think my patch will break this.

What kvm_mmu_mark_parents_unsync() does is:

  for each p_i in sp->parent_ptes rmap chain
mark_unsync(p_i);

Then, mark_unsync() finds the parent sp including that p_i to
set ->unsync_child_bitmap and increment ->unsync_children if
necessary.  It may also call kvm_mmu_mark_parents_unsync()
recursively.

I understand we need to tell the parents "you have an unsync
child/descendant" until this information reaches the top level
by that recursive calls.

But since these recursive calls cannot come back to the starting sp,
the child->parent graph has no loop, each mark_unsync(p_i) will not
be affected by other parents in that sp->parent_ptes rmap chain,
from which we started the recursive calls.


As the following code shows, my patch does mark_unsync(parent_pte)
separately, and then mmu_page_add_parent_pte(vcpu, sp, parent_pte):


-   } else if (sp->unsync)
+   if (parent_pte)
+   mark_unsync(parent_pte);
+   } else if (sp->unsync) {
kvm_mmu_mark_parents_unsync(sp);
+   if (parent_pte)
+   mark_unsync(parent_pte);
+   }
+   mmu_page_add_parent_pte(vcpu, sp, parent_pte);


So, as you worried, during each mark_unsync(p_i) is processed,
this parent_pte does not exist in that sp->parent_ptes rmap chain.

But as I explained above, this does not change anything about what
each mark_unsync(p_i) call does, so keeps the original behaviour.


By the way, I think "kvm_mmu_mark_parents_unsync" and "mark_unsync"
do not tell what they actually do well. When I first saw the names,
I thought they would just set the parents' sp->unsync.

To reflect the following meaning better, it should be
propagate_unsync(_to_parents) or something:

  Tell the parents "you have an unsync child/descendant"
  until this unsync information reaches the top level


Thanks,
  Takuya


--
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] KVM: kvm_is_visible_gfn can be boolean

[Yaowei Bai]

On Sat, Nov 14, 2015 at 06:07:51PM +0800, Amos Jianjun Kong wrote:
> On Sat, Nov 14, 2015 at 11:21 AM, Yaowei Bai
>  wrote:
> > This patch makes kvm_is_visible_gfn return bool due to this particular
> > function only using either one or zero as its return value.
> >
> > No functional change.
> >
> > Signed-off-by: Yaowei Bai 
> 
> Hi Yaowei,

Hi,

> 
> > ---
> >  include/linux/kvm_host.h | 2 +-
> >  virt/kvm/kvm_main.c  | 6 +++---
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index 5706a21..4436539 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -623,7 +623,7 @@ int kvm_gfn_to_hva_cache_init(struct kvm *kvm, struct 
> > gfn_to_hva_cache *ghc,
> >  int kvm_clear_guest_page(struct kvm *kvm, gfn_t gfn, int offset, int len);
> >  int kvm_clear_guest(struct kvm *kvm, gpa_t gpa, unsigned long len);
> >  struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn);
> > -int kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn);
> > +bool kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn);
> >  unsigned long kvm_host_page_size(struct kvm *kvm, gfn_t gfn);
> >  void mark_page_dirty(struct kvm *kvm, gfn_t gfn);
> >
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index 484079e..73cbb41 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -1164,15 +1164,15 @@ struct kvm_memory_slot 
> > *kvm_vcpu_gfn_to_memslot(struct kvm_vcpu *vcpu, gfn_t gfn
> > return __gfn_to_memslot(kvm_vcpu_memslots(vcpu), gfn);
> >  }
> >
> > -int kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn)
> > +bool kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn)
> >  {
> > struct kvm_memory_slot *memslot = gfn_to_memslot(kvm, gfn);
> >
> > if (!memslot || memslot->id >= KVM_USER_MEM_SLOTS ||
> >   memslot->flags & KVM_MEMSLOT_INVALID)
> > -   return 0;
> > +   return false;
> >
> > -   return 1;
> > +   return true;
> >  }
> >  EXPORT_SYMBOL_GPL(kvm_is_visible_gfn);
> 
> 
> kvm_is_visible_gfn() is also used in arch/powerpc/kvm/book3s_pr.c:
> 
> static int kvmppc_visible_gpa(struct kvm_vcpu *vcpu, gpa_t gpa)
> {
> ..
> if (unlikely(mp_pa) && unlikely((mp_pa & KVM_PAM) == (gpa & 
> KVM_PAM))) {
> return 1;
> }
> 
> return kvm_is_visible_gfn(vcpu->kvm, gpa >> PAGE_SHIFT);
> }
> 
> Do we still need to update that function?

OK, i'll send another patch to update it, thanks.

> 
> Thanks, Amos


--
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] mm: change mm_vmscan_lru_shrink_inactive() proto types

[yalin wang]

Move node_id zone_idx shrink flags into trace function,
so thay we don't need caculate these args if the trace is disabled,
and will make this function have less arguments.

Signed-off-by: yalin wang 
---
 include/trace/events/vmscan.h | 14 +++---
 mm/vmscan.c   |  7 ++-
 2 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
index dae7836..31763dd 100644
--- a/include/trace/events/vmscan.h
+++ b/include/trace/events/vmscan.h
@@ -352,11 +352,11 @@ TRACE_EVENT(mm_vmscan_writepage,
 
 TRACE_EVENT(mm_vmscan_lru_shrink_inactive,
 
-   TP_PROTO(int nid, int zid,
-   unsigned long nr_scanned, unsigned long nr_reclaimed,
-   int priority, int reclaim_flags),
+   TP_PROTO(struct zone *zone,
+   unsigned long nr_scanned, unsigned long nr_reclaimed,
+   int priority, int file),
 
-   TP_ARGS(nid, zid, nr_scanned, nr_reclaimed, priority, reclaim_flags),
+   TP_ARGS(zone, nr_scanned, nr_reclaimed, priority, file),
 
TP_STRUCT__entry(
__field(int, nid)
@@ -368,12 +368,12 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive,
),
 
TP_fast_assign(
-   __entry->nid = nid;
-   __entry->zid = zid;
+   __entry->nid = zone_to_nid(zone);
+   __entry->zid = zone_idx(zone);
__entry->nr_scanned = nr_scanned;
__entry->nr_reclaimed = nr_reclaimed;
__entry->priority = priority;
-   __entry->reclaim_flags = reclaim_flags;
+   __entry->reclaim_flags = trace_shrink_flags(file);
),
 
TP_printk("nid=%d zid=%d nr_scanned=%ld nr_reclaimed=%ld priority=%d 
flags=%s",
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 69ca1f5..f8fc8c1 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1691,11 +1691,8 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
current_may_throttle())
wait_iff_congested(zone, BLK_RW_ASYNC, HZ/10);
 
-   trace_mm_vmscan_lru_shrink_inactive(zone->zone_pgdat->node_id,
-   zone_idx(zone),
-   nr_scanned, nr_reclaimed,
-   sc->priority,
-   trace_shrink_flags(file));
+   trace_mm_vmscan_lru_shrink_inactive(zone, nr_scanned, nr_reclaimed,
+   sc->priority, file);
return nr_reclaimed;
 }
 
-- 
1.9.1

--
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] mm: change mm_vmscan_lru_shrink_inactive() proto types

[yalin wang]

> On Nov 13, 2015, at 21:16, Vlastimil Babka  wrote:
> 
> zone_to_nid
make sense,
i will send V2 patch ,
--
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] regulator: pv88090: new regulator driver

[James Bans]

From: James Ban 

This is the driver for the Powerventure PV88090 BUCKs and LDOs regulator.
It communicates via an I2C bus to the device.

Signed-off-by: James Ban 

---
This patch applies against linux-next and next-20151110 


 .../devicetree/bindings/regulator/pv88090.txt  |   65 +++
 drivers/regulator/Kconfig  |8 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/pv88090-regulator.c  |  482 
 drivers/regulator/pv88090-regulator.h  |   78 
 include/linux/regulator/pv88090.h  |   28 ++
 6 files changed, 662 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/pv88090.txt
 create mode 100644 drivers/regulator/pv88090-regulator.c
 create mode 100644 drivers/regulator/pv88090-regulator.h
 create mode 100644 include/linux/regulator/pv88090.h

diff --git a/Documentation/devicetree/bindings/regulator/pv88090.txt 
b/Documentation/devicetree/bindings/regulator/pv88090.txt
new file mode 100644
index 000..39a121f
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/pv88090.txt
@@ -0,0 +1,65 @@
+* Powerventure Semiconductor PV88090 Voltage Regulator
+
+Required properties:
+- compatible: "pvs,pv88090".
+- reg: I2C slave address, usually 0x48.
+- interrupts: the interrupt outputs of the controller
+- regulators: A node that houses a sub-node for each regulator within the
+  device. Each sub-node is identified using the node's name, with valid
+  values listed below. The content of each sub-node is defined by the
+  standard binding for regulators; see regulator.txt.
+  BUCK1, BUCK2, BUCK3, LDO1, and LDO2.
+
+Optional properties:
+- Any optional property defined in regulator.txt
+
+Example
+
+   pmic: pv88090@48 {
+   compatible = "pvs,pv88090";
+   reg = <0x48>;
+   interrupt-parent = <&gpio>;
+   interrupts = <24 24>;
+
+   regulators {
+   BUCK1 {
+   regulator-name = "buck1";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <1393750>;
+   regulator-min-microamp  = < 22>;
+   regulator-max-microamp  = <704>;
+   regulator-boot-on;
+   };
+
+   BUCK2 {
+   regulator-name = "buck2";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <1393750>;
+   regulator-min-microamp  = <1496000>;
+   regulator-max-microamp  = <4189000>;
+   };
+
+   BUCK3 {
+   regulator-name = "buck3";
+   regulator-min-microvolt = <140>;
+   regulator-max-microvolt = <2193750>;
+   regulator-min-microamp  = <1496000>;
+   regulator-max-microamp  = <4189000>;
+   regulator-boot-on;
+   };
+
+   LDO1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <435>;
+   regulator-boot-on;
+   };
+
+   LDO2 {
+   regulator-name = "ldo2";
+   regulator-min-microvolt = < 65>;
+   regulator-max-microvolt = <2225000>;
+   regulator-boot-on;
+   };
+   };
+   };
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8df0b0e..1e27bd8 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -504,6 +504,14 @@ config REGULATOR_PFUZE100
  Say y here to support the regulators found on the Freescale
  PFUZE100/PFUZE200 PMIC.
 
+config REGULATOR_PV88090
+   tristate "Powerventure Semiconductor PV88090 regulator"
+   depends on I2C
+   select REGMAP_I2C
+   help
+ Say y here to support the voltage regulators and convertors
+ on PV88090
+
 config REGULATOR_PWM
tristate "PWM voltage regulator"
depends on PWM
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 0f81749..5c1c09a 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
 obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
 obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
+obj-$(CONFIG_REGULAT

Re: [PATCH v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk

[Lu Baolu]

Hi,

On 11/13/2015 11:34 PM, Dmitry Malkin wrote:

On Mon, 9 Nov 2015 15:38:33 +0800, Lu Baolu wrote:

On Intel platform, if the debug target is connected with debug
host, enabling DCE bit in command register leads to a hung bus
state. In the hung state, the host system will not see a port
connected status bit set. Hence debug target fails to be probed.

The state could be resolved by performing a port reset to the
debug port from the host xHCI. This patch introduces this work
around.

Is it correct to call this a "hung bus state"?  Wouldn't calling it
"hung port state" more appropriate?


Yes, "hung port state" is more appropriate.



I have observed this DCE-enable-related hung port state,
but the reason seemed to be different in my case:

Citing a note (sic!) from The Holy XHCI Spec, section 7.6.4.1:

If a Debug Host attempts to attach to a Debug Target before the DCE flag is set,
both ends of the link shall transition to the Inactive state.
So a Debug Host should periodically issue a Warm Reset
to ports that are Inactive to enable a connection to the DbC of the Debug 
Target.


Exactly. A formal workaround is to periodically issue Warm Resets to ports
from debug host.


Indeed, the inactive state is what I have observed (PLS field of port register 
PORTSC)
when the DCE bit is set to 1 with the cable already plugged in.

Now, according to my interpretation of The Hole USB 3.1 spec, section 7.5.2,
which says:

eSS.Inactive is a state where a link has failed Enhanced SuperSpeed operation.
A downstream port can only exit from this state when directed, or upon 
detection of
an absence of a far-end receiver termination (R RX-DC ) specified in Table 6-21,
or upon a Warm Reset.

It follows, that since hosts without DBC cannot listen to upstream requests,
the debug target-originated port reset requests (both hot and warm) will be 
ignored
by the debug host.


As above, a formal workaround is to issue Warm Reset periodically from debug
host, but that could cause much complexity. My quirk is to issue port 
reset just

*before* setting DCE bit. This quirk seems to work on several platforms.
(My debug host doesn't have DBC.)



This is the essence of the "hung port state" that I was able to observe.

Note, that this roadblock doesn't appear if you attach the cable /after/ 
enabling the DCE bit,


Yes.


or, alternatively, if the host has DBC.


Really? I haven't tried it yet.



And indeed, your quirk will work in the latter case, since the debug host hub
will be able to see the upstream reset request.


This quirk works as well if debug host doesn't have DBC. I didn't try a 
DBC-capable

debug host yet.



--
with best regards,
Dmitry Malkin


Thank you.
-Baolu


--
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/



--
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 01/17] mm: support madvise(MADV_FREE)

[Minchan Kim]

On Fri, Nov 13, 2015 at 11:46:07AM -0800, Andy Lutomirski wrote:
> On Fri, Nov 13, 2015 at 12:13 AM, Daniel Micay  wrote:
> > On 13/11/15 02:03 AM, Minchan Kim wrote:
> >> On Fri, Nov 13, 2015 at 01:45:52AM -0500, Daniel Micay wrote:
>  And now I am thinking if we use access bit, we could implment 
>  MADV_FREE_UNDO
>  easily when we need it. Maybe, that's what you want. Right?
> >>>
> >>> Yes, but why the access bit instead of the dirty bit for that? It could
> >>> always be made more strict (i.e. access bit) in the future, while going
> >>> the other way won't be possible. So I think the dirty bit is really the
> >>> more conservative choice since if it turns out to be a mistake it can be
> >>> fixed without a backwards incompatible change.
> >>
> >> Absolutely true. That's why I insist on dirty bit until now although
> >> I didn't tell the reason. But I thought you wanted to change for using
> >> access bit for the future, too. It seems MADV_FREE start to bloat
> >> over and over again before knowing real problems and usecases.
> >> It's almost same situation with volatile ranges so I really want to
> >> stop at proper point which maintainer should decide, I hope.
> >> Without it, we will make the feature a lot heavy by just brain storming
> >> and then causes lots of churn in MM code without real bebenfit
> >> It would be very painful for us.
> >
> > Well, I don't think you need more than a good API and an implementation
> > with no known bugs, kernel security concerns or backwards compatibility
> > issues. Configuration and API extensions are something for later (i.e.
> > land a baseline, then submit stuff like sysctl tunables). Just my take
> > on it though...
> >
> 
> As long as it's anonymous MAP_PRIVATE only, then the security aspects
> should be okay.  MADV_DONTNEED seems to work on pretty much any VMA,
> and there's been long history of interesting bugs there.
> 
> As for dirty vs accessed, an argument in favor of going straight to
> accessed is that it means that users can write code like this without
> worrying about whether they have a kernel that uses the dirty bit:
> 
> x = mmap(...);
> *x = 1;  /* mark it present */
> 
> /* i'm done with it */
> *x = 1;
> madvise(MADV_FREE, x, ...);
> 
> wait a while;
> 
> /* is it still there? */
> if (*x == 1) {
>   /* use whatever was cached there */
> } else {
>  /* reinitialize it */
>  *x = 1;
> }
> 
> With the dirty bit, this will look like it works, but on occasion
> users will lose the race where they probe *x to see if the data was
> lost and then the data gets lost before the next write comes in.
> 
> Sure, that load from *x could be changed to RMW or users could do a
> dummy write (e.g. x[1] = 1; if (*x == 1) ...), but people might forget
> to do that, and the caching implications are a little bit worse.

I think your example is the case what people abuse MADV_FREE.
What happens if the object(ie, x) spans multiple pages?
User should know object's memory align and investigate all of pages
which span the object. Hmm, I don't think it's good for API.

> 
> Note that switching to RMW is really really dangerous.  Doing:
> 
> *x &= 1;
> if (*x == 1) ...;
> 
> is safe on x86 if the compiler generates:
> 
> andl $1, (%[x]);
> cmpl $1, (%[x]);
> 
> but is unsafe if the compiler generates:
> 
> movl (%[x]), %eax;
> andl $1, %eax;
> movl %eax, (%[x]);
> cmpl $1, %eax;
> 
> and even worse if the write is omitted when "provably" unnecessary.
> 
> OTOH, if switching to the accessed bit is too much of a mess, then
> using the dirty bit at first isn't so bad.

Thanks! I want to use dirty bit first.

About access bit, I don't want to say it to mess but I guess it would
change a lot subtle thing for all architectures. Because we have used
access bit as just *hint* for aging while dirty bit is really
*critical marker* for system integrity. A example in x86, we don't
keep accuracy of access bit for reducing TLB flush IPI. I don't know
what technique other arches have used but they might have.

Thanks.


> 
> --Andy
> 
> -- 
> Andy Lutomirski
> AMA Capital Management, LLC
--
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: manual merge of the target-merge tree with the scsi tree

[Stephen Rothwell]

Hi Nicholas,

On Fri, 13 Nov 2015 12:06:05 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the target-merge tree got conflicts in
> several files.  It looks like a newer version of all the commits in the
> target-merge tree has been applied to the scsi tree, so I just dropped
> the target-merge tree for today.  You might like to tidy it up with
> respect to the current scsi tree.

In particular this series from the target-merge tree:

8edb1554f7c2 mpt3sas: Fix unprotected list lookup in v4.3-rc0 changes
db9e2f795915 mpt3sas: Refcount fw_events and fix unsafe list usage
9dab68af61d6 mpt3sas: Refcount sas_device objects and fix unsafe list usage
0f9b74e50d06 mpt2sas: Refcount fw_events and fix unsafe list usage
2757abdc85c1 mpt2sas: Refcount sas_device objects and fix unsafe list usage

conflicts with this series (now from Linus' tree):

abc01f7d54da mpt3sas: Bump mpt3sas driver version to 09.102.00.00
c84b06a48c4d mpt3sas: Single driver module which supports both SAS 2.0 & SAS 
3.0 HBAs
d0c627afb7a6 mpt2sas, mpt3sas: Update the driver versions
08c4d550c579 mpt3sas: setpci reset kernel oops fix
989e43c7ec34 mpt3sas: Added OEM Gen2 PnP ID branding names
146b16c8071f mpt3sas: Refcount fw_events and fix unsafe list usage
d1cb5e495e53 mpt3sas: Refcount sas_device objects and fix unsafe list usage
422630955ea3 mpt3sas: sysfs attribute to report Backup Rail Monitor Status
7786ab6aff9c mpt3sas: Ported WarpDrive product SSS6200 support
16e179bda58f mpt3sas: fix for driver fails EEH, recovery from injected pci bus 
error
42081173c74e mpt3sas: Manage MSI-X vectors according to HBA device type
45506049c7ab mpt3sas: Don't send PHYDISK_HIDDEN RAID action request on SAS2 HBAs
471ef9d4e498 mpt3sas: Build MPI SGL LIST on GEN2 HBAs and IEEE SGL LIST on GEN3 
HBAs
af0094115b08 mpt2sas, mpt3sas: Remove SCSI_MPTXSAS_LOGGING entry from Kconfig
d357e84d65df mpt3sas: Define 'hba_mpi_version_belonged' IOC variable
09ec55ed74eb mpt2sas: Remove .c and .h files from mpt2sas driver
78f97c8f612d mpt2sas: Move Gen2 HBA's device registration to a separate file
7497392a1193 mpt3sas: Move Gen3 HBA's device registration to a separate file
8a7e4c24e08f mpt3sas: Added mpt2sas driver definitions

So it would be nice if you could tidy up the target-merge tree.
-- 
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: drivers/staging/wilc1000/host_interface.c:4135:5: error: conflicting types for 'host_int_init'

[glen lee]

Hi fengguang,

This was fixed on staging-testing branch but not yet merged.

8224ec3e05b626b1b18ed0c107f2a2b1da979553 fixes this error also.

regards,
glen lee.


On 2015년 11월 15일 08:15, kbuild test robot wrote:

Hi Glen,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   12b76f3bf336388916ddf8047156f9e9993ff4e9
commit: d5382219138db78b82631501b0f614e5fd012ad1 staging: wilc1000: 
host_int_init: add argument net_device
date:   2 weeks ago
config: i386-allyesconfig (attached as .config)
reproduce:
 git checkout d5382219138db78b82631501b0f614e5fd012ad1
 # save the attached .config to linux build tree
 make ARCH=i386

All errors (new ones prefixed by >>):

In file included from drivers/staging/wilc1000/host_interface.c:5:0:
drivers/staging/wilc1000/host_interface.h:914:50: warning: 'struct 
net_device' declared inside parameter list
 s32 host_int_init(struct net_device *dev, struct host_if_drv **phWFIDrv);
  ^
drivers/staging/wilc1000/host_interface.h:914:50: warning: its scope is 
only this definition or declaration, which is probably not what you want

drivers/staging/wilc1000/host_interface.c:4135:5: error: conflicting types for 
'host_int_init'

 s32 host_int_init(struct net_device *dev, struct host_if_drv 
**hif_drv_handler)
 ^
In file included from drivers/staging/wilc1000/host_interface.c:5:0:
drivers/staging/wilc1000/host_interface.h:914:5: note: previous declaration 
of 'host_int_init' was here
 s32 host_int_init(struct net_device *dev, struct host_if_drv **phWFIDrv);
 ^

vim +/host_int_init +4135 drivers/staging/wilc1000/host_interface.c

   4129 
   4130 void host_int_send_network_info_to_host
   4131 (u8 *macStartAddress, u16 u16RxFrameLen, s8 s8Rssi)
   4132 {
   4133 }
   4134 

4135s32 host_int_init(struct net_device *dev, struct host_if_drv 
**hif_drv_handler)

   4136 {
   4137 s32 result = 0;
   4138 struct host_if_drv *hif_drv;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


--
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] wireless: change cfg80211 regulatory domain info as debug messages

[Dave Young]

On 11/15/15 at 09:38am, Joe Perches wrote:
> On Sun, 2015-11-15 at 15:31 +0800, Dave Young wrote:
> > cfg80211 module prints a lot of messages like below. Actually printing
> > once is acceptable but sometimes it will print again and again, it looks
> > very annoying. It is better to change these detail messages to debugging
> > only.
> 
> So maybe add some wrapper that does a pr_info then
> a pr_debug for the second and subsequent uses like:
> 
> #define pr_info_once_then_debug(fmt, ...) \
> ({\
>   static bool __print_once __read_mostly; \
>   \
>   if (!__print_once) {\
>   __print_once = true;\
>   pr_info(fmt, ##__VA_ARGS__);\
>   } else {\
>   pr_debug(fmt, ##__VA_ARGS__);   \
>   }   \
> })
> 

Hmm, it looks too much for this issue, I'm thinking about to add a cmdline
param to disable mute it.

Thanks
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: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

[Dave Young]

Hi,

On 11/15/15 at 07:25pm, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On 2015-11-15, Dave Young wrote:
> > cfg80211 module prints a lot of messages like below. Actually printing
> > once is acceptable but sometimes it will print again and again, it looks
> > very annoying. It is better to change these detail messages to debugging
> > only.
> 
> It is a lot of info, easily repeated 3 times on boot, but it's also the
> only real chance to determine why you ended up with the regulatory 
> domain settings you got, rather than just the values itself. Given that
> a lot (most?) of officially shipping wireless devices are misconfigured
> (wrong EEPROM regdom settings for the region they're sold in) and 
> considering that the limits can even change at runtime (IEEE 802.11d), 
> it is imho quite important not just to be able what the current 
> restrictions (iw reg get) are, but also why the kernel settled on those.

If it is really important then a kernel cmdline param to disable the logs
sounds better?

Thanks
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: [PATCH v3 3/4] Crypto: rockchip/crypto - add crypto driver for rk3288

[Zain]

On 2015年11月15日 06:41, Heiko Stuebner wrote:
> Hi Zain,
>
> Am Freitag, 13. November 2015, 14:44:43 schrieb Zain:
>> On 2015年11月12日 20:32, Heiko Stuebner wrote:
>>> Hi Zain,
>>>
>>> I was able to sucessfully test your crypto-driver, but have found some
>>> improvements below that should probably get looked at:
>>>
>>> Am Mittwoch, 11. November 2015, 14:35:58 schrieb Zain Wang:
 Crypto driver support:
  ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
 You can alloc tags above in your case.

 And other algorithms and platforms will be added later on.

 Signed-off-by: Zain Wang 
 ---
>>> [...]
>>>
 diff --git a/drivers/crypto/rockchip/rk3288_crypto.c 
 b/drivers/crypto/rockchip/rk3288_crypto.c
 new file mode 100644
 index 000..bb36baa
 --- /dev/null
 +++ b/drivers/crypto/rockchip/rk3288_crypto.c
 @@ -0,0 +1,392 @@
> [...]
>
> static void rk_crypto_action(void *data)
> {
>   struct rk_crypto_info *crypto_info = data;
>
>   reset_control_assert(crypto_info->rst);
> }
>
 +static int rk_crypto_probe(struct platform_device *pdev)
 +{
 +  struct resource *res;
 +  struct device *dev = &pdev->dev;
 +  struct rk_crypto_info *crypto_info;
 +  int err = 0;
 +
 +  crypto_info = devm_kzalloc(&pdev->dev,
 + sizeof(*crypto_info), GFP_KERNEL);
 +  if (!crypto_info) {
 +  err = -ENOMEM;
 +  goto err_crypto;
 +  }
 +
 +  crypto_info->rst = devm_reset_control_get(dev, "crypto-rst");
 +  if (IS_ERR(crypto_info->rst)) {
 +  err = PTR_ERR(crypto_info->rst);
 +  goto err_crypto;
 +  }
 +
 +  reset_control_assert(crypto_info->rst);
 +  usleep_range(10, 20);
 +  reset_control_deassert(crypto_info->rst);
>   err = devm_add_action(dev, rk_crypto_action, crypto_info);
>   if (err) {
>   reset_control_assert(crypto_info->rst);
>   return err;
>   }
>
> from here onwards the devm_action will always be executed when either
> _probe fails, or after remove finishes, so no need to assert the reset
> manually.
I have known this function,
rk_crypto_action will be executed next to either failed _probe, or
_remove automatically.
It also make sure reset_control_assert can be executed after tasklet_kill.

OK! Done!
>
 +
 +  spin_lock_init(&crypto_info->lock);
 +
 +  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 +  crypto_info->reg = devm_ioremap_resource(&pdev->dev, res);
 +  if (IS_ERR(crypto_info->reg)) {
 +  err = PTR_ERR(crypto_info->reg);
 +  goto err_ioremap;
 +  }
 +
 +  crypto_info->aclk = devm_clk_get(&pdev->dev, "aclk");
 +  if (IS_ERR(crypto_info->aclk)) {
 +  err = PTR_ERR(crypto_info->aclk);
 +  goto err_ioremap;
 +  }
 +
 +  crypto_info->hclk = devm_clk_get(&pdev->dev, "hclk");
 +  if (IS_ERR(crypto_info->hclk)) {
 +  err = PTR_ERR(crypto_info->hclk);
 +  goto err_ioremap;
 +  }
 +
 +  crypto_info->sclk = devm_clk_get(&pdev->dev, "sclk");
 +  if (IS_ERR(crypto_info->sclk)) {
 +  err = PTR_ERR(crypto_info->sclk);
 +  goto err_ioremap;
 +  }
 +
 +  crypto_info->dmaclk = devm_clk_get(&pdev->dev, "apb_pclk");
 +  if (IS_ERR(crypto_info->dmaclk)) {
 +  err = PTR_ERR(crypto_info->dmaclk);
 +  goto err_ioremap;
 +  }
 +
 +  crypto_info->irq = platform_get_irq(pdev, 0);
 +  if (crypto_info->irq < 0) {
 +  dev_warn(crypto_info->dev,
 +   "control Interrupt is not available.\n");
 +  err = crypto_info->irq;
 +  goto err_ioremap;
 +  }
 +
 +  err = devm_request_irq(&pdev->dev, crypto_info->irq, crypto_irq_handle,
 + IRQF_SHARED, "rk-crypto", pdev);
>>> you are freeing the irq manually below and in _remove too. As it stands
>>> with putting the ip block in reset again on remove this should either loose
>>> the devm_ or you could add a devm_action that handles the reset assert
>>> like in [0] - registering the devm_action above where the reset is done.
>>> That way you could really use dev_request_irq and loose the free_irq
>>> calls here and in remove.
>>>
>>> [0] https://lkml.org/lkml/2015/11/8/159
>> I made a mistake here. I did not remove free_irq when using
>> devm_request_irq.
>>
>> As I do not konw enough about devm_action and reset-assert , can I
>> remove free_irq
>> simply like drivers/i2c/buses/i2c-sun6i-p2wi.c used devm_request_irq and
>> reset_assert?
> I did insert suitable code on how that could look a bit above :-)
Thanks, done!
>
>>> [...]
>>>
 +static int rk_crypto_remove(struct platform_device *pdev)
 +{
 +  struct rk_crypto_info *crypto_tmp = platform_get_drvdata(pdev);
 +
 +  rk_crypto_unregister();
 +  

Re: kernel oops on mmotm-2015-10-15-15-20

[Minchan Kim]

On Thu, Nov 12, 2015 at 09:36:14AM +0900, Minchan Kim wrote:



> > > mmotm-2015-10-15-15-20-no-madvise_free, IOW it means git head for
> > > 54bad5da4834 arm64: add pmd_[dirty|mkclean] for THP so there is no
> > > MADV_FREE code in there
> > >  + pte_mkdirty patch
> > >  + freeze/unfreeze patch
> > >  + do_page_add_anon_rmap patch
> > >  + above split_huge_pmd
> > > 
> > > 
> > > Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k 
> > > FS
> > > Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k 
> > > FS
> > > Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k 
> > > FS
> > > BUG: Bad rss-counter state mm:88007fa3bb80 idx:1 val:512
> > 
> > With the patch below my test setup run for 2+ days without triggering the
> > bug. split_huge_pmd patch should be dropped.
> > 
> > Please test.
> > 
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 14cbbad54a3e..7aa0a3fef2aa 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -2841,9 +2841,6 @@ static void __split_huge_pmd_locked(struct 
> > vm_area_struct *vma, pmd_t *pmd,
> > write = pmd_write(*pmd);
> > young = pmd_young(*pmd);
> >  
> > -   /* leave pmd empty until pte is filled */
> > -   pmdp_huge_clear_flush_notify(vma, haddr, pmd);
> > -
> > pgtable = pgtable_trans_huge_withdraw(mm, pmd);
> > pmd_populate(mm, &_pmd, pgtable);
> >  
> > @@ -2893,6 +2890,28 @@ static void __split_huge_pmd_locked(struct 
> > vm_area_struct *vma, pmd_t *pmd,
> > }
> >  
> > smp_wmb(); /* make pte visible before pmd */
> > +   /*
> > +* Up to this point the pmd is present and huge and userland has the
> > +* whole access to the hugepage during the split (which happens in
> > +* place). If we overwrite the pmd with the not-huge version pointing
> > +* to the pte here (which of course we could if all CPUs were bug
> > +* free), userland could trigger a small page size TLB miss on the
> > +* small sized TLB while the hugepage TLB entry is still established in
> > +* the huge TLB. Some CPU doesn't like that.
> > +* See http://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum
> > +* 383 on page 93. Intel should be safe but is also warns that it's
> > +* only safe if the permission and cache attributes of the two entries
> > +* loaded in the two TLB is identical (which should be the case here).
> > +* But it is generally safer to never allow small and huge TLB entries
> > +* for the same virtual address to be loaded simultaneously. So instead
> > +* of doing "pmd_populate(); flush_pmd_tlb_range();" we first mark the
> > +* current pmd notpresent (atomically because here the pmd_trans_huge
> > +* and pmd_trans_splitting must remain set at all times on the pmd
> > +* until the split is complete for this pmd), then we flush the SMP TLB
> > +* and finally we write the non-huge version of the pmd entry with
> > +* pmd_populate.
> > +*/
> > +   pmdp_invalidate(vma, haddr, pmd);
> > pmd_populate(mm, pmd, pgtable);
> >  
> > if (freeze) {
> 
> I have been tested this patch with MADV_DONTNEED for a few days and
> I couldn't see the problem any more. And I will continue to test it
> with MADV_FREE.

During the test with MADV_FREE on kernel I applied your patches,
I couldn't see any problem.

However, in this round, I did another test which is same one
I attached but a liitle bit different because it doesn't do
(memcg things/kill/swapoff) for testing program long-live test.

With that, I encountered this problem.

page:eaf60080 count:1 mapcount:0 mapping:88007f584691 
index:0x62a02
flags: 0x4006a028(uptodate|lru|writeback|swapcache|reclaim|swapbacked)
page dumped because: VM_BUG_ON_PAGE(!PageLocked(page))
page->mem_cgroup:880077cf0c00
[ cut here ]
kernel BUG at mm/huge_memory.c:3340!
invalid opcode:  [#1] SMP 
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 7 PID: 1657 Comm: memhog Not tainted 4.3.0-rc5-mm1-madv-free+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006b0f1a40 ti: 88004ced4000 task.ti: 88004ced4000
RIP: 0010:[]  [] 
split_huge_page_to_list+0x907/0x920
RSP: 0018:88004ced7a38  EFLAGS: 00010296
RAX: 0021 RBX: eaf60080 RCX: 81830db8
RDX: 0001 RSI: 0246 RDI: 821df4d8
RBP: 88004ced7ab8 R08:  R09: 880bc560
R10: 8163d880 R11: 00014f25 R12: eaf60080
R13: eaf60088 R14: eaf60080 R15: 
FS:  7f43d3ced740() GS:8800782e() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ff1f6fcdb98 CR3: 4cf56000 CR4: 06a0
Stack:
 cccd eaf60080 88004ced7ad0 eaf60088
 88004ced7ad0  88004ced7ab8 

Re: [PATCH] mm: change may_enter_fs check condition

[yalin wang]

> On Nov 13, 2015, at 23:36, Michal Hocko  wrote:
> 
> On Fri 13-11-15 13:01:16, Vlastimil Babka wrote:
>> On 11/13/2015 12:47 PM, yalin wang wrote:
>>> Add page_is_file_cache() for __GFP_FS check,
>>> otherwise, a Pageswapcache() && PageDirty() page can always be write
>>> back if the gfp flag is __GFP_FS, this is not the expected behavior.
>> 
>> I'm not sure I understand your point correctly *), but you seem to imply
>> that there would be an allocation that has __GFP_FS but doesn't have
>> __GFP_IO? Are there such allocations and does it make sense?
> 
> No it doesn't. There is a natural layering here and __GFP_FS allocations
> should contain __GFP_IO.
> 
> The patch as is makes only little sense to me. Are you seeing any issue
> which this is trying to fix?
mm..
i don’t see issue for this part ,
just feel confuse when i see code about this part ,
then i make a patch for this .
i am not sure if __GFP_FS will make sure __GFP_IO flag must be always set.
if it is ,  i think can add comment here to make people clear . :)

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/

[PATCH 1/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7

[Krzysztof Kozlowski]

Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
so it is built also on ARMv7. This does not bring any kind of benefit.
There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
multi_v7 for ARMv7).

Instead build clock drivers only for respective SoC's architecture.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/clk/samsung/Kconfig  | 13 +
 drivers/clk/samsung/Makefile |  4 ++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
index 84196ecdaa12..5f138fc4d84d 100644
--- a/drivers/clk/samsung/Kconfig
+++ b/drivers/clk/samsung/Kconfig
@@ -2,6 +2,7 @@ config COMMON_CLK_SAMSUNG
bool
select COMMON_CLK
 
+# ARMv7 SoCs:
 config S3C2410_COMMON_CLK
bool
select COMMON_CLK_SAMSUNG
@@ -24,3 +25,15 @@ config S3C2443_COMMON_CLK
bool
select COMMON_CLK_SAMSUNG
 
+# ARMv8 SoCs:
+config EXYNOS5433_COMMON_CLK
+   bool
+   depends on ARM64 || COMPILE_TEST
+   default ARCH_EXYNOS
+   select COMMON_CLK_SAMSUNG
+
+config EXYNOS7_COMMON_CLK
+   bool
+   depends on ARM64 || COMPILE_TEST
+   default ARCH_EXYNOS
+   select COMMON_CLK_SAMSUNG
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 5f6833ea355d..a31332a24ef4 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -10,11 +10,11 @@ obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5260)   += clk-exynos5260.o
 obj-$(CONFIG_SOC_EXYNOS5410)   += clk-exynos5410.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
-obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos5433.o
+obj-$(CONFIG_EXYNOS5433_COMMON_CLK)+= clk-exynos5433.o
 obj-$(CONFIG_SOC_EXYNOS5440)   += clk-exynos5440.o
 obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos-audss.o
 obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos-clkout.o
-obj-$(CONFIG_ARCH_EXYNOS7) += clk-exynos7.o
+obj-$(CONFIG_EXYNOS7_COMMON_CLK)   += clk-exynos7.o
 obj-$(CONFIG_S3C2410_COMMON_CLK)+= clk-s3c2410.o
 obj-$(CONFIG_S3C2410_COMMON_DCLK)+= clk-s3c2410-dclk.o
 obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
-- 
1.9.1

--
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 2/2] arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS

[Krzysztof Kozlowski]

The ARMv8 Exynos family SoCs in Linux kernel are currently:
 - Exynos5433 (controlled by ARCH_EXYNOS),
 - Exynos7 (controlled by ARCH_EXYNOS7).

It duplicates Kconfig symbols unnecessarily, so consolidate them into
one ARCH_EXYNOS. Future SoCs could fall also under the ARCH_EXYNOS
symbol.

The commit should not bring any visible functional change.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/Kconfig.platforms| 11 ++-
 arch/arm64/boot/dts/exynos/Makefile |  2 +-
 arch/arm64/configs/defconfig|  2 +-
 3 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4043c35962cc..afa19baca94e 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -13,21 +13,14 @@ config ARCH_BERLIN
  This enables support for Marvell Berlin SoC Family
 
 config ARCH_EXYNOS
-   bool
-   help
- This enables support for Samsung Exynos SoC family
-
-config ARCH_EXYNOS7
-   bool "ARMv8 based Samsung Exynos7"
-   select ARCH_EXYNOS
+   bool "ARMv8 based Samsung Exynos SoC family"
select COMMON_CLK_SAMSUNG
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
select PINCTRL
select PINCTRL_EXYNOS
-
help
- This enables support for Samsung Exynos7 SoC family
+ This enables support for Samsung Exynos ARMv8 SoC family
 
 config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
diff --git a/arch/arm64/boot/dts/exynos/Makefile 
b/arch/arm64/boot/dts/exynos/Makefile
index 20310e5b6d6f..50c9b9383cfa 100644
--- a/arch/arm64/boot/dts/exynos/Makefile
+++ b/arch/arm64/boot/dts/exynos/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos7-espresso.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index bdd7aa358d2a..a396fa7c69a5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -33,7 +33,7 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
-CONFIG_ARCH_EXYNOS7=y
+CONFIG_ARCH_EXYNOS=y
 CONFIG_ARCH_LAYERSCAPE=y
 CONFIG_ARCH_HISI=y
 CONFIG_ARCH_MEDIATEK=y
-- 
1.9.1

--
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] mm: fix kernel crash in khugepaged thread

[yalin wang]

> On Nov 13, 2015, at 22:01, Steven Rostedt  wrote:
> 
> On Fri, 13 Nov 2015 19:54:11 +0800
> yalin wang  wrote:
> 
>   TP_fast_assign(
>   __entry->mm = mm;
> - __entry->pfn = pfn;
> + __entry->pfn = page_to_pfn(page);  
 
 Instead of the condition, we could have:
 
__entry->pfn = page ? page_to_pfn(page) : -1;  
>>> 
>>> I agree. Please do it like this.  
> 
> hmm, pfn is defined as an unsigned long, would -1 be the best.
> Or should it be (-1UL).
> 
> Then we could also have:
> 
>TP_printk("mm=%p, scan_pfn=0x%lx%s, writable=%d, referenced=%d, 
> none_or_zero=%d, status=%s, unmapped=%d",
>__entry->mm,
>__entry->pfn == (-1UL) ? 0 : __entry->pfn,
>   __entry->pfn == (-1UL) ? "(null)" : "",
> 
> Note the added %s after %lx I have in the print format.
> 
> -- Steve
it is not easy to print for perf tools in userspace ,
if you use this format ,
for user space perf tool, it print the entry by look up the member in entry 
struct by offset ,
you print a dynamic string which user space perf tool don’t know how to print 
this string .

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/

[PATCH 0/2] arm64: EXYNOS: Consolidate Exynos7 symbol

[Krzysztof Kozlowski]

Hi,

We don't need ARCH_EXYNOS7 symbol because all ARMv8 platforms should
fall under generic ARCH_EXYNOS. In the same time there is no sense
in building clocks for these ARMv8 SoCs on ARMv7 builds. In future
this will also influence PMU [1] driver.

Patch 2 *depends* on patch 1. With ack from clock guys everything could
go through ARM64 tree... or the opposite path.

Best regards,
Krzysztof


[1] https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg48090.html



Krzysztof Kozlowski (2):
  clk: samsung: Don't build ARMv8 clock drivers on ARMv7
  arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS

 arch/arm64/Kconfig.platforms| 11 ++-
 arch/arm64/boot/dts/exynos/Makefile |  2 +-
 arch/arm64/configs/defconfig|  2 +-
 drivers/clk/samsung/Kconfig | 13 +
 drivers/clk/samsung/Makefile|  4 ++--
 5 files changed, 19 insertions(+), 13 deletions(-)

-- 
1.9.1

--
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 15/20] staging/wilc1000: pass hif operations through initialization

[glen lee]

On 2015년 11월 13일 18:17, Arnd Bergmann wrote:

On Friday 13 November 2015 16:49:22 glen lee wrote:

Hi arnd,

I found this. These should be like this. It works fine.
+   .hif_block_tx_ext = sdio_write,
+   .hif_block_rx_ext = sdio_read,

also, wilc_hif_spi need to be fixed together like this.
+   .hif_block_tx_ext = _wilc_spi_write,
+   .hif_block_rx_ext = _wilc_spi_read,

Thank you for all the patches.


Glad you found it. How should we go on to get the right version merged?
Do you want to send the working version of my patches to Greg along with
whatever you have on your end, or do you prefer me to re-send it?


In my opinion, why don't you re-send the whole patches again since I'm still 
working on.

regards,
glen lee.


Arnd


--
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 4.4-rc1

[Linus Torvalds]

So it's Sunday, two weeks has passed, and so 4.4-rc1 is out there and
the merge window is closed.

As usual, the full shortlog is much too big to post, so appended is
the usual shortlog of just my merges, which just shows who I did pulls
from, with a very short comment on each merge.

Just looking at the patch itself, things look fairly normal at a high
level, possibly a bit more driver-heavy than usual with about 75% of
the patch being drivers, and 10% being architecture updates. The
remaining 15% is documentation, filesystem, core networking (as
opposed to network drivers), tooling and some core infrastructure.

The driver changes are all over, although staging, networking and GPU
drivers stand out (and those three areas account for over half of the
driver changes - roughly 40% of the whole patch).

On the architecture side, ARM (when counting both 32-bit and 64-bit)
accounts for about half the changes, with x86, powerpc, mips, chris
and s390 accounting for the other half.

Go out and test.

Linus

---

Al Viro (2):
vfs update
vfs xattr cleanups

Alex Williamson (1):
VFIO updates

Alexandre Belloni (1):
RTC updates

Andrew Morton (4):
patch-bomb
second patch-bomb
third patch-bomb
final patch-bomb

Arnd Bergmann (1):
asm-generic cleanups

Bjorn Helgaas (1):
PCI updates

Bob Peterson (1):
gfs2 updates

Borislav Petkov (1):
EDAC updates

Brian Norris (1):
MTD updates

Bruce Fields (1):
nfsd updates

Catalin Marinas (2):
arm64 updates
arm64 fixes and clean-ups

Chris Mason (2):
btrfs updates
btrfs fixes and cleanups

Chris Zankel (1):
xtensa updates

Dan Williams (2):
libnvdimm updates
libnvdimm fixes

Darren Hart (2):
x86 platform driver update
another x86 platform driver update

Dave Airlie (4):
drm updates
drm fixes
drm fixes
drm sti driver updates

Dave Chinner (1):
xfs updates

David Miller (4):
networking updates
IDE fixlet
sparc updates
networking fixes

David Teigland (1):
dlm update

David Vrabel (1):
xen updates

David Woodhouse (1):
intel iommu updates

Dmitry Torokhov (2):
input updates
more input updates

Doug Ledford (1):
rdma updates

Eric Biederman (1):
userns hardlink capability check fix

Geert Uytterhoeven (1):
m68k update

Greg KH (5):
USB updates
tty/serial driver updates
staging driver updates
driver core updates
char/misc driver updates

Greg Ungerer (1):
m68knommu/coldfire fix

Guenter Roeck (1):
hwmon updates

Hans-Christian Noren Egtvedt (1):
avr32 update

Helge Deller (2):
parisc updates
parisc updates

Herbert Xu (2):
crypto update
crypto fix

Ingo Molnar (17):
wchan kernel address hiding
EFI changes
RCU changes
locking changes
perf updates
RAS changes
scheduler changes
x86 apic changes
x86 asm changes
x86 boot cleanup
x86 cleanups
x86 cpu changes
x86 kgdb fixlet
x86 fpu changes
x86 sigcontext header cleanups
x86 mm changes
x86 platform changes

Jacek Anaszewski (1):
LED updates

Jaegeuk Kim (1):
f2fs updates

James Bottomley (2):
SCSI updates
final round of SCSI updates

James Hogan (1):
metag arch updates

James Morris (2):
security subsystem update
security subsystem fixes

Jan Kara (1):
ext2 fix

Jassi Brar (1):
mailbox updates

Jean Delvare (1):
tiny hwmon update

Jeff Layton (1):
file locking updates

Jens Axboe (7):
core block updates
block driver updates
lightnvm support
block integrity updates
block reservation support
block IO poll support
misc block fixes

Jesper Nilsson (1):
CRIS changes

Jiri Kosina (3):
livepatching fix
HID updates
trivial updates

Joerg Roedel (1):
iommu updates

Jon Corbet (2):
documentation update
more documentation updates

Jon Mason (1):
NTB bugfixes

Lee Jones (2):
MFD updates
backlight updates

Ley Foon Tan (1):
nios2 updates

Linus Walleij (2):
pin control updates
GPIO updates

Mark Brown (3):
regmap updates
regulator updates
spi updates

Martin Schwidefsky (1):
s390 updates

Mauro Carvalho Chehab (1):
media updates

Michael Ellerman (1):
powerpc updates

Michal Marek (3):
kbuild update
kconfig updates
misc kbuild updates

Mike Snitzer (1):
device mapper updates

Neil Brown (2):
md updates
config fix for md

Nicholas Bellinger (1):
SCSI target updates

Olof Johansson (7):
ARM SoC non-urgent fixes
ARM SoC cleanups
ARM SoC platform updates
ARM SoC driver updates
ARM DT updates
ARM SoC defconfig updates
chrome platform updates

Paolo Bonzini (2):
KVM updates
second batch of kvm updates

Paul Moore (1):
audit updates

Rafael Wysocki (2):
power management and ACPI updates
more power management and ACPI updates

Ralf Baechle (1):
MIPS

Re: [PATCHv5 3/3] drm: bridge: anx78xx: Add anx78xx driver support by analogix.

[kbuild test robot]

Hi Enric,

[auto build test ERROR on: robh/for-next]
[also build test ERROR on: v4.3 next-20151115]
[cannot apply to: drm/drm-next]

url:
https://github.com/0day-ci/linux/commits/Enric-Balletbo-i-Serra/Add-initial-support-for-slimport-anx78xx/20151113-200502
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: i386-randconfig-h1-11160814 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c: In function 
'anx78xx_i2c_probe':
>> drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c:203:17: error: 'struct 
>> drm_bridge' has no member named 'of_node'
 anx78xx->bridge.of_node = client->dev.of_node;
^

vim +203 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c

   197  anx78xx->pdata = devm_kzalloc(&client->dev,
   198sizeof(struct 
anx78xx_platform_data),
   199GFP_KERNEL);
   200  if (!anx78xx->pdata)
   201  return -ENOMEM;
   202  
 > 203  anx78xx->bridge.of_node = client->dev.of_node;
   204  anx78xx->bridge.funcs = &anx78xx_bridge_funcs;
   205  ret = drm_bridge_add(&anx78xx->bridge);
   206  if (ret < 0) {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v5 00/11] exynos-ufs: add support for Exynos

[Alim Akhtar]

Hi Kishon,

Any more concern on the PHY part of this series?

Thanks!

On Mon, Nov 9, 2015 at 10:56 AM, Alim Akhtar  wrote:
> This patch-set introduces UFS (Universal Flash Storage) host support
> for Samsung Exynos SoC. Mostly, it consists of UFS PHY and host specific 
> driver.
> And it also contains some quirks handling for Exynos.
>
> NOTE: ** This series has a dependency on [4]. **
>
> -Changes since v4:
> * Removed platform specific PHY ops as suggested by Kishon
> * Rebased on the top of Yaniv Gardi's work [4]
> * make use of newly introduce ufshcd_{get,set}_variant
> * other small changes and improvements.
> * rebased on the top of linux next-20151109
>
> -Changes since v3:
> * Fixed compilation warrings as reported by "Kbuild Test Robot"[5].
> * Restructure the driver to make it as a platform driver, rebased on top of 
> [4].
> * Addressed review comments from Arnd Bergmann[5].
> * Other misc changes and improvements.
>
> -Changes since v2:
> * Addressed review comments from Kishon[1] and Rob Herring [2]
> * Splited ufs dt binding documetation from ufs driver patch
>
> -Changes since v1:
> * Addressed review comments from Alexey[3] and various review comments from 
> Amit.
> * Updated email id of Seungwon as his samsung id is void now.
> * Added ufs platform data
>
> [1]-> https://lkml.org/lkml/2015/9/18/29
> [2]-> https://lkml.org/lkml/2015/9/21/668
> [3]-> https://lkml.org/lkml/2015/8/23/124
> [4]-> https://lkml.org/lkml/2015/10/28/271
> [5]-> https://lkml.org/lkml/2015/10/1/402
>
> This patch set is tested on exynos7-espresso board.
>
>
> Alim Akhtar (1):
>   Documentation: samsung-phy: Add dt bindings for UFS
>
> Seungwon Jeon (10):
>   phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC
>   scsi: ufs: add quirk to contain unconformable utrd field
>   scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr
>   scsi: ufs: add quirk not to allow reset of interrupt aggregation
>   scsi: ufs: add quirk to enable host controller without hce
>   scsi: ufs: add specific callback for nexus type
>   scsi: ufs: add add specific callback for hibern8
>   scsi: ufs: make ufshcd_config_pwr_mode of non-static func
>   Documentation: devicetree: ufs: Add DT bindings for exynos UFS host
> controller
>   scsi: ufs-exynos: add UFS host support for Exynos SoCs
>
>  .../devicetree/bindings/phy/samsung-phy.txt|   22 +
>  .../devicetree/bindings/ufs/ufs-exynos.txt |  104 ++
>  drivers/phy/Kconfig|7 +
>  drivers/phy/Makefile   |1 +
>  drivers/phy/phy-exynos-ufs.c   |  241 
>  drivers/phy/phy-exynos-ufs.h   |   85 ++
>  drivers/phy/phy-exynos7-ufs.h  |   89 ++
>  drivers/scsi/ufs/Kconfig   |   12 +
>  drivers/scsi/ufs/Makefile  |1 +
>  drivers/scsi/ufs/ufs-exynos-hw.c   |  131 ++
>  drivers/scsi/ufs/ufs-exynos-hw.h   |   43 +
>  drivers/scsi/ufs/ufs-exynos.c  | 1304 
> 
>  drivers/scsi/ufs/ufs-exynos.h  |  247 
>  drivers/scsi/ufs/ufshcd.c  |  168 ++-
>  drivers/scsi/ufs/ufshcd.h  |   54 +
>  drivers/scsi/ufs/ufshci.h  |   26 +-
>  drivers/scsi/ufs/unipro.h  |   47 +
>  include/linux/phy/phy-exynos-ufs.h |   85 ++
>  18 files changed, 2647 insertions(+), 20 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt
>  create mode 100644 drivers/phy/phy-exynos-ufs.c
>  create mode 100644 drivers/phy/phy-exynos-ufs.h
>  create mode 100644 drivers/phy/phy-exynos7-ufs.h
>  create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
>  create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
>  create mode 100644 drivers/scsi/ufs/ufs-exynos.c
>  create mode 100644 drivers/scsi/ufs/ufs-exynos.h
>  create mode 100644 include/linux/phy/phy-exynos-ufs.h
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Regards,
Alim
--
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: BUG: unable to handle kernel paging request at ffffe8ff7fc00001

[Linus Torvalds]

On Sun, Nov 15, 2015 at 2:28 PM, Kyle Sanderson  wrote:
> [] BUG: unable to handle kernel paging request at e8ff7fc1
> [] IP: [] kstat_irqs+0x4f/0x90
> [] CPU: 2 PID: 1078 Comm: usage.pl Not tainted 4.1.7-hardened-r1 #1
> [] Hardware name: Supermicro Super Server/X10SRi-F, BIOS 1.0b 04/21/2015
RSI: 60f70001
> [] Call Trace:
> []  [<>] kstat_irqs_usr+0x1e/0x40
> []  [<>] show_stat+0x5ca/0x690
> []  [<>] seq_read+0xcd/0x3b0
> []  [<>] proc_reg_read+0x43/0x70
> []  [<>] __vfs_read+0x23/0xd0
> []  [<>] vfs_read+0xc0/0x1d0
> []  [<>] SyS_read+0x41/0xb0
> []  [<>] system_call_fastpath+0x16/0x72
> [] Code: 83 78 48 00 74 56 4c 8b ...

The code ends up being

  mov0x48(%r13),%rsi
  mov__per_cpu_offset(,%rcx,8),%rcx
  add(%rsi,%rcx,1),%ebx <-- trapping instruction

which is just the

   sum += *per_cpu_ptr(desc->kstat_irqs, cpu);

part of kstat_irqs().

Your registers being

   RSI: 60f70001
   RCX: 88087fc0

and it's RSI that makes no sense - RCX looks like a real kernel
pointer. So it looks like it's the "desc->kstat_irqs" thing that is
for some reason garbage.

I don't see any sane possible reason this would happen, though.
Thomas, does this look like anything you've seen before?

 Linus
--
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: Kernel 4.1 hang, apparently in __inet_lookup_established

[Grant Zhang]

Hi Patrick,

Have you tried the two patches Eric mentioned? One of my 4.1.11 server 
just hanged with very similar stack trace and I am wondering whether the 
aforementioned patches would help.


Thanks,

Grant

On 23/09/2015 09:31, Eric Dumazet wrote:

On Wed, 2015-09-23 at 10:25 +0200, Patrick Schaaf wrote:

Dear kernel developers,

I recently started to upgrade my production hosts and VMs from the 3.14 series
to 4.1 kernels, starting with 4.1.6. Yesterday, for the second time after I
started these upgrades, I experienced one of our webserver VMs hanging.

The first time this happened, the VM hung completely, all 5 virtual cores
spinning at 100%, ping still worked, but nothing else, including no virsh
console reaction - I had to destroy and restart that VM. No messages were to
be found.

Yesterday, when it happened the second time, I found the VM spinning on a
single core only, and could still connect to it via ssh - but it stopped
accepting apache connections. The core it spun on showed 100% time used in
"si", with top, and it produced the messages appended below. The VM did not
shutdown properly when told to, and had to be destroyed again.

If I read that dmesg output correctly it spins in __inet_lookup_established,
which indeed reads like it has infinite spin potential. But that code itself
did not change relative to the 3.14 series we've been running for a long time
without the issues - so the root cause would be something else.

For our production systems I'll revert to the 3.14 series, but maybe this
report may help somebody understand what's going on.

best regards
   Patrick



You could try following commits :

http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=ed2e923945892a8372ab70d2f61d364b0b6d9054

http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=29c6852602e259d2c1882f320b29d5c3fec0de04



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
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: Section mismatches in arch/powerpc/kernel/head_64.S

[Michael Ellerman]

Hi Laura,

On Thu, 2015-11-12 at 13:39 -0800, Laura Abbott wrote:
> Hi,
 
> There seem to be section mismatches coming from head_64.S
> 
> WARNING: vmlinux.o(.text+0x8994): Section mismatch in reference from the
> variable __boot_from_prom to the function .init.text:prom_init()
> The function __boot_from_prom() references
> the function __init prom_init().
> This is often because __boot_from_prom lacks a __init
> annotation or the annotation of prom_init is wrong.
> 
> WARNING: vmlinux.o(.text+0x8c30): Section mismatch in reference from the
> variable start_here_multiplatform to the function .init.text:early_setup()
> The function start_here_multiplatform() references
> the function __init early_setup().
> This is often because start_here_multiplatform lacks a __init
> annotation or the annotation of early_setup is wrong.
> 
> WARNING: vmlinux.o(.text+0x8c54): Section mismatch in reference from the
> variable start_here_common to the function .init.text:setup_system()
> The function start_here_common() references
> the function __init setup_system().
> This is often because start_here_common lacks a __init
> annotation or the annotation of setup_system is wrong.
> 
> WARNING: vmlinux.o(.text+0x8c68): Section mismatch in reference from the
> variable start_here_common to the function .init.text:start_kernel()
> The function start_here_common() references
> the function __init start_kernel().
> This is often because start_here_common lacks a __init
> annotation or the annotation of start_kernel is wrong.

These all look correct, ie. they are references from non-init code to init
code. I don't think any of them are real bugs, because that is all early boot
code anyway which should never run after boot, or if it did that would be a big
anyway.

I'm not sure how we fix them. Some of that code might be able to be moved out
of head_64.S and made __init, but then you just have the same problem again.

It looks like x86 calls through a pointer and marks that as __REFDATA, but
that's kind of gross just to avoid a section mismatch warning.

So I'm not sure what the solution is here.

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 -next] serial: etraxfs-uart: Fix crash

[Guenter Roeck]

On 11/15/2015 03:54 PM, Niklas Cassel wrote:

I think that Guenter's patch should be merged asap.
Right now the bug it fixes stops us from boot testing in qemu.



I'll send out a build (failure) report after -rc1 is out.
Maybe that will create enough visibility to get the patch accepted
(or officially Nacked).

Guenter


For the broken mctrl irq handling part, when Uwe
has converted mxs-auart to use the generic irq init,
I can do the same for etraxfs + make sure that it gets tested
properly on real hardware.

On 11/02/2015 10:29 PM, Uwe Kleine-König wrote:

Helo Niklas,

On Mon, Nov 02, 2015 at 10:13:25PM +0100, Niklas Cassel wrote:

On 11/02/2015 08:37 AM, Uwe Kleine-König wrote:

The function call in the etraxfs-uart driver was not renamed,
possibly due to interference with commit 7b9c5162c182 ("serial:
etraxfs-uart: use mctrl_gpio helpers for handling modem signals").

Yes. BTW, 7b9c5162c182 looks broken, too, because the interrupt handling
is missing.

The only drivers including serial_mctrl_gpio.h is atmel_serial.c,
clps711x.c, mxs-auart.c and etraxfs-uart.c

etraxfs commit
7b9c5162c182 ("serial: etraxfs-uart: use mctrl_gpio helpers for handling modem 
signals")
is heavily influenced by
62b0a1b3e759 ("serial: clps711x: Use mctrl_gpio helpers for handling modem 
signals")

a driver which also appears to lack mctrl irq setup/handling.


Uwe, are you going to convert all serial drivers that includes 
serial_mctrl_gpio.h to
use the new mctrl_gpio_init? (which also sets up irqs)

That is the plan. For drivers like mxs-auart (that do irq handling) this
is just simplification. When the irq handling is missing converting to
the new mctrl_gpio_init might introduce regressions because it does
request_irq which might fail.


Since mctrl gpios are optional in the device tree, I guess mctrl_gpio_init 
handles if
they are missing. So even if etraxfs-uart.c currently lacks mctrl irq 
setup/handling,
if we migrate it to use the new mctrl_gpio_init, we will get this automatically?

Right, if there are no gpios specified (new and old) mctrl_gpio is a
nop.

Best regards
Uwe






--
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] IIO: adc: at91_adc.c Prefer kmalloc_array over kmalloc with multiply

[Nizam Haider]

So this patch swaps that use out for kmalloc_array instead.

Signed-off-by Nizam Haider 
---
 drivers/iio/adc/at91_adc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 7b40925..f284cd6 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -742,7 +742,7 @@ static int at91_adc_of_get_resolution(struct at91_adc_state 
*st,
return count;
}
 
-   resolutions = kmalloc(count * sizeof(*resolutions), GFP_KERNEL);
+   resolutions = kmalloc_array(count, sizeof(*resolutions), GFP_KERNEL);
if (!resolutions)
return -ENOMEM;
 
-- 
1.8.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 -next] serial: etraxfs-uart: Fix crash

[Niklas Cassel]

I think that Guenter's patch should be merged asap.
Right now the bug it fixes stops us from boot testing in qemu.

For the broken mctrl irq handling part, when Uwe
has converted mxs-auart to use the generic irq init,
I can do the same for etraxfs + make sure that it gets tested
properly on real hardware.

On 11/02/2015 10:29 PM, Uwe Kleine-König wrote:
> Helo Niklas,
>
> On Mon, Nov 02, 2015 at 10:13:25PM +0100, Niklas Cassel wrote:
>> On 11/02/2015 08:37 AM, Uwe Kleine-König wrote:
 The function call in the etraxfs-uart driver was not renamed,
 possibly due to interference with commit 7b9c5162c182 ("serial:
 etraxfs-uart: use mctrl_gpio helpers for handling modem signals").
>>> Yes. BTW, 7b9c5162c182 looks broken, too, because the interrupt handling
>>> is missing.
>> The only drivers including serial_mctrl_gpio.h is atmel_serial.c,
>> clps711x.c, mxs-auart.c and etraxfs-uart.c
>>
>> etraxfs commit
>> 7b9c5162c182 ("serial: etraxfs-uart: use mctrl_gpio helpers for handling 
>> modem signals")
>> is heavily influenced by
>> 62b0a1b3e759 ("serial: clps711x: Use mctrl_gpio helpers for handling modem 
>> signals")
>>
>> a driver which also appears to lack mctrl irq setup/handling.
>>
>>
>> Uwe, are you going to convert all serial drivers that includes 
>> serial_mctrl_gpio.h to
>> use the new mctrl_gpio_init? (which also sets up irqs)
> That is the plan. For drivers like mxs-auart (that do irq handling) this
> is just simplification. When the irq handling is missing converting to
> the new mctrl_gpio_init might introduce regressions because it does
> request_irq which might fail.
>
>> Since mctrl gpios are optional in the device tree, I guess mctrl_gpio_init 
>> handles if
>> they are missing. So even if etraxfs-uart.c currently lacks mctrl irq 
>> setup/handling,
>> if we migrate it to use the new mctrl_gpio_init, we will get this 
>> automatically?
> Right, if there are no gpios specified (new and old) mctrl_gpio is a
> nop.
>
> Best regards
> Uwe
>

--
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 v4 2/2] media: v4l: ti-vpe: Document CAL driver

[Benoit Parrot]

Device Tree bindings for the Camera Adaptation Layer (CAL) driver

Signed-off-by: Benoit Parrot 
---
 Documentation/devicetree/bindings/media/ti-cal.txt | 70 ++
 1 file changed, 70 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/ti-cal.txt

diff --git a/Documentation/devicetree/bindings/media/ti-cal.txt 
b/Documentation/devicetree/bindings/media/ti-cal.txt
new file mode 100644
index ..680efadb6208
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti-cal.txt
@@ -0,0 +1,70 @@
+Texas Instruments DRA72x CAMERA ADAPTATION LAYER (CAL)
+--
+
+The Camera Adaptation Layer (CAL) is a key component for image capture
+applications. The capture module provides the system interface and the
+processing capability to connect CSI2 image-sensor modules to the
+DRA72x device.
+
+Required properties:
+- compatible: must be "ti,cal"
+- reg: physical base address and length of the registers set for the 4
+   memory regions required;
+- reg-names: name associated with the memory regions described is ;
+- interrupts: should contain IRQ line for the CAL;
+
+CAL supports 2 camera port nodes on MIPI bus. Each CSI2 camera port nodes
+should contain a 'port' child node with child 'endpoint' node. Please
+refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+   cal: cal@4845b000 {
+   compatible = "ti,cal";
+   ti,hwmods = "cal";
+   reg = <0x4845B000 0x400>,
+ <0x4845B800 0x40>,
+ <0x4845B900 0x40>,
+ <0x4A002e94 0x4>;
+   reg-names = "cal_top",
+   "cal_rx_core0",
+   "cal_rx_core1",
+   "camerrx_control";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   csi2_0: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+   endpoint {
+   slave-mode;
+   remote-endpoint = <&ar0330_1>;
+   };
+   };
+   csi2_1: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+
+   i2c5: i2c@4807c000 {
+   ar0330@10 {
+   compatible = "ti,ar0330";
+   reg = <0x10>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ar0330_1: endpoint {
+   reg = <0>;
+   clock-lanes = <1>;
+   data-lanes = <0 2 3 4>;
+   remote-endpoint = <&csi2_0>;
+   };
+   };
+   };
+   };
-- 
1.8.5.1

--
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 v4 1/2] media: v4l: ti-vpe: Add CAL v4l2 camera capture driver

[Benoit Parrot]

The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data lanes.
The driver implements the required API/ioctls to be V4L2 compliant.
Driver supports the following:
- V4L2 API using DMABUF/MMAP buffer access based on videobuf2 api
- Asynchronous sensor sub device registration
- DT support

Signed-off-by: Benoit Parrot 
Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/Kconfig   |   12 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/ti-vpe/Makefile   |4 +
 drivers/media/platform/ti-vpe/cal.c  | 2164 ++
 drivers/media/platform/ti-vpe/cal_regs.h |  779 +++
 5 files changed, 2961 insertions(+)
 create mode 100644 drivers/media/platform/ti-vpe/cal.c
 create mode 100644 drivers/media/platform/ti-vpe/cal_regs.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ccbc9742cb7a..373a0f62534a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -120,6 +120,18 @@ source "drivers/media/platform/s5p-tv/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 
+config VIDEO_TI_CAL
+   tristate "TI CAL (Camera Adaptation Layer) driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on SOC_DRA7XX || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   default n
+   ---help---
+ Support for the TI CAL (Camera Adaptation Layer) block
+ found on DRA72X SoC.
+ In TI Technical Reference Manual this module is referred as
+ Camera Interface Subsystem (CAMSS).
+
 endif # V4L_PLATFORM_DRIVERS
 
 menuconfig V4L_MEM2MEM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index efa0295af87b..028a7233096b 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -18,6 +18,8 @@ obj-$(CONFIG_VIDEO_VIM2M) += vim2m.o
 
 obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe/
 
+obj-$(CONFIG_VIDEO_TI_CAL) += ti-vpe/
+
 obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o
 obj-$(CONFIG_VIDEO_CODA)   += coda/
 
diff --git a/drivers/media/platform/ti-vpe/Makefile 
b/drivers/media/platform/ti-vpe/Makefile
index be680f839e77..e236059a60ad 100644
--- a/drivers/media/platform/ti-vpe/Makefile
+++ b/drivers/media/platform/ti-vpe/Makefile
@@ -3,3 +3,7 @@ obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe.o
 ti-vpe-y := vpe.o sc.o csc.o vpdma.o
 
 ccflags-$(CONFIG_VIDEO_TI_VPE_DEBUG) += -DDEBUG
+
+obj-$(CONFIG_VIDEO_TI_CAL) += ti-cal.o
+
+ti-cal-y := cal.o
diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
new file mode 100644
index ..5bfcddb068b9
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -0,0 +1,2164 @@
+/*
+ * TI CAL camera interface driver
+ *
+ * Copyright (c) 2015 Texas Instruments Inc.
+ * Benoit Parrot, 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "cal_regs.h"
+
+#define CAL_MODULE_NAME "cal"
+
+#define MAX_WIDTH 1920
+#define MAX_HEIGHT 1200
+
+#define CAL_VERSION "0.1.0"
+
+MODULE_DESCRIPTION("TI CAL driver");
+MODULE_AUTHOR("Benoit Parrot, ");
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(CAL_VERSION);
+
+static unsigned video_nr = -1;
+module_param(video_nr, uint, 0644);
+MODULE_PARM_DESC(video_nr, "videoX start number, -1 is autodetect");
+
+static unsigned debug;
+module_param(debug, uint, 0644);
+MODULE_PARM_DESC(debug, "activates debug info");
+
+/* timeperframe: min/max and default */
+static const struct v4l2_fract
+   tpf_default = {.numerator = 1001,   .denominator = 3};
+
+#define cal_dbg(level, caldev, fmt, arg...)\
+   v4l2_dbg(level, debug, &caldev->v4l2_dev, fmt, ##arg)
+#define cal_info(caldev, fmt, arg...)  \
+   v4l2_info(&caldev->v4l2_dev, fmt, ##arg)
+#define cal_err(caldev, fmt, arg...)   \
+   v4l2_err(&caldev->v4l2_dev, fmt, ##arg)
+
+#define ctx_dbg(level, ctx, fmt, arg...)   \
+   v4l2_dbg(level, debug, &ctx->v4l2_dev, fmt, ##arg)
+#define ctx_info(ctx, fmt, arg...) \
+   v4l2_info(&ctx->v4l2_dev, fmt, ##arg)
+#define ctx_err(ctx, fmt, arg...)  \
+   v4l2_err(&ctx->v4l2_dev, fmt, ##arg)
+
+#define CAL_NUM_INPUT 1
+#define CAL_NUM_CONTEXT 2
+
+/* ---

[Patch v4 0/2] media: v4l: ti-vpe: Add CAL v4l2 camera capture driver

[Benoit Parrot]

The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
This camera engine is currently found on DRA72xx family of devices.

Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data lanes.

The driver implements the required API/ioctls to be V4L2 compliant.
Driver supports the following:
- V4L2 API using DMABUF/MMAP buffer access based on videobuf2 api
- Asynchronous sensor sub device registration
- DT support

Currently each port is designed to connect to a single sub-device.
In other words port aggregation is not currently supported.

Changes since v3:
- Nothing really I messed up the previous format-patch with the
  wrong commit-id. Sorry about the repeat.

Changes since v2:
- Rework Kconfig options and added COMPILE_TEST
- Merged in provided vb2 buffer rework
- Rebase on tip of lmm master and fixe vb2 split related changes

Changes since v1:
- Remove unnecessary format description
- Reworked how transient frame format is maintained
  in order to make it easier to use the fill helper functions
- Added a per port list of active frame format
- Reworked an added missing vb2 cleanup code
- Fix a module load/unload kernel oops
- Switch to use proper int64 get function for pixel rate control

=

Here is a sample output of the v4l2-compliance tool:

# ./v4l2-compliance -f -s -v -d /dev/video0 
Driver Info:
Driver name   : cal
Card type : cal
Bus info : platform:cal-000

Capabilities  : 0x8521
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0521
Video Capture
Read/Write
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Test input 0:

Control ioctls:
info: checking v4l2_queryctrl of control 'User Controls' 
(0x00980001)
info: checking v4l2_queryctrl of control 'Horizontal Flip' 
(0x00980914)
info: checking v4l2_queryctrl of control 'Vertical Flip' 
(0x00980915)
info: checking v4l2_queryctrl of control 'Image Processing 
Controls' (0x009f0001)
info: checking v4l2_queryctrl of control 'Pixel Rate' 
(0x009f0902)
info: checking v4l2_queryctrl of control 'Horizontal Flip' 
(0x00980914)
info: checking v4l2_queryctrl of control 'Vertical Flip' 
(0x00980915)
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
info: checking control 'User Controls' (0x00980001)
info: checking control 'Horizontal Flip' (0x00980914)
info: checking control 'Vertical Flip' (0x00980915)
info: checking control 'Image Processing Controls' (0x009f0001)
info: checking control 'Pixel Rate' (0x009f0902)
test VIDIOC_G/S_CTRL: OK
info: checking extended control 'User Controls' (0x00980001)
info: checking extended control 'Horizontal Flip' (0x00980914)
info: checking extended control 'Vertical Flip' (0x00980915)
info: checking extended control 'Image Processing Controls' 
(0x009f0001)
info: checking extended control 'Pixel Rate' (0x009f0902)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
info: checking control event 'User Controls' (0x00980001)
info: checking control event 'Horizontal Flip' (0x00980914)
info: checking contro

[PATCH] IIO: adc: xilinx-xadc-core.c: constify iio_buffer_setup_ops structure

[Nizam Haider]

structure iio_buffer_setup_ops is never modified, so declare it as const.

Signed-off-by: Nizam Haider 
---
 drivers/iio/adc/xilinx-xadc-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/xilinx-xadc-core.c 
b/drivers/iio/adc/xilinx-xadc-core.c
index 0370624..c2b5f10 100644
--- a/drivers/iio/adc/xilinx-xadc-core.c
+++ b/drivers/iio/adc/xilinx-xadc-core.c
@@ -803,7 +803,7 @@ err:
return ret;
 }
 
-static struct iio_buffer_setup_ops xadc_buffer_ops = {
+static const struct iio_buffer_setup_ops xadc_buffer_ops = {
.preenable = &xadc_preenable,
.postenable = &iio_triggered_buffer_postenable,
.predisable = &iio_triggered_buffer_predisable,
-- 
1.8.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 v3 2/2] media: v4l: ti-vpe: Document CAL driver

[Benoit Parrot]

Device Tree bindings for the Camera Adaptation Layer (CAL) driver

Signed-off-by: Benoit Parrot 
---
 Documentation/devicetree/bindings/media/ti-cal.txt | 70 ++
 1 file changed, 70 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/ti-cal.txt

diff --git a/Documentation/devicetree/bindings/media/ti-cal.txt 
b/Documentation/devicetree/bindings/media/ti-cal.txt
new file mode 100644
index ..680efadb6208
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti-cal.txt
@@ -0,0 +1,70 @@
+Texas Instruments DRA72x CAMERA ADAPTATION LAYER (CAL)
+--
+
+The Camera Adaptation Layer (CAL) is a key component for image capture
+applications. The capture module provides the system interface and the
+processing capability to connect CSI2 image-sensor modules to the
+DRA72x device.
+
+Required properties:
+- compatible: must be "ti,cal"
+- reg: physical base address and length of the registers set for the 4
+   memory regions required;
+- reg-names: name associated with the memory regions described is ;
+- interrupts: should contain IRQ line for the CAL;
+
+CAL supports 2 camera port nodes on MIPI bus. Each CSI2 camera port nodes
+should contain a 'port' child node with child 'endpoint' node. Please
+refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+   cal: cal@4845b000 {
+   compatible = "ti,cal";
+   ti,hwmods = "cal";
+   reg = <0x4845B000 0x400>,
+ <0x4845B800 0x40>,
+ <0x4845B900 0x40>,
+ <0x4A002e94 0x4>;
+   reg-names = "cal_top",
+   "cal_rx_core0",
+   "cal_rx_core1",
+   "camerrx_control";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   csi2_0: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+   endpoint {
+   slave-mode;
+   remote-endpoint = <&ar0330_1>;
+   };
+   };
+   csi2_1: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+
+   i2c5: i2c@4807c000 {
+   ar0330@10 {
+   compatible = "ti,ar0330";
+   reg = <0x10>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ar0330_1: endpoint {
+   reg = <0>;
+   clock-lanes = <1>;
+   data-lanes = <0 2 3 4>;
+   remote-endpoint = <&csi2_0>;
+   };
+   };
+   };
+   };
-- 
1.8.5.1

--
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 v3 1/2] media: v4l: ti-vpe: Add CAL v4l2 camera capture driver

[Benoit Parrot]

The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data lanes.
The driver implements the required API/ioctls to be V4L2 compliant.
Driver supports the following:
- V4L2 API using DMABUF/MMAP buffer access based on videobuf2 api
- Asynchronous sensor sub device registration
- DT support

Signed-off-by: Benoit Parrot 
---
 drivers/media/platform/Kconfig   |   12 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/ti-vpe/Makefile   |4 +
 drivers/media/platform/ti-vpe/cal.c  | 2161 ++
 drivers/media/platform/ti-vpe/cal_regs.h |  779 +++
 5 files changed, 2958 insertions(+)
 create mode 100644 drivers/media/platform/ti-vpe/cal.c
 create mode 100644 drivers/media/platform/ti-vpe/cal_regs.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ccbc9742cb7a..c2e34e482b34 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -120,6 +120,18 @@ source "drivers/media/platform/s5p-tv/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 
+config VIDEO_TI_CAL
+   tristate "TI CAL (Camera Adaptation Layer) driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && SOC_DRA7XX
+   depends on VIDEO_V4L2_SUBDEV_API
+   depends on VIDEOBUF2_DMA_CONTIG
+   default n
+   ---help---
+ Support for the TI CAL (Camera Adaptation Layer) block
+ found on DRA72X SoC.
+ In TI Technical Reference Manual this module is referred as
+ Camera Interface Subsystem (CAMSS).
+
 endif # V4L_PLATFORM_DRIVERS
 
 menuconfig V4L_MEM2MEM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index efa0295af87b..028a7233096b 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -18,6 +18,8 @@ obj-$(CONFIG_VIDEO_VIM2M) += vim2m.o
 
 obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe/
 
+obj-$(CONFIG_VIDEO_TI_CAL) += ti-vpe/
+
 obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o
 obj-$(CONFIG_VIDEO_CODA)   += coda/
 
diff --git a/drivers/media/platform/ti-vpe/Makefile 
b/drivers/media/platform/ti-vpe/Makefile
index be680f839e77..e236059a60ad 100644
--- a/drivers/media/platform/ti-vpe/Makefile
+++ b/drivers/media/platform/ti-vpe/Makefile
@@ -3,3 +3,7 @@ obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe.o
 ti-vpe-y := vpe.o sc.o csc.o vpdma.o
 
 ccflags-$(CONFIG_VIDEO_TI_VPE_DEBUG) += -DDEBUG
+
+obj-$(CONFIG_VIDEO_TI_CAL) += ti-cal.o
+
+ti-cal-y := cal.o
diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
new file mode 100644
index ..25167566be91
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -0,0 +1,2161 @@
+/*
+ * TI CAL camera interface driver
+ *
+ * Copyright (c) 2015 Texas Instruments Inc.
+ * Benoit Parrot, 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "cal_regs.h"
+
+#define CAL_MODULE_NAME "cal"
+
+#define MAX_WIDTH 1920
+#define MAX_HEIGHT 1200
+
+#define CAL_VERSION "0.1.0"
+
+MODULE_DESCRIPTION("TI CAL driver");
+MODULE_AUTHOR("Benoit Parrot, ");
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(CAL_VERSION);
+
+static unsigned video_nr = -1;
+module_param(video_nr, uint, 0644);
+MODULE_PARM_DESC(video_nr, "videoX start number, -1 is autodetect");
+
+static unsigned debug;
+module_param(debug, uint, 0644);
+MODULE_PARM_DESC(debug, "activates debug info");
+
+/* timeperframe: min/max and default */
+static const struct v4l2_fract
+   tpf_default = {.numerator = 1001,   .denominator = 3};
+
+#define cal_dbg(level, caldev, fmt, arg...)\
+   v4l2_dbg(level, debug, &caldev->v4l2_dev, fmt, ##arg)
+#define cal_info(caldev, fmt, arg...)  \
+   v4l2_info(&caldev->v4l2_dev, fmt, ##arg)
+#define cal_err(caldev, fmt, arg...)   \
+   v4l2_err(&caldev->v4l2_dev, fmt, ##arg)
+
+#define ctx_dbg(level, ctx, fmt, arg...)   \
+   v4l2_dbg(level, debug, &ctx->v4l2_dev, fmt, ##arg)
+#define ctx_info(ctx, fmt, arg...) \
+   v4l2_info(&ctx->v4l2_dev, fmt, ##arg)
+#define ctx_err(ctx, fmt, arg...)  \
+   v4l2_err(&ctx->v4l2_dev, fmt, ##arg)
+
+#define CAL_NUM_INPUT 1
+#define CAL_NUM_CONTEXT 2
+
+/* --
+   Basic structu

[Patch v3 0/2] media: v4l: ti-vpe: Add CAL v4l2 camera capture driver

[Benoit Parrot]

The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
This camera engine is currently found on DRA72xx family of devices.

Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data lanes.

The driver implements the required API/ioctls to be V4L2 compliant.
Driver supports the following:
- V4L2 API using DMABUF/MMAP buffer access based on videobuf2 api
- Asynchronous sensor sub device registration
- DT support

Currently each port is designed to connect to a single sub-device.
In other words port aggregation is not currently supported.

Changes since v2:
- Rework Kconfig options and added COMPILE_TEST
- Merged in provided vb2 buffer rework
- Rebase on tip of lmm master and fixe vb2 split related changes

Changes since v1:
- Remove unnecessary format description
- Reworked how transient frame format is maintained
  in order to make it easier to use the fill helper functions
- Added a per port list of active frame format
- Reworked an added missing vb2 cleanup code
- Fix a module load/unload kernel oops
- Switch to use proper int64 get function for pixel rate control

=

Here is a sample output of the v4l2-compliance tool:

# ./v4l2-compliance -f -s -v -d /dev/video0 
Driver Info:
Driver name   : cal
Card type : cal
Bus info : platform:cal-000

Capabilities  : 0x8521
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0521
Video Capture
Read/Write
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Test input 0:

Control ioctls:
info: checking v4l2_queryctrl of control 'User Controls' 
(0x00980001)
info: checking v4l2_queryctrl of control 'Horizontal Flip' 
(0x00980914)
info: checking v4l2_queryctrl of control 'Vertical Flip' 
(0x00980915)
info: checking v4l2_queryctrl of control 'Image Processing 
Controls' (0x009f0001)
info: checking v4l2_queryctrl of control 'Pixel Rate' 
(0x009f0902)
info: checking v4l2_queryctrl of control 'Horizontal Flip' 
(0x00980914)
info: checking v4l2_queryctrl of control 'Vertical Flip' 
(0x00980915)
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
info: checking control 'User Controls' (0x00980001)
info: checking control 'Horizontal Flip' (0x00980914)
info: checking control 'Vertical Flip' (0x00980915)
info: checking control 'Image Processing Controls' (0x009f0001)
info: checking control 'Pixel Rate' (0x009f0902)
test VIDIOC_G/S_CTRL: OK
info: checking extended control 'User Controls' (0x00980001)
info: checking extended control 'Horizontal Flip' (0x00980914)
info: checking extended control 'Vertical Flip' (0x00980915)
info: checking extended control 'Image Processing Controls' 
(0x009f0001)
info: checking extended control 'Pixel Rate' (0x009f0902)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
info: checking control event 'User Controls' (0x00980001)
info: checking control event 'Horizontal Flip' (0x00980914)
info: checking control event 'Vertical Flip' (0x00980915)
info: checking control event 'Image Processing Controls' 
(0x009f0001)