Re: [PATCH 1/1] NVMe: Do not take nsid while a passthrough IO command is being issued via a block device file descriptor

2015-01-22 Thread Christoph Hellwig
On Thu, Jan 22, 2015 at 04:02:08PM -0800, Yan Liu wrote:
> When a passthrough IO command is issued with a specific block device file 
> descriptor. It should be applied at
> the namespace which is associated with that block device file descriptor. 
> This patch makes such passthrough
> command ignore nsid in nvme_passthru_cmd structure. Instead it takes the 
> namespace ID asscoiated with the
> block device descriptor.
> 
> Signed-off-by: Yan Liu 

Please move the code to find the ns into the caller, or even better a
seaprate helper used by the caller. instead of adding another argument to
nvme_user_cmd.
--
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 v9 0/7] devfreq: Add devfreq-event class to provide raw data for devfreq device

2015-01-22 Thread Kukjin Kim
Chanwoo Choi wrote:
> 
Hi,

> This patchset add new devfreq_event class to provide raw data to determine
> current utilization of device  which is used for devfreq governor.
> 
Yes, would be nice to use common framework something like the devfreq_event you 
created :)

> The following description explains the feature of two kind of devfreq class:
> - devfreq class (existing)
>  : devfreq consumer device use raw data from devfreq_event device for
>determining proper current system state and change voltage/frequency
>dynamically using various governors.
> - devfreq_event class (new)
>  : Provide measured raw data to devfreq device for governor

[...]

> Chanwoo Choi (7):
>   devfreq: event: Add new devfreq_event class to provide basic data for 
> devfreq governor
>   devfreq: event: Add exynos-ppmu devfreq-event driver
>   devfreq: event: Add documentation for exynos-ppmu devfreq-event driver
>   ARM: dts: Add PPMU dt node for Exynos3250 SoC
>   ARM: dts: Add PPMU dt node for Exynos4 SoCs
>   ARM: dts: exynos: Add PPMU node for Exynos3250-based Rinato/Monk board
>   ARM: dts: exynos: Add PPMU node for Exynos4412-based TRATS2 board
> 
>  .../bindings/devfreq/event/exynos-ppmu.txt | 110 +
>  arch/arm/boot/dts/exynos3250-monk.dts  |  40 ++
>  arch/arm/boot/dts/exynos3250-rinato.dts|  40 ++
>  arch/arm/boot/dts/exynos3250.dtsi  |  74 +++
>  arch/arm/boot/dts/exynos4.dtsi | 108 +
>  arch/arm/boot/dts/exynos4210.dtsi  |   8 +
>  arch/arm/boot/dts/exynos4412-trats2.dts|  40 ++
>  drivers/devfreq/Kconfig|   2 +
>  drivers/devfreq/Makefile   |   6 +-
>  drivers/devfreq/devfreq-event.c| 498 
> +
>  drivers/devfreq/event/Kconfig  |  25 ++
>  drivers/devfreq/event/Makefile |   2 +
>  drivers/devfreq/event/exynos-ppmu.c| 374 
>  drivers/devfreq/event/exynos-ppmu.h|  93 
>  include/linux/devfreq-event.h  | 196 
>  15 files changed, 1615 insertions(+), 1 deletion(-)
>  create mode 100644 
> Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
>  create mode 100644 drivers/devfreq/devfreq-event.c
>  create mode 100644 drivers/devfreq/event/Kconfig
>  create mode 100644 drivers/devfreq/event/Makefile
>  create mode 100644 drivers/devfreq/event/exynos-ppmu.c
>  create mode 100644 drivers/devfreq/event/exynos-ppmu.h
>  create mode 100644 include/linux/devfreq-event.h
> 
> --

Looks good to me.

Myungjoo, shall I take DT changes in this series into Samsung tree?

4/7 ARM: dts: Add PPMU dt node for Exynos3250 SoC
5/7 ARM: dts: Add PPMU dt node for Exynos4 SoCs
6/7 ARM: dts: exynos: Add PPMU node for Exynos3250-based Rinato/Monk board
7/7 ARM: dts: exynos: Add PPMU node for Exynos4412-based TRATS2 board

Thanks,
Kukjin

--
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] thermal: rockchip: make temperature reporting much more accurate

2015-01-22 Thread Daniel Kurtz
On Fri, Jan 23, 2015 at 12:01 AM, Caesar Wang  wrote:
> In general, the kernel should report temperature readings exactly as
> reported by the hardware. The cpu / gpu thermal driver works in 5 degree
> increments,but we ought to do more accurate. The temperature will do
> linear interpolation between the entries in the table.
>
> Test= $md5sum /dev/zero &
> $while true; do grep "" /sys/class/thermal/thermal_zone[1-2]/temp;
> sleep .5; done
>
> e.g. We can get the result as follows:
> /sys/class/thermal/thermal_zone1/temp:39994
> /sys/class/thermal/thermal_zone2/temp:39086
> /sys/class/thermal/thermal_zone1/temp:39994
> /sys/class/thermal/thermal_zone2/temp:39540
> /sys/class/thermal/thermal_zone1/temp:39540
> /sys/class/thermal/thermal_zone2/temp:39540
> /sys/class/thermal/thermal_zone1/temp:39540
> /sys/class/thermal/thermal_zone2/temp:39994
>
> Signed-off-by: Caesar Wang 
> Reviewed-by: Dmitry Torokhov 
>
> ---
>
> Changes in v4:
> "return -EAGAIN" instead of "return rk_tsadcv2_code_to_temp(code)"
>
> Changes in v3:
> Suggested-by Daniel Kurtz,
> the check doesn't reject "code == 0xfff"
> Fixed in rk_tsadcv2_code_to_temp(u32 code)
>
> Changes in v2:
> Reviewed-by: Dmitry Torokhov 
>
>  drivers/thermal/rockchip_thermal.c | 32 ++--
>  1 file changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/thermal/rockchip_thermal.c 
> b/drivers/thermal/rockchip_thermal.c
> index 1bcddfc..6267349 100644
> --- a/drivers/thermal/rockchip_thermal.c
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -193,19 +193,22 @@ static u32 rk_tsadcv2_temp_to_code(long temp)
>
>  static long rk_tsadcv2_code_to_temp(u32 code)
>  {
> -   int high, low, mid;
> -
> -   low = 0;
> -   high = ARRAY_SIZE(v2_code_table) - 1;
> -   mid = (high + low) / 2;
> +   unsigned int low = 0;
> +   unsigned int high = ARRAY_SIZE(v2_code_table) - 1;
> +   unsigned int mid = (low + high) / 2;
> +   unsigned int num;
> +   unsigned long denom;
>
> +   /* No code available, return -EAGAIN */
> if (code > v2_code_table[low].code || code < v2_code_table[high].code)
> -   return 125000; /* No code available, return max temperature */
> +   return -EAGAIN;

I think the following is more clear:

(a) reject invalid codes:

 /* Invalid code, return -EAGAIN */
 if (code >= TSADCV2_DATA_MASK)
return -EAGAIN;

(b) do not allow mid to be 0:

while (low < high && mid) {

> -   if (code >= v2_code_table[mid].code && code <
> -   v2_code_table[mid - 1].code)
> -   return v2_code_table[mid].temp;
> +   if (code >= v2_code_table[mid].code &&
> +   code < v2_code_table[mid - 1].code)
> +   break;
> +   else if (code == TSADCV2_DATA_MASK)
> +   break;
> else if (code < v2_code_table[mid].code)
> low = mid + 1;
> else
> @@ -213,7 +216,16 @@ static long rk_tsadcv2_code_to_temp(u32 code)
> mid = (low + high) / 2;
> }
>
> -   return 125000;
> +   /*
> +* The 5C granularity provided by the table is too much. Let's
> +* assume that the relationship between sensor readings and
> +* temperature between 2 table entries is linear and interpolate
> +* to produce less granular result.
> +*/
> +   num = v2_code_table[mid].temp - v2_code_table[mid - 1].temp;
> +   num *= v2_code_table[mid - 1].code - code;
> +   denom = v2_code_table[mid - 1].code - v2_code_table[mid].code;
> +   return v2_code_table[mid - 1].temp + (num / denom);
>  }
>
>  /**
> --
> 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] mm: incorporate read-only pages into transparent huge pages

2015-01-22 Thread Ebru Akagunduz
This patch aims to improve THP collapse rates, by allowing
THP collapse in the presence of read-only ptes, like those
left in place by do_swap_page after a read fault.

Currently THP can collapse 4kB pages into a THP when
there are up to khugepaged_max_ptes_none pte_none ptes
in a 2MB range. This patch applies the same limit for
read-only ptes.

The patch was tested with a test program that allocates
800MB of memory, writes to it, and then sleeps. I force
the system to swap out all but 190MB of the program by
touching other memory. Afterwards, the test program does
a mix of reads and writes to its memory, and the memory
gets swapped back in.

Without the patch, only the memory that did not get
swapped out remained in THPs, which corresponds to 24% of
the memory of the program. The percentage did not increase
over time.

With this patch, after 5 minutes of waiting khugepaged had
collapsed 55% of the program's memory back into THPs.

Signed-off-by: Ebru Akagunduz 
Reviewed-by: Rik van Riel 
---
I've written down test results:

With the patch:
After swapped out:
cat /proc/pid/smaps:
Anonymous:  100352 kB
AnonHugePages:  98304 kB
Swap:   699652 kB
Fraction:   97,95

cat /proc/meminfo:
AnonPages:  1763732 kB
AnonHugePages:  1716224 kB
Fraction:   97,30

After swapped in:
In a few seconds:
cat /proc/pid/smaps
Anonymous:  84 kB
AnonHugePages:  235520 kB
Swap:   0 kB
Fraction:   29,43

cat /proc/meminfo:
AnonPages:  2464336 kB
AnonHugePages:  1853440 kB
Fraction:   75,21

In five minutes:
cat /proc/pid/smaps:
Anonymous:  84 kB
AnonHugePages:  440320 kB
Swap:   0 kB
Fraction:   55,0

cat /proc/meminfo:
AnonPages:  2464340
AnonHugePages:  2058240
Fraction:   83,52

Without the patch:
After swapped out:
cat /proc/pid/smaps:
Anonymous:  190660 kB
AnonHugePages:  190464 kB
Swap:   609344 kB
Fraction:   99,89

cat /proc/meminfo:
AnonPages:  1740456 kB
AnonHugePages:  1667072 kB
Fraction:   95,78

After swapped in:
cat /proc/pid/smaps:
Anonymous:  84 kB
AnonHugePages:  190464 kB
Swap:   0 kB
Fraction:   23,80

cat /proc/meminfo:
AnonPages:  2350032 kB
AnonHugePages:  1667072 kB
Fraction:   70,93

I waited 10 minutes the fractions
did not change without the patch.

 mm/huge_memory.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 817a875..af750d9 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2158,7 +2158,7 @@ static int __collapse_huge_page_isolate(struct 
vm_area_struct *vma,
else
goto out;
}
-   if (!pte_present(pteval) || !pte_write(pteval))
+   if (!pte_present(pteval))
goto out;
page = vm_normal_page(vma, address, pteval);
if (unlikely(!page))
@@ -2169,7 +2169,7 @@ static int __collapse_huge_page_isolate(struct 
vm_area_struct *vma,
VM_BUG_ON_PAGE(!PageSwapBacked(page), page);
 
/* cannot use mapcount: can't collapse if there's a gup pin */
-   if (page_count(page) != 1)
+   if (page_count(page) != 1 + !!PageSwapCache(page))
goto out;
/*
 * We can do it before isolate_lru_page because the
@@ -2179,6 +2179,17 @@ static int __collapse_huge_page_isolate(struct 
vm_area_struct *vma,
 */
if (!trylock_page(page))
goto out;
+   if (!pte_write(pteval)) {
+   if (PageSwapCache(page) && !reuse_swap_page(page)) {
+   unlock_page(page);
+   goto out;
+   }
+   /*
+* Page is not in the swap cache, and page count is
+* one (see above). It can be collapsed into a THP.
+*/
+   }
+
/*
 * Isolate the page to avoid collapsing an hugepage
 * currently in use by the VM.
@@ -2550,7 +2561,7 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
 {
pmd_t *pmd;
pte_t *pte, *_pte;
-   int ret = 0, referenced = 0, none = 0;
+   int ret = 0, referenced = 0, none = 0, ro = 0;
struct page *page;
unsigned long _address;
spinlock_t *ptl;
@@ -2573,8 +2584,12 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
else
goto out_unmap;
}
-   if (!pte_present(pteval) || !pte_write(pteval))
+   if (!pte_present(pteval))
goto out_unmap;
+   if (!pte_write(pteval)) {
+   if (++ro > khugepaged_max_ptes_none)
+   goto 

[PATCH] ipv6: Provide definitions for GNU libc 2.8 and later

2015-01-22 Thread Thierry Reding
From: Thierry Reding 

Starting with GNU libc 2.8 and later, the definitions of the in6_pktinfo
and ip6_mtuinfo structures is guarded by __USE_GNU. Make sure to provide
the structures in the linux/ipv6.h when building against GNU libc 2.8 or
later and __USE_GNU is undefined to avoid breaking build issues.

One example where such failure to build can be observed is dhcpcd 6.6.7.

Signed-off-by: Thierry Reding 
---
This is based on next-20150122.

 include/uapi/linux/libc-compat.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index fa673e9cc040..40bd54df06e3 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -70,8 +70,17 @@
 #define __UAPI_DEF_IPV6_MREQ   0
 #define __UAPI_DEF_IPPROTO_V6  0
 #define __UAPI_DEF_IPV6_OPTIONS0
+/*
+ * The GNU C library 2.8 and later define the in6_pktinfo and ip6_mtuinfo
+ * structures only for __USE_GNU.
+ */
+#if __GLIBC_PREREQ(2, 8) && !defined(__USE_GNU)
+#define __UAPI_DEF_IN6_PKTINFO 1
+#define __UAPI_DEF_IP6_MTUINFO 1
+#else
 #define __UAPI_DEF_IN6_PKTINFO 0
 #define __UAPI_DEF_IP6_MTUINFO 0
+#endif
 
 #else
 
-- 
2.1.3

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


Re: [PATCH v3 01/12] clk: samsung: exynos5433: Add clocks using common clock framework

2015-01-22 Thread Chanwoo Choi
Hi Sylwester,

On 01/23/2015 01:47 AM, Sylwester Nawrocki wrote:
> Hi Chanwoo,
> 
> On 21/01/15 07:26, Chanwoo Choi wrote:
>> This patch adds the support for CMU (Clock Management Units) of Exynos5433
>> which is 64bit SoC and has Octa-cores. This patch supports necessary clocks
>> (PLL/MMC/UART/MCT/I2C/SPI) for kernel boot and includes binding documentation
>> for Exynos5433 clock controller.
> 
>> diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt 
>> b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
>> new file mode 100644
>> index 000..72cd0ba
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
>> @@ -0,0 +1,106 @@
>> +* Samsung Exynos5433 CMU (Clock Management Units)
>> +
>> +The Exynos5433 clock controller generates and supplies clock to various
>> +controllers within the Exynos5433 SoC.
>> +
>> +Required Properties:
>> +
>> +- compatible: should be one of the following.
>> +  - "samsung,exynos5433-cmu-top"   - clock controller compatible for CMU_TOP
>> +which generates clocks for 
>> IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
>> +domains and bus clocks.
>> +  - "samsung,exynos5433-cmu-cpif"  - clock controller compatible for 
>> CMU_CPIF
>> +which generates clocks for LLI (Low Latency Interface) IP.
>> +  - "samsung,exynos5433-cmu-mif"   - clock controller compatible for CMU_MIF
>> +which generates clocks for DRAM Memory Controller domain.
>> +  - "samsung,exynos5433-cmu-peric" - clock controller compatible for 
>> CMU_PERIC
>> +which generates clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS IPs.
>> +  - "samsung,exynos5433-cmu-peris" - clock controller compatible for 
>> CMU_PERIS
>> +which generates clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC IPs.
>> +  - "samsung,exynos5433-cmu-fsys"  - clock controller compatible for 
>> CMU_FSYS
>> +which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs.
>> +
>> +- reg: physical base address of the controller and length of memory mapped
>> +  region.
>> +
>> +- #clock-cells: should be 1.
>> +
>> +Each clock is assigned an identifier and client nodes can use this 
>> identifier
>> +to specify the clock which they consume.
>> +
>> +All available clocks are defined as preprocessor macros in
>> +dt-bindings/clock/exynos5433.h header and can be used in device
>> +tree sources.
>> +
>> +Example 1: Examples of clock controller nodes are listed below.
>> +
>> +cmu_top: clock-controller@0x1003 {
>> +compatible = "samsung,exynos5433-cmu-top";
>> +reg = <0x1003 0x0c04>;
>> +#clock-cells = <1>;
>> +};
>> +
>> +cmu_cpif: clock-controller@0x10fc {
>> +compatible = "samsung,exynos5433-cmu-cpif";
>> +reg = <0x10fc 0x0c04>;
>> +#clock-cells = <1>;
>> +};
>> +
>> +cmu_mif: clock-controller@0x105b {
>> +compatible = "samsung,exynos5433-cmu-mif";
>> +reg = <0x105b 0x100c>;
>> +#clock-cells = <1>;
>> +};
>> +
>> +cmu_peric: clock-controller@0x14c8 {
>> +compatible = "samsung,exynos5433-cmu-peric";
>> +reg = <0x14c8 0x0b08>;
>> +#clock-cells = <1>;
>> +};
>> +
>> +cmu_peris: clock-controller@0x1004 {
>> +compatible = "samsung,exynos5433-cmu-peris";
>> +reg = <0x1004 0x0b20>;
>> +#clock-cells = <1>;
>> +};
>> +
>> +cmu_fsys: clock-controller@0x156e {
>> +compatible = "samsung,exynos5433-cmu-fsys";
>> +reg = <0x156e 0x0b04>;
>> +#clock-cells = <1>;
>> +};
> 
> What are the reasons to split the whole clock controller into separate
> device nodes with different compatible strings like this? I doubt drivers
> associated with each of those compatible strings could be ever reused on
> different Exynos SoCs.

No special reason. I added the clock controller according to clock domain
separately. As I knew, samsung clk drivers use this way to support various
clock domains. For exmaple, drivers/clk/samsung/clk-exynos7.c.

> 
> There are hardware dependencies between these clock domains, which are
> not currently modelled in DT with your binding.

Right. current samsung clock drivers cannot show the hierarchy among clock 
domains in DT.

IOW, there is currently
> no way to ensure proper registration order of the CMUs (clock domains).
> This may be important in some cases.
> 
> To address this we could either add clocks/clock-names properties in
> respective CMU device nodes, pointing to any clocks in other CMU(s) or
> make a single device node for the whole clock controller, with an
> aggregated reg entry, e.g.
> 
>  cmu: clock-controller@0x1003 {
>   compatible = "samsung,exynos5433-cmu";
>   reg =   <0x1003 0x0c04>,
>   <0x10fc 0x0c04>,
>   <0x105b 0x100c>,
>   <0x14c8 0x0b08>,
>   <0x1004 0x0b20>,
>  

Re: [PATCH 6/6] Documentation: Add device tree bindings document for max77843

2015-01-22 Thread Beomho Seo
On 01/23/2015 03:25 PM, Chanwoo Choi wrote:
> Hi Jaewon,
> 
> On 01/23/2015 02:02 PM, Jaewon Kim wrote:
>> Add document describing device tree bindings for max77843 MFD.
>> Drivers: MFD core, regulator, extcon, charger and fuelgauge.
>>
>> Cc: Rob Herring 
>> Cc: Pawel Moll 
>> Cc: Mark Rutland 
>> Cc: Ian Campbell 
>> Cc: Kumar Gala 
>> Cc: Lee Jones 
>> Cc: Chanwoo Choi 
>> Cc: Sebastian Reichel 
>> Cc: Mark Brown 
>> Signed-off-by: Beomho Seo 
>> Signed-off-by: Jaewon Kim 
>> ---
>>  Documentation/devicetree/bindings/mfd/max77843.txt |   87 
>> 
>>  1 file changed, 87 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/max77843.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/max77843.txt 
>> b/Documentation/devicetree/bindings/mfd/max77843.txt
>> new file mode 100644
>> index 000..6895604
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/max77843.txt
>> @@ -0,0 +1,87 @@
>> +Maxim MAX77843 multi-function device
>> +
>> +MAX77843 is a Multi-Function Device with the following submodules:
>> +- PMIC: 2 SAFEOUT LDOs for USB device
>> +- CHARGER : Li+ battery charger with Fuel Gauge
>> +- MUIC: Micro USB Interface Circuit
>> +- HAPTIC  : motor control driver for haptics
> 
> HAPTIC ?
> 
>> +- LED : 4 channel RGBW LED
> 
> LED ?
> 
> This patchset don't include andy haptic/led drivers.
> I think it is un-necessary information.
> 
> When you implement the haptic/led driver, you will add the information
> for haptic/led driver.
> 

OK. I will remove them.

>> +
>> +It is interfaced to host controller using I2C.
>> +
>> +Required properties:
>> +- compatible : Must be "maxim,max77843".
>> +- reg : I2C slave address of PMIC block.
>> +- interrupts : I2C line for main SoCs.
>> +- interrupt-parent : The parent of interrupt controller.
>> +
>> +Optional properties:
>> +- regulators : The regulators of max77843 have to be instantiated under 
>> subnode
>> +named "regulators" using the following format.
>> +
>> +[*]refer : Documentation/devicetree/bindings/regulator/regulator.txt
>> +
>> +regulators {
>> +SAFEOUT {
>> +regulator-name = "SAFEOUT";
>> +};
>> +}
>> +
>> +List of valid regulator names:
>> +- SAFEOUT1, SAFEOUT2, CHARGER.
>> +
>> +- max77843-muic : This properties used by extcon consumers.
>> +Required properties:
>> +- compatible : Must be "maxim,max77842-muic".
>> +
>> +- max77843-charger : There battery charger of MAX77843 have to be 
>> instantiated
>> +under sub-node named "max77843-charger" using the following format.
>> +Required properties:
>> +- compatible : Must be "maxim,max77842-charger".
>> +- maxim,fast-charge-uamp : Fast charge current levels are
>> +100 mA to 3150 mA programmed by I2C per 100 mA.
>> +- maxim,top-off-uamp : Top off current threshold levels are
>> +125 mA to 650 mA programmed by I2C per 75 mA.
>> +- maxim,input-uamp-limit : Input current limit levels are
>> +100 mA to 3533 mA programmed by I2C per 33 mA.
>> +- max77843-fuelgauge : There fuelgauge of MAX77843 have to be instantiated
>> +under sub-node named "max77843-fuelgauge" using the following format.
>> +Required properties:
>> +- compatible : Must be "maxim,max77842-fuelgauge".
>> +
>> +Example:
>> +max77843@66 {
>> +compatible = "samsung,max77843";
>> +reg = <0x66>;
>> +interrupt-parent = <>;
>> +interrupts = <5 2>;
>> +
>> +regulators {
>> +SAFEOUT1 {
>> +regulator-name = "SAFEOUT1";
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <495>;
>> +};
>> +SAFEOUT2 {
>> +regulator-name = "SAFEOUT2";
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <495>;
>> +};
> 
> As I knew, max77843 regulator driver supprot 'CHARGER' regulator.
> I think you have to add the 'CHARGER' dt node for regulators.
> 
> 

Right, I will include charger regulator.

>> +};
>> +
>> +max77843-muic {
>> +compatible = "maxim,max77843-muic";
>> +};
>> +
>> +max77843-charger {
>> +compatible = "maxim,max77843-charger";
>> +maxim,fast-charge-uamp = <45>;
>> +maxim,top-off-uamp = <125000>;
>> +maxim,input-uamp-limit = <50>;
>> +};
>> +
>> +max77843-fuelgauge {
>> +compatible = "maxim,max77843-fuelgauge";
>> +};
>> +
>> +};
>>
> 
> Thanks,
> Chanwoo Choi
> --
> To unsubscribe 

Re: [PATCH] clk: ux500: Drop use of clk-private.h

2015-01-22 Thread Ulf Hansson
On 22 January 2015 at 20:34, Stephen Boyd  wrote:
> These drivers don't need to include clk-private.h. Remove the
> include.
>
> Cc: Ulf Hansson 
> Cc: Linus Walleij 
> Signed-off-by: Stephen Boyd 

Acked-by: Ulf Hansson 

I suppose you can queue this through your clk tree directly?

Kind regards
Uffe

> ---
>  drivers/clk/ux500/clk-prcc.c  | 1 -
>  drivers/clk/ux500/clk-prcmu.c | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/drivers/clk/ux500/clk-prcc.c b/drivers/clk/ux500/clk-prcc.c
> index bd4769a84485..0e950769ed03 100644
> --- a/drivers/clk/ux500/clk-prcc.c
> +++ b/drivers/clk/ux500/clk-prcc.c
> @@ -8,7 +8,6 @@
>   */
>
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/clk/ux500/clk-prcmu.c b/drivers/clk/ux500/clk-prcmu.c
> index e2d63bc47436..bf63c96acb1a 100644
> --- a/drivers/clk/ux500/clk-prcmu.c
> +++ b/drivers/clk/ux500/clk-prcmu.c
> @@ -8,7 +8,6 @@
>   */
>
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[RFC] dma-buf: cleanup dma_buf_export() to make it easily extensible

2015-01-22 Thread Sumit Semwal
At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.

Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().

While at it, unite dma_buf_export_named() with dma_buf_export(), and
change all callers accordingly.

Signed-off-by: Sumit Semwal 
---
 drivers/dma-buf/dma-buf.c  | 47 +-
 drivers/gpu/drm/armada/armada_gem.c| 12 +--
 drivers/gpu/drm/drm_prime.c| 14 +---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 13 +--
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 12 +--
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  | 11 +-
 drivers/gpu/drm/tegra/gem.c| 12 +--
 drivers/gpu/drm/ttm/ttm_object.c   | 11 --
 drivers/gpu/drm/udl/udl_dmabuf.c   | 10 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 10 +-
 drivers/media/v4l2-core/videobuf2-dma-sg.c | 10 +-
 drivers/media/v4l2-core/videobuf2-vmalloc.c| 10 +-
 drivers/staging/android/ion/ion.c  | 11 --
 include/linux/dma-buf.h| 28 +++
 14 files changed, 160 insertions(+), 51 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..6d3df3dd9310 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -265,7 +265,7 @@ static inline int is_dma_buf_file(struct file *file)
 }
 
 /**
- * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
  * Also connect the allocator specific data and ops to the buffer.
  * Additionally, provide a name string for exporter; useful in debugging.
@@ -277,31 +277,32 @@ static inline int is_dma_buf_file(struct file *file)
  * @exp_name:  [in]name of the exporting module - useful for debugging.
  * @resv:  [in]reservation-object, NULL to allocate default one.
  *
+ * All the above info comes from struct dma_buf_export_info.
+ *
  * Returns, on success, a newly created dma_buf object, which wraps the
  * supplied private data and operations for dma_buf_ops. On either missing
  * ops, or error in allocating struct dma_buf, will return negative error.
  *
  */
-struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
-   size_t size, int flags, const char *exp_name,
-   struct reservation_object *resv)
+struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info)
 {
struct dma_buf *dmabuf;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
-   if (!resv)
+   if (!exp_info->resv)
alloc_size += sizeof(struct reservation_object);
else
/* prevent _buf[1] == dma_buf->resv */
alloc_size += 1;
 
-   if (WARN_ON(!priv || !ops
- || !ops->map_dma_buf
- || !ops->unmap_dma_buf
- || !ops->release
- || !ops->kmap_atomic
- || !ops->kmap
- || !ops->mmap)) {
+   if (WARN_ON(!exp_info->priv
+ || !exp_info->ops
+ || !exp_info->ops->map_dma_buf
+ || !exp_info->ops->unmap_dma_buf
+ || !exp_info->ops->release
+ || !exp_info->ops->kmap_atomic
+ || !exp_info->ops->kmap
+ || !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
 
@@ -309,21 +310,22 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);
 
-   dmabuf->priv = priv;
-   dmabuf->ops = ops;
-   dmabuf->size = size;
-   dmabuf->exp_name = exp_name;
+   dmabuf->priv = exp_info->priv;
+   dmabuf->ops = exp_info->ops;
+   dmabuf->size = exp_info->size;
+   dmabuf->exp_name = exp_info->exp_name;
init_waitqueue_head(>poll);
dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = >poll;
dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
 
-   if (!resv) {
-   resv = (struct reservation_object *)[1];
-   reservation_object_init(resv);
+   if (!exp_info->resv) {
+   exp_info->resv = (struct reservation_object *)[1];
+   reservation_object_init(exp_info->resv);
}
-   dmabuf->resv = resv;
+   dmabuf->resv = exp_info->resv;
 
-   file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf, flags);
+   file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf,
+   

Re: [PATCH 3/6] power: max77843_charger: Add Max77843 charger device driver

2015-01-22 Thread Beomho Seo
Thank you for review.

On 01/23/2015 04:04 PM, Krzysztof Kozłowski wrote:
> 2015-01-23 6:02 GMT+01:00 Jaewon Kim :
>> From: Beomho Seo 
>>
>> This patch adds device driver of max77843 charger. This driver provide
>> initialize each charging mode(e.g. fast charge, top-off mode and constant
>> charging mode so on.). Additionally, control charging paramters to use
>> i2c interface.
>>
>> Cc: Sebastian Reichel 
>> Signed-off-by: Beomho Seo 
>> ---
>>  drivers/power/Kconfig|7 +
>>  drivers/power/Makefile   |1 +
>>  drivers/power/max77843_charger.c |  506 
>> ++
>>  3 files changed, 514 insertions(+)
>>  create mode 100644 drivers/power/max77843_charger.c
>>
>> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
>> index 0108c2a..a054a28 100644
>> --- a/drivers/power/Kconfig
>> +++ b/drivers/power/Kconfig
>> @@ -332,6 +332,13 @@ config CHARGER_MAX14577
>>   Say Y to enable support for the battery charger control sysfs and
>>   platform data of MAX14577/77836 MUICs.
>>
>> +config CHARGER_MAX77843
>> +   tristate "Maxim MAX77843 battery charger driver"
>> +   depends on MFD_MAX77843
>> +   help
>> + Say Y to enable support for the battery charger control sysfs and
>> + platform data of MAX77843
>> +
>>  config CHARGER_MAX8997
>> tristate "Maxim MAX8997/MAX8966 PMIC battery charger driver"
>> depends on MFD_MAX8997 && REGULATOR_MAX8997
>> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
>> index dfa8942..212c6a2 100644
>> --- a/drivers/power/Makefile
>> +++ b/drivers/power/Makefile
>> @@ -50,6 +50,7 @@ obj-$(CONFIG_CHARGER_LP8788)  += lp8788-charger.o
>>  obj-$(CONFIG_CHARGER_GPIO) += gpio-charger.o
>>  obj-$(CONFIG_CHARGER_MANAGER)  += charger-manager.o
>>  obj-$(CONFIG_CHARGER_MAX14577) += max14577_charger.o
>> +obj-$(CONFIG_CHARGER_MAX77843) += max77843_charger.o
>>  obj-$(CONFIG_CHARGER_MAX8997)  += max8997_charger.o
>>  obj-$(CONFIG_CHARGER_MAX8998)  += max8998_charger.o
>>  obj-$(CONFIG_CHARGER_BQ2415X)  += bq2415x_charger.o
>> diff --git a/drivers/power/max77843_charger.c 
>> b/drivers/power/max77843_charger.c
>> new file mode 100644
>> index 000..317b2cc
>> --- /dev/null
>> +++ b/drivers/power/max77843_charger.c
>> @@ -0,0 +1,506 @@
>> +/*
>> + * Charger driver for Maxim MAX77843
>> + *
>> + * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
>> + * Author: Beomho Seo 
>> + *
>> + * 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 bythe Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct max77843_charger_info {
>> +   u32 fast_charge_uamp;
>> +   u32 top_off_uamp;
>> +   u32 input_uamp_limit;
>> +};
>> +
>> +struct max77843_charger {
>> +   struct device   *dev;
>> +   struct max77843 *max77843;
>> +   struct i2c_client   *client;
>> +   struct regmap   *regmap;
>> +   struct power_supply psy;
>> +
>> +   struct max77843_charger_info*info;
>> +};
> 
> Why creating two separate structures?
> 

max77843_charger_info structure just have property of charger.
If you want to merge one structure, I will revise above structure.

>> +
>> +static int max77843_charger_get_max_current(struct max77843_charger 
>> *charger)
>> +{
>> +   struct regmap *regmap = charger->regmap;
>> +   int ret, val = 0;
>> +   unsigned int reg_data;
>> +
>> +   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_09, _data);
>> +   if (ret) {
>> +   dev_err(charger->dev, "Failed to read charger register\n");
>> +   return ret;
>> +   }
>> +
>> +   if (reg_data <= 0x03) {
>> +   val = MAX77843_CHG_INPUT_CURRENT_LIMIT_MIN;
>> +   } else if (reg_data >= 0x78) {
>> +   val = MAX77843_CHG_INPUT_CURRENT_LIMIT_MAX;
>> +   } else {
>> +   val = reg_data / 3;
>> +   if (reg_data % 3 == 0)
>> +   val *= 10;
>> +   else if (reg_data % 3 == 1)
>> +   val = val * 10 + 33000;
>> +   else
>> +   val = val * 10 + 67000;
>> +   }
>> +
>> +   return val;
>> +}
>> +
>> +static int max77843_charger_get_now_current(struct max77843_charger 
>> *charger)
>> +{
>> +   struct regmap *regmap = charger->regmap;
>> +   int ret, val = 0;
>> +   unsigned int reg_data;
>> +
>> +   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_02, _data);
>> +   if (ret) {
>> +   dev_err(charger->dev, "Failed to read charger register\n");
> 
> This error log shows up in many places. Please print also error code.
> 
> Additionally I think it could be useful to print also details about
> register which failed. Currently user would not know which 

Re: [PATCH 0/5] extcon: usb: Introduce USB GPIO extcon driver. Fix DRA7 USB.

2015-01-22 Thread Roger Quadros
Felipe,

On 22/01/15 22:29, Felipe Balbi wrote:
> On Thu, Jan 22, 2015 at 04:57:56PM +0200, Roger Quadros wrote:
>>
>> On 22/01/15 15:32, Roger Quadros wrote:
>>> Felipe,
>>>
>>> On 20/01/15 21:02, Felipe Balbi wrote:
 On Mon, Jan 19, 2015 at 07:52:17PM +0200, Roger Quadros wrote:
> Hi,
>
> On DRA7 EVMs the USB ID pin is connected to a GPIO line. The USB drivers
> (dwc3 + dwc3-omap) depend on extcon framework to get the USB cable state
> (USB or USB-Host) to put the controller in the right mode.
>
> There were earlier attempts [1] to get this working by trying to patch up
> the existing GPIO extcon driver.
>
> This series attemts to take a different approach by introducing a new
> USB specific extcon driver to handle the USB ID GPIO pin and
> interpret a right USB cable state.
>
> The reasoning to introduce this new driver is:
> 1) The existing GPIO extcon driver doesn't understand USB cable states
> and it can't handle more than one cable per instance.
>
> For the USB case we need to handle at least 2 cable states.
> a) USB (attach/detach)
> b) USB-Host (attach/detach)
> and could possible include more states like
> c) Fast-charger (attach/detach)
> d) Slow-charger (attach/detach)
> 
> 2) This USB specific driver can be easily updated in the future to
> handle VBUS events, or charger detect events, in case it happens
> to be available on GPIO for any platform.
>
> 3) The DT implementation is very easy. You just need one extcon node per 
> USB
> instead of one extcon node per cable state as in case of [1].
>
> 4) The cable state string doesn't need to be encoded in the device tree
> as in case of [1].
>
> 5) With only ID event available, you can simulate a USB-peripheral attach
> when USB-Host is detacted instead of hacking the USB driver to do the 
> same.
>
> Tested on DRA7-evm and DRA72-evm.

 while at that, you might want to patch X15 too.

>>> USB2 port is meant for peripheral use only. ID pin from USB port is not 
>>> connected to GPIO.
>>>
>>
>> OK answering myself here :).
>> Peripheral mode doesn't work on x15-bb as the USB driver (dwc3-omap)
>> doesn't set the mailbox correctly even when dwc3 node is set as otg = 
>> "peripheral".
>>
>> Looks like we need to implement usb-gpio-extcon for x15 even though ID is 
>> hard coded.
> 
> right, another option is to have dwc3-omap read the child's DTS to check
> dr_mode and hardcode things based on that.
> 
I think that option is better as it doesn't require a GPIO line to be reserved
for ID when USB is not meant for dual-role use.

cheers,
-roger
--
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 5/6] regulator: max77843: Add max77843 regulator driver

2015-01-22 Thread Jaewon Kim

Hi Krzysztof,

2015년 01월 23일 16:18에 Krzysztof Kozłowski 이(가) 쓴 글:

2015-01-23 6:02 GMT+01:00 Jaewon Kim :

This patch adds new regulator driver to support max77843
MFD(Multi Function Device) chip`s regulators.
The Max77843 has two voltage regulators for USB safeout.

Cc: Mark Brown 
Signed-off-by: Beomho Seo 
Signed-off-by: Jaewon Kim 
---
  drivers/regulator/Kconfig|8 ++
  drivers/regulator/Makefile   |1 +
  drivers/regulator/max77843.c |  259 ++
  3 files changed, 268 insertions(+)
  create mode 100644 drivers/regulator/max77843.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c3a60b5..c1f9c33 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -414,6 +414,14 @@ config REGULATOR_MAX77802
   Exynos5420/Exynos5800 SoCs to control various voltages.
   It includes support for control of voltage and ramp speed.

+config REGULATOR_MAX77843
+   tristate "Maxim 77843 regulator"
+   depends on MFD_MAX77843
+   help
+ This driver controls a Maxim 77843 regulator.
+ The regulator include two 'SAFEOUT' for USB(Universal Serial Bus)
+ This is suitable for Exynos5433 SoC chips.
+
  config REGULATOR_MC13XXX_CORE
 tristate

diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 1f28ebf..12408d6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_REGULATOR_MAX8998) += max8998.o
  obj-$(CONFIG_REGULATOR_MAX77686) += max77686.o
  obj-$(CONFIG_REGULATOR_MAX77693) += max77693.o
  obj-$(CONFIG_REGULATOR_MAX77802) += max77802.o
+obj-$(CONFIG_REGULATOR_MAX77843) += max77843.o
  obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
  obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
  obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
diff --git a/drivers/regulator/max77843.c b/drivers/regulator/max77843.c
new file mode 100644
index 000..86afc7a
--- /dev/null
+++ b/drivers/regulator/max77843.c
@@ -0,0 +1,259 @@
+/*
+ * max77843.c - Regulator driver for the Maxim MAX77843
+ *
+ * Copyright (C) 2014 Samsung Electrnoics
+ * Author: Jaewon Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX77843_SUPPORTED_VOLTAGE_NUM 4
+
+enum max77843_regulator_type {
+   MAX77843_SAFEOUT1 = 0,
+   MAX77843_SAFEOUT2,
+   MAX77843_CHARGER,
+
+   MAX77843_NUM,
+};
+
+static const unsigned int max77843_regulator_table[] = {
+   485,
+   490,
+   495,
+   330,
+};
+
+static int max77843_reg_is_enabled(struct regulator_dev *rdev)
+{
+   struct regmap *regmap = rdev->regmap;
+   int ret;
+   unsigned int reg;
+
+   ret = regmap_read(regmap, rdev->desc->enable_reg, );
+   if (ret) {
+   dev_err(>dev, "Fialed to read charger register\n");
+   return ret;
+   }
+
+   return (reg & rdev->desc->enable_mask) == rdev->desc->enable_mask;
+}
+
+static int max77843_reg_get_current_limit(struct regulator_dev *rdev)
+{
+   struct regmap *regmap = rdev->regmap;
+   unsigned int chg_min_uA = rdev->constraints->min_uA;
+   unsigned int chg_max_uA = rdev->constraints->max_uA;
+   unsigned int val;
+   int ret;
+   unsigned int reg, sel;
+
+   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_02, );
+   if (ret) {
+   dev_err(>dev, "Failed to read charger register\n");
+   return ret;
+   }
+
+   sel = reg & MAX77843_CHG_FAST_CHG_CURRENT_MASK;
+
+   if (sel < 0x03)
+   sel = 0;
+   else
+   sel -= 2;
+
+   val = chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel;
+   if (val > chg_max_uA)
+   return -EINVAL;
+
+   return val;
+}
+
+static int max77843_reg_set_current_limit(struct regulator_dev *rdev,
+   int min_uA, int max_uA)
+{
+   struct regmap *regmap = rdev->regmap;
+   unsigned int chg_min_uA = rdev->constraints->min_uA;
+   int sel = 0;
+
+   while (chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel < min_uA)
+   sel++;
+
+   if (chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel > max_uA)
+   return -EINVAL;
+
+   sel += 2;
+
+   return regmap_write(regmap, MAX77843_CHG_REG_CHG_CNFG_02, sel);
+}
+
+static struct regulator_ops max77843_charger_ops = {
+   .is_enabled = max77843_reg_is_enabled,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .get_current_limit  = max77843_reg_get_current_limit,
+   .set_current_limit  = 

[PATCH v2] staging: rts5208: use msecs_to_jiffies for timeouts

2015-01-22 Thread Nicholas Mc Guire
This is only an API consolidation and should make things more readable

Signed-off-by: Nicholas Mc Guire 
---

v2: typo in patch subject fixed - no change in actual patch

Converting milliseconds to jiffies by val * HZ / 1000 is technically
not wrong but msecs_to_jiffies(val) is the cleaner solution and handles
corner cases correctly.

This patch was only compile tested with x86_64_defconfig + CONFIG_STAGING=y, 
CONFIG_RTS5208=m

Patch is against 3.19.0-rc5 -next-20150122

 drivers/staging/rts5208/rtsx_transport.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index 756a968..dab1995 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -271,7 +271,7 @@ int rtsx_send_cmd(struct rtsx_chip *chip, u8 card, int 
timeout)
 
/* Wait for TRANS_OK_INT */
timeleft = wait_for_completion_interruptible_timeout(
-   _done, timeout * HZ / 1000);
+   _done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "chip->int_reg = 0x%x\n",
chip->int_reg);
@@ -431,7 +431,7 @@ static int rtsx_transfer_sglist_adma_partial(struct 
rtsx_chip *chip, u8 card,
spin_unlock_irq(>reg_lock);
 
timeleft = wait_for_completion_interruptible_timeout(
-   _done, timeout * HZ / 1000);
+   _done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
@@ -455,7 +455,7 @@ static int rtsx_transfer_sglist_adma_partial(struct 
rtsx_chip *chip, u8 card,
init_completion(_done);
spin_unlock_irq(>reg_lock);
timeleft = wait_for_completion_interruptible_timeout(
-   _done, timeout * HZ / 1000);
+   _done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
@@ -575,7 +575,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip 
*chip, u8 card,
spin_unlock_irq(>reg_lock);
 
timeleft = wait_for_completion_interruptible_timeout(
-   _done, timeout * HZ / 1000);
+   _done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
@@ -602,7 +602,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip 
*chip, u8 card,
init_completion(_done);
spin_unlock_irq(>reg_lock);
timeleft = wait_for_completion_interruptible_timeout(
-   _done, timeout * HZ / 1000);
+   _done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
@@ -688,7 +688,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 
card, void *buf,
 
/* Wait for TRANS_OK_INT */
timeleft = wait_for_completion_interruptible_timeout(
-   _done, timeout * HZ / 1000);
+   _done, msecs_to_jiffies(timeout));
if (timeleft <= 0) {
dev_dbg(rtsx_dev(chip), "Timeout (%s %d)\n",
__func__, __LINE__);
-- 
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: [PATCH v6 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support

2015-01-22 Thread Lyra Zhang
Hi, Peter

Many thanks to you for reviewing so carefully and giving us so many
suggestions and so clear explanations.

I'll address all of your comments and send an updated patch soon.

On Fri, Jan 23, 2015 at 11:57 AM, Peter Hurley  wrote:
> Hi Chunyan,
>
> On 01/22/2015 08:35 AM, Chunyan Zhang wrote:
>> Add a full sc9836-uart driver for SC9836 SoC which is based on the
>> spreadtrum sharkl64 platform.
>> This driver also support earlycon.
>
> Looking good. Comments below.
>
>> This patch also replaced the spaces between the macros and their
>> values with the tabs in serial_core.h
>
> Notes about patch changes goes...
>
>>
>> Originally-by: Lanqing Liu 
>> Signed-off-by: Orson Zhai 
>> Signed-off-by: Chunyan Zhang 
>> ---
>
> ...here. For example,
>
> * Replaced spaces with tab for PORT_SPRD define in serial_core.h
>

ok

>>  drivers/tty/serial/Kconfig   |   18 +
>>  drivers/tty/serial/Makefile  |1 +
>>  drivers/tty/serial/sprd_serial.c |  801 
>> ++
>>  include/uapi/linux/serial_core.h |3 +
>>  4 files changed, 823 insertions(+)
>>  create mode 100644 drivers/tty/serial/sprd_serial.c
>>
>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>> index c79b43c..13211f7 100644
>> --- a/drivers/tty/serial/Kconfig
>> +++ b/drivers/tty/serial/Kconfig
>> @@ -1577,6 +1577,24 @@ config SERIAL_MEN_Z135
>> This driver can also be build as a module. If so, the module will be 
>> called
>> men_z135_uart.ko
>>
>> +config SERIAL_SPRD
>> + tristate "Support for Spreadtrum serial"
>> + depends on ARCH_SPRD
>> + select SERIAL_CORE
>> + help
>> +   This enables the driver for the Spreadtrum's serial.
>> +
>> +config SERIAL_SPRD_CONSOLE
>> + bool "Spreadtrum UART console support"
>> + depends on SERIAL_SPRD=y
>> + select SERIAL_CORE_CONSOLE
>> + select SERIAL_EARLYCON
>> + help
>> +   Support for early debug console using Spreadtrum's serial. This 
>> enables
>> +   the console before standard serial driver is probed. This is enabled
>> +   with "earlycon" on the kernel command line. The console is
>> +   enabled when early_param is processed.
>> +
>>  endmenu
>>
>>  config SERIAL_MCTRL_GPIO
>> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
>> index 9a548ac..4801aca 100644
>> --- a/drivers/tty/serial/Makefile
>> +++ b/drivers/tty/serial/Makefile
>> @@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_ARC)+= arc_uart.o
>>  obj-$(CONFIG_SERIAL_RP2) += rp2.o
>>  obj-$(CONFIG_SERIAL_FSL_LPUART)  += fsl_lpuart.o
>>  obj-$(CONFIG_SERIAL_MEN_Z135)+= men_z135_uart.o
>> +obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
>>
>>  # GPIOLIB helpers for modem control lines
>>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)  += serial_mctrl_gpio.o
>> diff --git a/drivers/tty/serial/sprd_serial.c 
>> b/drivers/tty/serial/sprd_serial.c
>> new file mode 100644
>> index 000..fd98541
>> --- /dev/null
>> +++ b/drivers/tty/serial/sprd_serial.c
>> @@ -0,0 +1,801 @@
>> +/*
>> + * Copyright (C) 2012-2015 Spreadtrum Communications Inc.
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* device name */
>> +#define UART_NR_MAX  8
>> +#define SPRD_TTY_NAME"ttyS"
>> +#define SPRD_FIFO_SIZE   128
>> +#define SPRD_DEF_RATE2600
>> +#define SPRD_TIMEOUT 2048
>> +
>> +/* the offset of serial registers and BITs for them */
>> +/* data registers */
>> +#define SPRD_TXD 0x
>> +#define SPRD_RXD 0x0004
>> +
>> +/* line status register and its BITs  */
>> +#define SPRD_LSR 0x0008
>> +#define SPRD_LSR_OE  BIT(4)
>> +#define SPRD_LSR_FE  BIT(3)
>> +#define SPRD_LSR_PE  BIT(2)
>> +#define SPRD_LSR_BI  BIT(7)
>> +#define SPRD_LSR_TX_OVER BIT(15)
>> +
>> +/* data number in TX and RX fifo */
>> +#define SPRD_STS10x000C
>> +
>> +/* interrupt enable register and its BITs */
>> +#define SPRD_IEN 0x0010
>> +#define SPRD_IEN_RX_FULL BIT(0)
>> +#define SPRD_IEN_TX_EMPTYBIT(1)
>> +#define SPRD_IEN_BREAK_DETECTBIT(7)
>> +#define SPRD_IEN_TIMEOUT BIT(13)
>> +
>> +/* interrupt clear register */
>> +#define SPRD_ICLR0x0014
>> +
>> +/* line control register */
>> +#define SPRD_LCR  

Re: [PATCH 5/6] regulator: max77843: Add max77843 regulator driver

2015-01-22 Thread Krzysztof Kozłowski
2015-01-23 6:02 GMT+01:00 Jaewon Kim :
> This patch adds new regulator driver to support max77843
> MFD(Multi Function Device) chip`s regulators.
> The Max77843 has two voltage regulators for USB safeout.
>
> Cc: Mark Brown 
> Signed-off-by: Beomho Seo 
> Signed-off-by: Jaewon Kim 
> ---
>  drivers/regulator/Kconfig|8 ++
>  drivers/regulator/Makefile   |1 +
>  drivers/regulator/max77843.c |  259 
> ++
>  3 files changed, 268 insertions(+)
>  create mode 100644 drivers/regulator/max77843.c
>
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index c3a60b5..c1f9c33 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -414,6 +414,14 @@ config REGULATOR_MAX77802
>   Exynos5420/Exynos5800 SoCs to control various voltages.
>   It includes support for control of voltage and ramp speed.
>
> +config REGULATOR_MAX77843
> +   tristate "Maxim 77843 regulator"
> +   depends on MFD_MAX77843
> +   help
> + This driver controls a Maxim 77843 regulator.
> + The regulator include two 'SAFEOUT' for USB(Universal Serial Bus)
> + This is suitable for Exynos5433 SoC chips.
> +
>  config REGULATOR_MC13XXX_CORE
> tristate
>
> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
> index 1f28ebf..12408d6 100644
> --- a/drivers/regulator/Makefile
> +++ b/drivers/regulator/Makefile
> @@ -55,6 +55,7 @@ obj-$(CONFIG_REGULATOR_MAX8998) += max8998.o
>  obj-$(CONFIG_REGULATOR_MAX77686) += max77686.o
>  obj-$(CONFIG_REGULATOR_MAX77693) += max77693.o
>  obj-$(CONFIG_REGULATOR_MAX77802) += max77802.o
> +obj-$(CONFIG_REGULATOR_MAX77843) += max77843.o
>  obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
>  obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
>  obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
> diff --git a/drivers/regulator/max77843.c b/drivers/regulator/max77843.c
> new file mode 100644
> index 000..86afc7a
> --- /dev/null
> +++ b/drivers/regulator/max77843.c
> @@ -0,0 +1,259 @@
> +/*
> + * max77843.c - Regulator driver for the Maxim MAX77843
> + *
> + * Copyright (C) 2014 Samsung Electrnoics
> + * Author: Jaewon Kim 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX77843_SUPPORTED_VOLTAGE_NUM 4
> +
> +enum max77843_regulator_type {
> +   MAX77843_SAFEOUT1 = 0,
> +   MAX77843_SAFEOUT2,
> +   MAX77843_CHARGER,
> +
> +   MAX77843_NUM,
> +};
> +
> +static const unsigned int max77843_regulator_table[] = {
> +   485,
> +   490,
> +   495,
> +   330,
> +};
> +
> +static int max77843_reg_is_enabled(struct regulator_dev *rdev)
> +{
> +   struct regmap *regmap = rdev->regmap;
> +   int ret;
> +   unsigned int reg;
> +
> +   ret = regmap_read(regmap, rdev->desc->enable_reg, );
> +   if (ret) {
> +   dev_err(>dev, "Fialed to read charger register\n");
> +   return ret;
> +   }
> +
> +   return (reg & rdev->desc->enable_mask) == rdev->desc->enable_mask;
> +}
> +
> +static int max77843_reg_get_current_limit(struct regulator_dev *rdev)
> +{
> +   struct regmap *regmap = rdev->regmap;
> +   unsigned int chg_min_uA = rdev->constraints->min_uA;
> +   unsigned int chg_max_uA = rdev->constraints->max_uA;
> +   unsigned int val;
> +   int ret;
> +   unsigned int reg, sel;
> +
> +   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_02, );
> +   if (ret) {
> +   dev_err(>dev, "Failed to read charger register\n");
> +   return ret;
> +   }
> +
> +   sel = reg & MAX77843_CHG_FAST_CHG_CURRENT_MASK;
> +
> +   if (sel < 0x03)
> +   sel = 0;
> +   else
> +   sel -= 2;
> +
> +   val = chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel;
> +   if (val > chg_max_uA)
> +   return -EINVAL;
> +
> +   return val;
> +}
> +
> +static int max77843_reg_set_current_limit(struct regulator_dev *rdev,
> +   int min_uA, int max_uA)
> +{
> +   struct regmap *regmap = rdev->regmap;
> +   unsigned int chg_min_uA = rdev->constraints->min_uA;
> +   int sel = 0;
> +
> +   while (chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel < min_uA)
> +   sel++;
> +
> +   if (chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel > max_uA)
> +   return -EINVAL;
> +
> +   sel += 2;
> +
> +   return regmap_write(regmap, MAX77843_CHG_REG_CHG_CNFG_02, sel);
> +}
> +
> +static struct regulator_ops max77843_charger_ops = {
> +   .is_enabled = max77843_reg_is_enabled,
> 

Re: [PATCH 2/6] extcon: max77843: Add max77843 MUIC driver

2015-01-22 Thread Jaewon Kim

Hi Krzysztof,

2015년 01월 23일 15:38에 Krzysztof Kozłowski 이(가) 쓴 글:

2015-01-23 6:02 GMT+01:00 Jaewon Kim :

This patch adds MAX77843 extcon driver to support for MUIC(Micro
USB Interface Controller) device by using EXTCON subsystem to handle
various external connectors.

Cc: Chanwoo Choi 
Signed-off-by: Jaewon Kim 
---
  drivers/extcon/Kconfig   |   10 +
  drivers/extcon/Makefile  |1 +
  drivers/extcon/extcon-max77843.c |  871 ++
  3 files changed, 882 insertions(+)
  create mode 100644 drivers/extcon/extcon-max77843.c


(...)


+static int max77843_muic_remove(struct platform_device *pdev)
+{
+   struct max77843_muic_info *info = platform_get_drvdata(pdev);
+
+   cancel_work_sync(>irq_work);
+

Missing regmap_del_irq_chip().

Best regards,
Krzysztof



I miss remap_del_irq_chip() function. thanks.
I wil add this function.


Thanks
Jaewon Kim

--
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: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode control

2015-01-22 Thread Alexander Duyck
On 01/22/2015 04:32 PM, Hiroshi Shimamoto wrote:
>> Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous 
>> mode control
>>> "Skidmore, Donald C"  writes:
>>>
 My hang up is more related to: without the nob to enable it (off by
 default) we are letting one VF dictate policy for all the other VFs
 and the PF.  If one VF needs to be in promiscuous multicast so is
 everyone else.  Their stacks now needs to deal with all the extra
 multicast packets.  As you point out this might not be a direct
 concern for isolation in that the VM could have 'chosen' to join any
 Multicast group and seen this traffic.  My concern over isolation is
 one VF has chosen that all the other VM now have to see this multicast
 traffic.
>>> Apologies if this question is stupid, but I just have to ask about stuff I 
>>> don't
>>> understand...
>>>
>>> Looking at the proposed implementation, the promiscous multicast flag
>>> seems to be a per-VF flag:
>>>
>>> +int ixgbe_ndo_set_vf_mc_promisc(struct net_device *netdev, int vf, bool
>>> +setting) {
>>> +   struct ixgbe_adapter *adapter = netdev_priv(netdev);
>>> +   struct ixgbe_hw *hw = >hw;
>>> +   u32 vmolr;
>>> +
>>> +   if (vf >= adapter->num_vfs)
>>> +   return -EINVAL;
>>> +
>>> +   adapter->vfinfo[vf].mc_promisc_enabled = setting;
>>> +
>>> +   vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
>>> +   if (setting) {
>>> +   e_info(drv, "VF %u: enabling multicast promiscuous\n", vf);
>>> +   vmolr |= IXGBE_VMOLR_MPE;
>>> +   } else {
>>> +   e_info(drv, "VF %u: disabling multicast promiscuous\n", vf);
>>> +   vmolr &= ~IXGBE_VMOLR_MPE;
>>> +   }
>>> +
>>> +   IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>
>>> I haven't read the data sheet, but I took a quick look at the excellent high
>>> level driver docs:
>>> http://www.intel.com/content/dam/doc/design-guide/82599-sr-iov-driver-
>>> companion-guide.pdf
>>>
>>> It mentions "Multicast Promiscuous Enable" in its "Thoughts for
>>> Customization" section:
>>>
>>>  7.1 Multicast Promiscuous Enable
>>>
>>>  The controller has provisions to allow each VF to be put into Multicast
>>> Promiscuous mode.  The Intel reference driver does not configure this
>>> option .
>>>
>>>  The capability can be enabled/disabled by manipulating the MPE field  (bit
>>> 28) of the PF VF L2 Control Register (PFVML2FLT – 0x0F000)
>>>
>>> and showing a section from the data sheet describing the "PF VM L2 Control
>>> Register - PFVML2FLT[n]  (0x0F000 + 4 * n, n=0...63; RW)"
>>>
>>> To me it looks like enabling Promiscuos Multicast for a VF won't affect any
>>> other VF at all.  Is this really not the case?
>>>
>>>
>>>
>>> Bjørn
>> Clearly not a dumb question at all and I'm glad you mentioned that. :)  I 
>> was going off the assumption, been awhile since
>> I read the patch, that the patch was using FCTRL.MPE or MANC.MCST_PASS_L2 
>> which would turn multicast promiscuous on for
>> everyone.  Since the patch is using PFVML2FLT.MPE this lessens my concern 
>> over effect on the entire system.
> I believe the patches for this VF multicast promiscuous mode is per VF.
>
>> That said I still would prefer having a way to override this behavior on the 
>> PF, although I admit my argument is weaker.
>> I'm still concerned about a VF changing the behavior of the PF without any 
>> way to prevent it.  This might be one part
>> philosophical (PF sets policy not the VF) but this still could have a 
>> noticeable effect on the overall system.  If any
>> other VFs (or the PF) are receiving MC packets these will have to be 
>> replicated which will be a performance hit.  When
>> we use the MC hash this is limited vs. when anyone is in MC promiscuous 
>> every MC packet used by another pool would be
>> replicated.  I could imagine in some environments (i.e. public clouds) where 
>> you don't trust what is running in your VM
>> you might what to block this from happening.
> I understand your request and I'm thinking to submit the patches
>   1) Add new mbox API between ixgbe/ixgbevf to turn MC promiscuous on,
>  and enables it when ixgbevf needs over 30 MC addresses.
>   2) Add a policy knob to prevent enabling it from the PF.
>
> Does it seem okay?

I would advise that if such a knob is added it should be set to disabled
by default.  The main problem with supporting that many multicast
addresses per VF is that you run the risk for flooding the PCIe
interface on the network adapter if too many adapters were to go into
such a mode.

> BTW, I'm bit worried about to use ndo interface for 2) because adding a
> new hook makes core code complicated.
> Is it really reasonable to do it with ndo?
> I haven't find any other suitable method to do it, right now. And using
> ndo VF hook looks standard way to control VF functionality.
> Then, I think it's the best way to implement this policy in ndo hook.

The ndo is probably the only way to go on this.  

Re: [PATCH 1/3] IPVS: add wlib & wlip schedulers

2015-01-22 Thread Julian Anastasov

Hello,

On Tue, 20 Jan 2015, Chris Caputo wrote:

> My application consists of incoming TCP streams being load balanced to 
> servers which receive the feeds. These are long lived multi-gigabyte 
> streams, and so I believe the estimator's 2-second timer is fine. As an 
> example:
> 
> # cat /proc/net/ip_vs_stats
>Total Incoming Outgoing Incoming Outgoing
>Conns  Packets  PacketsBytesBytes
>  9AB  58B7C170  1237CA2C3250
> 
>  Conns/s   Pkts/s   Pkts/s  Bytes/s  Bytes/s
>1 387C0  B16C4AE0

All other schedulers react and see different
picture after every new connection. The worst example
is WLC where slow-start mechanism is desired because
idle server can be overloaded before the load is noticed
properly. Even WRR accounts every connection in its state.

Your setup may expect low number of connections per
second but for other kind of setups sending all connections
to same server for 2 seconds looks scary. In fact, what
changes is the position, so we rotate only among the
least loaded servers that look equally loaded but it is
one server in the common case. And as our stats are per
CPU and designed for human reading, it is difficult to
read them often for other purposes. We need a good idea
to solve this problem, so that we can have faster feedback
after every scheduling.

> > May be not so useful idea: use sum of both directions
> > or control it with svc->flags & IP_VS_SVC_F_SCHED_WLIB_xxx
> > flags, see how "sh" scheduler supports flags. I.e.
> > inbps + outbps.
> 
> I see a user-mode option as increasing complexity. For example, 
> keepalived users would need to have keepalived patched to support the new 
> algorithm, due to flags, rather than just configuring "wlib" or "wlip" and 
> it just working.

That is also true.

> I think I'd rather see a wlob/wlop version for users that want to 
> load-balance based on outgoing bytes/packets, and a wlb/wlp version for 
> users that want them summed.

ok

> From: Chris Caputo  
> 
> IPVS: Change inbps and outbps to 64-bits so that estimator handles faster
> flows. Also increases maximum viewable at user level from ~2.15Gbits/s to
> ~34.35Gbits/s.

Yep, we are limited from u32 in user space structs.
I have to think how to solve this problem.

1gbit => ~1.5 million pps
10gbit => ~15 million pps
100gbit => ~150 million pps

> Signed-off-by: Chris Caputo 
> ---
> diff -uprN linux-3.19-rc5-stock/include/net/ip_vs.h 
> linux-3.19-rc5/include/net/ip_vs.h
> --- linux-3.19-rc5-stock/include/net/ip_vs.h  2015-01-18 06:02:20.0 
> +
> +++ linux-3.19-rc5/include/net/ip_vs.h2015-01-20 08:01:15.548177969 
> +
> @@ -390,8 +390,8 @@ struct ip_vs_estimator {
>   u32 cps;
>   u32 inpps;
>   u32 outpps;
> - u32 inbps;
> - u32 outbps;
> + u64 inbps;
> + u64 outbps;

Not sure, may be everything here should be u64 because
we have shifted values. I'll need some days to investigate
this issue...

Regards

--
Julian Anastasov 
--
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/6] mfd: max77843: Add max77843 MFD driver core driver

2015-01-22 Thread Krzysztof Kozlowski
On pią, 2015-01-23 at 15:41 +0900, Beomho Seo wrote:
> On 01/23/2015 03:32 PM, Krzysztof Kozlowski wrote:
> > 2015-01-23 6:02 GMT+01:00 Jaewon Kim :
> >> This patch adds MAX77843 core/irq driver to support PMIC,
> >> MUIC(Micro USB Interface Controller), Charger, Fuel Gauge,
> >> LED and Haptic device.
> >>
> >> Cc: Lee Jones 
> >> Signed-off-by: Beomho Seo 
> >> Signed-off-by: Jaewon Kim 
> >> ---
> >>  drivers/mfd/Kconfig  |   14 ++
> >>  drivers/mfd/Makefile |1 +
> >>  drivers/mfd/max77843.c   |  241 
> >>  include/linux/mfd/max77843-private.h |  410 
> >> ++
> >>  4 files changed, 666 insertions(+)
> >>  create mode 100644 drivers/mfd/max77843.c
> >>  create mode 100644 include/linux/mfd/max77843-private.h
> >>
> >> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >> index 2e6b731..0c67c79 100644
> >> --- a/drivers/mfd/Kconfig
> >> +++ b/drivers/mfd/Kconfig
> >> @@ -442,6 +442,20 @@ config MFD_MAX77693
> >>   additional drivers must be enabled in order to use the 
> >> functionality
> >>   of the device.
> >>
> >> +config MFD_MAX77843
> >> +   bool "Maxim Semiconductor MAX77843 PMIC Support"
> >> +   depends on I2C=y
> >> +   select MFD_CORE
> >> +   select REGMAP_I2C
> >> +   select REGMAP_IRQ
> >> +   help
> >> + Say yes here to add support for Maxim Semiconductor MAX77843.
> >> + This is companion Power Management IC with LEDs, Haptic, Charger,
> >> + Fuel Gauge, MUIC(Micro USB Interface Controller) controls on 
> >> chip.
> >> + This driver provides common support for accessing the device;
> >> + additional drivers must be enabled in order to use the 
> >> functionality
> >> + of the device.
> >> +
> >>  config MFD_MAX8907
> >> tristate "Maxim Semiconductor MAX8907 PMIC Support"
> >> select MFD_CORE
> >> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> >> index 53467e2..fe4f75c 100644
> >> --- a/drivers/mfd/Makefile
> >> +++ b/drivers/mfd/Makefile
> >> @@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9063)+= da9063.o
> >>  obj-$(CONFIG_MFD_MAX14577) += max14577.o
> >>  obj-$(CONFIG_MFD_MAX77686) += max77686.o
> >>  obj-$(CONFIG_MFD_MAX77693) += max77693.o
> >> +obj-$(CONFIG_MFD_MAX77843) += max77843.o
> >>  obj-$(CONFIG_MFD_MAX8907)  += max8907.o
> >>  max8925-objs   := max8925-core.o max8925-i2c.o
> >>  obj-$(CONFIG_MFD_MAX8925)  += max8925.o
> >> diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
> >> new file mode 100644
> >> index 000..d7f8b76
> >> --- /dev/null
> >> +++ b/drivers/mfd/max77843.c
> >> @@ -0,0 +1,241 @@
> >> +/*
> >> + * max77843.c - MFD core driver for the Maxim MAX77843
> >> + *
> >> + * Copyright (C) 2014 Samsung Electrnoics
> >> + * Author: Jaewon Kim 
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +static const struct mfd_cell max77843_devs[] = {
> >> +   {
> >> +   .name = "max77843-muic",
> >> +   .of_compatible = "maxim,max77843-muic",
> >> +   }, {
> >> +   .name = "max77843-regulator",
> >> +   .of_compatible = "maxim,max77843-regulator",
> >> +   }, {
> >> +   .name = "max77843-charger",
> >> +   .of_compatible = "maxim,max77843-charger"
> >> +   }, {
> >> +   .name = "max77843-fuelgauge",
> >> +   .of_compatible = "maxim,max77843-fuelgauge",
> >> +   },
> >> +};
> >> +
> >> +static const struct regmap_config max77843_charger_regmap_config = {
> >> +   .reg_bits   = 8,
> >> +   .val_bits   = 8,
> >> +   .max_register   = MAX77843_CHG_REG_END,
> >> +};
> >> +
> >> +static const struct regmap_config max77843_regmap_config = {
> >> +   .reg_bits   = 8,
> >> +   .val_bits   = 8,
> >> +   .max_register   = MAX77843_SYS_REG_END,
> >> +};
> >> +
> >> +static const struct regmap_irq max77843_irqs[] = {
> >> +   /* TOPSYS interrupts */
> >> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSUVLO_INT, },
> >> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSOVLO_INT, },
> >> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TSHDN_INT, },
> >> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TM_INT, },
> >> +};
> >> +
> >> +static const struct regmap_irq_chip max77843_irq_chip = {
> >> +   .name   = "max77843",
> >> +   .status_base= MAX77843_SYS_REG_SYSINTSRC,
> >> +   .mask_base  = MAX77843_SYS_REG_SYSINTMASK,

linux-next: Tree for Jan 23

2015-01-22 Thread Stephen Rothwell
Hi all,

There will be no linux-next release on Monday (next-20150126).

Changes since 20150122:

Added tree: kvms390
Removed tree:   documentation (at maintainers request)

The vfs tree gained a conflict against Linus' tree.

The akpm tree lost a patch that turned up elsewhere.

Non-merge commits (relative to Linus' tree): 4500
 4390 files changed, 174556 insertions(+), 78123 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 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 206 trees (counting Linus' and 30 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 (f8de05ca38b7 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the 
debian/ directory)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (909ba297beb5 ARM: 8292/1: mm: fix size rounding-down 
of arm_add_memory() function)
Merging m68k-current/for-linus (f27bd5bfeda5 m68k: Wire up execveat)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused 
force_32bit_msi quirk)
Merging powerpc-merge-mpe/fixes (0eb13208aa16 powerpc/powernv: Restore LPCR 
with LPCR_PECE1 cleared)
Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() 
needs to disable interrupts.)
Merging net/master (06efe0e54018 Merge tag 'pinctrl-v3.19-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl)
Merging ipsec/master (f855691975bb xfrm6: Fix the nexthdr offset in 
_decode_session6.)
Merging sound-current/for-linus (6455931186bf ALSA: usb-audio: Add mic volume 
fix quirk for Logitech Webcam C210)
Merging pci-current/for-linus (d63e2e1f3df9 sparc/PCI: Clip bridge windows to 
fit in upstream windows)
Merging wireless-drivers/master (e3f31175a3ee ath9k: fix race condition in irq 
processing during hardware reset)
Merging driver-core.current/driver-core-linus (ec6f34e5b552 Linux 3.19-rc5)
Merging tty.current/tty-linus (ec6f34e5b552 Linux 3.19-rc5)
Merging usb.current/usb-linus (ec6f34e5b552 Linux 3.19-rc5)
Merging usb-gadget-fixes/fixes (0df8fc37f6e4 usb: phy: never defer probe in 
non-OF case)
Merging usb-serial-fixes/usb-linus (ec6f34e5b552 Linux 3.19-rc5)
Merging staging.current/staging-linus (ec6f34e5b552 Linux 3.19-rc5)
Merging char-misc.current/char-misc-linus (ec6f34e5b552 Linux 3.19-rc5)
Merging input-current/for-linus (1d90d6d5522b Input: i8042 - add noloop quirk 
for Medion Akoya E7225 (MD98857))
Merging crypto-current/master (3e14dcf7cb80 crypto: add missing crypto module 
aliases)
Merging ide/master (f96fe225677b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging devicetree-current/devicetree/merge (15204ab1ebc5 of/platform: Handle 
of_populate drivers in notifier)
Merging rr-fixes/fixes (d5db139ab376 module: make module_refcount() a signed 
integer.)
Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci 
device type in vfio_pci_probe())
Merging kselftest-fixes/fixes (f5db310d77ef selftests/vm: fix link error for 
transhuge-stress test)
Merging drm-intel-fixes/for-linux-next-fixes (78f4e4767cdd drm/i915: BDW Fix 
Halo PCI IDs marked as ULT.)
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_f

Re: [PATCH 1/6] mfd: max77843: Add max77843 MFD driver core driver

2015-01-22 Thread Krzysztof Kozlowski
On pią, 2015-01-23 at 15:55 +0900, Jaewon Kim wrote:
> Hi Krzysztof,
> 
> 2015년 01월 23일 15:32에 Krzysztof Kozlowski 이(가) 쓴 글:
> > 2015-01-23 6:02 GMT+01:00 Jaewon Kim :
> >> This patch adds MAX77843 core/irq driver to support PMIC,
> >> MUIC(Micro USB Interface Controller), Charger, Fuel Gauge,
> >> LED and Haptic device.
> >>
> >> Cc: Lee Jones 
> >> Signed-off-by: Beomho Seo 
> >> Signed-off-by: Jaewon Kim 
> >> ---
> >>   drivers/mfd/Kconfig  |   14 ++
> >>   drivers/mfd/Makefile |1 +
> >>   drivers/mfd/max77843.c   |  241 
> >>   include/linux/mfd/max77843-private.h |  410 
> >> ++
> >>   4 files changed, 666 insertions(+)
> >>   create mode 100644 drivers/mfd/max77843.c
> >>   create mode 100644 include/linux/mfd/max77843-private.h
> >>
> >> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >> index 2e6b731..0c67c79 100644
> >> --- a/drivers/mfd/Kconfig
> >> +++ b/drivers/mfd/Kconfig
> >> @@ -442,6 +442,20 @@ config MFD_MAX77693
> >>additional drivers must be enabled in order to use the 
> >> functionality
> >>of the device.
> >>
> >> +config MFD_MAX77843
> >> +   bool "Maxim Semiconductor MAX77843 PMIC Support"
> >> +   depends on I2C=y
> >> +   select MFD_CORE
> >> +   select REGMAP_I2C
> >> +   select REGMAP_IRQ
> >> +   help
> >> + Say yes here to add support for Maxim Semiconductor MAX77843.
> >> + This is companion Power Management IC with LEDs, Haptic, Charger,
> >> + Fuel Gauge, MUIC(Micro USB Interface Controller) controls on 
> >> chip.
> >> + This driver provides common support for accessing the device;
> >> + additional drivers must be enabled in order to use the 
> >> functionality
> >> + of the device.
> >> +
> >>   config MFD_MAX8907
> >>  tristate "Maxim Semiconductor MAX8907 PMIC Support"
> >>  select MFD_CORE
> >> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> >> index 53467e2..fe4f75c 100644
> >> --- a/drivers/mfd/Makefile
> >> +++ b/drivers/mfd/Makefile
> >> @@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9063)+= da9063.o
> >>   obj-$(CONFIG_MFD_MAX14577) += max14577.o
> >>   obj-$(CONFIG_MFD_MAX77686) += max77686.o
> >>   obj-$(CONFIG_MFD_MAX77693) += max77693.o
> >> +obj-$(CONFIG_MFD_MAX77843) += max77843.o
> >>   obj-$(CONFIG_MFD_MAX8907)  += max8907.o
> >>   max8925-objs   := max8925-core.o max8925-i2c.o
> >>   obj-$(CONFIG_MFD_MAX8925)  += max8925.o
> >> diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
> >> new file mode 100644
> >> index 000..d7f8b76
> >> --- /dev/null
> >> +++ b/drivers/mfd/max77843.c
> >> @@ -0,0 +1,241 @@
> >> +/*
> >> + * max77843.c - MFD core driver for the Maxim MAX77843
> >> + *
> >> + * Copyright (C) 2014 Samsung Electrnoics
> >> + * Author: Jaewon Kim 
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +static const struct mfd_cell max77843_devs[] = {
> >> +   {
> >> +   .name = "max77843-muic",
> >> +   .of_compatible = "maxim,max77843-muic",
> >> +   }, {
> >> +   .name = "max77843-regulator",
> >> +   .of_compatible = "maxim,max77843-regulator",
> >> +   }, {
> >> +   .name = "max77843-charger",
> >> +   .of_compatible = "maxim,max77843-charger"
> >> +   }, {
> >> +   .name = "max77843-fuelgauge",
> >> +   .of_compatible = "maxim,max77843-fuelgauge",
> >> +   },
> >> +};
> >> +
> >> +static const struct regmap_config max77843_charger_regmap_config = {
> >> +   .reg_bits   = 8,
> >> +   .val_bits   = 8,
> >> +   .max_register   = MAX77843_CHG_REG_END,
> >> +};
> >> +
> >> +static const struct regmap_config max77843_regmap_config = {
> >> +   .reg_bits   = 8,
> >> +   .val_bits   = 8,
> >> +   .max_register   = MAX77843_SYS_REG_END,
> >> +};
> >> +
> >> +static const struct regmap_irq max77843_irqs[] = {
> >> +   /* TOPSYS interrupts */
> >> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSUVLO_INT, },
> >> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSOVLO_INT, },
> >> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TSHDN_INT, },
> >> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TM_INT, },
> >> +};
> >> +
> >> +static const struct regmap_irq_chip max77843_irq_chip = {
> >> +   .name   = "max77843",
> >> +   .status_base= MAX77843_SYS_REG_SYSINTSRC,
> >> +   

Re: [PATCH 3/6] power: max77843_charger: Add Max77843 charger device driver

2015-01-22 Thread Krzysztof Kozłowski
2015-01-23 6:02 GMT+01:00 Jaewon Kim :
> From: Beomho Seo 
>
> This patch adds device driver of max77843 charger. This driver provide
> initialize each charging mode(e.g. fast charge, top-off mode and constant
> charging mode so on.). Additionally, control charging paramters to use
> i2c interface.
>
> Cc: Sebastian Reichel 
> Signed-off-by: Beomho Seo 
> ---
>  drivers/power/Kconfig|7 +
>  drivers/power/Makefile   |1 +
>  drivers/power/max77843_charger.c |  506 
> ++
>  3 files changed, 514 insertions(+)
>  create mode 100644 drivers/power/max77843_charger.c
>
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 0108c2a..a054a28 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -332,6 +332,13 @@ config CHARGER_MAX14577
>   Say Y to enable support for the battery charger control sysfs and
>   platform data of MAX14577/77836 MUICs.
>
> +config CHARGER_MAX77843
> +   tristate "Maxim MAX77843 battery charger driver"
> +   depends on MFD_MAX77843
> +   help
> + Say Y to enable support for the battery charger control sysfs and
> + platform data of MAX77843
> +
>  config CHARGER_MAX8997
> tristate "Maxim MAX8997/MAX8966 PMIC battery charger driver"
> depends on MFD_MAX8997 && REGULATOR_MAX8997
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index dfa8942..212c6a2 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_CHARGER_LP8788)  += lp8788-charger.o
>  obj-$(CONFIG_CHARGER_GPIO) += gpio-charger.o
>  obj-$(CONFIG_CHARGER_MANAGER)  += charger-manager.o
>  obj-$(CONFIG_CHARGER_MAX14577) += max14577_charger.o
> +obj-$(CONFIG_CHARGER_MAX77843) += max77843_charger.o
>  obj-$(CONFIG_CHARGER_MAX8997)  += max8997_charger.o
>  obj-$(CONFIG_CHARGER_MAX8998)  += max8998_charger.o
>  obj-$(CONFIG_CHARGER_BQ2415X)  += bq2415x_charger.o
> diff --git a/drivers/power/max77843_charger.c 
> b/drivers/power/max77843_charger.c
> new file mode 100644
> index 000..317b2cc
> --- /dev/null
> +++ b/drivers/power/max77843_charger.c
> @@ -0,0 +1,506 @@
> +/*
> + * Charger driver for Maxim MAX77843
> + *
> + * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
> + * Author: Beomho Seo 
> + *
> + * 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 bythe Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct max77843_charger_info {
> +   u32 fast_charge_uamp;
> +   u32 top_off_uamp;
> +   u32 input_uamp_limit;
> +};
> +
> +struct max77843_charger {
> +   struct device   *dev;
> +   struct max77843 *max77843;
> +   struct i2c_client   *client;
> +   struct regmap   *regmap;
> +   struct power_supply psy;
> +
> +   struct max77843_charger_info*info;
> +};

Why creating two separate structures?

> +
> +static int max77843_charger_get_max_current(struct max77843_charger *charger)
> +{
> +   struct regmap *regmap = charger->regmap;
> +   int ret, val = 0;
> +   unsigned int reg_data;
> +
> +   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_09, _data);
> +   if (ret) {
> +   dev_err(charger->dev, "Failed to read charger register\n");
> +   return ret;
> +   }
> +
> +   if (reg_data <= 0x03) {
> +   val = MAX77843_CHG_INPUT_CURRENT_LIMIT_MIN;
> +   } else if (reg_data >= 0x78) {
> +   val = MAX77843_CHG_INPUT_CURRENT_LIMIT_MAX;
> +   } else {
> +   val = reg_data / 3;
> +   if (reg_data % 3 == 0)
> +   val *= 10;
> +   else if (reg_data % 3 == 1)
> +   val = val * 10 + 33000;
> +   else
> +   val = val * 10 + 67000;
> +   }
> +
> +   return val;
> +}
> +
> +static int max77843_charger_get_now_current(struct max77843_charger *charger)
> +{
> +   struct regmap *regmap = charger->regmap;
> +   int ret, val = 0;
> +   unsigned int reg_data;
> +
> +   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_02, _data);
> +   if (ret) {
> +   dev_err(charger->dev, "Failed to read charger register\n");

This error log shows up in many places. Please print also error code.

Additionally I think it could be useful to print also details about
register which failed. Currently user would not know which register
access failed. Consider adding short description like "Failed to read
current charger register: %d...". However I do not insist on this so
it is up to you.

> +   return ret;
> +   }
> +
> +   reg_data &= MAX77843_CHG_FAST_CHG_CURRENT_MASK;
> +
> +   if (reg_data <= 0x02)
> +   val = 

Re: [PATCH] mm/slub: suppress BUG messages for kmem_cache_alloc/kmem_cache_free

2015-01-22 Thread Andrey Skvortsov
On Thu, Jan 22, 2015 at 03:19:18PM -0800, David Rientjes wrote:
> On Thu, 22 Jan 2015, Andrey Skvortsov wrote:
> 
> > diff --git a/mm/slub.c b/mm/slub.c
> > index ceee1d7..6bcd031 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -2404,7 +2404,7 @@ redo:
> >  */
> > do {
> > tid = this_cpu_read(s->cpu_slab->tid);
> > -   c = this_cpu_ptr(s->cpu_slab);
> > +   c = raw_cpu_ptr(s->cpu_slab);
> > } while (IS_ENABLED(CONFIG_PREEMPT) && unlikely(tid != c->tid));
> >  
> > /*
> > @@ -2670,7 +2670,7 @@ redo:
> >  */
> > do {
> > tid = this_cpu_read(s->cpu_slab->tid);
> > -   c = this_cpu_ptr(s->cpu_slab);
> > +   c = raw_cpu_ptr(s->cpu_slab);
> > } while (IS_ENABLED(CONFIG_PREEMPT) && unlikely(tid != c->tid));
> >  
> > /* Same with comment on barrier() in slab_alloc_node() */
> 
> This should already be fixed with 
> http://ozlabs.org/~akpm/mmotm/broken-out/mm-slub-optimize-alloc-free-fastpath-by-removing-preemption-on-off-v3.patch

> You can find the latest mmotm, which was just released, at 
> http://ozlabs.org/~akpm/mmotm and it should be in linux-next tomorrow.
ok. I've just looked at linux-next/master and
linux-next/akpm branches and that was not fixed there. Thanks for the
link. I'll look there in the future for mm-related patches posting a
new one.

-- 
Best regards,
Andrey Skvortsov

Secure eMail with gnupg: See http://www.gnupg.org/
PGP Key ID: 0x57A3AEAD


signature.asc
Description: Digital signature


Re: [alsa-devel] [PATCH v4 3/3] ARM: dts: Add sound nodes for exynos4412-trats2

2015-01-22 Thread Inha Song
Hi Kukjin,

Sorry, I missed to adding in Cc.

Best Regards,
Inha Song.

On Fri, 23 Jan 2015 14:03:30 +0900
Inha Song  wrote:

> This patch add WM1811 audio codec, I2S interface and the sound
> machine nodes to enable audio on exynos4412-trats2 board.
> 
> Signed-off-by: Inha Song 
> ---
>  arch/arm/boot/dts/exynos4412-trats2.dts | 42 
> +
>  1 file changed, 42 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 29231b4..6205b98 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -203,6 +203,25 @@
>   };
>   };
>  
> + i2c@138A {
> + samsung,i2c-sda-delay = <100>;
> + samsung,i2c-slave-addr = <0x10>;
> + samsung,i2c-max-bus-freq = <10>;
> + pinctrl-0 = <_bus>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + wm1811: wm1811@1a {
> + compatible = "wlf,wm1811";
> + reg = <0x1a>;
> + clocks = <_system_controller 0>;
> + clock-names = "MCLK1";
> + DCVDD-supply = <_reg>;
> + DBVDD1-supply = <_reg>;
> + wlf,ldo1ena = < 4 0>;
> + };
> + };
> +
>   i2c@138D {
>   samsung,i2c-sda-delay = <100>;
>   samsung,i2c-slave-addr = <0x10>;
> @@ -838,6 +857,24 @@
>   };
>   };
>  
> + i2s0: i2s@0383 {
> + pinctrl-0 = <_bus>;
> + pinctrl-names = "default";
> + status = "okay";
> + };
> +
> + sound {
> + compatible = "samsung,trats2-audio";
> + samsung,i2s-controller = <>;
> + samsung,model = "Trats2";
> + samsung,audio-codec = <>;
> + samsung,audio-routing =
> + "SPK", "SPKOUTLN",
> + "SPK", "SPKOUTLP",
> + "SPK", "SPKOUTRN",
> + "SPK", "SPKOUTRP";
> + };
> +
>   exynos-usbphy@125B {
>   status = "okay";
>   };
> @@ -865,6 +902,11 @@
>   };
>  };
>  
> +_system_controller {
> + assigned-clocks = <_system_controller 0>;
> + assigned-clock-parents =  < CLK_XUSBXTI>;
> +};
> +
>  _0 {
>   pinctrl-names = "default";
>   pinctrl-0 = <>;
> -- 
> 2.0.0.390.gcb682f8
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
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: rcu, sched: WARNING: CPU: 30 PID: 23771 at kernel/rcu/tree_plugin.h:337 rcu_read_unlock_special+0x369/0x550()

2015-01-22 Thread Paul E. McKenney
On Thu, Jan 22, 2015 at 11:05:45PM -0500, Sasha Levin wrote:
> On 01/22/2015 11:02 PM, Sasha Levin wrote:
> > On 01/22/2015 10:51 PM, Paul E. McKenney wrote:
> >> On Thu, Jan 22, 2015 at 10:29:01PM -0500, Sasha Levin wrote:
>  On 01/21/2015 07:43 PM, Paul E. McKenney wrote:
> >> On Wed, Jan 21, 2015 at 10:44:57AM -0500, Sasha Levin wrote:
>  On 01/20/2015 09:57 PM, Paul E. McKenney wrote:
> >> So RCU believes that an RCU read-side critical section that 
> >> ended within
> >> an interrupt handler (in this case, an hrtimer) somehow 
> >> got preempted.
> >> Which is not supposed to happen.
> >>
> >> Do you have CONFIG_PROVE_RCU enabled?  If not, could you 
> >> please enable it
> >> and retry?
> >>
> >> I did have CONFIG_PROVE_RCU, and didn't see anything else 
> >> besides what I pasted here.
> >> OK, fair enough.  I do have a stack of RCU CPU stall-warning 
> >> changes on
> >> their way in, please see v3.19-rc1..630181c4a915 in -rcu, which is 
> >> at:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> >>
> >> These handle the problems that Dave Jones, yourself, and a few 
> >> others
> >> located this past December.  Could you please give them a spin?
> 
>  They seem to be a part of -next already, so this testing already 
>  includes them.
> 
>  I seem to be getting them about once a day, anything I can add to 
>  debug it?
> >>
> >> Could you please try reproducing with the following patch?
> 
>  Yes, and I've got mixed results. It reproduced, and all I got was:
> 
>  [  717.645572] ===
>  [  717.645572] [ INFO: suspicious RCU usage. ]
>  [  717.645572] 3.19.0-rc5-next-20150121-sasha-00064-g3c37e35-dirty #1809 
>  Tainted: GW
>  [  717.645572] ---
>  [  717.645572] kernel/rcu/tree_plugin.h:337 rcu_read_unlock() from irq 
>  or softirq with blocking in critical section!!!
>  [  717.645572] !
>  [  717.645572]
>  [  717.645572] other info that might help us debug this:
>  [  717.645572]
>  [  717.645572]
>  [  717.645572] rcu_scheduler_active = 1, debug_locks = 1
>  [  717.645572] 3 locks held by trinity-c29/16497:
>  [  717.645572]  #0:  (>s_type->i_mutex_key){+.+.+.}, at: 
>  [] lookup_slow+0xd3/0x420
>  [  717.645572]  #1:
>  [hang]
> 
>  So the rest of the locks/stack trace didn't get printed, nor the 
>  pr_alert() which
>  should follow that.
> 
>  I've removed the lockdep call and will re-run it.
> >> Thank you!  You are keeping the pr_alert(), correct?
> > 
> > Yup, just the lockdep call goes away.
> 
> Okay, this reproduced faster than I anticipated:
> 
> [  786.160131] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> [  786.239513] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> [  786.240503] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> [  786.242575] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> [  786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> [  786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> [  786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> [  786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> [  786.243565] ->rcu_read_unlock_special: 0x100 (b: 0, nq: 1)
> 
> It seems like the WARN_ON_ONCE was hiding the fact it actually got hit couple
> of times in a very short interval. Maybe that would also explain lockdep 
> crapping
> itself.

OK, that was what I thought was the situation.  I have not yet fully
worked out how RCU gets into that state, but in the meantime, here
is a patch that should prevent the splats.  (It requires a subtle
interaction of quiescent-state detection and the scheduling-clock
interrupt.)

Thanx, Paul



rcu: Clear need_qs flag to prevent splat

If the scheduling-clock interrupt sets the current tasks need_qs flag,
but if the current CPU passes through a quiescent state in the meantime,
then rcu_preempt_qs() will fail to clear the need_qs flag, which can fool
RCU into thinking that additional rcu_read_unlock_special() processing
is needed.  This commit therefore clears the need_qs flag before checking
for additional processing.

Reported-by: Sasha Levin 
Signed-off-by: Paul E. McKenney 

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 8669de884445..ec99dc16aa38 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -322,6 +322,7 @@ void rcu_read_unlock_special(struct task_struct *t)
special = t->rcu_read_unlock_special;
  

RE: [PATCH RESEND 0/2] Add regulator-haptic device tree

2015-01-22 Thread Kukjin Kim
Jaewon Kim wrote:
> 
> This patch series adds regulator-haptic device tree in rinato and monk boards.
> 
> The regulator-haptic has haptic motor and it is controlled by
> voltage of regulator via force feedback framework.
> 
> regualtor-haptic driver merged at linux-next
> ref : https://lkml.org/lkml/2014/12/17/477
> 
Found the series in linux-next.

> Jaewon Kim (2):
>   ARM: dts: exynos3250-rinato: Add regulator-haptic node for haptics
>   ARM: dts: exynos3250-monk: Add regulator-haptic node for haptics
> 
OK, looks good to me, will apply this series.

Thanks,
Kukjin

--
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/6] mfd: max77843: Add max77843 MFD driver core driver

2015-01-22 Thread Jaewon Kim

Hi Krzysztof,

2015년 01월 23일 15:32에 Krzysztof Kozlowski 이(가) 쓴 글:

2015-01-23 6:02 GMT+01:00 Jaewon Kim :

This patch adds MAX77843 core/irq driver to support PMIC,
MUIC(Micro USB Interface Controller), Charger, Fuel Gauge,
LED and Haptic device.

Cc: Lee Jones 
Signed-off-by: Beomho Seo 
Signed-off-by: Jaewon Kim 
---
  drivers/mfd/Kconfig  |   14 ++
  drivers/mfd/Makefile |1 +
  drivers/mfd/max77843.c   |  241 
  include/linux/mfd/max77843-private.h |  410 ++
  4 files changed, 666 insertions(+)
  create mode 100644 drivers/mfd/max77843.c
  create mode 100644 include/linux/mfd/max77843-private.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b731..0c67c79 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -442,6 +442,20 @@ config MFD_MAX77693
   additional drivers must be enabled in order to use the functionality
   of the device.

+config MFD_MAX77843
+   bool "Maxim Semiconductor MAX77843 PMIC Support"
+   depends on I2C=y
+   select MFD_CORE
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   help
+ Say yes here to add support for Maxim Semiconductor MAX77843.
+ This is companion Power Management IC with LEDs, Haptic, Charger,
+ Fuel Gauge, MUIC(Micro USB Interface Controller) controls on chip.
+ This driver provides common support for accessing the device;
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
  config MFD_MAX8907
 tristate "Maxim Semiconductor MAX8907 PMIC Support"
 select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..fe4f75c 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9063)+= da9063.o
  obj-$(CONFIG_MFD_MAX14577) += max14577.o
  obj-$(CONFIG_MFD_MAX77686) += max77686.o
  obj-$(CONFIG_MFD_MAX77693) += max77693.o
+obj-$(CONFIG_MFD_MAX77843) += max77843.o
  obj-$(CONFIG_MFD_MAX8907)  += max8907.o
  max8925-objs   := max8925-core.o max8925-i2c.o
  obj-$(CONFIG_MFD_MAX8925)  += max8925.o
diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
new file mode 100644
index 000..d7f8b76
--- /dev/null
+++ b/drivers/mfd/max77843.c
@@ -0,0 +1,241 @@
+/*
+ * max77843.c - MFD core driver for the Maxim MAX77843
+ *
+ * Copyright (C) 2014 Samsung Electrnoics
+ * Author: Jaewon Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct mfd_cell max77843_devs[] = {
+   {
+   .name = "max77843-muic",
+   .of_compatible = "maxim,max77843-muic",
+   }, {
+   .name = "max77843-regulator",
+   .of_compatible = "maxim,max77843-regulator",
+   }, {
+   .name = "max77843-charger",
+   .of_compatible = "maxim,max77843-charger"
+   }, {
+   .name = "max77843-fuelgauge",
+   .of_compatible = "maxim,max77843-fuelgauge",
+   },
+};
+
+static const struct regmap_config max77843_charger_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .max_register   = MAX77843_CHG_REG_END,
+};
+
+static const struct regmap_config max77843_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .max_register   = MAX77843_SYS_REG_END,
+};
+
+static const struct regmap_irq max77843_irqs[] = {
+   /* TOPSYS interrupts */
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSUVLO_INT, },
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSOVLO_INT, },
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TSHDN_INT, },
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TM_INT, },
+};
+
+static const struct regmap_irq_chip max77843_irq_chip = {
+   .name   = "max77843",
+   .status_base= MAX77843_SYS_REG_SYSINTSRC,
+   .mask_base  = MAX77843_SYS_REG_SYSINTMASK,
+   .mask_invert= false,
+   .num_regs   = 1,
+   .irqs   = max77843_irqs,
+   .num_irqs   = ARRAY_SIZE(max77843_irqs),
+};
+
+static int max77843_chg_init(struct max77843 *max77843)
+{

Could this function be moved to the charger driver? This way the
driver will manage its own resources instead of depending on parent
MFD driver.


+   int ret;
+
+   max77843->i2c_chg = i2c_new_dummy(max77843->i2c->adapter, I2C_ADDR_CHG);
+   if (!max77843->i2c_chg) {
+   dev_err(>i2c->dev,
+   "Cannot allocate I2C device for Charger\n");
+   return 

Re: [Resend Patch v4 14/16] smp, s390: Kill SMP single function call interrupt

2015-01-22 Thread Heiko Carstens
On Fri, Jan 23, 2015 at 01:36:53PM +0800, Jiang Liu wrote:
> Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
> similar to smp_call_function_single()" has unified the way to handle
> single and multiple cross-CPU function calls. Now only one interrupt
> is needed for architecture specific code to support generic SMP function
> call interfaces, so kill the redundant single function call interrupt.
> 
> Signed-off-by: Jiang Liu 
> Acked-by: Heiko Carstens 

Is this really the patch I acked, whenever that was? Because the patch
description doesn't match what your patch does.
All it does is renaming ec_call_function_single to ec_call_function,
nothing else.

Could you please resend with a proper patch description?
Thanks!

> ---
>  arch/s390/kernel/smp.c |   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
> index 0b499f5cbe19..5b89eabc3a01 100644
> --- a/arch/s390/kernel/smp.c
> +++ b/arch/s390/kernel/smp.c
> @@ -50,7 +50,7 @@
> 
>  enum {
>   ec_schedule = 0,
> - ec_call_function_single,
> + ec_call_function,
>   ec_stop_cpu,
>  };
> 
> @@ -416,8 +416,8 @@ static void smp_handle_ext_call(void)
>   smp_stop_cpu();
>   if (test_bit(ec_schedule, ))
>   scheduler_ipi();
> - if (test_bit(ec_call_function_single, ))
> - generic_smp_call_function_single_interrupt();
> + if (test_bit(ec_call_function, ))
> + generic_smp_call_function_interrupt();
>  }
> 
>  static void do_ext_call_interrupt(struct ext_code ext_code,
> @@ -432,12 +432,12 @@ void arch_send_call_function_ipi_mask(const struct 
> cpumask *mask)
>   int cpu;
> 
>   for_each_cpu(cpu, mask)
> - pcpu_ec_call(pcpu_devices + cpu, ec_call_function_single);
> + pcpu_ec_call(pcpu_devices + cpu, ec_call_function);
>  }
> 
>  void arch_send_call_function_single_ipi(int cpu)
>  {
> - pcpu_ec_call(pcpu_devices + cpu, ec_call_function_single);
> + pcpu_ec_call(pcpu_devices + cpu, ec_call_function);
>  }
> 
>  #ifndef CONFIG_64BIT
> -- 
> 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: [PATCH 1/2] clk: exynos5420: Add IDs for clocks used in DISP1 power domain

2015-01-22 Thread Kukjin Kim
Javier Martinez Canillas wrote:
> 
> Hello,
> 
Hi,

> On 01/20/2015 06:54 PM, Mike Turquette wrote:
> > Quoting Sylwester Nawrocki (2015-01-20 06:04:00)
> >> Hi,
> >>
> >> On 20/01/15 11:35, Javier Martinez Canillas wrote:
> >> > When a power domain is powered off on Exynos5420 SoC, the input clocks of
> >> > the devices attached to this power domain are re-parented to oscclk and
> >> > restored to the original parent after powering on the power domain.
> >> >
> >> > So a reference to the input and parent clocks for the devices attached to
> >> > a power domain are needed to be able to do the re-parenting. The DISP1 pd
> >> > includes modules which uses the following clocks:
> >> >
> >> > ACLK_200_DISP1 (MIXER and HDMILINK)
> >> > ACLK_300_DISP1 (FIMD1)
> >> > ACLK_400_DISP1 (Internal Buses)
> >> >
> >> > Each of these clocks are generated as the output of a clock mux so add an
> >> > ID for all of these clock muxes and their parents to be referenced in the
> >> > DISP1 power domain device node.
> >> >
> >> > Signed-off-by: Javier Martinez Canillas 
> >>
> >> The patch looks OK to me, I'm fine with it being merged via Kukjin's tree
> >> due to the dts dependencies (including other pending dts patches touching
> >> the arch/arm/boot/dts/exynos5420.dtsi file).
> >> I think we need also Mike ACK for that, I could also queue the patch for
> >> the clk tree and create a topic branch, but merging both patches via
> >> arm-soc seems a more sane option in this case.
> >>
> >> Acked-by: Sylwester Nawrocki 
> >
> > Acked-by: Michael Turquette 
> >
> 
> Thanks a lot Sylwester and Mike for your acks.
> 
> Kukjin, could you please pick $subject and "Patch 2/2 ARM: dts: Add DISP1
> power domain for exynos5420" through your tree?
> 
Sure, I will after applying Marek's generic power domain patch.

Thanks,
Kukjin

--
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/6] mfd: max77843: Add max77843 MFD driver core driver

2015-01-22 Thread Chanwoo Choi
Hi Jaewon,

On 01/23/2015 02:02 PM, Jaewon Kim wrote:
> This patch adds MAX77843 core/irq driver to support PMIC,
> MUIC(Micro USB Interface Controller), Charger, Fuel Gauge,
> LED and Haptic device.
> 
> Cc: Lee Jones 
> Signed-off-by: Beomho Seo 
> Signed-off-by: Jaewon Kim 
> ---
>  drivers/mfd/Kconfig  |   14 ++
>  drivers/mfd/Makefile |1 +
>  drivers/mfd/max77843.c   |  241 
>  include/linux/mfd/max77843-private.h |  410 
> ++
>  4 files changed, 666 insertions(+)
>  create mode 100644 drivers/mfd/max77843.c
>  create mode 100644 include/linux/mfd/max77843-private.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 2e6b731..0c67c79 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -442,6 +442,20 @@ config MFD_MAX77693
> additional drivers must be enabled in order to use the functionality
> of the device.
>  
> +config MFD_MAX77843
> + bool "Maxim Semiconductor MAX77843 PMIC Support"
> + depends on I2C=y
> + select MFD_CORE
> + select REGMAP_I2C
> + select REGMAP_IRQ
> + help
> +   Say yes here to add support for Maxim Semiconductor MAX77843.
> +   This is companion Power Management IC with LEDs, Haptic, Charger,
> +   Fuel Gauge, MUIC(Micro USB Interface Controller) controls on chip.
> +   This driver provides common support for accessing the device;
> +   additional drivers must be enabled in order to use the functionality
> +   of the device.
> +
>  config MFD_MAX8907
>   tristate "Maxim Semiconductor MAX8907 PMIC Support"
>   select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 53467e2..fe4f75c 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9063)  += da9063.o
>  obj-$(CONFIG_MFD_MAX14577)   += max14577.o
>  obj-$(CONFIG_MFD_MAX77686)   += max77686.o
>  obj-$(CONFIG_MFD_MAX77693)   += max77693.o
> +obj-$(CONFIG_MFD_MAX77843)   += max77843.o
>  obj-$(CONFIG_MFD_MAX8907)+= max8907.o
>  max8925-objs := max8925-core.o max8925-i2c.o
>  obj-$(CONFIG_MFD_MAX8925)+= max8925.o
> diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
> new file mode 100644
> index 000..d7f8b76
> --- /dev/null
> +++ b/drivers/mfd/max77843.c
> @@ -0,0 +1,241 @@
> +/*
> + * max77843.c - MFD core driver for the Maxim MAX77843
> + *
> + * Copyright (C) 2014 Samsung Electrnoics
> + * Author: Jaewon Kim 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct mfd_cell max77843_devs[] = {
> + {
> + .name = "max77843-muic",
> + .of_compatible = "maxim,max77843-muic",
> + }, {
> + .name = "max77843-regulator",
> + .of_compatible = "maxim,max77843-regulator",
> + }, {
> + .name = "max77843-charger",
> + .of_compatible = "maxim,max77843-charger"
> + }, {
> + .name = "max77843-fuelgauge",
> + .of_compatible = "maxim,max77843-fuelgauge",
> + },
> +};
> +
> +static const struct regmap_config max77843_charger_regmap_config = {
> + .reg_bits   = 8,
> + .val_bits   = 8,
> + .max_register   = MAX77843_CHG_REG_END,
> +};
> +
> +static const struct regmap_config max77843_regmap_config = {
> + .reg_bits   = 8,
> + .val_bits   = 8,
> + .max_register   = MAX77843_SYS_REG_END,
> +};
> +
> +static const struct regmap_irq max77843_irqs[] = {
> + /* TOPSYS interrupts */
> + { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSUVLO_INT, },
> + { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSOVLO_INT, },
> + { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TSHDN_INT, },
> + { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TM_INT, },
> +};
> +
> +static const struct regmap_irq_chip max77843_irq_chip = {
> + .name   = "max77843",
> + .status_base= MAX77843_SYS_REG_SYSINTSRC,
> + .mask_base  = MAX77843_SYS_REG_SYSINTMASK,
> + .mask_invert= false,
> + .num_regs   = 1,
> + .irqs   = max77843_irqs,
> + .num_irqs   = ARRAY_SIZE(max77843_irqs),
> +};
> +
> +static int max77843_chg_init(struct max77843 *max77843)
> +{
> + int ret;
> +
> + max77843->i2c_chg = i2c_new_dummy(max77843->i2c->adapter, I2C_ADDR_CHG);
> + if (!max77843->i2c_chg) {
> + dev_err(>i2c->dev,
> + "Cannot allocate I2C device for Charger\n");
> + return PTR_ERR(max77843->i2c_chg);
> + }
> + 

Re: [PATCH 1/4] pinctrl: Broadcom Cygnus pinctrl device tree binding

2015-01-22 Thread Ray Jui


On 1/22/2015 6:14 PM, Ray Jui wrote:
> 
> 
> On 1/13/2015 12:20 AM, Linus Walleij wrote:
>> On Fri, Jan 9, 2015 at 7:26 PM, Ray Jui  wrote:
>>> On 1/9/2015 2:12 AM, Linus Walleij wrote:
>>
 Just use "groups" and "function" and refer to
 Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt

 Then "alt1", "alt2" etc are non-functional names of functions.
 Use the real function names, like "spi0" or so. This
 alt-business seems to be just a shortcut to make it
 simple, don't do that.

 Then you use e.g. "spi0" as a group name. I prefer you
 call that "spi0_grp" or something to say it is a group of
 pins associated with spi0, as spi0 is actually the
 function.

>>> Hmmm, I did this by following brcm,bcm11351-pinctrl.txt:
>>> - function: String. Specifies the pin mux selection. Values must be one
>>> of: "alt1", "alt2", "alt3", "alt4"
>>>
>>> But you are right, in the pinctrl binding document it describes the
>>> generic pin multiplexing nodes use "function" and "group".
>>
>> Note "function" and "groups". Note groups is pluralis. You can
>> select multiple groups for a single function.
>>
>>> For example, the group "lcd" covers 30 pins. When I configure "lcd" to
>>> alternate function 1, all 30 pins are muxed to LCD function. When
>>> configured to function 2, all pins are muxed to SRAM function. Now, here
>>> comes the issue, when configured to function 3, pins 1-15 and 20-30
>>> become GPIO function, but pins 16-19 becomes SPI5 function. When it's
>>> configured to function 4, all 30 pins become GPIO.
>>
>> I would split the use case in two groups for LCD and SRAM,
>> and three groups for GPIO:
>> "lcd_grp", "sram_grp", "gpio-1-15_grp",
>> "gpio-16-19_grp", "gpio-20-30_grp", "spi5_grp"
>>
>> Valid combinations become
>>
>> function = "lcd"
>> groups = "lcd_grp";
>>
>> function = "sram"
>> groups = "sram_grp"
>>
>> For all GPIO only this:
>>
>> function = "gpio"
>> groups = "gpio-1-16_grp", "gpio-16-19_grp", "gpio-20-30_grp"
>>
>> For a combined GPIO+SPI:
>>
>> function = "gpio"
>> groups = "gpio-1-16_grp", "gpio-20-30_grp"
>>
>> function = "spi5"
>> groups = "spi5_grp"
>>
>> The pinctrl runtile will protest if you try to combine spi5_grp
>> with gpio-16-19_grp.
>>
>>> In some other cases, when I configure a group to other functions, there
>>> could be spare pins which become unused (not brought out to the pad).
>>> Or, the spare pins may also become a separate function.
>>
>> That's cool.
>>
>>> Based on the LCD example, I'd assume I would do the following for the
>>> default LCD function:
>>>
>>> lcd_node {
>>> group = "lcd_grp";
>>> function = "lcd";
>>> };
>>>
>>> And in the case of function 3, I would call the function "spi5" and
>>> assume the rest of pins become either GPIO (or unused)?
>>>
>>> spi5_node {
>>> group = "lcd_grp";
>>> function = "spi5";
>>> };
>>
>> Looks cool per above.
>>
>> You need some clever code in the driver to handle double-configuration
>> of registers and so on, but I think it can be done.
>>
>> Using pin control as a GPIO backend can be a bit tricky and will need
>> some testing and elaboration, but the subsystem will block collisions.
>>
>> Yours,
>> Linus Walleij
>>
> 
> Hi Linus,
> 
> I have another question here. In the B0 revision of our Cygnus chip, the
> ASIC team added a feature to allow individual pins to be muxed to GPIO.
> The pinmux controller can still only do group-based muxing in general,
> but at the same time, you can override most (but not all) individual
> pins to GPIO.
> 
> I believe this HW design actually forces us to mix use "groups" and
> "pins" in DT.
> 
> For example, assuming we mux pins 1 - 10 as MMC (one cmd line, one clk
> line, and 8 data lines). One might make the decision that he only needs
> 4 data lines instead of 8 data lines, and he wants to free up the 4 data
> lines and uses as GPIO. Based on this example, is the following DT
> configuration valid?
> 
> sd_node {
> function = "sd";
> groups = "sd_grps";
> };
> 
> gpio_node {
> function = "gpio";
> pins = "gpio_7", "gpio_8", "gpio_9", "gpio_10"; /* assuming 1:1
> mapping between gpio and pin number to make this example simple */
> };
> 
> Thanks,
> 
> Ray
>

I dig into the pinctrl framework code a bit more and found that I can
use pinctrl_request_gpio from the GPIO driver and implement
gpio_request_enable in the pinctrl driver.

The only problem I see now is that these APIs seem to expect the use of
global GPIO numbers? And all pinctrl drivers I checked seem to be hard
coding the GPIO to pin mapping when declaring the struct
pinctrl_gpio_range array. How would this work in a system like ours that
have 3 GPIO controllers and was required to use a dynamic GPIO number
(i.e., we use gpio->base = -1, so it derives the base from
CONFIG_ARCH_NR_GPIO and goes backwards)?

I guess I can do some runtime calculation in my pinctrl driver to figure
out the GPIO->pin mapping based on 

Re: [PATCH 3/4] mfd: dln2: add support for ACPI

2015-01-22 Thread Octavian Purdila
On Fri, Jan 23, 2015 at 12:09 AM, Rafael J. Wysocki  wrote:
> On Thursday, January 22, 2015 12:13:13 PM Octavian Purdila wrote:
>> On Thu, Jan 22, 2015 at 4:00 AM, Rafael J. Wysocki  
>> wrote:

>> The idea here is to set the companion for the MFD sub-devices. Mika's
>> commit "mfd: Add ACPI support" propagates the parent's companion to
>> the MFD sub-devices, so it is sufficient to set the ACPI companion to
>> the USB device.
>
> For the USB device itself you'll then end up with an incomplete binding (you
> can't get back to the USB device from the ACPI object), so no, it isn't
> sufficient.
>
>> Then, the companion will be propagated to the sub-devices after which
>> acpi_bind_one() will be called for the sub-devices from
>> mfd_add_devices (via platform_device_add -> device_add ->
>> platform_notify).
>
> In fact, your use case doesn't seem to cover any of the use cases that
> the Mika's commit addressed.  Namely, your parent device doesn't have
> an ACPI companion to start with and you want your MFD cells to be bound
> to the "DLN2000" thing.  That's why you're setting the ACPI companion
> for the USB device, isn't it?
>
>> It is true that the USB dev will have its ACPI companion set without
>> having acpi_bind_one called but I do not see any harm in that. Even
>> though acpi_unbind_one() is called it will not find the USB dev on the
>> physical node list so no put_device() imbalance is caused.
>
> Well, there are places where it matters.  Some links in sysfs will be missing
> for one example.  Also please see the changelog of commit 52870786ff5d (ACPI:
> Use ACPI companion to match only the first physical device).
>
> Bottom line: You really should be using acpi_bind_one() here and
> acpi_unbind_one() on disconnect if you have to.
>

OK, I understand now.

>> > And no, "Let's come up with a patch that sort of works, throw it at the 
>> > maintainers
>> > and see what happens" is not an acceptable approach, sorry.
>>
>> This patch is based on your feedback of the previous RFC patch set:
>
> Oh, is it?  I can't recall advising you to use request_firmware() for
> uploading ACPI tables or some other questionable things that the patch is
> doing.
>
> And if it still was an RFC, that wouldn't be a problem, but if you just send
> non-RFC patches out, that means you want people to merge them.  This is bad
> if the patches in question are not in a good enough shape and this one isn't.
>

Yes, this should have been tagged with RFC, sorry about that.

> Now, why is this a bad idea to load ACPI tables from a driver using
> request_firmware()?  Because those tables are not device firmare.  They are
> not firmware that you load into a device to make it work (which then works
> with all instances of the given hardware), they are part of system 
> configuration
> information and have to match what's there in the system.  For instance, if 
> you
> ship your example SSDT with a general-purpose distro, it may just not match 
> the
> hardware configuration of systems that people will try to use it with.
>
> So, while it is sort of OK to look up "DLN2000" and bind the USB device to
> that by hand (although this looks ugly to me), it is not OK to load a random
> custom SSDT if it is missing.
>
> We need to add a generic mechanism for loading custom SSDTs not present in the
> firmware image and maybe even to load them on demand, but that cannot happen 
> in
> an ad-hoc way.  So the entire table loading-unloading code in your patch can 
> go
> away for now and you need to fail probing if the "DLN2000" ACPI object is not
> present.
>

That sounds interesting, I like the idea of a generic mechanism for
loading custom SSDTs. Do you have any initial thoughts/pointers for
starting that?

Thanks for the review and feedback.
--
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 -tip/urgent 2/2] [BUGFIX]kprobes: makes kprobes/enabled works correctly for optimized kprobes.

2015-01-22 Thread Masami Hiramatsu
From: Wang Nan 

debugfs/kprobes/enabled doesn't work correctly on optimized kprobes.
Masami Hiramatsu has a test report on x86_64 platform:

https://lkml.org/lkml/2015/1/19/274

This patch forces it to unoptimize kprobe if kprobes_all_disarmed
is set. It also checks the flag in unregistering path for skipping
unneeded disarming process when kprobes globally disarmed.

Signed-off-by: Wang Nan 
Acked-by: Masami Hiramatsu 
---
 kernel/kprobes.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 9471710..fb995ef 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -869,7 +869,8 @@ static void __disarm_kprobe(struct kprobe *p, bool reopt)
 {
struct kprobe *_p;
 
-   unoptimize_kprobe(p, false);/* Try to unoptimize */
+   /* Try to unoptimize */
+   unoptimize_kprobe(p, kprobes_all_disarmed);
 
if (!kprobe_queued(p)) {
arch_disarm_kprobe(p);
@@ -1571,7 +1572,13 @@ static struct kprobe *__disable_kprobe(struct kprobe *p)
 
/* Try to disarm and disable this/parent probe */
if (p == orig_p || aggr_kprobe_disabled(orig_p)) {
-   disarm_kprobe(orig_p, true);
+   /*
+* If kprobes_all_disarmed is set, orig_p
+* should have already been disarmed, so
+* skip unneed disarming process.
+*/
+   if (!kprobes_all_disarmed)
+   disarm_kprobe(orig_p, true);
orig_p->flags |= KPROBE_FLAG_DISABLED;
}
}

--
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 -tip/urgent 0/2]kprobes bugfixes around optprobe

2015-01-22 Thread Masami Hiramatsu
Hi Ingo,

Here are two patches for fixing bugs in kprobes, related to
optprobe and enable/disable kprobe knob.

These are reported and fixed by Wang Nan.
https://lkml.org/lkml/2015/1/5/270
https://lkml.org/lkml/2015/1/19/680

Thank you,


---

Wang Nan (2):
  [BUGFIX]kprobes: set kprobes_all_disarmed earlier to enable 
re-optimization.
  [BUGFIX]kprobes: makes kprobes/enabled works correctly for optimized 
kprobes.


 kernel/kprobes.c |   18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

--
Masami HIRAMATSU
Software Platform Research Dpt. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH -tip/urgent 1/2] [BUGFIX]kprobes: set kprobes_all_disarmed earlier to enable re-optimization.

2015-01-22 Thread Masami Hiramatsu
From: Wang Nan 

In original code, the probed instruction doesn't get optimized after

echo 0 > /sys/kernel/debug/kprobes/enabled
echo 1 > /sys/kernel/debug/kprobes/enabled

This is because original code checks kprobes_all_disarmed in
optimize_kprobe(), but this flag is turned off after calling that
function. Therefore, optimize_kprobe() will see
kprobes_all_disarmed == true and doesn't do the optimization.

This patch simply turns off kprobes_all_disarmed earlier to enable
optimization.

Signed-off-by: Wang Nan 
Acked-by: Masami Hiramatsu 
---
 kernel/kprobes.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 06f5830..9471710 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2320,6 +2320,12 @@ static void arm_all_kprobes(void)
if (!kprobes_all_disarmed)
goto already_enabled;
 
+   /*
+* optimize_kprobe() called by arm_kprobe() checks
+* kprobes_all_disarmed, so set kprobes_all_disarmed before
+* arm_kprobe.
+*/
+   kprobes_all_disarmed = false;
/* Arming kprobes doesn't optimize kprobe itself */
for (i = 0; i < KPROBE_TABLE_SIZE; i++) {
head = _table[i];
@@ -2328,7 +2334,6 @@ static void arm_all_kprobes(void)
arm_kprobe(p);
}
 
-   kprobes_all_disarmed = false;
printk(KERN_INFO "Kprobes globally enabled\n");
 
 already_enabled:

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


RE: [alsa-devel] [PATCH v3 3/4] ARM: dts: set clock out parent to XUSBXTI

2015-01-22 Thread Kukjin Kim
Sylwester Nawrocki wrote:
> 
> On 22/01/15 12:18, Inha Song wrote:
> > This patch set clock out parent to XUSBXTI.
> >
> > Signed-off-by: Inha Song 
> > ---
> >  arch/arm/boot/dts/exynos4.dtsi | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> > index b8168f1..020bbaf 100644
> > --- a/arch/arm/boot/dts/exynos4.dtsi
> > +++ b/arch/arm/boot/dts/exynos4.dtsi
> > @@ -141,6 +141,8 @@
> > pmu_system_controller: system-controller@1002 {
> > compatible = "samsung,exynos4210-pmu", "syscon";
> > reg = <0x1002 0x4000>;
> > +   assigned-clocks = <_system_controller 0>;
> > +   assigned-clock-parents =  < CLK_XUSBXTI>;
> > };
> 
> Looks good, except it needs to be done only for the Trats2 board, i.e.
> the PMU device node including these properties should be added to
> exynos4412-trats2.dts.  I think it's fine to make it a one patch including
> all dts changes.
> 
Yeah, I agree with Sylwester's suggestion. Please make a one patch for the
updating DT for sound support and adding me in Cc for the change for relevant
driver changes as well.

Thanks,
Kukjin

--
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/6] mfd: max77843: Add max77843 MFD driver core driver

2015-01-22 Thread Beomho Seo
On 01/23/2015 03:32 PM, Krzysztof Kozlowski wrote:
> 2015-01-23 6:02 GMT+01:00 Jaewon Kim :
>> This patch adds MAX77843 core/irq driver to support PMIC,
>> MUIC(Micro USB Interface Controller), Charger, Fuel Gauge,
>> LED and Haptic device.
>>
>> Cc: Lee Jones 
>> Signed-off-by: Beomho Seo 
>> Signed-off-by: Jaewon Kim 
>> ---
>>  drivers/mfd/Kconfig  |   14 ++
>>  drivers/mfd/Makefile |1 +
>>  drivers/mfd/max77843.c   |  241 
>>  include/linux/mfd/max77843-private.h |  410 
>> ++
>>  4 files changed, 666 insertions(+)
>>  create mode 100644 drivers/mfd/max77843.c
>>  create mode 100644 include/linux/mfd/max77843-private.h
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 2e6b731..0c67c79 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -442,6 +442,20 @@ config MFD_MAX77693
>>   additional drivers must be enabled in order to use the 
>> functionality
>>   of the device.
>>
>> +config MFD_MAX77843
>> +   bool "Maxim Semiconductor MAX77843 PMIC Support"
>> +   depends on I2C=y
>> +   select MFD_CORE
>> +   select REGMAP_I2C
>> +   select REGMAP_IRQ
>> +   help
>> + Say yes here to add support for Maxim Semiconductor MAX77843.
>> + This is companion Power Management IC with LEDs, Haptic, Charger,
>> + Fuel Gauge, MUIC(Micro USB Interface Controller) controls on chip.
>> + This driver provides common support for accessing the device;
>> + additional drivers must be enabled in order to use the 
>> functionality
>> + of the device.
>> +
>>  config MFD_MAX8907
>> tristate "Maxim Semiconductor MAX8907 PMIC Support"
>> select MFD_CORE
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index 53467e2..fe4f75c 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9063)+= da9063.o
>>  obj-$(CONFIG_MFD_MAX14577) += max14577.o
>>  obj-$(CONFIG_MFD_MAX77686) += max77686.o
>>  obj-$(CONFIG_MFD_MAX77693) += max77693.o
>> +obj-$(CONFIG_MFD_MAX77843) += max77843.o
>>  obj-$(CONFIG_MFD_MAX8907)  += max8907.o
>>  max8925-objs   := max8925-core.o max8925-i2c.o
>>  obj-$(CONFIG_MFD_MAX8925)  += max8925.o
>> diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
>> new file mode 100644
>> index 000..d7f8b76
>> --- /dev/null
>> +++ b/drivers/mfd/max77843.c
>> @@ -0,0 +1,241 @@
>> +/*
>> + * max77843.c - MFD core driver for the Maxim MAX77843
>> + *
>> + * Copyright (C) 2014 Samsung Electrnoics
>> + * Author: Jaewon Kim 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static const struct mfd_cell max77843_devs[] = {
>> +   {
>> +   .name = "max77843-muic",
>> +   .of_compatible = "maxim,max77843-muic",
>> +   }, {
>> +   .name = "max77843-regulator",
>> +   .of_compatible = "maxim,max77843-regulator",
>> +   }, {
>> +   .name = "max77843-charger",
>> +   .of_compatible = "maxim,max77843-charger"
>> +   }, {
>> +   .name = "max77843-fuelgauge",
>> +   .of_compatible = "maxim,max77843-fuelgauge",
>> +   },
>> +};
>> +
>> +static const struct regmap_config max77843_charger_regmap_config = {
>> +   .reg_bits   = 8,
>> +   .val_bits   = 8,
>> +   .max_register   = MAX77843_CHG_REG_END,
>> +};
>> +
>> +static const struct regmap_config max77843_regmap_config = {
>> +   .reg_bits   = 8,
>> +   .val_bits   = 8,
>> +   .max_register   = MAX77843_SYS_REG_END,
>> +};
>> +
>> +static const struct regmap_irq max77843_irqs[] = {
>> +   /* TOPSYS interrupts */
>> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSUVLO_INT, },
>> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSOVLO_INT, },
>> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TSHDN_INT, },
>> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TM_INT, },
>> +};
>> +
>> +static const struct regmap_irq_chip max77843_irq_chip = {
>> +   .name   = "max77843",
>> +   .status_base= MAX77843_SYS_REG_SYSINTSRC,
>> +   .mask_base  = MAX77843_SYS_REG_SYSINTMASK,
>> +   .mask_invert= false,
>> +   .num_regs   = 1,
>> +   .irqs   = max77843_irqs,
>> +   .num_irqs   = ARRAY_SIZE(max77843_irqs),
>> +};
>> +
>> +static int max77843_chg_init(struct max77843 *max77843)
>> +{
> 
> Could this function be moved to the charger driver? This 

Re: [PATCH 2/6] extcon: max77843: Add max77843 MUIC driver

2015-01-22 Thread Krzysztof Kozłowski
2015-01-23 6:02 GMT+01:00 Jaewon Kim :
> This patch adds MAX77843 extcon driver to support for MUIC(Micro
> USB Interface Controller) device by using EXTCON subsystem to handle
> various external connectors.
>
> Cc: Chanwoo Choi 
> Signed-off-by: Jaewon Kim 
> ---
>  drivers/extcon/Kconfig   |   10 +
>  drivers/extcon/Makefile  |1 +
>  drivers/extcon/extcon-max77843.c |  871 
> ++
>  3 files changed, 882 insertions(+)
>  create mode 100644 drivers/extcon/extcon-max77843.c
>

(...)

> +static int max77843_muic_remove(struct platform_device *pdev)
> +{
> +   struct max77843_muic_info *info = platform_get_drvdata(pdev);
> +
> +   cancel_work_sync(>irq_work);
> +

Missing regmap_del_irq_chip().

Best regards,
Krzysztof
--
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] ARM: dts: exynos5422-odroidxu3: add on-board INA231 sensors

2015-01-22 Thread Kukjin Kim
Kevin Hilman wrote:
> 
> From: Kevin Hilman 
> 
> The odroid-xu3 has 4 INA231 current sensors on board which can be
> accessed from the Linux via the hwmon interface.
> 
> There is one sensor for each of these power rails:
> 
> - A15 cluster: VDD_ARM
> - A7 cluster: VDD_KFC
> - GPU: VDD_G3D
> - memory: VDD_MEM
> 
> In addition to adding the sensors, LDO26 from the PMIC needs to be
> enabled because it's powering these sensor.
> 
> Cc: Javier Martinez Canillas 
> Cc: Sjoerd Simons 
> Reviewed-By: Sjoerd Simons 
> Signed-off-by: Kevin Hilman 
> ---
> v3: extend existing i2c_0 node
> v2: use "ti,ina231" as compatible string.
> 
> Applies on top of "ARM: dts: Add dts file for odroid XU3 board" from Sjoerd 
> Simons.
> 
>  arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39 
> ++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> index c29123c0734d..38694a4a5417 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -174,6 +174,13 @@
>   regulator-always-on;
>   };
> 
> + ldo26_reg: LDO26 {
> + regulator-name = "vdd_ldo26";
> + regulator-min-microvolt = <300>;
> + regulator-max-microvolt = <300>;
> + regulator-always-on;
> + };
> +
>   buck1_reg: BUCK1 {
>   regulator-name = "vdd_mif";
>   regulator-min-microvolt = <80>;
> @@ -330,3 +337,35 @@
>  _dwc3_1 {
>   dr_mode = "otg";
>  };
> +
> +_0 {
> + status = "okay";
> +
> + /* A15 cluster: VDD_ARM */
> + ina231@40 {
> + compatible = "ti,ina231";
> + reg = <0x40>;
> + shunt-resistor = <1>;
> + };
> +
> + /* memory: VDD_MEM */
> + ina231@41 {
> + compatible = "ti,ina231";
> + reg = <0x41>;
> + shunt-resistor = <1>;
> + };
> +
> + /* GPU: VDD_G3D */
> + ina231@44 {
> + compatible = "ti,ina231";
> + reg = <0x44>;
> + shunt-resistor = <1>;
> + };
> +
> + /* A7 cluster: VDD_KFC */
> + ina231@45 {
> + compatible = "ti,ina231";
> + reg = <0x45>;
> + shunt-resistor = <1>;
> + };
> +};
> --
> 2.1.3

OK, let me replace the applied patch with this in my tree.

Thanks,
Kukjin

--
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/3] mm: cma: allocation trigger

2015-01-22 Thread Joonsoo Kim
On Thu, Jan 22, 2015 at 09:48:25PM -0500, Sasha Levin wrote:
> On 01/22/2015 03:26 AM, Joonsoo Kim wrote:
> > On Tue, Jan 20, 2015 at 12:38:32PM -0500, Sasha Levin wrote:
> >> Provides a userspace interface to trigger a CMA allocation.
> >>
> >> Usage:
> >>
> >>echo [pages] > alloc
> >>
> >> This would provide testing/fuzzing access to the CMA allocation paths.
> >>
> >> Signed-off-by: Sasha Levin 
> >> ---
> >>  mm/cma_debug.c |   58 
> >> 
> >>  1 file changed, 58 insertions(+)
> >>
> >> diff --git a/mm/cma_debug.c b/mm/cma_debug.c
> >> index 3a25413..eda0a41 100644
> >> --- a/mm/cma_debug.c
> >> +++ b/mm/cma_debug.c
> >> @@ -7,9 +7,22 @@
> >>  
> >>  #include 
> >>  #include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >>  
> >>  #include "cma.h"
> >>  
> >> +struct cma_mem {
> >> +  struct hlist_node node;
> >> +  struct page *p;
> >> +  unsigned long n;
> >> +};
> >> +
> >> +static HLIST_HEAD(cma_mem_head);
> >> +static DEFINE_SPINLOCK(cma_mem_head_lock);
> >> +
> >>  static struct dentry *cma_debugfs_root;
> >>  
> >>  static int cma_debugfs_get(void *data, u64 *val)
> >> @@ -44,6 +57,48 @@ static void cma_debugfs_add_one(struct cma *cma, int 
> >> idx)
> >>debugfs_create_u32_array("bitmap", S_IRUGO, tmp, (u32*)cma->bitmap, 
> >> u32s);
> >>  }
> >>  
> >> +static void cma_add_to_cma_mem_list(struct cma_mem *mem)
> >> +{
> >> +  spin_lock(_mem_head_lock);
> >> +  hlist_add_head(>node, _mem_head);
> >> +  spin_unlock(_mem_head_lock);
> >> +}
> >> +
> >> +static int cma_alloc_mem(int count)
> >> +{
> >> +  struct cma_mem *mem;
> >> +  struct page *p;
> >> +
> >> +  mem = kzalloc(sizeof(*mem), GFP_KERNEL);
> >> +  if (!mem) 
> >> +  return -ENOMEM;
> >> +
> >> +  p = cma_alloc(dma_contiguous_default_area, count, CONFIG_CMA_ALIGNMENT);
> >> +  if (!p) {
> >> +  pr_info("CMA: Allocation failed.\n");
> >> +  kfree(mem);
> >> +  return -ENOMEM;
> >> +  }
> > 
> > Hello,
> > 
> > I'm glad to see this patchset. I had similar one privately. :)
> > Without this kind of facility, testing CMA is really hard.
> > 
> > Anyway, dma_contiguous_default_area is defined only in CONFIG_DMA_CMA.
> > So, it would cause build break.
> > 
> > And, I think that it is better for this tester to have an ability to
> > allocate pages on specific CMA reserved region. It could be easily
> > achieved by moving 'alloc' registration to cma_debugfs_add_one(). Is
> > there any reason not to do that?
> 
> Agreed, that would make more sense.
> 
> >> +
> >> +  pr_info("CMA: Allocated %d pages at %p\n", count, p);
> > 
> > I don't think this output is needed. If CONFIG_CMA_DEBUG is enabled,
> > cma_alloc() print similar output.
> 
> I didn't see any other output (and I have CONFIG_CMA_DEBUG set), which
> is why I've added this pr_info().

If you raise up your loglevel, you can see it.
That message is printed through pr_debug().

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


Re: [PATCH 2/3] mm: cma: introduce /proc/cmainfo

2015-01-22 Thread Joonsoo Kim
On Thu, Jan 22, 2015 at 06:35:53PM +0300, Stefan Strogin wrote:
> Hello Joonsoo,
> 
> On 30/12/14 07:38, Joonsoo Kim wrote:
> > On Fri, Dec 26, 2014 at 05:39:03PM +0300, Stefan I. Strogin wrote:
> >> /proc/cmainfo contains a list of currently allocated CMA buffers for every
> >> CMA area when CONFIG_CMA_DEBUG is enabled.
> > Hello,
> >
> > I think that providing these information looks useful, but, we need better
> > implementation. As Laura said, it is better to use debugfs. And,
> > instead of re-implementing the wheel, how about using tracepoint
> > to print these information? See below comments.
> 
> Excuse me for a long delay. I've tried to give a detailed answer here:
> https://lkml.org/lkml/2015/1/21/362
> Do you mean by «the re-implemented wheel» seq_print_stack_trace()? If so
> then it was thought to show an owner of each allocated buffer. I used a
> similar way as in page_owner: saving stack_trace for each allocation. Do
> you think we can use tracepoints instead?

I wrote why I said this is re-implemented wheel on the reply of other mail.
Please refer it.

Thanks.

> 
> 
> >
> >> Format is:
> >>
> >>  -  ( kB), allocated by \
> >>(), latency  us
> >>  
> >>
> >> Signed-off-by: Stefan I. Strogin 
> >> ---
> >>  mm/cma.c | 202 
> >> +++
> >>  1 file changed, 202 insertions(+)
> >>
> >> diff --git a/mm/cma.c b/mm/cma.c
> >> index a85ae28..ffaea26 100644
> >> --- a/mm/cma.c
> >> +++ b/mm/cma.c
> >> @@ -34,6 +34,10 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >>  
> >>  struct cma {
> >>unsigned long   base_pfn;
> >> @@ -41,8 +45,25 @@ struct cma {
> >>unsigned long   *bitmap;
> >>unsigned int order_per_bit; /* Order of pages represented by one bit */
> >>struct mutexlock;
> >> +#ifdef CONFIG_CMA_DEBUG
> >> +  struct list_head buffers_list;
> >> +  struct mutexlist_lock;
> >> +#endif
> >>  };
> >>  
> >> +#ifdef CONFIG_CMA_DEBUG
> >> +struct cma_buffer {
> >> +  unsigned long pfn;
> >> +  unsigned long count;
> >> +  pid_t pid;
> >> +  char comm[TASK_COMM_LEN];
> >> +  unsigned int latency;
> >> +  unsigned long trace_entries[16];
> >> +  unsigned int nr_entries;
> >> +  struct list_head list;
> >> +};
> >> +#endif
> >> +
> >>  static struct cma cma_areas[MAX_CMA_AREAS];
> >>  static unsigned cma_area_count;
> >>  static DEFINE_MUTEX(cma_mutex);
> >> @@ -132,6 +153,10 @@ static int __init cma_activate_area(struct cma *cma)
> >>} while (--i);
> >>  
> >>mutex_init(>lock);
> >> +#ifdef CONFIG_CMA_DEBUG
> >> +  INIT_LIST_HEAD(>buffers_list);
> >> +  mutex_init(>list_lock);
> >> +#endif
> >>return 0;
> >>  
> >>  err:
> >> @@ -347,6 +372,86 @@ err:
> >>return ret;
> >>  }
> >>  
> >> +#ifdef CONFIG_CMA_DEBUG
> >> +/**
> >> + * cma_buffer_list_add() - add a new entry to a list of allocated buffers
> >> + * @cma: Contiguous memory region for which the allocation is 
> >> performed.
> >> + * @pfn: Base PFN of the allocated buffer.
> >> + * @count:   Number of allocated pages.
> >> + * @latency: Nanoseconds spent to allocate the buffer.
> >> + *
> >> + * This function adds a new entry to the list of allocated contiguous 
> >> memory
> >> + * buffers in a CMA area. It uses the CMA area specificated by the device
> >> + * if available or the default global one otherwise.
> >> + */
> >> +static int cma_buffer_list_add(struct cma *cma, unsigned long pfn,
> >> + int count, s64 latency)
> >> +{
> >> +  struct cma_buffer *cmabuf;
> >> +  struct stack_trace trace;
> >> +
> >> +  cmabuf = kmalloc(sizeof(struct cma_buffer), GFP_KERNEL);
> >> +  if (!cmabuf)
> >> +  return -ENOMEM;
> >> +
> >> +  trace.nr_entries = 0;
> >> +  trace.max_entries = ARRAY_SIZE(cmabuf->trace_entries);
> >> +  trace.entries = >trace_entries[0];
> >> +  trace.skip = 2;
> >> +  save_stack_trace();
> >> +
> >> +  cmabuf->pfn = pfn;
> >> +  cmabuf->count = count;
> >> +  cmabuf->pid = task_pid_nr(current);
> >> +  cmabuf->nr_entries = trace.nr_entries;
> >> +  get_task_comm(cmabuf->comm, current);
> >> +  cmabuf->latency = (unsigned int) div_s64(latency, NSEC_PER_USEC);
> >> +
> >> +  mutex_lock(>list_lock);
> >> +  list_add_tail(>list, >buffers_list);
> >> +  mutex_unlock(>list_lock);
> >> +
> >> +  return 0;
> >> +}
> >> +
> >> +/**
> >> + * cma_buffer_list_del() - delete an entry from a list of allocated 
> >> buffers
> >> + * @cma:   Contiguous memory region for which the allocation was 
> >> performed.
> >> + * @pfn:   Base PFN of the released buffer.
> >> + *
> >> + * This function deletes a list entry added by cma_buffer_list_add().
> >> + */
> >> +static void cma_buffer_list_del(struct cma *cma, unsigned long pfn)
> >> +{
> >> +  struct cma_buffer *cmabuf;
> >> +
> >> +  mutex_lock(>list_lock);
> >> +
> >> +  list_for_each_entry(cmabuf, >buffers_list, list)
> >> +  if (cmabuf->pfn == pfn) {
> >> + 

Re: [PATCH 0/3] mm: cma: /proc/cmainfo

2015-01-22 Thread Joonsoo Kim
On Wed, Jan 21, 2015 at 04:52:36PM +0300, Stefan Strogin wrote:
> Sorry for such a long delay. Now I'll try to answer all the questions
> and make a second version.
> 
> The original reason of why we need a new debugging tool for CMA is
> written by Minchan (http://www.spinics.net/lists/linux-mm/msg81519.html):
> > 3. CMA allocation latency -> Broken
> > 4. CMA allocation success guarantee -> Broken.
> 
> We have no acceptable solution for these problems yet. We use CMA in our
> devices. But currently for lack of allocation guarantee there are some
> memory buffers that are always allocated at boot time even if they're
> not used. However we'd like to allocate contiguous buffers in runtime as
> much as it's possible.
> 
> First we want an interface like /proc/vmallocinfo to see that all needed
> contiguous buffers are allocated correctly, used/free memory in CMA
> regions (like in /proc/meminfo) and also CMA region's fragmentation.

Hello,

I agree that we need some information to debug or improve CMA.

But, why these complicate data structure in your code are needed for
information like as vmallocinfo? Just printing bitmap of struct cma seems
sufficient to me to check alignment and fragmentation problem.

> Stacktrace is used to see who and whence allocated each buffer. Since
> vmallocinfo and meminfo are located in /proc I thought that cmainfo
> should be in /proc too. Maybe latency is really unnecessary here (see
> hereinafter).

I guess that adding some tracepoints on alloc/free functions could
accomplish your purpose. They can print vairous information you want
and can also print stacktrace.

Thanks.

> 
> Second (not implemented yet) we want to debug 3) and 4) (especially in
> case of allocating in runtime). One of the main reasons of failed and
> slow allocations is pinning «movable» pages for a long time, so they
> can't be moved (SeongJae Park described it:
> http://lwn.net/Articles/619865/).
> To debug such cases we want to know for each allocation (for failed ones
> as well) its latency and some information about page migration, e.g. the
> number of pages that couldn't be migrated, why and page_owner's
> information for pages that failed to be migrated.
> 
> To my mind this might help us to identify subsystems that pin pages for
> too long in order to make such subsystems allocate only unmovable pages
> or fix the long-time page pinning.
> 
> The last thing should be done in debugfs of course. Maybe something like
> this, I'm not sure:
> # cd /sys/kernel/debug/cma//
> # ls
> allocated failed migration_stat released (...)
> # cat failed
> 0x3240 - 0x32406000 (24 kB), allocated by pid 63 (systemd-udevd),
> time spent 9000 us
> pages migrations required: 4
> succeeded [by the last try in __alloc_contig_migrate_range()]: 2
> failed/given up [on the last try in __alloc_contig_migrate_range()]: 2,
> page_owner's information for pages that couldn't be migrated.
> 
> # cat migration_stat
> Total pages migration requests: 1000
> Pages migrated successfully: 900
> Pages migration give-ups: 80
> Pages migration failures: 20
> Average tries per successful migration: 1.89
> (some other useful information)
> 
> 
> On 12/31/2014 03:25 AM, Minchan Kim wrote:
> > On Tue, Dec 30, 2014 at 02:00:27PM -0800, Laura Abbott wrote:
> >> On 12/29/2014 8:47 PM, Minchan Kim wrote:
>  I've been meaning to write something like this for a while so I'm
>  happy to see an attempt made to fix this. I can't speak for the
>  author's reasons for wanting this information but there are
>  several reasons why I was thinking of something similar.
> 
>  The most common bug reports seen internally on CMA are 1) CMA is
>  too slow and 2) CMA failed to allocate memory. For #1, not all
>  allocations may be slow so it's useful to be able to keep track
>  of which allocations are taking too long. For #2, migration
> >>> Then, I don't think we could keep all of allocations. What we need
> >>> is only slow allocations. I hope we can do that with ftrace.
> >>>
> >>> ex)
> >>>
> >>> # cd /sys/kernel/debug/tracing
> >>> # echo 1 > options/stacktrace
> >>> # echo cam_alloc > set_ftrace_filter
> >>> # echo your_threshold > tracing_thresh
> >>>
> >>> I know it doesn't work now but I think it's more flexible
> >>> and general way to handle such issues(ie, latency of some functions).
> >>> So, I hope we could enhance ftrace rather than new wheel.
> >>> Ccing ftrace people.
> >>>
> >>> Futhermore, if we really need to have such information, we need more data
> >>> (ex, how many of pages were migrated out, how many pages were dropped
> >>> without migrated, how many pages were written back, how many pages were
> >>> retried with the page lock and so on).
> >>> In this case, event trace would be better.
> >>>
> >>>
> >> I agree ftrace is significantly more flexible in many respects but
> >> for the type of information we're actually trying to collect here
> >> ftrace may not be the right tool. Often times it 

Re: [PATCH 1/6] mfd: max77843: Add max77843 MFD driver core driver

2015-01-22 Thread Krzysztof Kozlowski
2015-01-23 6:02 GMT+01:00 Jaewon Kim :
> This patch adds MAX77843 core/irq driver to support PMIC,
> MUIC(Micro USB Interface Controller), Charger, Fuel Gauge,
> LED and Haptic device.
>
> Cc: Lee Jones 
> Signed-off-by: Beomho Seo 
> Signed-off-by: Jaewon Kim 
> ---
>  drivers/mfd/Kconfig  |   14 ++
>  drivers/mfd/Makefile |1 +
>  drivers/mfd/max77843.c   |  241 
>  include/linux/mfd/max77843-private.h |  410 
> ++
>  4 files changed, 666 insertions(+)
>  create mode 100644 drivers/mfd/max77843.c
>  create mode 100644 include/linux/mfd/max77843-private.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 2e6b731..0c67c79 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -442,6 +442,20 @@ config MFD_MAX77693
>   additional drivers must be enabled in order to use the functionality
>   of the device.
>
> +config MFD_MAX77843
> +   bool "Maxim Semiconductor MAX77843 PMIC Support"
> +   depends on I2C=y
> +   select MFD_CORE
> +   select REGMAP_I2C
> +   select REGMAP_IRQ
> +   help
> + Say yes here to add support for Maxim Semiconductor MAX77843.
> + This is companion Power Management IC with LEDs, Haptic, Charger,
> + Fuel Gauge, MUIC(Micro USB Interface Controller) controls on chip.
> + This driver provides common support for accessing the device;
> + additional drivers must be enabled in order to use the functionality
> + of the device.
> +
>  config MFD_MAX8907
> tristate "Maxim Semiconductor MAX8907 PMIC Support"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 53467e2..fe4f75c 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9063)+= da9063.o
>  obj-$(CONFIG_MFD_MAX14577) += max14577.o
>  obj-$(CONFIG_MFD_MAX77686) += max77686.o
>  obj-$(CONFIG_MFD_MAX77693) += max77693.o
> +obj-$(CONFIG_MFD_MAX77843) += max77843.o
>  obj-$(CONFIG_MFD_MAX8907)  += max8907.o
>  max8925-objs   := max8925-core.o max8925-i2c.o
>  obj-$(CONFIG_MFD_MAX8925)  += max8925.o
> diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
> new file mode 100644
> index 000..d7f8b76
> --- /dev/null
> +++ b/drivers/mfd/max77843.c
> @@ -0,0 +1,241 @@
> +/*
> + * max77843.c - MFD core driver for the Maxim MAX77843
> + *
> + * Copyright (C) 2014 Samsung Electrnoics
> + * Author: Jaewon Kim 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct mfd_cell max77843_devs[] = {
> +   {
> +   .name = "max77843-muic",
> +   .of_compatible = "maxim,max77843-muic",
> +   }, {
> +   .name = "max77843-regulator",
> +   .of_compatible = "maxim,max77843-regulator",
> +   }, {
> +   .name = "max77843-charger",
> +   .of_compatible = "maxim,max77843-charger"
> +   }, {
> +   .name = "max77843-fuelgauge",
> +   .of_compatible = "maxim,max77843-fuelgauge",
> +   },
> +};
> +
> +static const struct regmap_config max77843_charger_regmap_config = {
> +   .reg_bits   = 8,
> +   .val_bits   = 8,
> +   .max_register   = MAX77843_CHG_REG_END,
> +};
> +
> +static const struct regmap_config max77843_regmap_config = {
> +   .reg_bits   = 8,
> +   .val_bits   = 8,
> +   .max_register   = MAX77843_SYS_REG_END,
> +};
> +
> +static const struct regmap_irq max77843_irqs[] = {
> +   /* TOPSYS interrupts */
> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSUVLO_INT, },
> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSOVLO_INT, },
> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TSHDN_INT, },
> +   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TM_INT, },
> +};
> +
> +static const struct regmap_irq_chip max77843_irq_chip = {
> +   .name   = "max77843",
> +   .status_base= MAX77843_SYS_REG_SYSINTSRC,
> +   .mask_base  = MAX77843_SYS_REG_SYSINTMASK,
> +   .mask_invert= false,
> +   .num_regs   = 1,
> +   .irqs   = max77843_irqs,
> +   .num_irqs   = ARRAY_SIZE(max77843_irqs),
> +};
> +
> +static int max77843_chg_init(struct max77843 *max77843)
> +{

Could this function be moved to the charger driver? This way the
driver will manage its own resources instead of depending on parent
MFD driver.

> +   int ret;
> +
> +   max77843->i2c_chg = i2c_new_dummy(max77843->i2c->adapter, 
> I2C_ADDR_CHG);

[PATCH v10 6/6] devicetree: i2c: Add SKY81452 to the Trivial Devices list

2015-01-22 Thread gyungoh
From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
---
Changes v10:
Nothing

Changes v9:
Nothing

Changes v8:
Nothing

Changes v7:
Nothing

Changes v6:
Nothing

Changes v5:
Nothing

Changes v4:
Nothing

Changes v3:
Nothing

Changes v2:
Add SKY81452 to the Trivial Devices list

 Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index fbde415..122fa1e 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -77,6 +77,7 @@ ramtron,24c64 i2c serial eeprom  (24cxx)
 ricoh,rs5c372a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
 samsung,24ad0xd1   S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
 sii,s35390a2-wire CMOS real-time clock
+skyworks,sky81452  Skyworks SKY81452: Six-Channel White LED Driver with 
Touch Panel Bias Supply
 st-micro,24c256i2c serial eeprom  (24cxx)
 stm,m41t00 Serial Access TIMEKEEPER
 stm,m41t62 Serial real-time clock (RTC) with alarm
-- 
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 v10 2/6] backlight: Add support Skyworks SKY81452 backlight driver

2015-01-22 Thread gyungoh
From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
Acked-by: Jingoo Han 
Acked-by: Bryan Wu 
---
Changes v10:
Removed trivial get_brightness implementations

Changes v9:
Nothing

Changes v8:
Renamed property names for backlight with vendor prefix
Modified gpio-enable property to generic property for GPIO

Changes v7:
Modified licensing text to GPLv2

Changes v6:
Added new line character at the end of line of dev_err()

Changes v5:
Move sky81452-backlight.h to include/linux/platform_data

Changes v4:
Reordering header files for readability
Removed calling to backlight_device_unregister()
Removed MODULE_VERSION()
Modified license to GPLv2

Changes v3:
Modified DBG messages

Changes v2:
Added 'compatible' attribute in the driver
Added message for exception or errors

 drivers/video/backlight/Kconfig  |  10 +
 drivers/video/backlight/Makefile |   1 +
 drivers/video/backlight/sky81452-backlight.c | 334 +++
 include/linux/platform_data/sky81452-backlight.h |  46 
 4 files changed, 391 insertions(+)
 create mode 100644 drivers/video/backlight/sky81452-backlight.c
 create mode 100644 include/linux/platform_data/sky81452-backlight.h

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 8d03924..2586fdd 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -409,6 +409,16 @@ config BACKLIGHT_PANDORA
  If you have a Pandora console, say Y to enable the
  backlight driver.
 
+config BACKLIGHT_SKY81452
+   tristate "Backlight driver for SKY81452"
+   depends on BACKLIGHT_CLASS_DEVICE && MFD_SKY81452
+   help
+ If you have a Skyworks SKY81452, say Y to enable the
+ backlight driver.
+
+ To compile this driver as a module, choose M here: the module will
+ be called sky81452-backlight
+
 config BACKLIGHT_TPS65217
tristate "TPS65217 Backlight"
depends on BACKLIGHT_CLASS_DEVICE && MFD_TPS65217
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index fcd50b73..d67073f 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_BACKLIGHT_PANDORA)   += pandora_bl.o
 obj-$(CONFIG_BACKLIGHT_PCF50633)   += pcf50633-backlight.o
 obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
 obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
+obj-$(CONFIG_BACKLIGHT_SKY81452)   += sky81452-backlight.o
 obj-$(CONFIG_BACKLIGHT_TOSA)   += tosa_bl.o
 obj-$(CONFIG_BACKLIGHT_TPS65217)   += tps65217_bl.o
 obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
diff --git a/drivers/video/backlight/sky81452-backlight.c 
b/drivers/video/backlight/sky81452-backlight.c
new file mode 100644
index 000..8105597
--- /dev/null
+++ b/drivers/video/backlight/sky81452-backlight.c
@@ -0,0 +1,334 @@
+/*
+ * sky81452-backlight.cSKY81452 backlight driver
+ *
+ * Copyright 2014 Skyworks Solutions Inc.
+ * Author : Gyungoh Yoo 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* registers */
+#define SKY81452_REG0  0x00
+#define SKY81452_REG1  0x01
+#define SKY81452_REG2  0x02
+#define SKY81452_REG4  0x04
+#define SKY81452_REG5  0x05
+
+/* bit mask */
+#define SKY81452_CS0xFF
+#define SKY81452_EN0x3F
+#define SKY81452_IGPW  0x20
+#define SKY81452_PWMMD 0x10
+#define SKY81452_PHASE 0x08
+#define SKY81452_ILIM  0x04
+#define SKY81452_VSHRT 0x03
+#define SKY81452_OCP   0x80
+#define SKY81452_OTMP  0x40
+#define SKY81452_SHRT  0x3F
+#define SKY81452_OPN   0x3F
+
+#define SKY81452_DEFAULT_NAME "lcd-backlight"
+#define SKY81452_MAX_BRIGHTNESS(SKY81452_CS + 1)
+
+#define CTZ(b) __builtin_ctz(b)
+
+static int sky81452_bl_update_status(struct backlight_device *bd)
+{
+   const struct sky81452_bl_platform_data *pdata =
+   dev_get_platdata(bd->dev.parent);
+   const unsigned int brightness = (unsigned int)bd->props.brightness;
+   struct regmap *regmap = bl_get_data(bd);
+   int ret;
+
+   if (brightness > 0) {
+   ret = regmap_write(regmap, SKY81452_REG0, brightness - 1);
+   if (IS_ERR_VALUE(ret))
+   return ret;
+
+   return regmap_update_bits(regmap, SKY81452_REG1, 

[PATCH v10 5/6] devicetree: Add vendor prefix for Skyworks Solutions, Inc.

2015-01-22 Thread gyungoh
From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
Acked-by: Lee Jones 
---
Changes v10:
Nothing

Changes v9:
Nothing

Changes v8:
Nothing

Changes v7:
Nothing

Changes v6:
Nothing

Changes v5:
Nothing

Changes v4:
Nothing

Changes v3:
Nothing

Changes v2:
Added vendor prefix for Skyworks Solutions, Inc.

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index a344ec2..68143f0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -140,6 +140,7 @@ sii Seiko Instruments, Inc.
 silergySilergy Corp.
 sirf   SiRF Technology, Inc.
 sitronix   Sitronix Technology Corporation
+skyworks   Skyworks Solutions, Inc.
 smsc   Standard Microsystems Corporation
 snps   Synopsys, Inc.
 solidrun   SolidRun
-- 
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 v10 3/6] devicetree: Add new SKY81452 mfd binding

2015-01-22 Thread gyungoh
From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
Acked-by: Lee Jones 
---
Changes v10:
Nothing

Changes v9:
Nothing

Changes v8:
Made up the example for backlight DT

Changes v7:
Nothing

Changes v6:
Nothing

Changes v5:
Changed DT for regulator : 'lout' node should be defined under 'regulator'
Removed compatible string from sky81452-regulator driver

Changes v4:
Nothing

Changes v3:
Nothing

Changes v2:
Added reg attribute for I2C slave address

 Documentation/devicetree/bindings/mfd/sky81452.txt | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt

diff --git a/Documentation/devicetree/bindings/mfd/sky81452.txt 
b/Documentation/devicetree/bindings/mfd/sky81452.txt
new file mode 100644
index 000..ab71473
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/sky81452.txt
@@ -0,0 +1,36 @@
+SKY81452 bindings
+
+Required properties:
+- compatible   : Must be "skyworks,sky81452"
+- reg  : I2C slave address
+
+Required child nodes:
+- backlight: container node for backlight following the binding
+   in video/backlight/sky81452-backlight.txt
+- regulator: container node for regulators following the binding
+   in regulator/sky81452-regulator.txt
+
+Example:
+
+   sky81452@2c {
+   compatible = "skyworks,sky81452";
+   reg = <0x2c>;
+
+   backlight {
+   compatible = "skyworks,sky81452-backlight";
+   name = "pwm-backlight";
+   skyworks,en-channels = <0x3f>;
+   skyworks,ignore-pwm;
+   skyworks,phase-shift;
+   skyworks,ovp-level = <20>;
+   skyworks,current-limit = <2300>;
+   };
+
+   regulator {
+   lout {
+   regulator-name = "sky81452-lout";
+   regulator-min-microvolt = <450>;
+   regulator-max-microvolt = <800>;
+   };
+   };
+   };
-- 
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 v10 1/6] mfd: Add support for Skyworks SKY81452 driver

2015-01-22 Thread gyungoh
From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
Acked-by: Lee Jones 
---
Changes v10:
Nothing

Changes v9:
Nothing

Changes v8:
Nothing

Changes v7:
Modified licensing text to GPLv2

Changes v6:
Added new line character at the end of line of dev_err()

Changes v5:
Move sky81452-backlight.h to include/linux/platform_data

Changes v4:
Removed MODULE_VERSION()
Modified license to GPLv2

Changes v3:
Fixed the backlight name from 'sky81452-bl' to 'sky81452-backlight'
Assigned mfd_cell.of_compatible for binding device node
Modified error messages

Changes v2:
Renamed CONFIG_SKY81452 to CONFIG_MFD_SKY81452
Changed the dependency from I2C=y to I2C, for CONFIG_MFD_SKY81452
Added message for exception or errors

 drivers/mfd/Kconfig  |  12 +
 drivers/mfd/Makefile |   1 +
 drivers/mfd/sky81452.c   | 108 +++
 include/linux/mfd/sky81452.h |  31 +
 4 files changed, 152 insertions(+)
 create mode 100644 drivers/mfd/sky81452.c
 create mode 100644 include/linux/mfd/sky81452.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 1456ea7..a54244c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -693,6 +693,18 @@ config MFD_SM501_GPIO
 lines on the SM501. The platform data is used to supply the
 base number for the first GPIO line to register.
 
+config MFD_SKY81452
+   tristate "Skyworks Solutions SKY81452"
+   select MFD_CORE
+   select REGMAP_I2C
+   depends on I2C
+   help
+ This is the core driver for the Skyworks SKY81452 backlight and
+ voltage regulator device.
+
+ This driver can also be built as a module.  If so, the module
+ will be called sky81452.
+
 config MFD_SMSC
bool "SMSC ECE1099 series chips"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8bd54b1..d9683ea 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -174,6 +174,7 @@ obj-$(CONFIG_MFD_STW481X)   += stw481x.o
 obj-$(CONFIG_MFD_IPAQ_MICRO)   += ipaq-micro.o
 obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
 obj-$(CONFIG_MFD_HI6421_PMIC)  += hi6421-pmic-core.o
+obj-$(CONFIG_MFD_SKY81452) += sky81452.o
 
 intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
diff --git a/drivers/mfd/sky81452.c b/drivers/mfd/sky81452.c
new file mode 100644
index 000..b0c9b04
--- /dev/null
+++ b/drivers/mfd/sky81452.c
@@ -0,0 +1,108 @@
+/*
+ * sky81452.c  SKY81452 MFD driver
+ *
+ * Copyright 2014 Skyworks Solutions Inc.
+ * Author : Gyungoh Yoo 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct regmap_config sky81452_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+};
+
+static int sky81452_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct device *dev = >dev;
+   const struct sky81452_platform_data *pdata = dev_get_platdata(dev);
+   struct mfd_cell cells[2];
+   struct regmap *regmap;
+   int ret;
+
+   if (!pdata) {
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+   }
+
+   regmap = devm_regmap_init_i2c(client, _config);
+   if (IS_ERR(regmap)) {
+   dev_err(dev, "failed to initialize.err=%ld\n", PTR_ERR(regmap));
+   return PTR_ERR(regmap);
+   }
+
+   i2c_set_clientdata(client, regmap);
+
+   memset(cells, 0, sizeof(cells));
+   cells[0].name = "sky81452-backlight";
+   cells[0].of_compatible = "skyworks,sky81452-backlight";
+   cells[0].platform_data = pdata->bl_pdata;
+   cells[0].pdata_size = sizeof(*pdata->bl_pdata);
+   cells[1].name = "sky81452-regulator";
+   cells[1].platform_data = pdata->regulator_init_data;
+   cells[1].pdata_size = sizeof(*pdata->regulator_init_data);
+
+   ret = mfd_add_devices(dev, -1, cells, ARRAY_SIZE(cells), NULL, 0, NULL);
+   if (ret)
+   dev_err(dev, "failed to add child devices. err=%d\n", ret);
+
+   return ret;
+}
+
+static int sky81452_remove(struct i2c_client *client)
+{
+   mfd_remove_devices(>dev);
+   return 0;
+}
+
+static const struct i2c_device_id sky81452_ids[] = 

[PATCH v10 0/6] Add Skyworks SKY81452 device drivers

2015-01-22 Thread gyungoh
From: Gyungoh Yoo 

This patch set includes regulator and backlight driver for SKY81452.
Also it includes documents for device tree and module.
sky81452-regulator was already applied. So this series doesn't
include it.

v10:
Removed trivial get_brightness implementations for sky81452-backlight

v9:
Removed the change to remove MODULE_VERSION() for sky81452-regulator

v8:
Renamed property names for backlight with vendor prefix
Modified gpio-enable property to generic property for GPIO
Made up the example for backlight DT
Changed the DT parsing of regulator using regulator_node and of_match

v7:
Modified licensing text to GPLv2
Splitted Kconfig renaming from DT patch

v6:
Added new line character at the end of line of dev_err()

v5:
Changed DT for regulator : 'lout' node should be defined under 'regulator'
Removed compatible string from sky81452-regulator driver
Modified sky81452-regulator to return EINVAL when of_node is NULL
Move sky81452-backlight.h to include/linux/platform_data

v4:
Removed MODULE_VERSION()
Modified license to GPLv2
Removed calling to backlight_device_unregister() in sky81452-backlight

v3:
Cleaned-up DBG messages
Cleaned-up DT
Fixed the backlight name from 'sky81452-bl' to 'sky81452-backlight'
Assigned mfd_cell.of_compatible for binding device node
Modified error messages
Modified sky81452-regulator to return ENODATA when of_node is NULL

v2:
Split the patches for each sub-system
Added 'reg' attribute for I2C address in device tree documents
Added 'compatible' attribute in child drivers
Renamed CONFIG_SKY81452 to CONFIG_MFD_SKY81452
Changed the dependency from I2C=y to I2C, for CONFIG_MFD_SKY81452
Added message for exception or errors.
Added vendor prefix for Skyworks Solutions, Inc.
Add SKY81452 to the Trivial Devices list

Gyungoh Yoo (6):
  mfd: Add support for Skyworks SKY81452 driver
  backlight: Add support Skyworks SKY81452 backlight driver
  devicetree: mfd: Add new SKY81452 mfd binding
  devicetree: backlight: Add new SKY81452 backlight binding
  devicetree: Add vendor prefix for Skyworks Solutions, Inc.
  devicetree: i2c: Add SKY81452 to the Trivial Devices list

 .../devicetree/bindings/i2c/trivial-devices.txt|   1 +
 Documentation/devicetree/bindings/mfd/sky81452.txt |  36 +++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 .../video/backlight/sky81452-backlight.txt |  29 ++
 drivers/mfd/Kconfig|  12 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/sky81452.c | 108 +++
 drivers/video/backlight/Kconfig|  10 +
 drivers/video/backlight/Makefile   |   1 +
 drivers/video/backlight/sky81452-backlight.c   | 334 +
 include/linux/mfd/sky81452.h   |  31 ++
 include/linux/platform_data/sky81452-backlight.h   |  46 +++
 12 files changed, 610 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt
 create mode 100644 
Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
 create mode 100644 drivers/mfd/sky81452.c
 create mode 100644 drivers/video/backlight/sky81452-backlight.c
 create mode 100644 include/linux/mfd/sky81452.h
 create mode 100644 include/linux/platform_data/sky81452-backlight.h

-- 
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 v10 4/6] devicetree: Add new SKY81452 backlight binding

2015-01-22 Thread gyungoh
From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
Acked-by: Bryan Wu 
---
Changes v10:
Nothing

Changes v9:
Nothing

Changes v8:
Renamed property names for backlight with vendor prefix
Modified gpio-enable property to generic property for GPIO
Made up the example for backlight DT

Changes v7:
Nothing

Changes v6:
Nothing

Changes v5:
Nothing

Changes v4:
Nothing

Changes v3:
Nothing

Changes v2:
Added reg attribute for I2C slave address

 .../video/backlight/sky81452-backlight.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt

diff --git 
a/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt 
b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
new file mode 100644
index 000..8daebf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
@@ -0,0 +1,29 @@
+SKY81452-backlight bindings
+
+Required properties:
+- compatible   : Must be "skyworks,sky81452-backlight"
+
+Optional properties:
+- name : Name of backlight device. Default is 'lcd-backlight'.
+- gpios: GPIO to use to EN pin.
+   See Documentation/devicetree/bindings/gpio/gpio.txt
+- skyworks,en-channels : Enable mask for current sink channel 1 to 6.
+- skyworks,ignore-pwm  : Ignore both PWM input
+- skyworks,dpwm-mode   : Enable DPWM dimming mode, otherwise Analog dimming.
+- skyworks,phase-shift : Enable phase shift mode
+- skyworks,ovp-level   : Over-voltage protection level.
+   Should be between 14 or 28V.
+- skyworks,short-detection-threshold   : It should be one of 4, 5, 6 and 7V.
+- skyworks,current-limit   : It should be 2300mA or 2750mA.
+
+Example:
+
+   backlight {
+   compatible = "skyworks,sky81452-backlight";
+   name = "pwm-backlight";
+   skyworks,en-channels = <0x3f>;
+   skyworks,ignore-pwm;
+   skyworks,phase-shift;
+   skyworks,ovp-level = <20>;
+   skyworks,current-limit = <2300>;
+   };
-- 
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 01/13] kdbus: add documentation

2015-01-22 Thread Ahmed S. Darwish
On Fri, Jan 16, 2015 at 11:16:05AM -0800, Greg Kroah-Hartman wrote:
> From: Daniel Mack 
> 
> kdbus is a system for low-latency, low-overhead, easy to use
> interprocess communication (IPC).
> 
> The interface to all functions in this driver is implemented via ioctls
> on files exposed through a filesystem called 'kdbusfs'. The default
> mount point of kdbusfs is /sys/fs/kdbus.

Pardon my ignorance, but we've always been told that adding
new ioctl()s to the kernel is a very big no-no.  But given
the seniority of the folks stewarding this kdbus effort,
there must be a good rationale ;-)

So, can the rationale behind introducing new ioctl()s be
further explained? It would be even better if it's included
in the documentation patch itself.

Thanks,
Darwish
--
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 6/6] Documentation: Add device tree bindings document for max77843

2015-01-22 Thread Chanwoo Choi
Hi Jaewon,

On 01/23/2015 02:02 PM, Jaewon Kim wrote:
> Add document describing device tree bindings for max77843 MFD.
> Drivers: MFD core, regulator, extcon, charger and fuelgauge.
> 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> Cc: Lee Jones 
> Cc: Chanwoo Choi 
> Cc: Sebastian Reichel 
> Cc: Mark Brown 
> Signed-off-by: Beomho Seo 
> Signed-off-by: Jaewon Kim 
> ---
>  Documentation/devicetree/bindings/mfd/max77843.txt |   87 
> 
>  1 file changed, 87 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/max77843.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/max77843.txt 
> b/Documentation/devicetree/bindings/mfd/max77843.txt
> new file mode 100644
> index 000..6895604
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/max77843.txt
> @@ -0,0 +1,87 @@
> +Maxim MAX77843 multi-function device
> +
> +MAX77843 is a Multi-Function Device with the following submodules:
> +- PMIC : 2 SAFEOUT LDOs for USB device
> +- CHARGER : Li+ battery charger with Fuel Gauge
> +- MUIC : Micro USB Interface Circuit
> +- HAPTIC  : motor control driver for haptics

HAPTIC ?

> +- LED  : 4 channel RGBW LED

LED ?

This patchset don't include andy haptic/led drivers.
I think it is un-necessary information.

When you implement the haptic/led driver, you will add the information
for haptic/led driver.

> +
> +It is interfaced to host controller using I2C.
> +
> +Required properties:
> +- compatible : Must be "maxim,max77843".
> +- reg : I2C slave address of PMIC block.
> +- interrupts : I2C line for main SoCs.
> +- interrupt-parent : The parent of interrupt controller.
> +
> +Optional properties:
> +- regulators : The regulators of max77843 have to be instantiated under 
> subnode
> + named "regulators" using the following format.
> +
> + [*]refer : Documentation/devicetree/bindings/regulator/regulator.txt
> +
> + regulators {
> + SAFEOUT {
> + regulator-name = "SAFEOUT";
> + };
> + }
> +
> + List of valid regulator names:
> + - SAFEOUT1, SAFEOUT2, CHARGER.
> +
> +- max77843-muic : This properties used by extcon consumers.
> + Required properties:
> + - compatible : Must be "maxim,max77842-muic".
> +
> +- max77843-charger : There battery charger of MAX77843 have to be 
> instantiated
> + under sub-node named "max77843-charger" using the following format.
> + Required properties:
> + - compatible : Must be "maxim,max77842-charger".
> + - maxim,fast-charge-uamp : Fast charge current levels are
> + 100 mA to 3150 mA programmed by I2C per 100 mA.
> + - maxim,top-off-uamp : Top off current threshold levels are
> + 125 mA to 650 mA programmed by I2C per 75 mA.
> + - maxim,input-uamp-limit : Input current limit levels are
> + 100 mA to 3533 mA programmed by I2C per 33 mA.
> +- max77843-fuelgauge : There fuelgauge of MAX77843 have to be instantiated
> + under sub-node named "max77843-fuelgauge" using the following format.
> + Required properties:
> + - compatible : Must be "maxim,max77842-fuelgauge".
> +
> +Example:
> + max77843@66 {
> + compatible = "samsung,max77843";
> + reg = <0x66>;
> + interrupt-parent = <>;
> + interrupts = <5 2>;
> +
> + regulators {
> + SAFEOUT1 {
> + regulator-name = "SAFEOUT1";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <495>;
> + };
> + SAFEOUT2 {
> + regulator-name = "SAFEOUT2";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <495>;
> + };

As I knew, max77843 regulator driver supprot 'CHARGER' regulator.
I think you have to add the 'CHARGER' dt node for regulators.


> + };
> +
> + max77843-muic {
> + compatible = "maxim,max77843-muic";
> + };
> +
> + max77843-charger {
> + compatible = "maxim,max77843-charger";
> + maxim,fast-charge-uamp = <45>;
> + maxim,top-off-uamp = <125000>;
> + maxim,input-uamp-limit = <50>;
> + };
> +
> + max77843-fuelgauge {
> + compatible = "maxim,max77843-fuelgauge";
> + };
> +
> + };
> 

Thanks,
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  

Re: [PATCH RFC 5/6] epoll: Add implementation for epoll_mod_wait

2015-01-22 Thread Fam Zheng
On Thu, 01/22 13:12, Andy Lutomirski wrote:
> On Wed, Jan 21, 2015 at 3:50 AM, Paolo Bonzini  wrote:
> >
> >
> > On 21/01/2015 12:14, Fam Zheng wrote:
> >> > My take for simplicity will be leaving epoll_ctl as-is, and my take for
> >> > performance will be epoll_pwait1. And I don't really like putting my 
> >> > time on
> >> > epoll_ctl_batch, thinking it as a ambivalent compromise in between.
> >>
> >> > I agree with Michael actually.  The big change is going from O(n)
> >> > epoll_ctl calls to O(1), and epoll_ctl_batch achieves that just fine.
> >> > Changing 2 syscalls to 1 is the icing on the cake, but we're talking of
> >> > a fraction of a microsecond.
> >>
> >> Maybe I'm missing something, but in common cases, the set of fds for 
> >> epoll_wait
> >> doesn't change that radically from one iteration to another, does it?
> >
> > That depends on the application.
> 
> In my application, the set of fds almost never changes, but the set of
> events I want changes all the time.  The main thing that changes is
> whether I care about EPOLLOUT.  If I'm ready to send something, then I
> want EPOLLOUT.  If I'm not ready, then I don't want EPOLLOUT.
> 

OK, I'll split it to epoll_ctl_batch and epoll_pwait1 as Micheal suggested in
v2.

Fam
--
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/6] extcon: max77843: Add max77843 MUIC driver

2015-01-22 Thread Chanwoo Choi
Hi Jaewon,

On 01/23/2015 02:02 PM, Jaewon Kim wrote:
> This patch adds MAX77843 extcon driver to support for MUIC(Micro

Add company name (MAX77843 -> Maxim MAX77843)

> USB Interface Controller) device by using EXTCON subsystem to handle
> various external connectors.
> 
> Cc: Chanwoo Choi 
> Signed-off-by: Jaewon Kim 
> ---
>  drivers/extcon/Kconfig   |   10 +
>  drivers/extcon/Makefile  |1 +
>  drivers/extcon/extcon-max77843.c |  871 
> ++
>  3 files changed, 882 insertions(+)
>  create mode 100644 drivers/extcon/extcon-max77843.c
> 
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 6a1f7de..0b67538 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -55,6 +55,16 @@ config EXTCON_MAX77693
> Maxim MAX77693 PMIC. The MAX77693 MUIC is a USB port accessory
> detector and switch.
>  
> +config EXTCON_MAX77843
> + tristate "MAX77843 EXTCON Support"
> + depends on MFD_MAX77843
> + select IRQ_DOMAIN
> + select REGMAP_I2C
> + help
> +   If you say yes here you get support for the MUIC device of
> +   Maxim MAX77843. The MAX77843 MUIC is a USB port accessory
> +   detector add switch.
> +
>  config EXTCON_MAX8997
>   tristate "MAX8997 EXTCON Support"
>   depends on MFD_MAX8997 && IRQ_DOMAIN
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 0370b42..f21d5c4 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)  += extcon-arizona.o
>  obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o
>  obj-$(CONFIG_EXTCON_MAX14577)+= extcon-max14577.o
>  obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
> +obj-$(CONFIG_EXTCON_MAX77843)+= extcon-max77843.o
>  obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
>  obj-$(CONFIG_EXTCON_PALMAS)  += extcon-palmas.o
>  obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
> diff --git a/drivers/extcon/extcon-max77843.c 
> b/drivers/extcon/extcon-max77843.c
> new file mode 100644
> index 000..caae9a7
> --- /dev/null
> +++ b/drivers/extcon/extcon-max77843.c
> @@ -0,0 +1,871 @@
> +/*
> + * extcon-max77843.c - MAX77843 extcon driver to support MUIC
> + *
> + * Copyright (C) 2014 Samsung Electrnoics
> + *  Author: Jaewon Kim 

Remove un-necessary blank before 'Author'.

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DELAY_MS_DEFAULT 15000   /* unit: millisecond */
> +
> +enum max77843_muic_acc_type {
> + MAX77843_MUIC_ADC_GROUND = 0,
> + MAX77843_MUIC_ADC_SEND_END_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S1_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S2_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S3_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S4_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S5_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S6_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S7_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S8_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S9_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S10_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S11_BUTTON,
> + MAX77843_MUIC_ADC_REMOTE_S12_BUTTON,
> + MAX77843_MUIC_ADC_RESERVED_ACC_1,
> + MAX77843_MUIC_ADC_RESERVED_ACC_2,
> + MAX77843_MUIC_ADC_RESERVED_ACC_3,
> + MAX77843_MUIC_ADC_RESERVED_ACC_4,
> + MAX77843_MUIC_ADC_RESERVED_ACC_5,
> + MAX77843_MUIC_ADC_AUDIO_DEVICE_TYPE2,
> + MAX77843_MUIC_ADC_PHONE_POWERED_DEV,
> + MAX77843_MUIC_ADC_TTY_CONVERTER,
> + MAX77843_MUIC_ADC_UART_CABLE,
> + MAX77843_MUIC_ADC_CEA936A_TYPE1_CHG,
> + MAX77843_MUIC_ADC_FACTORY_MODE_USB_OFF,
> + MAX77843_MUIC_ADC_FACTORY_MODE_USB_ON,
> + MAX77843_MUIC_ADC_AV_CABLE_NOLOAD,
> + MAX77843_MUIC_ADC_CEA936A_TYPE2_CHG,
> + MAX77843_MUIC_ADC_FACTORY_MODE_UART_OFF,
> + MAX77843_MUIC_ADC_FACTORY_MODE_UART_ON,
> + MAX77843_MUIC_ADC_AUDIO_DEVICE_TYPE1,
> + MAX77843_MUIC_ADC_OPEN,
> +};
> +
> +enum max77843_muic_cable_group {
> + MAX77843_CABLE_GROUP_ADC = 0,
> + MAX77843_CABLE_GROUP_CHG,
> + MAX77843_CABLE_GROUP_GND,
> +};

Cable group show the category of supported cables.
I think you better move this enum on upper of 'enum max77843_muic_acc_type'

> +
> +enum max77843_muic_adv_debounce_time {
> + MAX77843_DEBOUNCE_TIME_5MS = 0,
> + MAX77843_DEBOUNCE_TIME_10MS,
> + MAX77843_DEBOUNCE_TIME_25MS,
> + MAX77843_DEBOUNCE_TIME_38_62MS,
> +};
> +
> +enum max77843_muic_support_list {

Use only 'enum' keyword without 'max77843_muic_support_list' enum name.

> + EXTCON_CABLE_USB = 0,
> + EXTCON_CABLE_USB_HOST,
> + EXTCON_CABLE_USB_HOST_TA,
> + 

RE: [f2fs-dev][RFC PATCH 06/10] f2fs: add core functions for rb-tree extent cache

2015-01-22 Thread Chao Yu
Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Friday, January 23, 2015 9:48 AM
> To: Chao Yu
> Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net; 
> linux-kernel@vger.kernel.org
> Subject: Re: [f2fs-dev][RFC PATCH 06/10] f2fs: add core functions for rb-tree 
> extent cache
> 
> On Mon, Jan 12, 2015 at 03:14:48PM +0800, Chao Yu wrote:
> > This patch adds core functions including slab cache init function and
> > init/lookup/update/shrink/destroy function for rb-tree based extent cache.
> >
> > Thank Jaegeuk Kim and Changman Lee as they gave much suggestion about detail
> > design and implementation of extent cache.
> >
> > Todo:
> >  * add a cached_ei into struct extent_tree for a quick recent cache.
> >  * register rb-based extent cache shrink with mm shrink interface.
> >  * disable dir inode's extent cache.
> >
> > Signed-off-by: Chao Yu 
> > Signed-off-by: Jaegeuk Kim 
> > Signed-off-by: Changman Lee 
> > ---
> >  fs/f2fs/data.c | 458 
> > +
> >  fs/f2fs/node.c |   9 +-
> >  2 files changed, 466 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 4f5b871e..bf8c5eb 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -25,6 +25,9 @@
> >  #include "trace.h"
> >  #include 
> >
> > +struct kmem_cache *extent_tree_slab;
> > +struct kmem_cache *extent_node_slab;
> > +
> >  static void f2fs_read_end_io(struct bio *bio, int err)
> >  {
> > struct bio_vec *bvec;
> > @@ -373,6 +376,430 @@ end_update:
> > return need_update;
> >  }
> >
> > +static struct extent_node *__lookup_extent_tree(struct extent_tree *et,
> > +   unsigned int fofs)
> > +{
> > +   struct rb_node *node = et->root.rb_node;
> > +   struct extent_node *en;
> > +
> > +   while (node) {
> > +   en = rb_entry(node, struct extent_node, rb_node);
> > +   if (fofs < en->ei.fofs)
> > +   node = node->rb_left;
> > +   else if (fofs >= en->ei.fofs + en->ei.len)
> > +   node = node->rb_right;
> > +   else
> > +   return en;
> > +   }
> > +   return NULL;
> > +}
> > +
> > +static inline void set_extent_info(struct extent_info *ei, unsigned int 
> > fofs,
> > +   u32 blk, unsigned int len)
> > +{
> > +   ei->fofs = fofs;
> > +   ei->blk = blk;
> > +   ei->len = len;
> > +}
> > +
> > +static inline bool __is_extent_mergeable(struct extent_info *back,
> > +   struct extent_info *front)
> > +{
> > +   return (back->fofs + back->len == front->fofs &&
> > +   back->blk + back->len == front->blk);
> > +}
> > +
> > +static bool __is_back_mergeable(struct extent_info *cur,
> > +   struct extent_info *back)
> > +{
> > +   return __is_extent_mergeable(back, cur);
> > +}
> > +
> > +static bool __is_front_mergeable(struct extent_info *cur,
> > +   struct extent_info *front)
> > +{
> > +   return __is_extent_mergeable(cur, front);
> > +}
> 
> 
> How about declaring these four functions as inline ones and locating them
> inside f2fs.h?

Good idea! Will do.

> 
> > +
> > +static struct extent_node *__try_back_merge(struct extent_tree *et,
> > +   struct extent_node *en)
> > +{
> > +   struct extent_node *prev;
> > +   struct rb_node *node;
> > +
> > +   node = rb_prev(>rb_node);
> > +   if (!node)
> > +   return NULL;
> > +
> > +   prev = rb_entry(node, struct extent_node, rb_node);
> > +   if (__is_back_mergeable(>ei, >ei)) {
> > +   en->ei.fofs = prev->ei.fofs;
> > +   en->ei.blk = prev->ei.blk;
> > +   en->ei.len += prev->ei.len;
> > +   rb_erase(>rb_node, >root);
> > +   et->count--;
> > +   return prev;
> > +   }
> > +   return NULL;
> > +}
> > +
> > +static struct extent_node *__try_front_merge(struct extent_tree *et,
> > +   struct extent_node *en)
> > +{
> > +   struct extent_node *next;
> > +   struct rb_node *node;
> > +
> > +   node = rb_next(>rb_node);
> > +   if (!node)
> > +   return NULL;
> > +
> > +   next = rb_entry(node, struct extent_node, rb_node);
> > +   if (__is_front_mergeable(>ei, >ei)) {
> > +   en->ei.len += next->ei.len;
> > +   rb_erase(>rb_node, >root);
> > +   et->count--;
> > +   return next;
> > +   }
> > +   return NULL;
> > +}
> > +
> > +static struct extent_node *__insert_extent_tree(struct f2fs_sb_info *sbi,
> > +   struct extent_tree *et, struct extent_info *ei,
> > +   struct extent_node **den)
> > +{
> > +   struct rb_node **p = >root.rb_node;
> > +   struct rb_node *parent = NULL;
> > +   struct extent_node *en;
> > +
> > +   while (*p) {
> > +  

RE: [RFC PATCH 0/2 shit_A shit_B] workqueue: fix wq_numa bug

2015-01-22 Thread Izumi, Taku

> This patches are un-changloged, un-compiled, un-booted, un-tested,
> they are just shits, I even hope them un-sent or blocked.
> 
> The patches include two -solutions-:
> 
> Shit_A:
>   workqueue: reset pool->node and unhash the pool when the node is
> offline
>   update wq_numa when cpu_present_mask changed
> 
>  kernel/workqueue.c | 107 
> +
>  1 file changed, 84 insertions(+), 23 deletions(-)
> 
> 
> Shit_B:
>   workqueue: reset pool->node and unhash the pool when the node is
> offline
>   workqueue: remove wq_numa_possible_cpumask
>   workqueue: directly update attrs of pools when cpu hot[un]plug
> 
>  kernel/workqueue.c | 135 
> +++--
>  1 file changed, 101 insertions(+), 34 deletions(-)
> 

  I tried your patchsets.
  linux-3.18.3 + Shit_A:

Build OK. 
I tried to reproduce the problem that Ishimatsu had reported, but it 
doesn't occur.
It seems that your patch fixes this problem.

  linux-3.18.3  + Shit_B: 

Build OK, but I encountered kernel panic at boot time.

[0.189000] BUG: unable to handle kernel NULL pointer dereference at 
0008
[0.189000] IP: [] __list_add+0x16/0xc0
[0.189000] PGD 0 
[0.189000] Oops:  [#1] SMP 
[0.189000] Modules linked in:
[0.189000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.3+ #3
[0.189000] Hardware name: FUJITSU PRIMEQUEST2800E/SB, BIOS PRIMEQUEST 2000 
Series BIOS Version 01.81 12/03/2014
[0.189000] task: 880869678000 ti: 880869664000 task.ti: 
880869664000
[0.189000] RIP: 0010:[]  [] 
__list_add+0x16/0xc0
[0.189000] RSP: :880869667be8  EFLAGS: 00010296
[0.189000] RAX: 88087f83cda8 RBX: 88087f83cd80 RCX: 
[0.189000] RDX:  RSI: 88086912bb98 RDI: 88087f83cd80
[0.189000] RBP: 880869667c08 R08:  R09: 88087f807480
[0.189000] R10: 810911b6 R11: 810956ac R12: 
[0.189000] R13: 88086912bb98 R14: 0400 R15: 0400
[0.189000] FS:  () GS:88087fc0() 
knlGS:
[0.189000] CS:  0010 DS:  ES:  CR0: 80050033
[0.189000] CR2: 0008 CR3: 01998000 CR4: 001407f0
[0.189000] Stack:
[0.189000]  000a 88086912b800 88087f83cd00 
88087f80c000
[0.189000]  880869667c48 810912c8 880869667c28 
88087f803f00
[0.189000]  fff4 88086964b760 88086964b6a0 
88086964b740
[0.189000] Call Trace:
[0.189000]  [] alloc_unbound_pwq+0x298/0x3b0
[0.189000]  [] apply_workqueue_attrs+0x158/0x4c0
[0.189000]  [] __alloc_workqueue_key+0x174/0x5b0
[0.189000]  [] ? alloc_cpumask_var_node+0x56/0x80
[0.189000]  [] init_workqueues+0x33d/0x40f
[0.189000]  [] ? 
ftrace_define_fields_workqueue_execute_start+0x6a/0x6a
[0.189000]  [] do_one_initcall+0xd4/0x210
[0.189000]  [] ? native_smp_prepare_cpus+0x34d/0x352
[0.189000]  [] kernel_init_freeable+0xf5/0x23c
[0.189000]  [] ? rest_init+0x80/0x80
[0.189000]  [] kernel_init+0xe/0xf0
[0.189000]  [] ret_from_fork+0x7c/0xb0
[0.189000]  [] ? rest_init+0x80/0x80
[0.189000] Code: ff b8 f4 ff ff ff e9 3b ff ff ff b8 f4 ff ff ff e9 31 ff 
ff ff 55 48 89 e5 41 55 49 89 f5 41 54 49 89 d4 53 48 89 fb 48 83 ec 08 <4c> 8b 
42 08 49 39 f0 75 2e 4d 8b 45 00 4d 39 c4 75 6c 4c 39 e3 
[0.189000] RIP  [] __list_add+0x16/0xc0
[0.189000]  RSP 
[0.189000] CR2: 0008
[0.189000] ---[ end trace 58feee6875cf67cf ]---
[0.189000] Kernel panic - not syncing: Fatal exception
[0.189000] ---[ end Kernel panic - not syncing: Fatal exception

   
  Sincerely,
  Taku Izumi


> Both patch1 of the both solutions are: reset pool->node and unhash the pool,
> it is suggested by TJ, I found it is a good leading-step for fixing the bug.
> 
> The other patches are handling wq_numa_possible_cpumask where the solutions
> diverge.
> 
> Solution_A uses present_mask rather than possible_cpumask. It adds
> wq_numa_notify_cpu_present_set/cleared() for notifications of
> the changes of cpu_present_mask.  But the notifications are un-existed
> right now, so I fake one (wq_numa_check_present_cpumask_changes())
> to imitate them.  I hope the memory people add a real one.
> 
> Solution_B uses online_mask rather than possible_cpumask.
> this solution remove more coupling between numa_code and workqueue,
> it just depends on cpumask_of_node(node).
> 
> Patch2_of_Solution_B removes the wq_numa_possible_cpumask and add
> overhead when cpu hot[un]plug, Patch3 reduce this overhead.
> 
> Thanks,
> Lai
> 
> 
> Reported-by: Yasuaki Ishimatsu 
> Cc: Tejun Heo 
> Cc: Yasuaki Ishimatsu 
> Cc: "Gu, Zheng" 
> Cc: tangchen 
> Cc: Hiroyuki KAMEZAWA 
> --
> 2.1.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH v6 1/7] perf: provide sysfs_show for struct perf_pmu_events_attr

2015-01-22 Thread Sukadev Bhattiprolu
Jiri, Arnaldo,

Can you please review/ack this and the next (i.e patches 1 and 2)
of this set ? Since other patches in this set depend on these two,
it maybe easier to have them all go through the ppc tree ?

Thanks,

Sukadev

Sukadev Bhattiprolu [suka...@linux.vnet.ibm.com] wrote:
| From: Cody P Schafer 
| 
| (struct perf_pmu_events_attr) is defined in include/linux/perf_event.h,
| but the only "show" for it is in x86 and contains x86 specific stuff.
| 
| Make a generic one for those of us who are just using the event_str.
| 
| CC: Sukadev Bhattiprolu 
| CC: Haren Myneni 
| CC: Cody P Schafer 
| Signed-off-by: Cody P Schafer 
| ---
|  include/linux/perf_event.h | 3 +++
|  kernel/events/core.c   | 8 
|  2 files changed, 11 insertions(+)
| 
| diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
| index 486e84c..58f59bd 100644
| --- a/include/linux/perf_event.h
| +++ b/include/linux/perf_event.h
| @@ -897,6 +897,9 @@ struct perf_pmu_events_attr {
|   const char *event_str;
|  };
|  
| +ssize_t perf_event_sysfs_show(struct device *dev, struct device_attribute 
*attr,
| +   char *page);
| +
|  #define PMU_EVENT_ATTR(_name, _var, _id, _show)  
\
|  static struct perf_pmu_events_attr _var = {  \
|   .attr = __ATTR(_name, 0444, _show, NULL),   \
| diff --git a/kernel/events/core.c b/kernel/events/core.c
| index af0a5ba..1808d0e 100644
| --- a/kernel/events/core.c
| +++ b/kernel/events/core.c
| @@ -8276,6 +8276,14 @@ void __init perf_event_init(void)
|!= 1024);
|  }
|  
| +ssize_t perf_event_sysfs_show(struct device *dev, struct device_attribute 
*attr,
| +   char *page)
| +{
| + struct perf_pmu_events_attr *pmu_attr =
| + container_of(attr, struct perf_pmu_events_attr, attr);
| + return sprintf(page, "%s\n", pmu_attr->event_str);
| +}
| +
|  static int __init perf_event_sysfs_init(void)
|  {
|   struct pmu *pmu;
| -- 
| 1.8.3.1
| 
| ___
| Linuxppc-dev mailing list
| linuxppc-...@lists.ozlabs.org
| https://lists.ozlabs.org/listinfo/linuxppc-dev

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


Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling

2015-01-22 Thread Ahmed S. Darwish
On Wed, Jan 21, 2015 at 05:13:45PM +0100, Wolfgang Grandegger wrote:
> On Wed, 21 Jan 2015 10:36:47 -0500, "Ahmed S. Darwish"
>  wrote:
> > On Wed, Jan 21, 2015 at 03:00:15PM +, Andri Yngvason wrote:
> >> Quoting Ahmed S. Darwish (2015-01-21 14:43:23)
> >> > Hi!
> > 
> > ...
> > 
> >> > <-- Unplug the cable -->
> >> > 
> >> >  (000.009106)  can0  2080   [8]  00 00 00 00 00 00 08 00  
> >> >  ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{8}{0}}
> >> >  (000.001872)  can0  2080   [8]  00 00 00 00 00 00 10 00  
> 
> For a bus-errors I would also expcect some more information in the
> data[2..3] fields. But these are always zero.
> 

M16C error factors made it possible to report things like
CAN_ERR_PROT_FORM/STUFF/BIT0/BIT1/TX in data[2], and
CAN_ERR_PROT_LOC_ACK/CRC_DEL in data[3].

Unfortunately such error factors are only reported in Leaf, but
not in USBCan-II due to the wire format change in the error event:

struct leaf_msg_error_event {
u8 tid;
u8 flags;
__le16 time[3];
u8 channel;
u8 padding;
u8 tx_errors_count;
u8 rx_errors_count;
u8 status;
u8 error_factor;
} __packed;

struct usbcan_msg_error_event {
u8 tid;
u8 padding;
u8 tx_errors_count_ch0;
u8 rx_errors_count_ch0;
u8 tx_errors_count_ch1;
u8 rx_errors_count_ch1;
u8 status_ch0;
u8 status_ch1;
__le16 time;
} __packed;

I speculate that the wire format was changed due to controller
bugs in the USBCan-II, which was slightly mentioned in their
data sheets here:


http://www.kvaser.com/canlib-webhelp/page_hardware_specific_can_controllers.html

So it seems there's really no way for filling such bus error
info given the very limited amount of data exported :-(

The issue of incomplete data does not even stop here, kindly
check below notes regarding reverse state transitions:

> >> >  ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{16}{0}}
> >> [...]
> >> > error-counter-tx-rx{{80}{0}}
> >> >  (000.001910)  can0  2080   [8]  00 00 00 00 00 00 58 00  
> >> >  ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{88}{0}}
> >> >  (000.001753)  can0  2084   [8]  00 08 00 00 00 00 60 00  
> >> >  ERRORFRAME
> >> > controller-problem{tx-error-warning}
> >> Good.
> >> > bus-error
> >> > error-counter-tx-rx{{96}{0}}
> > 
> > Nice.
> > 
> >> >  (000.001720)  can0  2080   [8]  00 00 00 00 00 00 68 00  
> >> >  ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{104}{0}}
> >> >  (000.001876)  can0  2080   [8]  00 00 00 00 00 00 70 00  
> >> >  ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{112}{0}}
> >> >  (000.001749)  can0  2080   [8]  00 00 00 00 00 00 78 00  
> >> >  ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{120}{0}}
> >> >  (000.001771)  can0  2084   [8]  00 20 00 00 00 00 80 00  
> >> >  ERRORFRAME
> >> > controller-problem{tx-error-passive}
> >> Also good.
> >> > bus-error
> >> > error-counter-tx-rx{{128}{0}}
> > 
> > Also nice :-)
> > 
> >> >  (000.001868)  can0  2080   [8]  00 00 00 00 00 00 80 00  
> >> >  ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{128}{0}}
> >> >  (000.001982)  can0  2080   [8]  00 00 00 00 00 00 80 00  
> >> >  ERRORFRAME
> >> > bus-error
> >> > error-counter-tx-rx{{128}{0}}
> >> > 
> >> > (( Then a continous flood, exactly similar to the above packet,
> >> > appears.
> >> >Unfortunately this flooding is a firmware problem. ))
> >> > 
> >> > <-- Replug the cable, after a good amount of time -->
> >> >
> >> Where are the reverse state transitions?
> >> > 
> > 
> > Hmmm...
> > 
> > [ ... ]
> >> 
> >> Reverse state transitions are missing from the logs. See comments
> above.
> >> 
> > 
> > When the device is on the _receiving_ end, and I unplug the CAN cable
> after
> > introducing some noise to the level of reaching WARNING or PASSIVE, I
> > receive a BUS_ERROR event with the rxerr count reset back to 0 or 1. In
> > that case, the driver correctly transitions back the state to
> ERROR_ACTIVE
> > and candump produces something similar to:
> > 
> > (000.000362)  can0  208C   [8]  00 40 40 00 00 00 00 01  
> > ERRORFRAME
> > controller-problem{}
> > protocol-violation{{back-to-error-active}{}}
> > bus-error
> > error-counter-tx-rx{{0}{1}}
> > 
> > which is, AFAIK, the correct behaviour from the driver side.
> > 
> > Meanwhile, when the device is on the _sending_ end and I re-plug the CAN
> > cable again. Sometimes I receive events with txerr reset to 0 or 1, and
> > the driver correctly reverts back to 

Re: [PATCH] selftests/exec: Check if the syscall exists and bail if not

2015-01-22 Thread Michael Ellerman
On Wed, 2015-01-21 at 10:22 +, David Drysdale wrote:
> On Wed, Jan 21, 2015 at 7:41 AM, Michael Ellerman  wrote:
> > On systems which don't implement sys_execveat(), this test produces a
> > lot of output.
> >
> > Add a check at the beginning to see if the syscall is present, and if
> > not just note one error and return.
> 
> Good point, thanks.
> 
> > diff --git a/tools/testing/selftests/exec/execveat.c 
> > b/tools/testing/selftests/exec/execveat.c
> > index e238c9559caf..b87e4a843bea 100644
> > --- a/tools/testing/selftests/exec/execveat.c
> > +++ b/tools/testing/selftests/exec/execveat.c
> > @@ -234,6 +234,14 @@ static int run_tests(void)
> > int fd_cloexec = open_or_die("execveat", O_RDONLY|O_CLOEXEC);
> > int fd_script_cloexec = open_or_die("script", O_RDONLY|O_CLOEXEC);
> >
> > +   /* Check if we have execveat at all, and bail early if not */
> > +   errno = 0;
> > +   execveat_(-1, NULL, NULL, NULL, 0);
> > +   if (errno == -ENOSYS) {
> 
> Could we change this to ENOSYS (no minus) and also change
> the execveat_() function similarly, so that a binary built where
> __NR_execveat is available but running where it isn't also exits
> early?  (My bad for having the minus sign in execveat_() in the
> first place -- fingers too used to kernel mode.)

Ah yeah, me too, -ENOSYS just came naturally.

Will fix up and retest and resend.

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/


[PATCH 1/2] zram: free meta out of init_lock

2015-01-22 Thread Minchan Kim
We don't need to call zram_meta_free, zcomp_destroy and zs_free
under init_lock. What we need to prevent race with init_lock
in reset is setting NULL into zram->meta (ie, init_done).
This patch does it.

Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 9250b3f54a8f..0299d82275e7 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -708,6 +708,7 @@ static void zram_reset_device(struct zram *zram, bool 
reset_capacity)
 {
size_t index;
struct zram_meta *meta;
+   struct zcomp *comp;
 
down_write(>init_lock);
 
@@ -719,20 +720,10 @@ static void zram_reset_device(struct zram *zram, bool 
reset_capacity)
}
 
meta = zram->meta;
-   /* Free all pages that are still in this zram device */
-   for (index = 0; index < zram->disksize >> PAGE_SHIFT; index++) {
-   unsigned long handle = meta->table[index].handle;
-   if (!handle)
-   continue;
-
-   zs_free(meta->mem_pool, handle);
-   }
-
-   zcomp_destroy(zram->comp);
+   comp = zram->comp;
+   zram->meta = NULL;
zram->max_comp_streams = 1;
 
-   zram_meta_free(zram->meta);
-   zram->meta = NULL;
/* Reset stats */
memset(>stats, 0, sizeof(zram->stats));
 
@@ -742,6 +733,19 @@ static void zram_reset_device(struct zram *zram, bool 
reset_capacity)
 
up_write(>init_lock);
 
+   /* Free all pages that are still in this zram device */
+   for (index = 0; index < zram->disksize >> PAGE_SHIFT; index++) {
+   unsigned long handle = meta->table[index].handle;
+
+   if (!handle)
+   continue;
+
+   zs_free(meta->mem_pool, handle);
+   }
+
+   zcomp_destroy(comp);
+   zram_meta_free(meta);
+
/*
 * Revalidate disk out of the init_lock to avoid lockdep splat.
 * It's okay because disk's capacity is protected by init_lock
-- 
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] zram: protect zram->stat race with init_lock

2015-01-22 Thread Minchan Kim
The zram->stat handling should be procted by init_lock.
Otherwise, user could see stale value from the stat.

Signed-off-by: Minchan Kim 
---

I don't think it's stable material. The race is rare in real practice
and this stale stat value read is not a critical.

 drivers/block/zram/zram_drv.c | 37 -
 1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 0299d82275e7..53f176f590b0 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -48,8 +48,13 @@ static ssize_t name##_show(struct device *d, \
struct device_attribute *attr, char *b) \
 {  \
struct zram *zram = dev_to_zram(d); \
-   return scnprintf(b, PAGE_SIZE, "%llu\n",\
-   (u64)atomic64_read(>stats.name)); \
+   u64 val = 0;\
+   \
+   down_read(>init_lock);\
+   if (init_done(zram))\
+   val = atomic64_read(>stats.name); \
+   up_read(>init_lock);  \
+   return scnprintf(b, PAGE_SIZE, "%llu\n", val);  \
 }  \
 static DEVICE_ATTR_RO(name);
 
@@ -67,8 +72,14 @@ static ssize_t disksize_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
struct zram *zram = dev_to_zram(dev);
+   u64 val = 0;
+
+   down_read(>init_lock);
+   if (init_done(zram))
+   val = zram->disksize;
+   up_read(>init_lock);
 
-   return scnprintf(buf, PAGE_SIZE, "%llu\n", zram->disksize);
+   return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
 }
 
 static ssize_t initstate_show(struct device *dev,
@@ -88,9 +99,14 @@ static ssize_t orig_data_size_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
struct zram *zram = dev_to_zram(dev);
+   u64 val = 0;
+
+   down_read(>init_lock);
+   if (init_done(zram))
+   val = atomic64_read(>stats.pages_stored) << PAGE_SHIFT;
+   up_read(>init_lock);
 
-   return scnprintf(buf, PAGE_SIZE, "%llu\n",
-   (u64)(atomic64_read(>stats.pages_stored)) << PAGE_SHIFT);
+   return scnprintf(buf, PAGE_SIZE, "%llu\n", val);
 }
 
 static ssize_t mem_used_total_show(struct device *dev,
@@ -957,10 +973,6 @@ static int zram_rw_page(struct block_device *bdev, 
sector_t sector,
struct bio_vec bv;
 
zram = bdev->bd_disk->private_data;
-   if (!valid_io_request(zram, sector, PAGE_SIZE)) {
-   atomic64_inc(>stats.invalid_io);
-   return -EINVAL;
-   }
 
down_read(>init_lock);
if (unlikely(!init_done(zram))) {
@@ -968,6 +980,13 @@ static int zram_rw_page(struct block_device *bdev, 
sector_t sector,
goto out_unlock;
}
 
+   if (!valid_io_request(zram, sector, PAGE_SIZE)) {
+   atomic64_inc(>stats.invalid_io);
+   err = -EINVAL;
+   goto out_unlock;
+   }
+
+
index = sector >> SECTORS_PER_PAGE_SHIFT;
offset = sector & (SECTORS_PER_PAGE - 1) << SECTOR_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: weird and wrong directory entries

2015-01-22 Thread Sergey Senozhatsky
On (01/23/15 12:57), Sergey Senozhatsky wrote:
> > Am 23.01.2015 um 03:06 schrieb Sergey Senozhatsky:
> > > On (01/23/15 01:30), Al Viro wrote:
> > >> On Fri, Jan 23, 2015 at 09:42:21AM +0900, Sergey Senozhatsky wrote:
> > >>> Hello gents,
> > >>>
> > >>> I observe this sick behaviour for the past few days. (sorry, some lines 
> > >>> are
> > >>> over 80 symbols). all of the things above are happening during kernel 
> > >>> compilation.
> > >>> attached .config.
> > >>
> > >>> happens both on reiserfs and ext4, both on current linus's tree and 
> > >>> linux-next.
> > >>> no doubt, an attempt to rm -fr pkg/   kills   /usr/, etc.
> > >>>
> > >>
> > >>> I'm puzzled. any thoughts?
> > >>
> > >> Try to bisect, perhaps?
> > >>
> > 
> > There are some weird pieces in the kernel buildsysten which are
> > generating Makefile content based on some filenames and might brake or
> > confuse future builds. See e.g. https://lkml.org/lkml/2014/10/19/10.
> > 
> > Maybe you've stumbled over a similiar thing.
> > 
> 
> Hm, basically, I don't add any new files, especially with commas, etc.,
> just kernel.org vanilla and linux-next.
> 
> 
> things like this:
> 
> $ ll
> ls: cannot access /ho: No such file or directory
> total 12
> d? ? ?  ? ?? /ho
> drwxr-xr-x 3 ss ss 4096 Jan 23 08:44 ethernet
> -rw-r--r-- 1 ss ss 3195 Jan 23 08:44 mii.ko.gz
> drwxr-xr-x 2 ss ss 4096 Jan 23 08:44 usb
> 
> make me think that I'm facing a bit different kind of issues.
> 
> gonna bisect for a while. marked Sept 19th tree as good. the issue is not

I meant Jan 19th... apparently, it's january.
good 12ba8571ab6b232f5facef6b1dd28c5ebc2b530a (just randomly picked up).

-ss

> 100% reproducible, and 1 `ok build' doesn't mean anything. let's see if
> this will fly.
> 
--
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] procfs: Always expose /proc//map_files/ and make it readable

2015-01-22 Thread Calvin Owens
On Thursday 01/22 at 23:27 +0200, Kirill A. Shutemov wrote:
> On Thu, Jan 22, 2015 at 01:00:25PM -0800, Calvin Owens wrote:
> > On Thursday 01/22 at 13:02 +0200, Kirill A. Shutemov wrote:
> > > On Wed, Jan 21, 2015 at 06:45:54PM -0800, Calvin Owens wrote:
> > > > Currently, /proc//map_files/ is restricted to CAP_SYS_ADMIN, and
> > > > is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface
> > > > is very useful for enumerating the files mapped into a process when
> > > > the more verbose information in /proc//maps is not needed.
> > > > 
> > > > This patch moves the folder out from behind CHECKPOINT_RESTORE, and
> > > > removes the CAP_SYS_ADMIN restrictions. To avoid exposing files to
> > > > processes for whom they may not be visible, a follow_link() stub is
> > > > added to the inode_operations struct attached to the symlinks that
> > > > prevent them from being followed without CAP_SYS_ADMIN.
> > > > 
> > > > Signed-off-by: Calvin Owens 
> > > > ---
> > > >  fs/proc/base.c | 42 +++---
> > > >  1 file changed, 23 insertions(+), 19 deletions(-)
> > > > 
> > > > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > > > index 3f3d7ae..7d48003 100644
> > > > --- a/fs/proc/base.c
> > > > +++ b/fs/proc/base.c
> > > > @@ -1632,8 +1632,6 @@ end_instantiate:
> > > > return dir_emit(ctx, name, len, 1, DT_UNKNOWN);
> > > >  }
> > > >  
> > > > -#ifdef CONFIG_CHECKPOINT_RESTORE
> > > > -
> > > >  /*
> > > >   * dname_to_vma_addr - maps a dentry name into two unsigned longs
> > > >   * which represent vma start and end addresses.
> > > > @@ -1660,11 +1658,6 @@ static int map_files_d_revalidate(struct dentry 
> > > > *dentry, unsigned int flags)
> > > > if (flags & LOOKUP_RCU)
> > > > return -ECHILD;
> > > >  
> > > > -   if (!capable(CAP_SYS_ADMIN)) {
> > > > -   status = -EPERM;
> > > > -   goto out_notask;
> > > > -   }
> > > > -
> > > > inode = dentry->d_inode;
> > > > task = get_proc_task(inode);
> > > > if (!task)
> > > > @@ -1753,6 +1746,28 @@ struct map_files_info {
> > > > unsigned char   name[4*sizeof(long)+2]; /* max: %lx-%lx\0 */
> > > >  };
> > > >  
> > > > +/*
> > > > + * Allowing any user to follow the symlinks in /proc//map_files/ 
> > > > could
> > > > + * allow processes to access files that should not be visible to them, 
> > > > so
> > > > + * restrict follow_link() to CAP_SYS_ADMIN for these files.
> > > > + */
> > > > +static void *proc_map_files_follow_link(struct dentry *d, struct 
> > > > nameidata *n)
> > > > +{
> > > > +   if (!capable(CAP_SYS_ADMIN))
> > > > +   return ERR_PTR(-EPERM);
> > > > +
> > > > +   return proc_pid_follow_link(d, n);
> > > > +}
> > > 
> > > I have thought a bit more about this and not sure it's reasonable to
> > > limit it to CAP_SYS_ADMIN. What scenario are we protecting from?
> > > 
> > > Initially, I thought about something like this: privileged process opens a
> > > file, map part of it, closes the file and drop privileges with hope to
> > > limit further access to mapped window of the file. But I don't see what
> > > would stop the unprivileged process from accessing rest of the file using
> > > mremap(2). And if a process can do this, anybody who can ptrace(2) the
> > > process can do this.
> > > 
> > > Am I missing something?
> > 
> > The specific case I was thinking of is a process in a chroot with a
> > mounted /proc inside of it: if a process inside the chroot has the same
> > UID as a process outside of it, the chroot'ed process could follow the
> > symlinks in map_files/ and poke files it can't actually see, right?
> 
> It depends on how you define "poke". If you mean touch content of the
> file, then, well, you can do it now. You cannot do anything which requires
> file descriptor -- open(), ftrancate(), etc.

Ah okay, I didn't realize you couldn't get the file descriptor. I wrote
a quick test case, you get -EACCES on open() in my chroot scenario.

I'll resend without the CAP_SYS_ADMIN check.

Thanks,
Calvin
--
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/


[Resend Patch v4 16/16] smp, trivial: Remove unused function prototype from smp_boot.h

2015-01-22 Thread Jiang Liu
Function smpboot_thread_schedule() is neither used nor defined,
so kill it.

Signed-off-by: Jiang Liu 
---
 include/linux/smpboot.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/smpboot.h b/include/linux/smpboot.h
index 13e929679550..d600afb21926 100644
--- a/include/linux/smpboot.h
+++ b/include/linux/smpboot.h
@@ -47,6 +47,5 @@ struct smp_hotplug_thread {
 
 int smpboot_register_percpu_thread(struct smp_hotplug_thread *plug_thread);
 void smpboot_unregister_percpu_thread(struct smp_hotplug_thread *plug_thread);
-int smpboot_thread_schedule(void);
 
 #endif
-- 
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/


[Resend Patch v4 15/16] smp: Cleanup unsued generic_smp_call_function_single_interrupt()

2015-01-22 Thread Jiang Liu
Now we have killed all usage of generic_smp_call_function_single_interrupt()
from arch code, so kill it.

Signed-off-by: Jiang Liu 
---
 include/linux/smp.h |4 +---
 kernel/smp.c|4 ++--
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/include/linux/smp.h b/include/linux/smp.h
index 93dff5fff524..cd78b3aa2cf8 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -106,9 +106,7 @@ void wake_up_all_idle_cpus(void);
  * Generic and arch helpers
  */
 void __init call_function_init(void);
-void generic_smp_call_function_single_interrupt(void);
-#define generic_smp_call_function_interrupt \
-   generic_smp_call_function_single_interrupt
+void generic_smp_call_function_interrupt(void);
 
 /*
  * Mark the boot cpu "online" so that it can call console drivers in
diff --git a/kernel/smp.c b/kernel/smp.c
index f38a1e692259..e39712cbe92d 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -197,12 +197,12 @@ static int generic_exec_single(int cpu, struct 
call_single_data *csd,
 }
 
 /**
- * generic_smp_call_function_single_interrupt - Execute SMP IPI callbacks
+ * generic_smp_call_function_interrupt - Execute SMP IPI callbacks
  *
  * Invoked by arch to handle an IPI for call function single.
  * Must be called with interrupts disabled.
  */
-void generic_smp_call_function_single_interrupt(void)
+void generic_smp_call_function_interrupt(void)
 {
flush_smp_call_function_queue(true);
 }
-- 
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/


[Resend Patch v4 11/16] smp, x86, xen: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Signed-off-by: Jiang Liu 
Acked-by: Konrad Rzeszutek Wilk 
Cc: x...@kernel.org
Cc: xen-de...@lists.xensource.com
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/xen/events.h |1 -
 arch/x86/xen/smp.c|   38 ++---
 2 files changed, 2 insertions(+), 37 deletions(-)

diff --git a/arch/x86/include/asm/xen/events.h 
b/arch/x86/include/asm/xen/events.h
index 608a79d5a466..a9e54dc05c50 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -4,7 +4,6 @@
 enum ipi_vector {
XEN_RESCHEDULE_VECTOR,
XEN_CALL_FUNCTION_VECTOR,
-   XEN_CALL_FUNCTION_SINGLE_VECTOR,
XEN_SPIN_UNLOCK_VECTOR,
XEN_IRQ_WORK_VECTOR,
XEN_NMI_VECTOR,
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 4c071aeb8417..d54c122a0486 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -47,12 +47,10 @@ struct xen_common_irq {
 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_resched_irq) = { .irq = -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_callfunc_irq) = { .irq = -1 };
-static DEFINE_PER_CPU(struct xen_common_irq, xen_callfuncsingle_irq) = { .irq 
= -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_irq_work) = { .irq = -1 };
 static DEFINE_PER_CPU(struct xen_common_irq, xen_debug_irq) = { .irq = -1 };
 
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
-static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id);
 static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id);
 
 /*
@@ -136,13 +134,6 @@ static void xen_smp_intr_free(unsigned int cpu)
kfree(per_cpu(xen_debug_irq, cpu).name);
per_cpu(xen_debug_irq, cpu).name = NULL;
}
-   if (per_cpu(xen_callfuncsingle_irq, cpu).irq >= 0) {
-   unbind_from_irqhandler(per_cpu(xen_callfuncsingle_irq, cpu).irq,
-  NULL);
-   per_cpu(xen_callfuncsingle_irq, cpu).irq = -1;
-   kfree(per_cpu(xen_callfuncsingle_irq, cpu).name);
-   per_cpu(xen_callfuncsingle_irq, cpu).name = NULL;
-   }
if (xen_hvm_domain())
return;
 
@@ -191,18 +182,6 @@ static int xen_smp_intr_init(unsigned int cpu)
per_cpu(xen_debug_irq, cpu).irq = rc;
per_cpu(xen_debug_irq, cpu).name = debug_name;
 
-   callfunc_name = kasprintf(GFP_KERNEL, "callfuncsingle%d", cpu);
-   rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_SINGLE_VECTOR,
-   cpu,
-   xen_call_function_single_interrupt,
-   IRQF_PERCPU|IRQF_NOBALANCING,
-   callfunc_name,
-   NULL);
-   if (rc < 0)
-   goto fail;
-   per_cpu(xen_callfuncsingle_irq, cpu).irq = rc;
-   per_cpu(xen_callfuncsingle_irq, cpu).name = callfunc_name;
-
/*
 * The IRQ worker on PVHVM goes through the native path and uses the
 * IPI mechanism.
@@ -599,8 +578,7 @@ static void xen_smp_send_call_function_ipi(const struct 
cpumask *mask)
 
 static void xen_smp_send_call_function_single_ipi(int cpu)
 {
-   __xen_send_IPI_mask(cpumask_of(cpu),
- XEN_CALL_FUNCTION_SINGLE_VECTOR);
+   __xen_send_IPI_mask(cpumask_of(cpu), XEN_CALL_FUNCTION_VECTOR);
 }
 
 static inline int xen_map_vector(int vector)
@@ -612,10 +590,8 @@ static inline int xen_map_vector(int vector)
xen_vector = XEN_RESCHEDULE_VECTOR;
break;
case CALL_FUNCTION_VECTOR:
-   xen_vector = XEN_CALL_FUNCTION_VECTOR;
-   break;
case CALL_FUNCTION_SINGLE_VECTOR:
-   xen_vector = XEN_CALL_FUNCTION_SINGLE_VECTOR;
+   xen_vector = XEN_CALL_FUNCTION_VECTOR;
break;
case IRQ_WORK_VECTOR:
xen_vector = XEN_IRQ_WORK_VECTOR;
@@ -693,16 +669,6 @@ static irqreturn_t xen_call_function_interrupt(int irq, 
void *dev_id)
return IRQ_HANDLED;
 }
 
-static irqreturn_t xen_call_function_single_interrupt(int irq, void *dev_id)
-{
-   irq_enter();
-   generic_smp_call_function_single_interrupt();
-   inc_irq_stat(irq_call_count);
-   irq_exit();
-
-   return IRQ_HANDLED;
-}
-
 static irqreturn_t xen_irq_work_interrupt(int irq, void *dev_id)
 {
irq_enter();
-- 
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 

[Resend Patch v4 14/16] smp, s390: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Signed-off-by: Jiang Liu 
Acked-by: Heiko Carstens 
---
 arch/s390/kernel/smp.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index 0b499f5cbe19..5b89eabc3a01 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -50,7 +50,7 @@
 
 enum {
ec_schedule = 0,
-   ec_call_function_single,
+   ec_call_function,
ec_stop_cpu,
 };
 
@@ -416,8 +416,8 @@ static void smp_handle_ext_call(void)
smp_stop_cpu();
if (test_bit(ec_schedule, ))
scheduler_ipi();
-   if (test_bit(ec_call_function_single, ))
-   generic_smp_call_function_single_interrupt();
+   if (test_bit(ec_call_function, ))
+   generic_smp_call_function_interrupt();
 }
 
 static void do_ext_call_interrupt(struct ext_code ext_code,
@@ -432,12 +432,12 @@ void arch_send_call_function_ipi_mask(const struct 
cpumask *mask)
int cpu;
 
for_each_cpu(cpu, mask)
-   pcpu_ec_call(pcpu_devices + cpu, ec_call_function_single);
+   pcpu_ec_call(pcpu_devices + cpu, ec_call_function);
 }
 
 void arch_send_call_function_single_ipi(int cpu)
 {
-   pcpu_ec_call(pcpu_devices + cpu, ec_call_function_single);
+   pcpu_ec_call(pcpu_devices + cpu, ec_call_function);
 }
 
 #ifndef CONFIG_64BIT
-- 
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/


[Resend Patch v4 12/16] smp, x86: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Steven Rostedt 
Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/entry_arch.h|1 -
 arch/x86/include/asm/hw_irq.h|3 ---
 arch/x86/include/asm/irq_vectors.h   |7 +++
 arch/x86/include/asm/trace/irq_vectors.h |6 --
 arch/x86/kernel/entry_64.S   |2 --
 arch/x86/kernel/irqinit.c|4 
 arch/x86/kernel/smp.c|   24 +---
 arch/x86/xen/smp.c   |1 -
 8 files changed, 4 insertions(+), 44 deletions(-)

diff --git a/arch/x86/include/asm/entry_arch.h 
b/arch/x86/include/asm/entry_arch.h
index dc5fa661465f..9670cff64e93 100644
--- a/arch/x86/include/asm/entry_arch.h
+++ b/arch/x86/include/asm/entry_arch.h
@@ -12,7 +12,6 @@
 #ifdef CONFIG_SMP
 BUILD_INTERRUPT(reschedule_interrupt,RESCHEDULE_VECTOR)
 BUILD_INTERRUPT(call_function_interrupt,CALL_FUNCTION_VECTOR)
-BUILD_INTERRUPT(call_function_single_interrupt,CALL_FUNCTION_SINGLE_VECTOR)
 BUILD_INTERRUPT3(irq_move_cleanup_interrupt, IRQ_MOVE_CLEANUP_VECTOR,
 smp_irq_move_cleanup_interrupt)
 BUILD_INTERRUPT3(reboot_interrupt, REBOOT_VECTOR, smp_reboot_interrupt)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 9662290e0b20..4a7f5d4cfcdb 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -75,7 +75,6 @@ extern asmlinkage void reboot_interrupt(void);
 extern asmlinkage void threshold_interrupt(void);
 
 extern asmlinkage void call_function_interrupt(void);
-extern asmlinkage void call_function_single_interrupt(void);
 
 #ifdef CONFIG_TRACING
 /* Interrupt handlers registered during init_IRQ */
@@ -88,7 +87,6 @@ extern void trace_thermal_interrupt(void);
 extern void trace_reschedule_interrupt(void);
 extern void trace_threshold_interrupt(void);
 extern void trace_call_function_interrupt(void);
-extern void trace_call_function_single_interrupt(void);
 #define trace_irq_move_cleanup_interrupt  irq_move_cleanup_interrupt
 #define trace_reboot_interrupt  reboot_interrupt
 #define trace_kvm_posted_intr_ipi kvm_posted_intr_ipi
@@ -177,7 +175,6 @@ extern asmlinkage void smp_irq_move_cleanup_interrupt(void);
 #ifdef CONFIG_SMP
 extern __visible void smp_reschedule_interrupt(struct pt_regs *);
 extern __visible void smp_call_function_interrupt(struct pt_regs *);
-extern __visible void smp_call_function_single_interrupt(struct pt_regs *);
 extern __visible void smp_invalidate_interrupt(struct pt_regs *);
 #endif
 
diff --git a/arch/x86/include/asm/irq_vectors.h 
b/arch/x86/include/asm/irq_vectors.h
index 666c89ec4bd7..bab7f0a1edde 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -92,10 +92,9 @@
 #define ERROR_APIC_VECTOR  0xfe
 #define RESCHEDULE_VECTOR  0xfd
 #define CALL_FUNCTION_VECTOR   0xfc
-#define CALL_FUNCTION_SINGLE_VECTOR0xfb
-#define THERMAL_APIC_VECTOR0xfa
-#define THRESHOLD_APIC_VECTOR  0xf9
-#define REBOOT_VECTOR  0xf8
+#define THERMAL_APIC_VECTOR0xfb
+#define THRESHOLD_APIC_VECTOR  0xfa
+#define REBOOT_VECTOR  0xf9
 
 /*
  * Generic system vector for platform specific use
diff --git a/arch/x86/include/asm/trace/irq_vectors.h 
b/arch/x86/include/asm/trace/irq_vectors.h
index 4cab890007a7..e672e203edc1 100644
--- a/arch/x86/include/asm/trace/irq_vectors.h
+++ b/arch/x86/include/asm/trace/irq_vectors.h
@@ -89,12 +89,6 @@ TRACE_EVENT_PERF_PERM(irq_work_exit, 
is_sampling_event(p_event) ? -EPERM : 0);
 DEFINE_IRQ_VECTOR_EVENT(call_function);
 
 /*
- * call_function_single - called when entering/exiting a call function
- * single interrupt vector handler
- */
-DEFINE_IRQ_VECTOR_EVENT(call_function_single);
-
-/*
  * threshold_apic - called when entering/exiting a threshold apic interrupt
  * vector handler
  */
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 9ebaf63ba182..284e5741a9ba 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1001,8 +1001,6 @@ apicinterrupt THERMAL_APIC_VECTOR \
 #endif
 
 #ifdef CONFIG_SMP
-apicinterrupt CALL_FUNCTION_SINGLE_VECTOR \
-   call_function_single_interrupt smp_call_function_single_interrupt
 apicinterrupt CALL_FUNCTION_VECTOR \
call_function_interrupt smp_call_function_interrupt
 apicinterrupt RESCHEDULE_VECTOR \
diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
index 70e181ea1eac..d72a8c4da145 100644
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -111,10 +111,6 @@ static void 

[Resend Patch v4 13/16] smp, tile: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Signed-off-by: Jiang Liu 
Acked-by: Chris Metcalf 
---
 arch/tile/include/asm/smp.h |7 +++
 arch/tile/kernel/smp.c  |6 +-
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/tile/include/asm/smp.h b/arch/tile/include/asm/smp.h
index 9a326b64f7ae..67e58e781549 100644
--- a/arch/tile/include/asm/smp.h
+++ b/arch/tile/include/asm/smp.h
@@ -67,19 +67,18 @@ static inline int xy_to_cpu(int x, int y)
 /* Hypervisor message tags sent via the tile send_IPI*() routines. */
 #define MSG_TAG_START_CPU  1
 #define MSG_TAG_STOP_CPU   2
-#define MSG_TAG_CALL_FUNCTION_MANY 3
-#define MSG_TAG_CALL_FUNCTION_SINGLE   4
+#define MSG_TAG_CALL_FUNCTION  3
 
 /* Hook for the generic smp_call_function_many() routine. */
 static inline void arch_send_call_function_ipi_mask(struct cpumask *mask)
 {
-   send_IPI_many(mask, MSG_TAG_CALL_FUNCTION_MANY);
+   send_IPI_many(mask, MSG_TAG_CALL_FUNCTION);
 }
 
 /* Hook for the generic smp_call_function_single() routine. */
 static inline void arch_send_call_function_single_ipi(int cpu)
 {
-   send_IPI_single(cpu, MSG_TAG_CALL_FUNCTION_SINGLE);
+   send_IPI_single(cpu, MSG_TAG_CALL_FUNCTION);
 }
 
 /* Print out the boot string describing which cpus were disabled. */
diff --git a/arch/tile/kernel/smp.c b/arch/tile/kernel/smp.c
index d3c4ed780ce2..780410176341 100644
--- a/arch/tile/kernel/smp.c
+++ b/arch/tile/kernel/smp.c
@@ -139,14 +139,10 @@ void evaluate_message(int tag)
smp_stop_cpu_interrupt();
break;
 
-   case MSG_TAG_CALL_FUNCTION_MANY: /* Call function on cpumask */
+   case MSG_TAG_CALL_FUNCTION: /* Call function on cpumask */
generic_smp_call_function_interrupt();
break;
 
-   case MSG_TAG_CALL_FUNCTION_SINGLE: /* Call function on one other CPU */
-   generic_smp_call_function_single_interrupt();
-   break;
-
default:
panic("Unknown IPI message tag %d", tag);
break;
-- 
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/


[Resend Patch v4 08/16] smp, sh: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Cc: Paul Mundt 
Signed-off-by: Jiang Liu 
---
 arch/sh/include/asm/smp.h |1 -
 arch/sh/kernel/smp.c  |5 +
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/sh/include/asm/smp.h b/arch/sh/include/asm/smp.h
index 78b0d0f4b24b..93ce87b3a18d 100644
--- a/arch/sh/include/asm/smp.h
+++ b/arch/sh/include/asm/smp.h
@@ -25,7 +25,6 @@ extern int __cpu_logical_map[NR_CPUS];
 enum {
SMP_MSG_FUNCTION,
SMP_MSG_RESCHEDULE,
-   SMP_MSG_FUNCTION_SINGLE,
SMP_MSG_TIMER,
 
SMP_MSG_NR, /* must be last */
diff --git a/arch/sh/kernel/smp.c b/arch/sh/kernel/smp.c
index fc5acfc93c92..fc03baf8b661 100644
--- a/arch/sh/kernel/smp.c
+++ b/arch/sh/kernel/smp.c
@@ -282,7 +282,7 @@ void arch_send_call_function_ipi_mask(const struct cpumask 
*mask)
 
 void arch_send_call_function_single_ipi(int cpu)
 {
-   mp_ops->send_ipi(cpu, SMP_MSG_FUNCTION_SINGLE);
+   mp_ops->send_ipi(cpu, SMP_MSG_FUNCTION);
 }
 
 void smp_timer_broadcast(const struct cpumask *mask)
@@ -309,9 +309,6 @@ void smp_message_recv(unsigned int msg)
case SMP_MSG_RESCHEDULE:
scheduler_ipi();
break;
-   case SMP_MSG_FUNCTION_SINGLE:
-   generic_smp_call_function_single_interrupt();
-   break;
case SMP_MSG_TIMER:
ipi_timer();
break;
-- 
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/


[Resend Patch v4 10/16] smp, sparc: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Cc: "David S. Miller" 
Cc: Sam Ravnborg 
Cc: sparcli...@vger.kernel.org
Signed-off-by: Jiang Liu 
---
 arch/sparc/include/asm/smp_32.h |4 +---
 arch/sparc/kernel/entry.S   |   10 ++
 arch/sparc/kernel/leon_smp.c|   31 +++
 arch/sparc/kernel/smp_32.c  |   14 ++
 arch/sparc/kernel/sun4d_smp.c   |   31 +++
 arch/sparc/kernel/sun4m_smp.c   |   11 ++-
 6 files changed, 21 insertions(+), 80 deletions(-)

diff --git a/arch/sparc/include/asm/smp_32.h b/arch/sparc/include/asm/smp_32.h
index 7c24e08a88d2..51e53c606cc9 100644
--- a/arch/sparc/include/asm/smp_32.h
+++ b/arch/sparc/include/asm/smp_32.h
@@ -48,7 +48,6 @@ void smp_callin(void);
 void smp_store_cpu_info(int);
 
 void smp_resched_interrupt(void);
-void smp_call_function_single_interrupt(void);
 void smp_call_function_interrupt(void);
 
 struct seq_file;
@@ -60,8 +59,7 @@ struct sparc32_ipi_ops {
   unsigned long arg2, unsigned long arg3,
   unsigned long arg4);
void (*resched)(int cpu);
-   void (*single)(int cpu);
-   void (*mask_one)(int cpu);
+   void (*func_call)(int cpu);
 };
 extern const struct sparc32_ipi_ops *sparc32_ipi_ops;
 
diff --git a/arch/sparc/kernel/entry.S b/arch/sparc/kernel/entry.S
index 33c02b15f478..98bacfb16fa8 100644
--- a/arch/sparc/kernel/entry.S
+++ b/arch/sparc/kernel/entry.S
@@ -263,7 +263,7 @@ smp4m_ticker:
 * on some level other than 15 which is the NMI and only used
 * for cross calls.  That has a separate entry point below.
 *
-* IPIs are sent on Level 12, 13 and 14. See IRQ_IPI_*.
+* IPIs are sent on Level 13 and 14. See IRQ_IPI_*.
 */
 maybe_smp4m_msg:
GET_PROCESSOR4M_ID(o3)
@@ -287,14 +287,8 @@ maybe_smp4m_msg:
wr  %l4, PSR_ET, %psr
WRITE_PAUSE
srl %o3, 28, %o2! shift for simpler checks below
-maybe_smp4m_msg_check_single:
-   andcc   %o2, 0x1, %g0
-   beq,a   maybe_smp4m_msg_check_mask
-andcc  %o2, 0x2, %g0
-   callsmp_call_function_single_interrupt
-nop
-   andcc   %o2, 0x2, %g0
 maybe_smp4m_msg_check_mask:
+   andcc   %o2, 0x2, %g0
beq,a   maybe_smp4m_msg_check_resched
 andcc  %o2, 0x4, %g0
callsmp_call_function_interrupt
diff --git a/arch/sparc/kernel/leon_smp.c b/arch/sparc/kernel/leon_smp.c
index 71e16f2241c2..ee3c6599c271 100644
--- a/arch/sparc/kernel/leon_smp.c
+++ b/arch/sparc/kernel/leon_smp.c
@@ -260,8 +260,7 @@ void __init leon_smp_done(void)
 }
 
 struct leon_ipi_work {
-   int single;
-   int msk;
+   int func_call;
int resched;
 };
 
@@ -297,7 +296,7 @@ static void __init leon_ipi_init(void)
 
for_each_possible_cpu(cpu) {
work = _cpu(leon_ipi_work, cpu);
-   work->single = work->msk = work->resched = 0;
+   work->func_call = work->resched = 0;
}
 }
 
@@ -308,23 +307,12 @@ static void leon_send_ipi(int cpu, int level)
LEON3_BYPASS_STORE_PA(_irqctrl_regs->force[cpu], mask);
 }
 
-static void leon_ipi_single(int cpu)
+static void leon_ipi_func_call(int cpu)
 {
struct leon_ipi_work *work = _cpu(leon_ipi_work, cpu);
 
/* Mark work */
-   work->single = 1;
-
-   /* Generate IRQ on the CPU */
-   leon_send_ipi(cpu, leon_ipi_irq);
-}
-
-static void leon_ipi_mask_one(int cpu)
-{
-   struct leon_ipi_work *work = _cpu(leon_ipi_work, cpu);
-
-   /* Mark work */
-   work->msk = 1;
+   work->func_call = 1;
 
/* Generate IRQ on the CPU */
leon_send_ipi(cpu, leon_ipi_irq);
@@ -345,12 +333,8 @@ void leonsmp_ipi_interrupt(void)
 {
struct leon_ipi_work *work = this_cpu_ptr(_ipi_work);
 
-   if (work->single) {
-   work->single = 0;
-   smp_call_function_single_interrupt();
-   }
-   if (work->msk) {
-   work->msk = 0;
+   if (work->func_call) {
+   work->func_call = 0;
smp_call_function_interrupt();
}
if (work->resched) {
@@ -456,8 +440,7 @@ void leon_cross_call_irq(void)
 static const struct sparc32_ipi_ops leon_ipi_ops = {
.cross_call = leon_cross_call,
.resched= leon_ipi_resched,
-   .single = leon_ipi_single,
-   .mask_one   = leon_ipi_mask_one,
+   .func_call   = leon_ipi_func_call,
 };
 
 void __init leon_init_smp(void)
diff --git a/arch/sparc/kernel/smp_32.c b/arch/sparc/kernel/smp_32.c
index b3a5d81b20f0..0d5287bad74c 100644
--- a/arch/sparc/kernel/smp_32.c
+++ 

[Resend Patch v4 07/16] smp, mn10300: Enable arch_send_call_function_ipi_mask()

2015-01-22 Thread Jiang Liu
Enable arch_send_call_function_ipi_mask() on mn10300 to support
smp_call_function_many().

Cc: Koichi Yasutake 
Cc: linux-am33-l...@redhat.com
Signed-off-by: Jiang Liu 
---
 arch/mn10300/kernel/smp.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/mn10300/kernel/smp.c b/arch/mn10300/kernel/smp.c
index 13aa7ac5a82b..9d21c3391374 100644
--- a/arch/mn10300/kernel/smp.c
+++ b/arch/mn10300/kernel/smp.c
@@ -356,8 +356,7 @@ void send_IPI_allbutself(int irq)
 
 void arch_send_call_function_ipi_mask(const struct cpumask *mask)
 {
-   BUG();
-   /*send_IPI_mask(mask, CALL_FUNCTION_IPI);*/
+   send_IPI_mask(mask, CALL_FUNC_IPI);
 }
 
 void arch_send_call_function_single_ipi(int cpu)
-- 
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/


[Resend Patch v4 09/16] smp, sparc64: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Cc: "David S. Miller" 
Cc: Sam Ravnborg 
Cc: sparcli...@vger.kernel.org
Signed-off-by: Jiang Liu 
---
 arch/sparc/include/asm/pil.h  |5 ++---
 arch/sparc/kernel/smp_64.c|   13 +
 arch/sparc/kernel/ttable_64.S |   12 
 arch/sparc/mm/ultra.S |5 -
 4 files changed, 7 insertions(+), 28 deletions(-)

diff --git a/arch/sparc/include/asm/pil.h b/arch/sparc/include/asm/pil.h
index 266937030546..5ffb15df5062 100644
--- a/arch/sparc/include/asm/pil.h
+++ b/arch/sparc/include/asm/pil.h
@@ -22,9 +22,8 @@
 #define PIL_SMP_CAPTURE3
 #define PIL_SMP_CTX_NEW_VERSION4
 #define PIL_DEVICE_IRQ 5
-#define PIL_SMP_CALL_FUNC_SNGL 6
-#define PIL_DEFERRED_PCR_WORK  7
-#define PIL_KGDB_CAPTURE   8
+#define PIL_DEFERRED_PCR_WORK  6
+#define PIL_KGDB_CAPTURE   7
 #define PIL_NORMAL_MAX 14
 #define PIL_NMI15
 
diff --git a/arch/sparc/kernel/smp_64.c b/arch/sparc/kernel/smp_64.c
index da6f1a7fc4db..a91b4f9ca822 100644
--- a/arch/sparc/kernel/smp_64.c
+++ b/arch/sparc/kernel/smp_64.c
@@ -805,12 +805,9 @@ void arch_send_call_function_ipi_mask(const struct cpumask 
*mask)
xcall_deliver((u64) _call_function, 0, 0, mask);
 }
 
-extern unsigned long xcall_call_function_single;
-
 void arch_send_call_function_single_ipi(int cpu)
 {
-   xcall_deliver((u64) _call_function_single, 0, 0,
- cpumask_of(cpu));
+   xcall_deliver((u64) _call_function, 0, 0, cpumask_of(cpu));
 }
 
 void __irq_entry smp_call_function_client(int irq, struct pt_regs *regs)
@@ -821,14 +818,6 @@ void __irq_entry smp_call_function_client(int irq, struct 
pt_regs *regs)
irq_exit();
 }
 
-void __irq_entry smp_call_function_single_client(int irq, struct pt_regs *regs)
-{
-   clear_softint(1 << irq);
-   irq_enter();
-   generic_smp_call_function_single_interrupt();
-   irq_exit();
-}
-
 static void tsb_sync(void *info)
 {
struct trap_per_cpu *tp = _block[raw_smp_processor_id()];
diff --git a/arch/sparc/kernel/ttable_64.S b/arch/sparc/kernel/ttable_64.S
index c6dfdaa29e20..defa2db9f914 100644
--- a/arch/sparc/kernel/ttable_64.S
+++ b/arch/sparc/kernel/ttable_64.S
@@ -58,17 +58,13 @@ tl0_irq3:   BTRAP(0x43)
 tl0_irq4:  BTRAP(0x44)
 #endif
 tl0_irq5:  TRAP_IRQ(handler_irq, 5)
-#ifdef CONFIG_SMP
-tl0_irq6:  TRAP_IRQ(smp_call_function_single_client, 6)
-#else
-tl0_irq6:  BTRAP(0x46)
-#endif
-tl0_irq7:  TRAP_IRQ(deferred_pcr_work_irq, 7)
+tl0_irq6:  TRAP_IRQ(deferred_pcr_work_irq, 6)
 #if defined(CONFIG_KGDB) && defined(CONFIG_SMP)
-tl0_irq8:  TRAP_IRQ(smp_kgdb_capture_client, 8)
+tl0_irq7:  TRAP_IRQ(smp_kgdb_capture_client, 7)
 #else
-tl0_irq8:  BTRAP(0x48)
+tl0_irq7:  BTRAP(0x47)
 #endif
+tl0_irq8:  BTRAP(0x48)
 tl0_irq9:  BTRAP(0x49)
 tl0_irq10: BTRAP(0x4a) BTRAP(0x4b) BTRAP(0x4c) BTRAP(0x4d)
 tl0_irq14: TRAP_IRQ(timer_interrupt, 14)
diff --git a/arch/sparc/mm/ultra.S b/arch/sparc/mm/ultra.S
index b4f4733abc6e..1da47398df65 100644
--- a/arch/sparc/mm/ultra.S
+++ b/arch/sparc/mm/ultra.S
@@ -780,11 +780,6 @@ xcall_call_function:
wr  %g0, (1 << PIL_SMP_CALL_FUNC), %set_softint
retry
 
-   .globl  xcall_call_function_single
-xcall_call_function_single:
-   wr  %g0, (1 << PIL_SMP_CALL_FUNC_SNGL), %set_softint
-   retry
-
.globl  xcall_receive_signal
 xcall_receive_signal:
wr  %g0, (1 << PIL_SMP_RECEIVE_SIGNAL), %set_softint
-- 
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/


[Resend Patch v4 05/16] smp, m32r: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Signed-off-by: Jiang Liu 
---
 arch/m32r/include/asm/smp.h |1 -
 arch/m32r/kernel/smp.c  |9 +
 arch/m32r/kernel/traps.c|3 +--
 3 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/m32r/include/asm/smp.h b/arch/m32r/include/asm/smp.h
index c689b828dfe2..3a502d4592e9 100644
--- a/arch/m32r/include/asm/smp.h
+++ b/arch/m32r/include/asm/smp.h
@@ -98,7 +98,6 @@ extern void arch_send_call_function_ipi_mask(const struct 
cpumask *mask);
 #define LOCAL_TIMER_IPI(M32R_IRQ_IPI3-M32R_IRQ_IPI0)
 #define INVALIDATE_CACHE_IPI   (M32R_IRQ_IPI4-M32R_IRQ_IPI0)
 #define CPU_BOOT_IPI   (M32R_IRQ_IPI5-M32R_IRQ_IPI0)
-#define CALL_FUNC_SINGLE_IPI   (M32R_IRQ_IPI6-M32R_IRQ_IPI0)
 
 #define IPI_SHIFT  (0)
 #define NR_IPIS(8)
diff --git a/arch/m32r/kernel/smp.c b/arch/m32r/kernel/smp.c
index ce7aea34fdf4..c6d0bb93ad2d 100644
--- a/arch/m32r/kernel/smp.c
+++ b/arch/m32r/kernel/smp.c
@@ -542,7 +542,7 @@ void arch_send_call_function_ipi_mask(const struct cpumask 
*mask)
 
 void arch_send_call_function_single_ipi(int cpu)
 {
-   send_IPI_mask(cpumask_of(cpu), CALL_FUNC_SINGLE_IPI, 0);
+   send_IPI_mask(cpumask_of(cpu), CALL_FUNCTION_IPI, 0);
 }
 
 /*==*
@@ -569,13 +569,6 @@ void smp_call_function_interrupt(void)
irq_exit();
 }
 
-void smp_call_function_single_interrupt(void)
-{
-   irq_enter();
-   generic_smp_call_function_single_interrupt();
-   irq_exit();
-}
-
 /*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*/
 /* Timer Routines*/
 /*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*/
diff --git a/arch/m32r/kernel/traps.c b/arch/m32r/kernel/traps.c
index a7a424f852e4..f5d911dcd763 100644
--- a/arch/m32r/kernel/traps.c
+++ b/arch/m32r/kernel/traps.c
@@ -39,7 +39,6 @@ extern void smp_invalidate_interrupt(void);
 extern void smp_call_function_interrupt(void);
 extern void smp_ipi_timer_interrupt(void);
 extern void smp_flush_cache_all_interrupt(void);
-extern void smp_call_function_single_interrupt(void);
 
 /*
  * for Boot AP function
@@ -104,7 +103,7 @@ static void set_eit_vector_entries(void)
eit_vector[187] = (unsigned long)smp_ipi_timer_interrupt;
eit_vector[188] = (unsigned long)smp_flush_cache_all_interrupt;
eit_vector[189] = 0;/* CPU_BOOT_IPI */
-   eit_vector[190] = (unsigned long)smp_call_function_single_interrupt;
+   eit_vector[190] = 0;
eit_vector[191] = 0;
 #endif
_flush_cache_copyback_all();
-- 
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/


[Resend Patch v4 03/16] smp, ARM64: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Signed-off-by: Jiang Liu 
Acked-by: Will Deacon 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Catalin Marinas 
Cc: Arnd Bergmann 
---
 arch/arm64/include/asm/hardirq.h |2 +-
 arch/arm64/kernel/smp.c  |   10 +-
 2 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/hardirq.h b/arch/arm64/include/asm/hardirq.h
index e8a3268a891c..6aae421f4d73 100644
--- a/arch/arm64/include/asm/hardirq.h
+++ b/arch/arm64/include/asm/hardirq.h
@@ -20,7 +20,7 @@
 #include 
 #include 
 
-#define NR_IPI 6
+#define NR_IPI 5
 
 typedef struct {
unsigned int __softirq_pending;
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 7ae6ee085261..328b8ce4b007 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -65,7 +65,6 @@ struct secondary_data secondary_data;
 enum ipi_msg_type {
IPI_RESCHEDULE,
IPI_CALL_FUNC,
-   IPI_CALL_FUNC_SINGLE,
IPI_CPU_STOP,
IPI_TIMER,
IPI_IRQ_WORK,
@@ -483,7 +482,6 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
 #define S(x,s) [x] = s
S(IPI_RESCHEDULE, "Rescheduling interrupts"),
S(IPI_CALL_FUNC, "Function call interrupts"),
-   S(IPI_CALL_FUNC_SINGLE, "Single function call interrupts"),
S(IPI_CPU_STOP, "CPU stop interrupts"),
S(IPI_TIMER, "Timer broadcast interrupts"),
S(IPI_IRQ_WORK, "IRQ work interrupts"),
@@ -527,7 +525,7 @@ void arch_send_call_function_ipi_mask(const struct cpumask 
*mask)
 
 void arch_send_call_function_single_ipi(int cpu)
 {
-   smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
+   smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC);
 }
 
 #ifdef CONFIG_IRQ_WORK
@@ -585,12 +583,6 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
irq_exit();
break;
 
-   case IPI_CALL_FUNC_SINGLE:
-   irq_enter();
-   generic_smp_call_function_single_interrupt();
-   irq_exit();
-   break;
-
case IPI_CPU_STOP:
irq_enter();
ipi_cpu_stop(cpu);
-- 
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/


[Resend Patch v4 04/16] smp, IA64: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: linux-i...@vger.kernel.org
Signed-off-by: Jiang Liu 
---
 arch/ia64/kernel/smp.c |8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/ia64/kernel/smp.c b/arch/ia64/kernel/smp.c
index 9fcd4e63048f..0532909b6e8e 100644
--- a/arch/ia64/kernel/smp.c
+++ b/arch/ia64/kernel/smp.c
@@ -62,8 +62,7 @@ static DEFINE_PER_CPU_SHARED_ALIGNED(unsigned short [NR_CPUS],
 
 #define IPI_CALL_FUNC  0
 #define IPI_CPU_STOP   1
-#define IPI_CALL_FUNC_SINGLE   2
-#define IPI_KDUMP_CPU_STOP 3
+#define IPI_KDUMP_CPU_STOP 2
 
 /* This needs to be cacheline aligned because it is written to by *other* 
CPUs.  */
 static DEFINE_PER_CPU_SHARED_ALIGNED(unsigned long, ipi_operation);
@@ -116,9 +115,6 @@ handle_IPI (int irq, void *dev_id)
case IPI_CALL_FUNC:
generic_smp_call_function_interrupt();
break;
-   case IPI_CALL_FUNC_SINGLE:
-   generic_smp_call_function_single_interrupt();
-   break;
 #ifdef CONFIG_KEXEC
case IPI_KDUMP_CPU_STOP:
unw_init_running(kdump_cpu_freeze, NULL);
@@ -318,7 +314,7 @@ smp_flush_tlb_mm (struct mm_struct *mm)
 
 void arch_send_call_function_single_ipi(int cpu)
 {
-   send_IPI_single(cpu, IPI_CALL_FUNC_SINGLE);
+   send_IPI_single(cpu, IPI_CALL_FUNC);
 }
 
 void arch_send_call_function_ipi_mask(const struct cpumask *mask)
-- 
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/


[Resend Patch v4 06/16] smp, mn10300: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Rename CALL_FUNC_SINGLE_IPI as CALL_FUNC_IPI to prepare for
killing generic_smp_call_function_single_interrupt().

Cc: Koichi Yasutake 
Cc: linux-am33-l...@redhat.com
Signed-off-by: Jiang Liu 
---
 arch/mn10300/include/asm/smp.h |2 +-
 arch/mn10300/kernel/smp.c  |   16 
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/mn10300/include/asm/smp.h b/arch/mn10300/include/asm/smp.h
index 56c42417d428..8e689d1724bf 100644
--- a/arch/mn10300/include/asm/smp.h
+++ b/arch/mn10300/include/asm/smp.h
@@ -31,7 +31,7 @@
 #include 
 
 #define RESCHEDULE_IPI 63
-#define CALL_FUNC_SINGLE_IPI   192
+#define CALL_FUNC_IPI  192
 #define LOCAL_TIMER_IPI193
 #define FLUSH_CACHE_IPI194
 #define CALL_FUNCTION_NMI_IPI  195
diff --git a/arch/mn10300/kernel/smp.c b/arch/mn10300/kernel/smp.c
index f984193718b1..13aa7ac5a82b 100644
--- a/arch/mn10300/kernel/smp.c
+++ b/arch/mn10300/kernel/smp.c
@@ -164,11 +164,11 @@ static void init_ipi(void)
mn10300_ipi_enable(RESCHEDULE_IPI);
 
/* set up the call function IPI */
-   irq_set_chip_and_handler(CALL_FUNC_SINGLE_IPI, _ipi_type,
+   irq_set_chip_and_handler(CALL_FUNC_IPI, _ipi_type,
 handle_percpu_irq);
-   setup_irq(CALL_FUNC_SINGLE_IPI, _function_ipi);
-   set_intr_level(CALL_FUNC_SINGLE_IPI, CALL_FUNCTION_GxICR_LV);
-   mn10300_ipi_enable(CALL_FUNC_SINGLE_IPI);
+   setup_irq(CALL_FUNC_IPI, _function_ipi);
+   set_intr_level(CALL_FUNC_IPI, CALL_FUNCTION_GxICR_LV);
+   mn10300_ipi_enable(CALL_FUNC_IPI);
 
/* set up the local timer IPI */
 #if !defined(CONFIG_GENERIC_CLOCKEVENTS) || \
@@ -362,7 +362,7 @@ void arch_send_call_function_ipi_mask(const struct cpumask 
*mask)
 
 void arch_send_call_function_single_ipi(int cpu)
 {
-   send_IPI_mask(cpumask_of(cpu), CALL_FUNC_SINGLE_IPI);
+   send_IPI_mask(cpumask_of(cpu), CALL_FUNC_IPI);
 }
 
 /**
@@ -519,7 +519,7 @@ static irqreturn_t smp_reschedule_interrupt(int irq, void 
*dev_id)
 static irqreturn_t smp_call_function_interrupt(int irq, void *dev_id)
 {
/* generic_smp_call_function_interrupt(); */
-   generic_smp_call_function_single_interrupt();
+   generic_smp_call_function_interrupt();
return IRQ_HANDLED;
 }
 
@@ -598,8 +598,8 @@ static void __init smp_cpu_init(void)
/* Force FPU initialization */
clear_using_fpu(current);
 
-   GxICR(CALL_FUNC_SINGLE_IPI) = CALL_FUNCTION_GxICR_LV | GxICR_DETECT;
-   mn10300_ipi_enable(CALL_FUNC_SINGLE_IPI);
+   GxICR(CALL_FUNC_IPI) = CALL_FUNCTION_GxICR_LV | GxICR_DETECT;
+   mn10300_ipi_enable(CALL_FUNC_IPI);
 
GxICR(LOCAL_TIMER_IPI) = LOCAL_TIMER_GxICR_LV | GxICR_DETECT;
mn10300_ipi_enable(LOCAL_TIMER_IPI);
-- 
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/


[Resend Patch v4 02/16] smp, ARM: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Arnd Bergmann 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Russell King 
Signed-off-by: Jiang Liu 
---
 arch/arm/include/asm/hardirq.h |2 +-
 arch/arm/kernel/smp.c  |   10 +-
 2 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index fe3ea776dc34..3d7351c844aa 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-#define NR_IPI 8
+#define NR_IPI 7
 
 typedef struct {
unsigned int __softirq_pending;
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 86ef244c5a24..2bab642eb0b1 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -68,7 +68,6 @@ enum ipi_msg_type {
IPI_TIMER,
IPI_RESCHEDULE,
IPI_CALL_FUNC,
-   IPI_CALL_FUNC_SINGLE,
IPI_CPU_STOP,
IPI_IRQ_WORK,
IPI_COMPLETION,
@@ -452,7 +451,6 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
S(IPI_TIMER, "Timer broadcast interrupts"),
S(IPI_RESCHEDULE, "Rescheduling interrupts"),
S(IPI_CALL_FUNC, "Function call interrupts"),
-   S(IPI_CALL_FUNC_SINGLE, "Single function call interrupts"),
S(IPI_CPU_STOP, "CPU stop interrupts"),
S(IPI_IRQ_WORK, "IRQ work interrupts"),
S(IPI_COMPLETION, "completion interrupts"),
@@ -502,7 +500,7 @@ void arch_send_wakeup_ipi_mask(const struct cpumask *mask)
 
 void arch_send_call_function_single_ipi(int cpu)
 {
-   smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
+   smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC);
 }
 
 #ifdef CONFIG_IRQ_WORK
@@ -597,12 +595,6 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
irq_exit();
break;
 
-   case IPI_CALL_FUNC_SINGLE:
-   irq_enter();
-   generic_smp_call_function_single_interrupt();
-   irq_exit();
-   break;
-
case IPI_CPU_STOP:
irq_enter();
ipi_cpu_stop(cpu);
-- 
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/


[Resend Patch v4 01/16] smp, alpha: Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: linux-al...@vger.kernel.org
Signed-off-by: Jiang Liu 
---
 arch/alpha/kernel/smp.c |8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c
index 99ac36d5de4e..2f24447fef92 100644
--- a/arch/alpha/kernel/smp.c
+++ b/arch/alpha/kernel/smp.c
@@ -63,7 +63,6 @@ static struct {
 enum ipi_message_type {
IPI_RESCHEDULE,
IPI_CALL_FUNC,
-   IPI_CALL_FUNC_SINGLE,
IPI_CPU_STOP,
 };
 
@@ -506,7 +505,6 @@ setup_profiling_timer(unsigned int multiplier)
return -EINVAL;
 }
 
-
 static void
 send_ipi_message(const struct cpumask *to_whom, enum ipi_message_type 
operation)
 {
@@ -552,10 +550,6 @@ handle_ipi(struct pt_regs *regs)
generic_smp_call_function_interrupt();
break;
 
-   case IPI_CALL_FUNC_SINGLE:
-   generic_smp_call_function_single_interrupt();
-   break;
-
case IPI_CPU_STOP:
halt();
 
@@ -606,7 +600,7 @@ void arch_send_call_function_ipi_mask(const struct cpumask 
*mask)
 
 void arch_send_call_function_single_ipi(int cpu)
 {
-   send_ipi_message(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
+   send_ipi_message(cpumask_of(cpu), IPI_CALL_FUNC);
 }
 
 static void
-- 
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/


[Resend Patch v4 00/16] Kill SMP single function call interrupt

2015-01-22 Thread Jiang Liu
This patch set has been hanging around for more than one year since v3.
Resend for collecting more Acks targetting v3.20 merging window.
Patches for ARC, Hexagon, Metag, MIPS and PARISC has been merged.
Gained Acks for Tile, Xen, ARM64 and S390.

Since commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use
logic similar to smp_call_function_single()", single and multiple
(mask version) cross CPU function calls are handled in the same way,
and generic_smp_call_function_interrupt() becomes an aliases of
generic_smp_call_function_single_interrupt(), so only one interrupt
is needed for arch code to support generic SMP function call interfaces.
This patch series simplifies arch code by killing the redundant
interrupt for cross CPU function calls.

We choose to keep generic_smp_call_function_interrupt() instead of
generic_smp_call_function_single_interrupt() because the former is
more generic.

Jiang Liu (16):
  smp, alpha: Kill SMP single function call interrupt
  smp, ARM: Kill SMP single function call interrupt
  smp, ARM64: Kill SMP single function call interrupt
  smp, IA64: Kill SMP single function call interrupt
  smp, m32r: Kill SMP single function call interrupt
  smp, mn10300: Kill SMP single function call interrupt
  smp, mn10300: Enable arch_send_call_function_ipi_mask()
  smp, sh: Kill SMP single function call interrupt
  smp, sparc64: Kill SMP single function call interrupt
  smp, sparc: Kill SMP single function call interrupt
  smp, x86, xen: Kill SMP single function call interrupt
  smp, x86: Kill SMP single function call interrupt
  smp, tile: Kill SMP single function call interrupt
  smp, s390: Kill SMP single function call interrupt
  smp: Cleanup unsued generic_smp_call_function_single_interrupt()
  smp, trivial: Remove unused function prototype from smp_boot.h

 arch/alpha/kernel/smp.c  |8 +--
 arch/arm/include/asm/hardirq.h   |2 +-
 arch/arm/kernel/smp.c|   10 +---
 arch/arm64/include/asm/hardirq.h |2 +-
 arch/arm64/kernel/smp.c  |   10 +---
 arch/ia64/kernel/smp.c   |8 ++-
 arch/m32r/include/asm/smp.h  |1 -
 arch/m32r/kernel/smp.c   |9 +---
 arch/m32r/kernel/traps.c |3 +--
 arch/mn10300/include/asm/smp.h   |2 +-
 arch/mn10300/kernel/smp.c|   19 ---
 arch/s390/kernel/smp.c   |   10 
 arch/sh/include/asm/smp.h|1 -
 arch/sh/kernel/smp.c |5 +---
 arch/sparc/include/asm/pil.h |5 ++--
 arch/sparc/include/asm/smp_32.h  |4 +---
 arch/sparc/kernel/entry.S|   10 ++--
 arch/sparc/kernel/leon_smp.c |   31 ++---
 arch/sparc/kernel/smp_32.c   |   14 ++-
 arch/sparc/kernel/smp_64.c   |   13 +--
 arch/sparc/kernel/sun4d_smp.c|   31 ++---
 arch/sparc/kernel/sun4m_smp.c|   11 ++---
 arch/sparc/kernel/ttable_64.S|   12 --
 arch/sparc/mm/ultra.S|5 
 arch/tile/include/asm/smp.h  |7 +++---
 arch/tile/kernel/smp.c   |6 +
 arch/x86/include/asm/entry_arch.h|1 -
 arch/x86/include/asm/hw_irq.h|3 ---
 arch/x86/include/asm/irq_vectors.h   |7 +++---
 arch/x86/include/asm/trace/irq_vectors.h |6 -
 arch/x86/include/asm/xen/events.h|1 -
 arch/x86/kernel/entry_64.S   |2 --
 arch/x86/kernel/irqinit.c|4 
 arch/x86/kernel/smp.c|   24 +--
 arch/x86/xen/smp.c   |   37 +-
 include/linux/smp.h  |4 +---
 include/linux/smpboot.h  |1 -
 kernel/smp.c |4 ++--
 38 files changed, 65 insertions(+), 268 deletions(-)

-- 
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: [PATCH v2 0/5] Overhaul the audit filename handling

2015-01-22 Thread Al Viro
On Thu, Jan 22, 2015 at 09:40:01PM +, Al Viro wrote:
> On Thu, Jan 22, 2015 at 09:29:03PM +, Al Viro wrote:
> > On Thu, Jan 22, 2015 at 04:25:13PM -0500, Paul Moore wrote:
> > 
> > > Your experimental branch looks good to me, thanks.
> > 
> > Pushed into for-next; I'm probably going to move that stuff into a 
> > never-rebased
> > branch, merged into for-next and safe to pull into your tree if you want to 
> > do
> > something on top of that set.
> 
> OK, vfs.git#getname is it; it's in never-to-be-rebased mode and it's merged
> into vfs.git#for-next (as of right now; HEAD is 9ee4c4).  If you need to do
> something on top of that stuff, pulling vfs.git#getname is safe.

Unfortunately, that thing was -rc2-based, leading to conflict with mainline
in kernel/auditsc.c.  My fault, I hadn't realized that "audit: create private
file name copies when auditing inodes" in audit tree was, in fact, present in
mainline.  vfs.git#getname2 is -rc3-based, same resulting kernel/auditsc.c as
in #getname.  Please, use that.  vfs.git#for-next merges from that one now,
so tomorrow -next should have no problems from vfs.git...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] mm, vmacache: Add kconfig VMACACHE_SHIFT

2015-01-22 Thread WANG Chao
On 01/22/15 at 11:22am, Rik van Riel wrote:
> On 01/22/2015 11:19 AM, Davidlohr Bueso wrote:
> > On Thu, 2015-01-22 at 15:57 +0800, WANG Chao wrote:
> >> Hi, Davidlohr
> >>
> >> On 01/21/15 at 11:46pm, Davidlohr Bueso wrote:
> >>> On Thu, 2015-01-22 at 14:29 +0800, WANG Chao wrote:
>  Add a new kconfig option VMACACHE_SHIFT (as a power of 2) to specify the
>  number of slots vma cache has for each thread. Range is chosen 0-4 (1-16
>  slots) to consider both overhead and performance penalty. Default is 2
>  (4 slots) as it originally is, which provides good enough balance.
> 
> >>>
> >>> Nack. I don't feel comfortable making scalability features of core code
> >>> configurable.
> >>
> >> Out of respect, is this a general rule not making scalability features
> >> of core code configurable?
> > 
> > I doubt its a rule, just common sense. Users have no business
> > configuring such low level details. The optimizations need to
> > transparently work for everyone.
> 
> There may sometimes be a good reason for making this kind of
> thing configurable, but since there were no performance
> numbers in the changelog, I have not seen any such reason for
> this particular change :)

True. I didn't run any kind of benchmark, thus no numbers here. This is
purely hypothetical.

I'm glad to run some tests. For the sake of consistency, could you
please show me a hint how do you measure at the first place? I can do
hit-rate, but I don't know how you measure cpu cycles. Could you
elaborate?

Thanks
WANG Chao
--
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/


mmotm 2015-01-22-15-04: qemu failure due to 'mm: memcontrol: remove unnecessary soft limit tree node test'

2015-01-22 Thread Guenter Roeck
On Thu, Jan 22, 2015 at 03:05:17PM -0800, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2015-01-22-15-04 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
qemu test for ppc64 fails with

Unable to handle kernel paging request for data at address 0xaf50
Faulting instruction address: 0xc089d5d4
Oops: Kernel access of bad area, sig: 11 [#1]

with the following call stack:

Call Trace:
[c0003d32f920] [c089d588] .__slab_alloc.isra.44+0x7c/0x6f4
(unreliable)
[c0003d32fa90] [c020cf8c] .kmem_cache_alloc_node_trace+0x12c/0x3b0
[c0003d32fb60] [c0bceeb4] .mem_cgroup_init+0x128/0x1b0
[c0003d32fbf0] [c000a2b4] .do_one_initcall+0xd4/0x260
[c0003d32fce0] [c0ba26a8] .kernel_init_freeable+0x244/0x32c
[c0003d32fdb0] [c000ac24] .kernel_init+0x24/0x140
[c0003d32fe30] [c0009564] .ret_from_kernel_thread+0x58/0x74

bisect log:

# bad: [03586ad04b2170ee816e6936981cc7cd2aeba129] pci: test for unexpectedly 
disabled bridges
# good: [ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc] Linux 3.19-rc5
git bisect start 'HEAD' 'v3.19-rc5'
# bad: [d113ba21d15c7d3615fd88490d1197615bb39fc0] mm: remove lock validation 
check for MADV_FREE
git bisect bad d113ba21d15c7d3615fd88490d1197615bb39fc0
# good: [17351d1625a5030fa16f1346b77064c03b51f107] mm:add KPF_ZERO_PAGE flag 
for /proc/kpageflags
git bisect good 17351d1625a5030fa16f1346b77064c03b51f107
# good: [ad18ad1fce6f241a9cbd4adfd6b16c9283181e39] memcg: add BUILD_BUG_ON() 
for string tables
git bisect good ad18ad1fce6f241a9cbd4adfd6b16c9283181e39
# bad: [aa7e7cbfa43b74f6faef04ff730b5098544a4f77] mm/compaction: enhance 
tracepoint output for compaction begin/end
git bisect bad aa7e7cbfa43b74f6faef04ff730b5098544a4f77
# bad: [a40d0d2cf21e2714e9a6c842085148c938bf36ab] mm: memcontrol: remove 
unnecessary soft limit tree node test
git bisect bad a40d0d2cf21e2714e9a6c842085148c938bf36ab
# good: [e987aa804213c2d0c7f583639d868c7629ae479e] oom: add helpers for setting 
and clearing TIF_MEMDIE
git bisect good e987aa804213c2d0c7f583639d868c7629ae479e
# good: [af52cb6dc98bd833d4d15fe8eafc4a3e1f17951d] sysrq: convert printk to 
pr_* equivalent
git bisect good af52cb6dc98bd833d4d15fe8eafc4a3e1f17951d
# good: [61e257724ea22eb85488e7209f594106ca57258a] mm: cma: fix totalcma_pages 
to include DT defined CMA regions
git bisect good 61e257724ea22eb85488e7209f594106ca57258a
# first bad commit: [a40d0d2cf21e2714e9a6c842085148c938bf36ab] mm: memcontrol: 
remove unnecessary soft limit tree node test

If there is anything I can do to help debugging, please let me know.

Guenter
--
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/6] Add new MFD driver for MAX77843

2015-01-22 Thread Jaewon Kim
This patch series adds MAX77843(Multi Function Device) driver.
The MAX77843 includes MUIC(Micro USB Interface Circuit), Li+ Charger
with Fuel Gauge and 2 safeout LDOs for USB device.
It is interfaced to host controller using I2C.

Beomho Seo (2):
  power: max77843_charger: Add Max77843 charger device driver
  power: max77843_battery: Add Max77843 fuel gauge device driver

Jaewon Kim (4):
  mfd: max77843: Add max77843 MFD driver core driver
  extcon: max77843: Add max77843 MUIC driver
  regulator: max77843: Add max77843 regulator driver
  Documentation: Add device tree bindings document for max77843

 Documentation/devicetree/bindings/mfd/max77843.txt |   87 ++
 drivers/extcon/Kconfig |   10 +
 drivers/extcon/Makefile|1 +
 drivers/extcon/extcon-max77843.c   |  871 
 drivers/mfd/Kconfig|   14 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/max77843.c |  241 ++
 drivers/power/Kconfig  |   16 +
 drivers/power/Makefile |2 +
 drivers/power/max77843_battery.c   |  283 +++
 drivers/power/max77843_charger.c   |  506 
 drivers/regulator/Kconfig  |8 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/max77843.c   |  259 ++
 include/linux/mfd/max77843-private.h   |  410 +
 15 files changed, 2710 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/max77843.txt
 create mode 100644 drivers/extcon/extcon-max77843.c
 create mode 100644 drivers/mfd/max77843.c
 create mode 100644 drivers/power/max77843_battery.c
 create mode 100644 drivers/power/max77843_charger.c
 create mode 100644 drivers/regulator/max77843.c
 create mode 100644 include/linux/mfd/max77843-private.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 5/6] regulator: max77843: Add max77843 regulator driver

2015-01-22 Thread Jaewon Kim
This patch adds new regulator driver to support max77843
MFD(Multi Function Device) chip`s regulators.
The Max77843 has two voltage regulators for USB safeout.

Cc: Mark Brown 
Signed-off-by: Beomho Seo 
Signed-off-by: Jaewon Kim 
---
 drivers/regulator/Kconfig|8 ++
 drivers/regulator/Makefile   |1 +
 drivers/regulator/max77843.c |  259 ++
 3 files changed, 268 insertions(+)
 create mode 100644 drivers/regulator/max77843.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c3a60b5..c1f9c33 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -414,6 +414,14 @@ config REGULATOR_MAX77802
  Exynos5420/Exynos5800 SoCs to control various voltages.
  It includes support for control of voltage and ramp speed.
 
+config REGULATOR_MAX77843
+   tristate "Maxim 77843 regulator"
+   depends on MFD_MAX77843
+   help
+ This driver controls a Maxim 77843 regulator.
+ The regulator include two 'SAFEOUT' for USB(Universal Serial Bus)
+ This is suitable for Exynos5433 SoC chips.
+
 config REGULATOR_MC13XXX_CORE
tristate
 
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 1f28ebf..12408d6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_REGULATOR_MAX8998) += max8998.o
 obj-$(CONFIG_REGULATOR_MAX77686) += max77686.o
 obj-$(CONFIG_REGULATOR_MAX77693) += max77693.o
 obj-$(CONFIG_REGULATOR_MAX77802) += max77802.o
+obj-$(CONFIG_REGULATOR_MAX77843) += max77843.o
 obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
 obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
 obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
diff --git a/drivers/regulator/max77843.c b/drivers/regulator/max77843.c
new file mode 100644
index 000..86afc7a
--- /dev/null
+++ b/drivers/regulator/max77843.c
@@ -0,0 +1,259 @@
+/*
+ * max77843.c - Regulator driver for the Maxim MAX77843
+ *
+ * Copyright (C) 2014 Samsung Electrnoics
+ * Author: Jaewon Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX77843_SUPPORTED_VOLTAGE_NUM 4
+
+enum max77843_regulator_type {
+   MAX77843_SAFEOUT1 = 0,
+   MAX77843_SAFEOUT2,
+   MAX77843_CHARGER,
+
+   MAX77843_NUM,
+};
+
+static const unsigned int max77843_regulator_table[] = {
+   485,
+   490,
+   495,
+   330,
+};
+
+static int max77843_reg_is_enabled(struct regulator_dev *rdev)
+{
+   struct regmap *regmap = rdev->regmap;
+   int ret;
+   unsigned int reg;
+
+   ret = regmap_read(regmap, rdev->desc->enable_reg, );
+   if (ret) {
+   dev_err(>dev, "Fialed to read charger register\n");
+   return ret;
+   }
+
+   return (reg & rdev->desc->enable_mask) == rdev->desc->enable_mask;
+}
+
+static int max77843_reg_get_current_limit(struct regulator_dev *rdev)
+{
+   struct regmap *regmap = rdev->regmap;
+   unsigned int chg_min_uA = rdev->constraints->min_uA;
+   unsigned int chg_max_uA = rdev->constraints->max_uA;
+   unsigned int val;
+   int ret;
+   unsigned int reg, sel;
+
+   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_02, );
+   if (ret) {
+   dev_err(>dev, "Failed to read charger register\n");
+   return ret;
+   }
+
+   sel = reg & MAX77843_CHG_FAST_CHG_CURRENT_MASK;
+
+   if (sel < 0x03)
+   sel = 0;
+   else
+   sel -= 2;
+
+   val = chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel;
+   if (val > chg_max_uA)
+   return -EINVAL;
+
+   return val;
+}
+
+static int max77843_reg_set_current_limit(struct regulator_dev *rdev,
+   int min_uA, int max_uA)
+{
+   struct regmap *regmap = rdev->regmap;
+   unsigned int chg_min_uA = rdev->constraints->min_uA;
+   int sel = 0;
+
+   while (chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel < min_uA)
+   sel++;
+
+   if (chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel > max_uA)
+   return -EINVAL;
+
+   sel += 2;
+
+   return regmap_write(regmap, MAX77843_CHG_REG_CHG_CNFG_02, sel);
+}
+
+static struct regulator_ops max77843_charger_ops = {
+   .is_enabled = max77843_reg_is_enabled,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .get_current_limit  = max77843_reg_get_current_limit,
+   .set_current_limit  = max77843_reg_set_current_limit,
+};
+
+static struct regulator_ops max77843_regulator_ops = {
+   .is_enabled

[PATCH 1/6] mfd: max77843: Add max77843 MFD driver core driver

2015-01-22 Thread Jaewon Kim
This patch adds MAX77843 core/irq driver to support PMIC,
MUIC(Micro USB Interface Controller), Charger, Fuel Gauge,
LED and Haptic device.

Cc: Lee Jones 
Signed-off-by: Beomho Seo 
Signed-off-by: Jaewon Kim 
---
 drivers/mfd/Kconfig  |   14 ++
 drivers/mfd/Makefile |1 +
 drivers/mfd/max77843.c   |  241 
 include/linux/mfd/max77843-private.h |  410 ++
 4 files changed, 666 insertions(+)
 create mode 100644 drivers/mfd/max77843.c
 create mode 100644 include/linux/mfd/max77843-private.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b731..0c67c79 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -442,6 +442,20 @@ config MFD_MAX77693
  additional drivers must be enabled in order to use the functionality
  of the device.
 
+config MFD_MAX77843
+   bool "Maxim Semiconductor MAX77843 PMIC Support"
+   depends on I2C=y
+   select MFD_CORE
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   help
+ Say yes here to add support for Maxim Semiconductor MAX77843.
+ This is companion Power Management IC with LEDs, Haptic, Charger,
+ Fuel Gauge, MUIC(Micro USB Interface Controller) controls on chip.
+ This driver provides common support for accessing the device;
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
 config MFD_MAX8907
tristate "Maxim Semiconductor MAX8907 PMIC Support"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..fe4f75c 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9063)+= da9063.o
 obj-$(CONFIG_MFD_MAX14577) += max14577.o
 obj-$(CONFIG_MFD_MAX77686) += max77686.o
 obj-$(CONFIG_MFD_MAX77693) += max77693.o
+obj-$(CONFIG_MFD_MAX77843) += max77843.o
 obj-$(CONFIG_MFD_MAX8907)  += max8907.o
 max8925-objs   := max8925-core.o max8925-i2c.o
 obj-$(CONFIG_MFD_MAX8925)  += max8925.o
diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
new file mode 100644
index 000..d7f8b76
--- /dev/null
+++ b/drivers/mfd/max77843.c
@@ -0,0 +1,241 @@
+/*
+ * max77843.c - MFD core driver for the Maxim MAX77843
+ *
+ * Copyright (C) 2014 Samsung Electrnoics
+ * Author: Jaewon Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct mfd_cell max77843_devs[] = {
+   {
+   .name = "max77843-muic",
+   .of_compatible = "maxim,max77843-muic",
+   }, {
+   .name = "max77843-regulator",
+   .of_compatible = "maxim,max77843-regulator",
+   }, {
+   .name = "max77843-charger",
+   .of_compatible = "maxim,max77843-charger"
+   }, {
+   .name = "max77843-fuelgauge",
+   .of_compatible = "maxim,max77843-fuelgauge",
+   },
+};
+
+static const struct regmap_config max77843_charger_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .max_register   = MAX77843_CHG_REG_END,
+};
+
+static const struct regmap_config max77843_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .max_register   = MAX77843_SYS_REG_END,
+};
+
+static const struct regmap_irq max77843_irqs[] = {
+   /* TOPSYS interrupts */
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSUVLO_INT, },
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSOVLO_INT, },
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TSHDN_INT, },
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TM_INT, },
+};
+
+static const struct regmap_irq_chip max77843_irq_chip = {
+   .name   = "max77843",
+   .status_base= MAX77843_SYS_REG_SYSINTSRC,
+   .mask_base  = MAX77843_SYS_REG_SYSINTMASK,
+   .mask_invert= false,
+   .num_regs   = 1,
+   .irqs   = max77843_irqs,
+   .num_irqs   = ARRAY_SIZE(max77843_irqs),
+};
+
+static int max77843_chg_init(struct max77843 *max77843)
+{
+   int ret;
+
+   max77843->i2c_chg = i2c_new_dummy(max77843->i2c->adapter, I2C_ADDR_CHG);
+   if (!max77843->i2c_chg) {
+   dev_err(>i2c->dev,
+   "Cannot allocate I2C device for Charger\n");
+   return PTR_ERR(max77843->i2c_chg);
+   }
+   i2c_set_clientdata(max77843->i2c_chg, max77843);
+
+   max77843->regmap_chg = devm_regmap_init_i2c(max77843->i2c_chg,
+   _charger_regmap_config);
+   if (IS_ERR(max77843->regmap_chg)) {
+   ret = 

mmotm 2015-01-22-15-04: qemu failures due to 'mm: account pmd page tables to the process'

2015-01-22 Thread Guenter Roeck
On Thu, Jan 22, 2015 at 03:05:17PM -0800, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2015-01-22-15-04 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
qemu:sh fails to shut down.

bisect log:

# bad: [03586ad04b2170ee816e6936981cc7cd2aeba129] pci: test for unexpectedly 
disabled bridges
# good: [ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc] Linux 3.19-rc5
git bisect start 'HEAD' 'v3.19-rc5'
# bad: [d113ba21d15c7d3615fd88490d1197615bb39fc0] mm: remove lock validation 
check for MADV_FREE
git bisect bad d113ba21d15c7d3615fd88490d1197615bb39fc0
# good: [17351d1625a5030fa16f1346b77064c03b51f107] mm:add KPF_ZERO_PAGE flag 
for /proc/kpageflags
git bisect good 17351d1625a5030fa16f1346b77064c03b51f107
# good: [ad18ad1fce6f241a9cbd4adfd6b16c9283181e39] memcg: add BUILD_BUG_ON() 
for string tables
git bisect good ad18ad1fce6f241a9cbd4adfd6b16c9283181e39
# bad: [aa7e7cbfa43b74f6faef04ff730b5098544a4f77] mm/compaction: enhance 
tracepoint output for compaction begin/end
git bisect bad aa7e7cbfa43b74f6faef04ff730b5098544a4f77
# good: [a40d0d2cf21e2714e9a6c842085148c938bf36ab] mm: memcontrol: remove 
unnecessary soft limit tree node test
git bisect good a40d0d2cf21e2714e9a6c842085148c938bf36ab
# good: [4ec4aa2e07c1d6eee61f6cace29401c6febcb6c5] mm: make FIRST_USER_ADDRESS 
unsigned long on all archs
git bisect good 4ec4aa2e07c1d6eee61f6cace29401c6febcb6c5
# bad: [22310c209483224a64436a6e815a86feda681659] mm: account pmd page tables 
to the process
git bisect bad 22310c209483224a64436a6e815a86feda681659
# good: [19a41261b1dcd8d12372d9c57c2035144608a599] arm: define 
__PAGETABLE_PMD_FOLDED for !LPAE
git bisect good 19a41261b1dcd8d12372d9c57c2035144608a599
# first bad commit: [22310c209483224a64436a6e815a86feda681659] mm: account pmd 
page tables to the process

---

qemu:microblaze generates warnings to the console.

WARNING: CPU: 0 PID: 32 at mm/mmap.c:2858 exit_mmap+0x184/0x1a4()

with various call stacks. See
http://server.roeck-us.net:8010/builders/qemu-microblaze-mmotm/builds/15/steps/qemubuildcommand/logs/stdio
for details.

bisect log:

# bad: [03586ad04b2170ee816e6936981cc7cd2aeba129] pci: test for unexpectedly 
disabled bridges
# good: [ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc] Linux 3.19-rc5
git bisect start 'HEAD' 'v3.19-rc5'
# bad: [d113ba21d15c7d3615fd88490d1197615bb39fc0] mm: remove lock validation 
check for MADV_FREE
git bisect bad d113ba21d15c7d3615fd88490d1197615bb39fc0
# good: [17351d1625a5030fa16f1346b77064c03b51f107] mm:add KPF_ZERO_PAGE flag 
for /proc/kpageflags
git bisect good 17351d1625a5030fa16f1346b77064c03b51f107
# good: [ad18ad1fce6f241a9cbd4adfd6b16c9283181e39] memcg: add BUILD_BUG_ON() 
for string tables
git bisect good ad18ad1fce6f241a9cbd4adfd6b16c9283181e39
# bad: [aa7e7cbfa43b74f6faef04ff730b5098544a4f77] mm/compaction: enhance 
tracepoint output for compaction begin/end
git bisect bad aa7e7cbfa43b74f6faef04ff730b5098544a4f77
# good: [a40d0d2cf21e2714e9a6c842085148c938bf36ab] mm: memcontrol: remove 
unnecessary soft limit tree node test
git bisect good a40d0d2cf21e2714e9a6c842085148c938bf36ab
# good: [4ec4aa2e07c1d6eee61f6cace29401c6febcb6c5] mm: make FIRST_USER_ADDRESS 
unsigned long on all archs
git bisect good 4ec4aa2e07c1d6eee61f6cace29401c6febcb6c5
# bad: [22310c209483224a64436a6e815a86feda681659] mm: account pmd page tables 
to the process
git bisect bad 22310c209483224a64436a6e815a86feda681659
# good: [19a41261b1dcd8d12372d9c57c2035144608a599] arm: define 
__PAGETABLE_PMD_FOLDED for !LPAE
git bisect good 19a41261b1dcd8d12372d9c57c2035144608a599
# first bad commit: [22310c209483224a64436a6e815a86feda681659] mm: account pmd 
page tables to the process

If there is anything I can do to help debugging, please let me know.

Guenter
--
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/6] power: max77843_battery: Add Max77843 fuel gauge device driver

2015-01-22 Thread Jaewon Kim
From: Beomho Seo 

This patch adds device driver of max77843 fuel gauge.
The driver support for battery fuel gauge in Maxim Max77843.
It is fuel-gauge systems for lithuum-ion batteries in handled and
portable devices.

Cc: Sebastian Reichel 
Signed-off-by: Beomho Seo 
---
 drivers/power/Kconfig|9 ++
 drivers/power/Makefile   |1 +
 drivers/power/max77843_battery.c |  283 ++
 3 files changed, 293 insertions(+)
 create mode 100644 drivers/power/max77843_battery.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index a054a28..0039bbb 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -212,6 +212,15 @@ config BATTERY_MAX17042
  with MAX17042. This driver also supports max17047/50 chips which are
  improved version of max17042.
 
+config BATTERY_MAX77843
+   tristate "Maxim MAX77843 Fuel Gauge"
+   depends on MFD_MAX77843
+   help
+ This add support for battery fuel gauge in Maxim MAX77843. It is
+ fuel-gauge systems for lithuum-ion (Li+) batteries in handled and
+ portable devices. The MAX17040 is configured to operate with a single
+ lithium cell.
+
 config BATTERY_Z2
tristate "Z2 battery driver"
depends on I2C && MACH_ZIPIT2
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 212c6a2..ae0d795 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_BATTERY_DA9030)  += da9030_battery.o
 obj-$(CONFIG_BATTERY_DA9052)   += da9052-battery.o
 obj-$(CONFIG_BATTERY_MAX17040) += max17040_battery.o
 obj-$(CONFIG_BATTERY_MAX17042) += max17042_battery.o
+obj-$(CONFIG_BATTERY_MAX77843) += max77843_battery.o
 obj-$(CONFIG_BATTERY_Z2)   += z2_battery.o
 obj-$(CONFIG_BATTERY_S3C_ADC)  += s3c_adc_battery.o
 obj-$(CONFIG_BATTERY_TWL4030_MADC) += twl4030_madc_battery.o
diff --git a/drivers/power/max77843_battery.c b/drivers/power/max77843_battery.c
new file mode 100644
index 000..a08dd0c
--- /dev/null
+++ b/drivers/power/max77843_battery.c
@@ -0,0 +1,283 @@
+/*
+ * Fuel gauge driver for Maxim MAX77843
+ *
+ * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
+ * Author: Beomho Seo 
+ *
+ * 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 bythe Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct max77843_battery {
+   struct device   *dev;
+   struct max77843 *max77843;
+   struct i2c_client   *client;
+   struct regmap   *regmap;
+   struct power_supply psy;
+};
+
+static int max77843_battery_get_capacity(struct max77843_battery *battery)
+{
+   struct regmap *regmap = battery->regmap;
+   int ret, val;
+   u8 reg_data[2];
+
+   ret = regmap_bulk_read(regmap, MAX77843_FG_REG_SOCREP, reg_data, 2);
+   if (ret) {
+   dev_err(battery->dev, "Failed to read fuelgauge register\n");
+   return ret;
+   }
+
+   val =  ((reg_data[1] * 100) + (reg_data[0] * 100 / 256)) / 100;
+
+   return val;
+}
+
+static int max77843_battery_get_energy_prop(struct max77843_battery *battery,
+   enum power_supply_property psp)
+{
+   struct regmap *regmap = battery->regmap;
+   unsigned int reg;
+   int ret, val;
+   u8 reg_data[2];
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_ENERGY_FULL:
+   reg = MAX77843_FG_REG_FULLCAP;
+   break;
+   case POWER_SUPPLY_PROP_ENERGY_NOW:
+   reg = MAX77843_FG_REG_REMCAP_REP;
+   break;
+   case POWER_SUPPLY_PROP_ENERGY_AVG:
+   reg = MAX77843_FG_REG_REMCAP_AV;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = regmap_bulk_read(regmap, reg, reg_data, 2);
+   if (ret) {
+   dev_err(battery->dev, "Failed to read fuelgauge register\n");
+   return ret;
+   }
+
+   val = (reg_data[1] << 8) | reg_data[0];
+
+   return val;
+}
+
+static int max77843_battery_get_current_prop(struct max77843_battery *battery,
+   enum power_supply_property psp)
+{
+   struct regmap *regmap = battery->regmap;
+   unsigned int reg;
+   int ret, val;
+   u8 reg_data[2];
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_CURRENT_NOW:
+   reg = MAX77843_FG_REG_CURRENT;
+   break;
+   case POWER_SUPPLY_PROP_CURRENT_AVG:
+   reg = MAX77843_FG_REG_AVG_CURRENT;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = regmap_bulk_read(regmap, reg, reg_data, 2);
+   if (ret) {
+   dev_err(battery->dev, "Failed to read fuelgauge register\n");
+   return ret;
+   }
+
+   val = (reg_data[1] << 8) | reg_data[0];
+   if (val & 0x8000) {
+ 

[alsa-devel] [PATCH v4 0/3] Sound support for Exynos4412 Trats2 board

2015-01-22 Thread Inha Song
This patch-set adds basic sound support for the Trats2 boards.
It just support primary I2s and external speaker playback.

Changes in v4:
  - Move to clock out parent settings in exynos4412-trats2.dts
  - Remove unnecessary lines in Trats2 machine driver.
  - Change name of dai stream to more cleary.
  - Add MFD_WM8994 to select in machine driver kconfig.

Changes in v3:
  - Set clock out parent to XUSBXTI in pmu_system_controller DT node.

Changes in v2:
  - Remove unnecessary lines in Trats2 machine driver.
  - move clock enable/disable to .startup / .shutdown.
  - Fix code style issues.
  - Remove mclk DT property in Trats2 sound and add MCLK1 property in WM1811 
node.
(MCLK1 is optional property in WM8994 node - refer: 
Document/devicetree/bindings/sound/wm8994.txt)
  - Use mclk that defined in WM1811 DT node.
  - Add "samsung,audio-codec" property to required properties.

Inha Song (3):
  ASoC: samsung: Add machine driver for Trats2
  ASoC: samsung: Document Trats2 audio subsystem bindings
  ARM: dts: Add sound nodes for exynos4412-trats2

 .../bindings/sound/samsung,trats2-wm1811.txt   |  25 +++
 arch/arm/boot/dts/exynos4412-trats2.dts|  42 
 sound/soc/samsung/Kconfig  |   9 +
 sound/soc/samsung/Makefile |   2 +
 sound/soc/samsung/trats2_wm1811.c  | 211 +
 5 files changed, 289 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt
 create mode 100644 sound/soc/samsung/trats2_wm1811.c

-- 
2.0.0.390.gcb682f8

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


[alsa-devel] [PATCH v4 1/3] ASoC: samsung: Add machine driver for Trats2

2015-01-22 Thread Inha Song
This patch add the sound machine driver for Trats2 board.
The codec operate in master mode.

Signed-off-by: Inha Song 
---
 sound/soc/samsung/Kconfig |   9 ++
 sound/soc/samsung/Makefile|   2 +
 sound/soc/samsung/trats2_wm1811.c | 211 ++
 3 files changed, 222 insertions(+)
 create mode 100644 sound/soc/samsung/trats2_wm1811.c

diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index fc67f97..df6734d 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -245,3 +245,12 @@ config SND_SOC_ARNDALE_RT5631_ALC5631
 depends on SND_SOC_SAMSUNG
 select SND_SAMSUNG_I2S
 select SND_SOC_RT5631
+
+config SND_SOC_SAMSUNG_TRATS2_WM1811
+   tristate "SoC I2S Audio support for WM1811 on Tizen Trats2 board"
+   depends on SND_SOC_SAMSUNG
+   select SND_SAMSUNG_I2S
+   select MFD_WM8994
+   select SND_SOC_WM8994
+   help
+ Say Y if you want to add support for SoC audio on the Tizen Trats2 
board.
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index 31e3dba..e2b7b1b 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -46,6 +46,7 @@ snd-soc-littlemill-objs := littlemill.o
 snd-soc-bells-objs := bells.o
 snd-soc-odroidx2-max98090-objs := odroidx2_max98090.o
 snd-soc-arndale-rt5631-objs := arndale_rt5631.o
+snd-soc-trats2-wm1811-objs := trats2_wm1811.o
 
 obj-$(CONFIG_SND_SOC_SAMSUNG_JIVE_WM8750) += snd-soc-jive-wm8750.o
 obj-$(CONFIG_SND_SOC_SAMSUNG_NEO1973_WM8753) += snd-soc-neo1973-wm8753.o
@@ -73,3 +74,4 @@ obj-$(CONFIG_SND_SOC_LITTLEMILL) += snd-soc-littlemill.o
 obj-$(CONFIG_SND_SOC_BELLS) += snd-soc-bells.o
 obj-$(CONFIG_SND_SOC_ODROIDX2) += snd-soc-odroidx2-max98090.o
 obj-$(CONFIG_SND_SOC_ARNDALE_RT5631_ALC5631) += snd-soc-arndale-rt5631.o
+obj-$(CONFIG_SND_SOC_SAMSUNG_TRATS2_WM1811) += snd-soc-trats2-wm1811.o
diff --git a/sound/soc/samsung/trats2_wm1811.c 
b/sound/soc/samsung/trats2_wm1811.c
new file mode 100644
index 000..e87ea1f
--- /dev/null
+++ b/sound/soc/samsung/trats2_wm1811.c
@@ -0,0 +1,211 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "i2s.h"
+#include "../codecs/wm8994.h"
+
+struct trats2_machine_priv {
+   struct clk *clk_mclk;
+};
+
+static struct trats2_machine_priv trats2_wm1811_priv;
+
+static const struct snd_kcontrol_new trats2_controls[] = {
+   SOC_DAPM_PIN_SWITCH("SPK"),
+};
+
+static const struct snd_soc_dapm_widget trats2_dapm_widgets[] = {
+   SND_SOC_DAPM_SPK("SPK", NULL),
+};
+
+static int trats2_aif1_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *codec_dai = rtd->codec_dai;
+   struct trats2_machine_priv *priv = snd_soc_card_get_drvdata(rtd->card);
+   unsigned int sysclk_rate;
+   unsigned int mclk_rate =
+   (unsigned int)clk_get_rate(priv->clk_mclk);
+   int ret;
+
+   /* SYSCLK must be greater than 4.096MHz */
+   if (params_rate(params) == 8000 || params_rate(params) == 11025)
+   sysclk_rate = params_rate(params) * 512;
+   else
+   sysclk_rate = params_rate(params) * 256;
+
+   /* Set the codec FLL1 */
+   ret = snd_soc_dai_set_pll(codec_dai, WM8994_FLL1, WM8994_FLL_SRC_MCLK1,
+ mclk_rate, sysclk_rate);
+   if (ret < 0) {
+   dev_err(codec_dai->dev, "Failed to set FLL1: %d\n", ret);
+   return ret;
+   }
+
+   /* Set the codec SYSCLK */
+   ret = snd_soc_dai_set_sysclk(codec_dai, WM8994_SYSCLK_FLL1,
+sysclk_rate, SND_SOC_CLOCK_IN);
+   if (ret < 0) {
+   dev_err(codec_dai->dev, "Failed to set SYSCLK: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int trats2_aif1_startup(struct snd_pcm_substream *substream)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct trats2_machine_priv *priv = snd_soc_card_get_drvdata(rtd->card);
+   int ret;
+
+   ret = clk_prepare_enable(priv->clk_mclk);
+   if (ret) {
+   dev_err(rtd->card->dev, "Failed to enable mclk: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void trats2_aif1_shutdown(struct snd_pcm_substream *substream)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct trats2_machine_priv *priv = snd_soc_card_get_drvdata(rtd->card);
+
+   clk_disable_unprepare(priv->clk_mclk);

[alsa-devel] [PATCH v4 3/3] ARM: dts: Add sound nodes for exynos4412-trats2

2015-01-22 Thread Inha Song
This patch add WM1811 audio codec, I2S interface and the sound
machine nodes to enable audio on exynos4412-trats2 board.

Signed-off-by: Inha Song 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 42 +
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b4..6205b98 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -203,6 +203,25 @@
};
};
 
+   i2c@138A {
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-slave-addr = <0x10>;
+   samsung,i2c-max-bus-freq = <10>;
+   pinctrl-0 = <_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   wm1811: wm1811@1a {
+   compatible = "wlf,wm1811";
+   reg = <0x1a>;
+   clocks = <_system_controller 0>;
+   clock-names = "MCLK1";
+   DCVDD-supply = <_reg>;
+   DBVDD1-supply = <_reg>;
+   wlf,ldo1ena = < 4 0>;
+   };
+   };
+
i2c@138D {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -838,6 +857,24 @@
};
};
 
+   i2s0: i2s@0383 {
+   pinctrl-0 = <_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+   };
+
+   sound {
+   compatible = "samsung,trats2-audio";
+   samsung,i2s-controller = <>;
+   samsung,model = "Trats2";
+   samsung,audio-codec = <>;
+   samsung,audio-routing =
+   "SPK", "SPKOUTLN",
+   "SPK", "SPKOUTLP",
+   "SPK", "SPKOUTRN",
+   "SPK", "SPKOUTRP";
+   };
+
exynos-usbphy@125B {
status = "okay";
};
@@ -865,6 +902,11 @@
};
 };
 
+_system_controller {
+   assigned-clocks = <_system_controller 0>;
+   assigned-clock-parents =  < CLK_XUSBXTI>;
+};
+
 _0 {
pinctrl-names = "default";
pinctrl-0 = <>;
-- 
2.0.0.390.gcb682f8

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


[alsa-devel] [PATCH v4 2/3] ASoC: samsung: Document Trats2 audio subsystem bindings

2015-01-22 Thread Inha Song
This patch add Trats2 audio subsystem bindings document.

Signed-off-by: Inha Song 
---
 .../bindings/sound/samsung,trats2-wm1811.txt   | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt

diff --git a/Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt 
b/Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt
new file mode 100644
index 000..319ff07
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/samsung,trats2-wm1811.txt
@@ -0,0 +1,25 @@
+Samsung Exynos Trats2 audio with WM1811 codec
+
+Required properties:
+
+ - compatible : Must be "samsung,trats2-audio"
+ - samsung,i2s-controller : The phandle of the I2S controller
+ - samsung,model : The user visible name of this sound
+ - samsung,audio-codec : The phandle of the WM1811 audio codec
+ - samsung,audio-routing : A list of the connections between audio
+   components. each entry is a pair of strings, the first being the
+   connection's sink, the second being the connection's source
+
+Example:
+
+sound {
+   compatible = "samsung,trats2-audio";
+   samsung,i2s-controller = <>;
+   samsung,model = "Trats2";
+   samsung,audio-codec = <>;
+   samsung,audio-routing =
+   "SPK", "SPKOUTLN",
+   "SPK", "SPKOUTLP",
+   "SPK", "SPKOUTRN",
+   "SPK", "SPKOUTRP";
+};
-- 
2.0.0.390.gcb682f8

--
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/6] Documentation: Add device tree bindings document for max77843

2015-01-22 Thread Jaewon Kim
Add document describing device tree bindings for max77843 MFD.
Drivers: MFD core, regulator, extcon, charger and fuelgauge.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Lee Jones 
Cc: Chanwoo Choi 
Cc: Sebastian Reichel 
Cc: Mark Brown 
Signed-off-by: Beomho Seo 
Signed-off-by: Jaewon Kim 
---
 Documentation/devicetree/bindings/mfd/max77843.txt |   87 
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/max77843.txt

diff --git a/Documentation/devicetree/bindings/mfd/max77843.txt 
b/Documentation/devicetree/bindings/mfd/max77843.txt
new file mode 100644
index 000..6895604
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77843.txt
@@ -0,0 +1,87 @@
+Maxim MAX77843 multi-function device
+
+MAX77843 is a Multi-Function Device with the following submodules:
+- PMIC   : 2 SAFEOUT LDOs for USB device
+- CHARGER : Li+ battery charger with Fuel Gauge
+- MUIC   : Micro USB Interface Circuit
+- HAPTIC  : motor control driver for haptics
+- LED: 4 channel RGBW LED
+
+It is interfaced to host controller using I2C.
+
+Required properties:
+- compatible : Must be "maxim,max77843".
+- reg : I2C slave address of PMIC block.
+- interrupts : I2C line for main SoCs.
+- interrupt-parent : The parent of interrupt controller.
+
+Optional properties:
+- regulators : The regulators of max77843 have to be instantiated under subnode
+   named "regulators" using the following format.
+
+   [*]refer : Documentation/devicetree/bindings/regulator/regulator.txt
+
+   regulators {
+   SAFEOUT {
+   regulator-name = "SAFEOUT";
+   };
+   }
+
+   List of valid regulator names:
+   - SAFEOUT1, SAFEOUT2, CHARGER.
+
+- max77843-muic : This properties used by extcon consumers.
+   Required properties:
+   - compatible : Must be "maxim,max77842-muic".
+
+- max77843-charger : There battery charger of MAX77843 have to be instantiated
+   under sub-node named "max77843-charger" using the following format.
+   Required properties:
+   - compatible : Must be "maxim,max77842-charger".
+   - maxim,fast-charge-uamp : Fast charge current levels are
+   100 mA to 3150 mA programmed by I2C per 100 mA.
+   - maxim,top-off-uamp : Top off current threshold levels are
+   125 mA to 650 mA programmed by I2C per 75 mA.
+   - maxim,input-uamp-limit : Input current limit levels are
+   100 mA to 3533 mA programmed by I2C per 33 mA.
+- max77843-fuelgauge : There fuelgauge of MAX77843 have to be instantiated
+   under sub-node named "max77843-fuelgauge" using the following format.
+   Required properties:
+   - compatible : Must be "maxim,max77842-fuelgauge".
+
+Example:
+   max77843@66 {
+   compatible = "samsung,max77843";
+   reg = <0x66>;
+   interrupt-parent = <>;
+   interrupts = <5 2>;
+
+   regulators {
+   SAFEOUT1 {
+   regulator-name = "SAFEOUT1";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <495>;
+   };
+   SAFEOUT2 {
+   regulator-name = "SAFEOUT2";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <495>;
+   };
+   };
+
+   max77843-muic {
+   compatible = "maxim,max77843-muic";
+   };
+
+   max77843-charger {
+   compatible = "maxim,max77843-charger";
+   maxim,fast-charge-uamp = <45>;
+   maxim,top-off-uamp = <125000>;
+   maxim,input-uamp-limit = <50>;
+   };
+
+   max77843-fuelgauge {
+   compatible = "maxim,max77843-fuelgauge";
+   };
+
+   };
-- 
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 3/6] power: max77843_charger: Add Max77843 charger device driver

2015-01-22 Thread Jaewon Kim
From: Beomho Seo 

This patch adds device driver of max77843 charger. This driver provide
initialize each charging mode(e.g. fast charge, top-off mode and constant
charging mode so on.). Additionally, control charging paramters to use
i2c interface.

Cc: Sebastian Reichel 
Signed-off-by: Beomho Seo 
---
 drivers/power/Kconfig|7 +
 drivers/power/Makefile   |1 +
 drivers/power/max77843_charger.c |  506 ++
 3 files changed, 514 insertions(+)
 create mode 100644 drivers/power/max77843_charger.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 0108c2a..a054a28 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -332,6 +332,13 @@ config CHARGER_MAX14577
  Say Y to enable support for the battery charger control sysfs and
  platform data of MAX14577/77836 MUICs.
 
+config CHARGER_MAX77843
+   tristate "Maxim MAX77843 battery charger driver"
+   depends on MFD_MAX77843
+   help
+ Say Y to enable support for the battery charger control sysfs and
+ platform data of MAX77843
+
 config CHARGER_MAX8997
tristate "Maxim MAX8997/MAX8966 PMIC battery charger driver"
depends on MFD_MAX8997 && REGULATOR_MAX8997
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index dfa8942..212c6a2 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_CHARGER_LP8788)  += lp8788-charger.o
 obj-$(CONFIG_CHARGER_GPIO) += gpio-charger.o
 obj-$(CONFIG_CHARGER_MANAGER)  += charger-manager.o
 obj-$(CONFIG_CHARGER_MAX14577) += max14577_charger.o
+obj-$(CONFIG_CHARGER_MAX77843) += max77843_charger.o
 obj-$(CONFIG_CHARGER_MAX8997)  += max8997_charger.o
 obj-$(CONFIG_CHARGER_MAX8998)  += max8998_charger.o
 obj-$(CONFIG_CHARGER_BQ2415X)  += bq2415x_charger.o
diff --git a/drivers/power/max77843_charger.c b/drivers/power/max77843_charger.c
new file mode 100644
index 000..317b2cc
--- /dev/null
+++ b/drivers/power/max77843_charger.c
@@ -0,0 +1,506 @@
+/*
+ * Charger driver for Maxim MAX77843
+ *
+ * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
+ * Author: Beomho Seo 
+ *
+ * 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 bythe Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct max77843_charger_info {
+   u32 fast_charge_uamp;
+   u32 top_off_uamp;
+   u32 input_uamp_limit;
+};
+
+struct max77843_charger {
+   struct device   *dev;
+   struct max77843 *max77843;
+   struct i2c_client   *client;
+   struct regmap   *regmap;
+   struct power_supply psy;
+
+   struct max77843_charger_info*info;
+};
+
+static int max77843_charger_get_max_current(struct max77843_charger *charger)
+{
+   struct regmap *regmap = charger->regmap;
+   int ret, val = 0;
+   unsigned int reg_data;
+
+   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_09, _data);
+   if (ret) {
+   dev_err(charger->dev, "Failed to read charger register\n");
+   return ret;
+   }
+
+   if (reg_data <= 0x03) {
+   val = MAX77843_CHG_INPUT_CURRENT_LIMIT_MIN;
+   } else if (reg_data >= 0x78) {
+   val = MAX77843_CHG_INPUT_CURRENT_LIMIT_MAX;
+   } else {
+   val = reg_data / 3;
+   if (reg_data % 3 == 0)
+   val *= 10;
+   else if (reg_data % 3 == 1)
+   val = val * 10 + 33000;
+   else
+   val = val * 10 + 67000;
+   }
+
+   return val;
+}
+
+static int max77843_charger_get_now_current(struct max77843_charger *charger)
+{
+   struct regmap *regmap = charger->regmap;
+   int ret, val = 0;
+   unsigned int reg_data;
+
+   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_02, _data);
+   if (ret) {
+   dev_err(charger->dev, "Failed to read charger register\n");
+   return ret;
+   }
+
+   reg_data &= MAX77843_CHG_FAST_CHG_CURRENT_MASK;
+
+   if (reg_data <= 0x02)
+   val = MAX77843_CHG_FAST_CHG_CURRENT_MIN;
+   else if (reg_data >= 0x3f)
+   val = MAX77843_CHG_FAST_CHG_CURRENT_MAX;
+   else
+   val = reg_data * MAX77843_CHG_FAST_CHG_CURRENT_STEP;
+
+   return val;
+}
+
+static int max77843_charger_get_online(struct max77843_charger *charger)
+{
+   struct regmap *regmap = charger->regmap;
+   int ret, val = 0;
+   unsigned int reg_data;
+
+   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_INT_OK, _data);
+   if (ret) {
+   dev_err(charger->dev, "Failed to read charger register\n");
+   return ret;
+   }
+
+   if (reg_data & MAX77843_CHG_CHGIN_OK)
+   val = true;
+   else
+   

[PATCH 2/6] extcon: max77843: Add max77843 MUIC driver

2015-01-22 Thread Jaewon Kim
This patch adds MAX77843 extcon driver to support for MUIC(Micro
USB Interface Controller) device by using EXTCON subsystem to handle
various external connectors.

Cc: Chanwoo Choi 
Signed-off-by: Jaewon Kim 
---
 drivers/extcon/Kconfig   |   10 +
 drivers/extcon/Makefile  |1 +
 drivers/extcon/extcon-max77843.c |  871 ++
 3 files changed, 882 insertions(+)
 create mode 100644 drivers/extcon/extcon-max77843.c

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..0b67538 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -55,6 +55,16 @@ config EXTCON_MAX77693
  Maxim MAX77693 PMIC. The MAX77693 MUIC is a USB port accessory
  detector and switch.
 
+config EXTCON_MAX77843
+   tristate "MAX77843 EXTCON Support"
+   depends on MFD_MAX77843
+   select IRQ_DOMAIN
+   select REGMAP_I2C
+   help
+ If you say yes here you get support for the MUIC device of
+ Maxim MAX77843. The MAX77843 MUIC is a USB port accessory
+ detector add switch.
+
 config EXTCON_MAX8997
tristate "MAX8997 EXTCON Support"
depends on MFD_MAX8997 && IRQ_DOMAIN
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..f21d5c4 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-arizona.o
 obj-$(CONFIG_EXTCON_GPIO)  += extcon-gpio.o
 obj-$(CONFIG_EXTCON_MAX14577)  += extcon-max14577.o
 obj-$(CONFIG_EXTCON_MAX77693)  += extcon-max77693.o
+obj-$(CONFIG_EXTCON_MAX77843)  += extcon-max77843.o
 obj-$(CONFIG_EXTCON_MAX8997)   += extcon-max8997.o
 obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
 obj-$(CONFIG_EXTCON_RT8973A)   += extcon-rt8973a.o
diff --git a/drivers/extcon/extcon-max77843.c b/drivers/extcon/extcon-max77843.c
new file mode 100644
index 000..caae9a7
--- /dev/null
+++ b/drivers/extcon/extcon-max77843.c
@@ -0,0 +1,871 @@
+/*
+ * extcon-max77843.c - MAX77843 extcon driver to support MUIC
+ *
+ * Copyright (C) 2014 Samsung Electrnoics
+ *  Author: Jaewon Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DELAY_MS_DEFAULT   15000   /* unit: millisecond */
+
+enum max77843_muic_acc_type {
+   MAX77843_MUIC_ADC_GROUND = 0,
+   MAX77843_MUIC_ADC_SEND_END_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S1_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S2_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S3_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S4_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S5_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S6_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S7_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S8_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S9_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S10_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S11_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S12_BUTTON,
+   MAX77843_MUIC_ADC_RESERVED_ACC_1,
+   MAX77843_MUIC_ADC_RESERVED_ACC_2,
+   MAX77843_MUIC_ADC_RESERVED_ACC_3,
+   MAX77843_MUIC_ADC_RESERVED_ACC_4,
+   MAX77843_MUIC_ADC_RESERVED_ACC_5,
+   MAX77843_MUIC_ADC_AUDIO_DEVICE_TYPE2,
+   MAX77843_MUIC_ADC_PHONE_POWERED_DEV,
+   MAX77843_MUIC_ADC_TTY_CONVERTER,
+   MAX77843_MUIC_ADC_UART_CABLE,
+   MAX77843_MUIC_ADC_CEA936A_TYPE1_CHG,
+   MAX77843_MUIC_ADC_FACTORY_MODE_USB_OFF,
+   MAX77843_MUIC_ADC_FACTORY_MODE_USB_ON,
+   MAX77843_MUIC_ADC_AV_CABLE_NOLOAD,
+   MAX77843_MUIC_ADC_CEA936A_TYPE2_CHG,
+   MAX77843_MUIC_ADC_FACTORY_MODE_UART_OFF,
+   MAX77843_MUIC_ADC_FACTORY_MODE_UART_ON,
+   MAX77843_MUIC_ADC_AUDIO_DEVICE_TYPE1,
+   MAX77843_MUIC_ADC_OPEN,
+};
+
+enum max77843_muic_cable_group {
+   MAX77843_CABLE_GROUP_ADC = 0,
+   MAX77843_CABLE_GROUP_CHG,
+   MAX77843_CABLE_GROUP_GND,
+};
+
+enum max77843_muic_adv_debounce_time {
+   MAX77843_DEBOUNCE_TIME_5MS = 0,
+   MAX77843_DEBOUNCE_TIME_10MS,
+   MAX77843_DEBOUNCE_TIME_25MS,
+   MAX77843_DEBOUNCE_TIME_38_62MS,
+};
+
+enum max77843_muic_support_list {
+   EXTCON_CABLE_USB = 0,
+   EXTCON_CABLE_USB_HOST,
+   EXTCON_CABLE_USB_HOST_TA,
+   EXTCON_CABLE_TA,
+   EXTCON_CABLE_FAST_CHARGER,
+   EXTCON_CABLE_SLOW_CHARGER,
+   EXTCON_CABLE_CHARGE_DOWNSTREAM,
+   EXTCON_CABLE_MHL,
+   EXTCON_CABLE_MHL_TA,
+   EXTCON_CABLE_JIG_USB_ON,
+   EXTCON_CABLE_JIG_USB_OFF,
+   EXTCON_CABLE_JIG_UART_OFF,
+   EXTCON_CABLE_JIG_UART_ON,
+
+   EXTCON_CABLE_NUM,
+};
+
+enum max77843_muic_gnd_cable {
+   MAX77843_MUIC_GND_USB_OTG   = 0x0,
+   MAX77843_MUIC_GND_USB_OTG_VB= 0x1,
+   MAX77843_MUIC_GND_MHL   = 

Re: cpuidle/powernv: Read target_residency value of idle states from DT if available

2015-01-22 Thread Michael Ellerman
On Tue, 2015-20-01 at 11:26:49 UTC, Preeti U Murthy wrote:
> @@ -177,34 +178,39 @@ static int powernv_add_idle_states(void)
>   return nr_idle_states;
>   }
>  
> - idle_state_latency = of_get_property(power_mgt,
> - "ibm,cpu-idle-state-latencies-ns", NULL);
> - if (!idle_state_latency) {
> + dt_idle_states = len_flags / sizeof(u32);
> +
> + latency_ns = kzalloc(sizeof(*latency_ns) * dt_idle_states, GFP_KERNEL);
> + rc = of_property_read_u32(power_mgt,
> + "ibm,cpu-idle-state-latencies-ns", latency_ns);

That's only reading the first value.

If you want to read the full property you need the _array version.

> + if (rc) {
>   pr_warn("DT-PowerMgmt: missing 
> ibm,cpu-idle-state-latencies-ns\n");

You missed my hint that "DT-PowerMgmt" is a weird and ugly prefix. Can you use
"cpuidle-powernv:" instead?

>  
> - dt_idle_states = len_flags / sizeof(u32);
> + residency_ns = kzalloc(sizeof(*residency_ns) * dt_idle_states, 
> GFP_KERNEL);
> + rc = of_property_read_u32(power_mgt,
> + "ibm,cpu-idle-state-residency-ns", residency_ns);
> + if (rc) {
> + pr_warn("DT-PowerMgmt: missing 
> ibm,cpu-idle-state-residency-ns\n");
> + pr_warn("Falling back to default values\n");

I don't think this is worth a warning seeing as we know there are firmwares out
there which do not have the property.

>   for (i = 0; i < dt_idle_states; i++) {
>  
>   flags = be32_to_cpu(idle_state_flags[i]);
> -
> - /* Cpuidle accepts exit_latency in us and we estimate
> -  * target residency to be 10x exit_latency
> + /*
> +  * Cpuidle accepts exit_latency and target_residency in us.
> +  * Use default target_residency values if f/w does not expose 
> it.
>*/
> - latency_ns = be32_to_cpu(idle_state_latency[i]);
>   if (flags & OPAL_PM_NAP_ENABLED) {
>   /* Add NAP state */
>   strcpy(powernv_states[nr_idle_states].name, "Nap");
>   strcpy(powernv_states[nr_idle_states].desc, "Nap");
>   powernv_states[nr_idle_states].flags = 0;
> - powernv_states[nr_idle_states].exit_latency =
> - ((unsigned int)latency_ns) / 1000;
> - powernv_states[nr_idle_states].target_residency =
> - ((unsigned int)latency_ns / 100);
> + powernv_states[nr_idle_states].target_residency = 100;
>   powernv_states[nr_idle_states].enter = _loop;
> - nr_idle_states++;

That looks wrong? Or do you mean to do that?

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 RESEND] char:ipmi: Free ipmi_recv_msg messages from the linked list,recv_msgs for the function,ipmi_release in the file,ipmi_devintf.c

2015-01-22 Thread Sasha Levin
On 01/22/2015 08:05 AM, Corey Minyard wrote:
> Patch is queued for 3.20.  Thanks.

That patch is horribly broken.


Thanks,
Sasha

> -corey
> 
> On 01/19/2015 09:14 PM, Nicholas Krause wrote:
>> This adds a loop through the elements in the linked list, recv_msgs using
>> list_for_entry_safe in order to free messages in this list.  In addition
>> we are using the safe version of this marco in order to prevent use after
>> bugs related to deleting the element we are on currently by holding a
>> pointer to the next element after the current one we are on and freeing
>> with the function, ipmi_free_recv_msg internally in this loop.
>>
>> Signed-off-by: Nicholas Krause 
>> ---
>>  drivers/char/ipmi/ipmi_devintf.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/char/ipmi/ipmi_devintf.c 
>> b/drivers/char/ipmi/ipmi_devintf.c
>> index ec318bf..d2af38a 100644
>> --- a/drivers/char/ipmi/ipmi_devintf.c
>> +++ b/drivers/char/ipmi/ipmi_devintf.c
>> @@ -157,14 +157,15 @@ static int ipmi_release(struct inode *inode, struct 
>> file *file)
>>  {
>>  struct ipmi_file_private *priv = file->private_data;
>>  int  rv;
>> +struct  ipmi_recv_msg *msg, *next;
>>  
>>  rv = ipmi_destroy_user(priv->user);
>>  if (rv)
>>  return rv;
>>  
>> -/* FIXME - free the messages in the list. */
>> -kfree(priv);
>> -
>> +list_for_each_entry_safe(msg, next, >recv_msgs, link) {
>> +ipmi_free_recv_msg(msg);
>> +}
>>  return 0;
>>  }
>>  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
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] sched-rt: Reduce excessive task push rate by not pushing tasks with equal priority as the current task

2015-01-22 Thread Steven Rostedt
On Fri, 23 Jan 2015 05:29:30 +0100
Mike Galbraith  wrote:

> On Thu, 2015-01-22 at 10:53 -0800, Tim Chen wrote: 
> > Commit 3be209a8 tries to migrate task of equal priority as the
> > running one to other cpus to balance load and eliminate any idle
> > cpus.  However, for system that is fully busy and running workload
> > of a few priorities, we found this change to cause tasks getting
> > pushed around without improving cpu utilization. On a fully loaded
> > system running a well known OLTP benchmark, it causes 70% more run
> > queue locking in the push task path without improving cpu
> > utilization and make throughput degrade by 1.5%. We observe much
> > higher rq lock contention due to excessive lockings of target run
> > queues on task wakeup.
> 
> Pushing tasks of equal priority is about getting rt tasks to a CPU
> they can utilize NOW.  Trying to improve throughput and whatnot is
> all well and good, but sacrificing the most sacred rt cow on the
> planet to improve some benchmark number is a very bad idea :)
> 

What Mike said.

With RT tasks the #1 importance is running as soon as they should run.
Throughput is #2. We never sacrifice #1 to improve #2.

Non RT tasks have much better throughput algorithms than RT tasks. But
they are much less likely to react to an event consistently as an RT
task will.

Never give a task an RT priority if your main objective is to have it
"run faster". If you do, you have no clue about what RT is used for.

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


Re: [PATCH RESEND] char:ipmi: Free ipmi_recv_msg messages from the linked list,recv_msgs for the function,ipmi_release in the file,ipmi_devintf.c

2015-01-22 Thread Sasha Levin
On 01/22/2015 08:05 AM, Corey Minyard wrote:
> Patch is queued for 3.20.  Thanks.

That patch is horribly broken.


Thanks,
Sasha

> -corey
> 
> On 01/19/2015 09:14 PM, Nicholas Krause wrote:
>> This adds a loop through the elements in the linked list, recv_msgs using
>> list_for_entry_safe in order to free messages in this list.  In addition
>> we are using the safe version of this marco in order to prevent use after
>> bugs related to deleting the element we are on currently by holding a
>> pointer to the next element after the current one we are on and freeing
>> with the function, ipmi_free_recv_msg internally in this loop.
>>
>> Signed-off-by: Nicholas Krause 
>> ---
>>  drivers/char/ipmi/ipmi_devintf.c | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/char/ipmi/ipmi_devintf.c 
>> b/drivers/char/ipmi/ipmi_devintf.c
>> index ec318bf..d2af38a 100644
>> --- a/drivers/char/ipmi/ipmi_devintf.c
>> +++ b/drivers/char/ipmi/ipmi_devintf.c
>> @@ -157,14 +157,15 @@ static int ipmi_release(struct inode *inode, struct 
>> file *file)
>>  {
>>  struct ipmi_file_private *priv = file->private_data;
>>  int  rv;
>> +struct  ipmi_recv_msg *msg, *next;
>>  
>>  rv = ipmi_destroy_user(priv->user);
>>  if (rv)
>>  return rv;
>>  
>> -/* FIXME - free the messages in the list. */
>> -kfree(priv);
>> -
>> +list_for_each_entry_safe(msg, next, >recv_msgs, link) {
>> +ipmi_free_recv_msg(msg);
>> +}
>>  return 0;
>>  }
>>  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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


Re: [LKP] [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel

2015-01-22 Thread Rusty Russell
Kees Cook  writes:
> On Sun, Jan 4, 2015 at 8:28 PM, Rusty Russell  wrote:
>> Oded Gabbay  writes:
>>> On 12/24/2014 01:01 AM, Rusty Russell wrote:
 Oded Gabbay  writes:
> I didn't say it doesn't always work.
> The actual thing that doesn't work is the define symbol_get and only in a
> specific case of 32bit kernel AND CONFIG_MODULES is unset AND
> CONFIG_RANDOMIZE_BASE is set.
> The define in that case is:
> #define symbol_get(x) ({ extern typeof(x) x __attribute__((weak)); &(x); 
> })
>
> Why it doesn't work (doesn't return NULL when symbol doesn't exists) ?

 Hmm, I'd guess CONFIG_RANDOMIZE_BASE is relocating NULL symbols...

 No, I can't reproduce this.  Please send your .config privately.

 Here's my test case:

 diff --git a/init/main.c b/init/main.c
 index 61b993767db5..a3ee1ec97ec3 100644
 --- a/init/main.c
 +++ b/init/main.c
 @@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)

  ftrace_init();

 +{
 +extern void nonexistent_fn(void);
 +printk("symbol_get(nonexistent_fn) = %p\n",
 +   symbol_get(nonexistent_fn));
 +}
 +
  /* Do the rest non-__init'ed, we're now alive */
  rest_init();
   }

 Thanks,
 Rusty.

>>> Hi Rusty,
>>>
>>> Attached is the bad config file. (config-bad)
>>> I have narrowed the changes you need to do to the config file in order to
>>> reproduce this bug.
>>> The base assumption is a 32-bit kernel and without modules support. Rest of 
>>> the
>>> config file is pretty standard, IMO.
>>> Then, its not enough to enable CONFIG_RANDOMIZE_BASE like I wrote in my 
>>> original
>>> post. You need also to unset CONFIG_HIBERNATION.
>>
>> Indeed, thanks; your config breaks as reported.  With CONFIG_HIBERNATION
>> the kernel offset is 0, so we don't see this.
>>
>> Kees, as far as I can tell you need another 0-terminated vmlinux.relocs
>> section for weak symbols.  These should not be relocated if already 0.
>>
>> Put this somewhere to test.  It fails for x86_64, too:
>>
>> diff --git a/init/main.c b/init/main.c
>> index 61b993767db5..c9e0195c792a 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
>>
>> ftrace_init();
>>
>> +   {
>> +   extern void __attribute__((weak)) nonexistent_fn(void);
>> +   printk("nonexistent_fn = %p\n", nonexistent_fn);
>> +   BUG_ON(nonexistent_fn != NULL);
>> +   }
>> +
>> /* Do the rest non-__init'ed, we're now alive */
>> rest_init();
>>  }
>
> Hm, I can't reproduce this on v3.19-rc4. My nonexistent_fn comes back
> NULL regardless of CONFIG and kaslr on/off states I've tried. Could
> this be a (yet another) linker bug? What was the toolchain used? I
> built with gcc 4.8.2 and binutils 2.24.

$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.24.90.20141014
...
$ gcc --version
gcc (Ubuntu 4.9.1-16ubuntu6) 4.9.1

I tested with gcc 4.8.3 as well, same fail.

I'll send you the config I used separately.

Cheers,
Rusty.



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


  1   2   3   4   5   6   7   8   9   10   >