Re: [PATCH 21/24] irqchip: mips-gic: Support local interrupts

[Qais Yousef]

On 09/17/2014 06:40 PM, Andrew Bresticker wrote:

On Wed, Sep 17, 2014 at 2:50 AM, Qais Yousef  wrote:

On 09/16/2014 12:51 AM, Andrew Bresticker wrote:

The MIPS GIC supports 7 local interrupts, 2 of which are the GIC
local watchdog and count/compare timer.  The remainder are CPU
interrupts which may optionally be re-routed through the GIC.
GIC hardware IRQs 0-6 are now used for local interrupts while
hardware IRQs 7+ are used for external (shared) interrupts.

Note that the 5 CPU interrupts may not be re-routable through
the GIC.  In that case mapping will fail and the vectors reported
in C0_IntCtl should be used instead.  gic_get_c0_compare_int() and
gic_get_c0_perfcount_int() will return the correct IRQ number to
use for the C0 timer and perfcounter interrupts based on the
routability of those interrupts through the GIC.

Malta, SEAD-3, and the GIC clockevent driver have been updated
to use local interrupts and the R4K clockevent driver has been
updated to poll for C0 timer interrupts through the GIC when
the GIC is present.

Signed-off-by: Andrew Bresticker 
diff --git a/arch/mips/include/asm/mips-boards/maltaint.h
b/arch/mips/include/asm/mips-boards/maltaint.h
index bdd6f39..38b06a0 100644
--- a/arch/mips/include/asm/mips-boards/maltaint.h
+++ b/arch/mips/include/asm/mips-boards/maltaint.h
@@ -10,6 +10,8 @@
   #ifndef _MIPS_MALTAINT_H
   #define _MIPS_MALTAINT_H
   +#include 
+


nit: I think gic.h should be split to driver/irqchip/irq-mips-gic.h for
private definitions and include/linux/irqchip/irq-mips-gic.h for
exported/public definitions.

Yup, I was planning on doing this in the next series :).  Malta and
the clockevent/clocksource driver need to get cleaned up first though,
so that they don't have to use the private register definitions.


diff --git a/drivers/irqchip/irq-mips-gic.c
b/drivers/irqchip/irq-mips-gic.c
index 6682a4e..3abe310 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -95,12 +96,39 @@ cycle_t gic_read_compare(void)
   }
   #endif
   +static bool gic_local_irq_is_routable(int intr)
+{
+   u32 vpe_ctl;
+
+   /* All local interrupts are routable in EIC mode. */
+   if (cpu_has_veic)
+   return true;
+
+   GICREAD(GIC_REG(VPE_LOCAL, GIC_VPE_CTL), vpe_ctl);
+   switch (intr) {
+   case GIC_LOCAL_INT_TIMER:
+   return vpe_ctl & GIC_VPE_CTL_TIMER_RTBL_MSK;
+   case GIC_LOCAL_INT_PERFCTR:
+   return vpe_ctl & GIC_VPE_CTL_PERFCNT_RTBL_MSK;
+   case GIC_LOCAL_INT_FDC:
+   return vpe_ctl & GIC_VPE_CTL_FDC_RTBL_MSK;
+   case GIC_LOCAL_INT_SWINT0:
+   case GIC_LOCAL_INT_SWINT1:
+   /*
+* SWINT{0,1} are not routable in non-EIC mode, regardless
+* of the setting of SWINT_ROUTABLE.
+*/
+   return false;


Hmm AFAIK they are routable. Actually from hard reset they're automatically
routed to vpe0 pin 0 which caught me a number of times when trying to use
software interrupt on hardware that has GIC. When setting software interrupt
I was seeing pin 0 going high too and thought it's a hardware bug for a
while.

Interesting, the interAptiv User's Manual I have, in section 9.4.7.1,
says: "Note that Software Interrupts from the VPE are routed
internally by the CPU in vectored interrupt mode, and are only routed
through the GIC when the GIC is in EIC mode, regardless of the
GIC_VPEi_CTL register."  IIRC, there's a similar statement in the
proAptiv manual as well.  I didn't play with the SWINT bits myself, so
I wouldn't be surprised if that's wrong :).


I think all local interrupts should be masked at GIC initialisation except
for timer interrupt. I was preparing a set of patches for GIC but you beat
me into it :)

If SWINT gets routed both through the GIC and directly to the CPU,
then that's probably the best thing to do.  I suspect we'll also want
to leave the performance counter interrupt unmasked too, since,
unfortunately, both the HW perf event driver and oprofile do not use
the percpu IRQ API.


Yeah probably. I haven't played much with the perf counters to be honest.


@@ -341,12 +342,54 @@ static struct irq_chip gic_edge_irq_controller = {
   #endif
   };
   +static unsigned int gic_get_local_int(void)
+{
+   unsigned long pending, masked;
+
+   GICREAD(GIC_REG(VPE_LOCAL, GIC_VPE_PEND), pending);
+   GICREAD(GIC_REG(VPE_LOCAL, GIC_VPE_MASK), masked);
+
+   bitmap_and(&pending, &pending, &masked, GIC_NUM_LOCAL_INTRS);
+
+   return find_first_bit(&pending, GIC_NUM_LOCAL_INTRS);
+}
+
+static void gic_mask_local_irq(struct irq_data *d)
+{
+   int intr = GIC_HWIRQ_TO_LOCAL(d->hwirq);
+
+   GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_RMASK), 1 << intr);
+}
+
+static void gic_unmask_local_irq(struct irq_data *d)
+{
+   int intr = GIC_HWIRQ_TO_LOCAL(d->hwirq);
+
+   GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_SMASK), 1 << intr);
+}
+
+static struct irq_chip gic_local_irq_controller = {
+  

Re: [PATCH 2/2] ARM: dts: Add rtc_src clk for s3c-rtc on exynos5250-snow

[Javier Martinez Canillas]

Hello Doug, Andreas,

On 09/17/2014 05:47 PM, Doug Anderson wrote:
>>
>> rtc@101E {
>> status = "okay";
>> +   clocks = <&clock CLK_RTC>, <&max77686 MAX77686_CLK_AP>;
>> +   clock-names = "rtc", "rtc_src";
> 
> Wait, seriously?  Snow is still using the "rtc@101E" syntax?
> Whatever happened to the series that Andreas worked so hard on,
> including ?
>

Andreas, I completely forgot about your series when writing this patch even
though I've on my TO-DO to sync the downstream and upstream Snow DTS once your
patches land. Sorry about that.

> 
> In any case, there's nothing wrong with Javier's patch other than the
> fact that it will eventually need to get merged with Andreas's, so:
> 
> Reviewed-by: Doug Anderson 
> 

Thanks, I'll re-spin and post again once Kukjin merges Andreas series.

Best regards,
Javier
--
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] mfd: rtsx: fix PM suspend for 5227 & 5249

[micky_ching]

From: Micky Ching 

Fix rts5227&5249 failed send buffer cmd after suspend,
PM_CTRL3 should reset before send any buffer cmd after suspend.
Otherwise, buffer cmd will failed, this will lead resume fail.

Signed-off-by: Micky Ching 
---
 drivers/mfd/Makefile |2 +-
 drivers/mfd/rts5227.c|6 ++
 drivers/mfd/rts5249.c|4 
 drivers/mfd/rtsx_gops.c  |   36 
 drivers/mfd/rtsx_pcr.h   |3 +++
 include/linux/mfd/rtsx_pci.h |   12 
 6 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mfd/rtsx_gops.c

diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f001487..7f45c06 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
 obj-$(CONFIG_MFD_CROS_EC_I2C)  += cros_ec_i2c.o
 obj-$(CONFIG_MFD_CROS_EC_SPI)  += cros_ec_spi.o
 
-rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
rts5227.o rts5249.o
+rtsx_pci-objs  := rtsx_pcr.o rtsx_gops.o rts5209.o rts5229.o 
rtl8411.o rts5227.o rts5249.o
 obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
 obj-$(CONFIG_MFD_RTSX_USB) += rtsx_usb.o
 
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 9c8eec8..3240740 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -130,6 +130,12 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
 
 static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
 {
+   int err;
+
+   err = rtsx_gops_pm_reset(pcr);
+   if (err < 0)
+   return err;
+
/* Optimize RX sensitivity */
return rtsx_pci_write_phy_register(pcr, 0x00, 0xBA42);
 }
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 573de7b..cf425cc 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -130,6 +130,10 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
 {
int err;
 
+   err = rtsx_gops_pm_reset(pcr);
+   if (err < 0)
+   return err;
+
err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
diff --git a/drivers/mfd/rtsx_gops.c b/drivers/mfd/rtsx_gops.c
new file mode 100644
index 000..3cf596f
--- /dev/null
+++ b/drivers/mfd/rtsx_gops.c
@@ -0,0 +1,36 @@
+/* Driver for Realtek PCI-Express card reader
+ *
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * 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, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ * Author:
+ *   Micky Ching 
+ */
+
+#include 
+#include "rtsx_pcr.h"
+
+int rtsx_gops_pm_reset(struct rtsx_pcr *pcr)
+{
+   int err;
+
+   /* init aspm */
+   err = rtsx_pci_update_cfg_byte(pcr, LCTLR, 0xFC, 0);
+   if (err < 0)
+   return err;
+
+   /* reset PM_CTRL3 before send buffer cmd */
+   return rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x00);
+}
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 07e4c2e..fe2bbb6 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -72,4 +72,7 @@ do {  
\
pcr->ms_pull_ctl_disable_tbl = __device##_ms_pull_ctl_disable_tbl; \
 } while (0)
 
+/* generic operations */
+int rtsx_gops_pm_reset(struct rtsx_pcr *pcr);
+
 #endif
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..b34fec8 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -967,4 +967,16 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr 
*pcr)
return (u8 *)(pcr->host_cmds_ptr);
 }
 
+static inline int rtsx_pci_update_cfg_byte(struct rtsx_pcr *pcr, int addr,
+   u8 mask, u8 append)
+{
+   int err;
+   u8 val;
+
+   err = pci_read_config_byte(pcr->pci, addr, &val);
+   if (err < 0)
+   return err;
+   return pci_write_config_byte(pcr->pci, addr, (val & mask) | append);
+}
+
 #endif
-- 
1.7.9.5

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

RE: [PATCH Resend] arm:extend the reserved mrmory for initrd to be page aligned

[Wang, Yalin]

This patch extends the start and end address of initrd to be page aligned,
so that we can free all memory including the un-page aligned head or tail
page of initrd, if the start or end address of initrd are not page
aligned, the page can't be freed by free_initrd_mem() function.

Signed-off-by: Yalin Wang 
---
 arch/arm/mm/init.c   | 5 +
 arch/arm64/mm/init.c | 8 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 659c75d..9221645 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -636,6 +636,11 @@ static int keep_initrd;
 void free_initrd_mem(unsigned long start, unsigned long end)
 {
if (!keep_initrd) {
+   if (start == initrd_start)
+   start = round_down(start, PAGE_SIZE);
+   if (end == initrd_end)
+   end = round_up(end, PAGE_SIZE);
+
poison_init_mem((void *)start, PAGE_ALIGN(end) - start);
free_reserved_area((void *)start, (void *)end, -1, "initrd");
}
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5472c24..c5512f6 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -334,8 +334,14 @@ static int keep_initrd;
 
 void free_initrd_mem(unsigned long start, unsigned long end)
 {
-   if (!keep_initrd)
+   if (!keep_initrd) {
+   if (start == initrd_start)
+   start = round_down(start, PAGE_SIZE);
+   if (end == initrd_end)
+   end = round_up(end, PAGE_SIZE);
+
free_reserved_area((void *)start, (void *)end, 0, "initrd");
+   }
 }
 
 static int __init keepinitrd_setup(char *__unused)
-- 
2.1.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/

linux-next: Tree for Sep 18

[Stephen Rothwell]

Hi all,

Changes since 20140917:

The net tree lost its build failure.

The fsl tree gained a build failure so I used the version from
next-20140917.

The v4l-dvb tree still had its build failure so I used the version from
next-20140908.

The kvm-arm tree gained a conflict against the kvm tree.

The rd-docs tree lost its build failure.

Non-merge commits (relative to Linus' tree): 5629
 5074 files changed, 189602 insertions(+), 118493 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 225 trees (counting Linus' and 32 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 (8ba4caf1ee15 Revert "init: make rootdelay=N consistent 
with rootwait behaviour")
Merging fixes/master (23cf8d3ca0fd powerpc: Fix "attempt to move .org 
backwards" error)
Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1)
Merging arc-current/for-curr (55d65081ef2a ARC: [nsimosci] Allow "headless" 
models to boot)
Merging arm-current/fixes (505013bc9065 ARM: 8149/1: perf: Don't sleep while 
atomic when enabling per-cpu interrupts)
Merging m68k-current/for-linus (4ed7800987b1 m68k: Wire up memfd_create)
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 (396a34340cdf powerpc: Fix endianness of 
flash_block_list in rtas_flash)
Merging powerpc-merge-mpe/for-linus (7d59deb50aaf powerpc: Wire up 
sys_seccomp(), sys_getrandom() and sys_memfd_create())
Merging sparc/master (c21c4ab0d692 sparc64: Move request_irq() from ldc_bind() 
to ldc_alloc())
Merging net/master (6a38792ca8a5 scsi: use 'depends' instead of 'select' for 
SCSI_FC_ATTRS)
Merging ipsec/master (95cd6f488d16 scsi: fix build errors, SCSI_FC_ATTRS needs 
to depend on SCSI && NET)
Merging sound-current/for-linus (779608521976 Merge tag 'asoc-v3.17-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (f554e7136cdb Merge commit '6a73336bde29' into 
for-linus)
Merging wireless/master (dda3b191eb6c net: rfkill: gpio: Enable module 
auto-loading for ACPI based switches)
Merging driver-core.current/driver-core-linus (9e82bf014195 Linux 3.17-rc5)
Merging tty.current/tty-linus (9e82bf014195 Linux 3.17-rc5)
Merging usb.current/usb-linus (9e82bf014195 Linux 3.17-rc5)
Merging usb-gadget-fixes/fixes (0b93a4c838fa usb: dwc3: fix TRB completion when 
multiple TRBs are started)
Merging usb-serial-fixes/usb-linus (9e82bf014195 Linux 3.17-rc5)
Merging staging.current/staging-linus (9e82bf014195 Linux 3.17-rc5)
Merging char-misc.current/char-misc-linus (9e82bf014195 Linux 3.17-rc5)
Merging input-current/for-linus (807362cd960d Input: atmel_mxt_ts - fix merge 
in DT documentation)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (78f543a93473 crypto: drbg - remove check for 
uninitialized DRBG handle)
Merging ide/master (a53dae49b2fe ide: use module_platform_driver())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (5a12a597a862 arm: Add devicetree 
fixup machine function)
Merging rr-fixes/fixes (f49819560f53 virtio-rng: skip reading when we start to 
remove the device)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joer

Re: [PATCH] mmc: don't request CD IRQ until mmc_start_host()

[Adrian Hunter]

On 09/18/2014 08:25 AM, Adrian Hunter wrote:
> On 09/17/2014 10:57 PM, Stephen Warren wrote:
>> On 09/17/2014 01:55 PM, Ulf Hansson wrote:
>>> On 12 September 2014 19:18, Stephen Warren  wrote:
 From: Stephen Warren 

 As soon as the CD IRQ is requested, it can trigger, since it's an
 externally controlled event. If it does, delayed_work host->detect will
 be scheduled.

 Many host controller probe()s are roughly structured as:

 *_probe() {
  host = sdhci_pltfm_init();
  mmc_of_parse(host->mmc);
  rc = sdhci_add_host(host);
  if (rc) {
  sdhci_pltfm_free();
  return rc;
  }

 In 3.17, CD IRQs can are enabled quite early via *_probe() ->
 mmc_of_parse() -> mmc_gpio_request_cd() -> mmc_gpiod_request_cd_irq().

 Note that in linux-next, mmc_of_parse() calls mmc_gpio*d*_request_cd()
 rather than mmc_gpio_request_cd(), and mmc_gpio*d*_request_cd() doesn't
 call mmc_gpiod_request_cd_irq(). However, this issue still exists for
 any other direct users of mmc_gpio_request_cd().

 sdhci_add_host() may fail part way through (e.g. due to deferred
 probe for a vmmc regulator), and sdhci_pltfm_free() does nothing to
 unrequest the CD IRQ nor cancel the delayed_work. sdhci_pltfm_free() is
 coded to assume that if sdhci_add_host() failed, then the delayed_work
 cannot (or should not) have been triggered.

 This can lead to the following with CONFIG_DEBUG_OBJECTS_* enabled, when
 kfree(host) is eventually called inside sdhci_pltfm_free():

 WARNING: CPU: 2 PID: 6 at lib/debugobjects.c:263
 debug_print_object+0x8c/0xb4()
 ODEBUG: free active (active state 0) object type: timer_list hint:
 delayed_work_timer_fn+0x0/0x18

 The object being complained about is host->detect.

 There's no need to request the CD IRQ so early; mmc_start_host() already
 requests it, and I *assume* that mmc_start_host() is called somehow for
 all host controllers. For SDHCI hosts at least, the typical call path
 that does this is: *_probe() -> sdhci_add_host() -> mmc_add_host() ->
 mmc_start_host(). So, remove the call to mmc_gpiod_request_cd_irq() from
 mmc_gpio_request_cd(). This matches mmc_gpio*d*_request_cd(), which
 already doesn't call mmc_gpiod_request_cd_irq().

 This solves the problem (eliminates the kernel error message above),
 since it guarantees that the IRQ can't trigger before mmc_start_host()
 is called.

 The critical point here is that once sdhci_add_host() calls
 mmc_add_host() -> mmc_start_host(), sdhci_add_host() is coded not to
 fail. In other words, if there's a chance that mmc_start_host() may have
 been called, and CD IRQs triggered, and the delayed_work scheduled,
 sdhci_add_host() won't fail, and so cleanup is no longer via
 sdhci_pltfm_free() (which doesn't free the IRQ or cancel the work queue)
 but instead must be via sdhci_remove_host(), which calls mmc_remove_host()
 -> mmc_stop_host(), which does free the IRQ and cancel the work queue.

 This fixes what I might conclude to be a mistake in commit 740a221ef0e5
 ("mmc: slot-gpio: Add GPIO descriptor based CD GPIO API"), which added the
 call from mmc_start_host() to mmc_gpiod_request_cd_irq(), but also added
 incorrectly added a call from mmc_gpio_request_cd() to
 mmc_gpiod_request_cd_irq().

That comment is wrong.  mmc_gpio_request_cd() has always set up the irq.


 CC: Russell King 
 Cc: Adrian Hunter 
 Cc: Alexandre Courbot 
 Cc: Linus Walleij 
 Signed-off-by: Stephen Warren 
>>>
>>> Hi Stephen,
>>>
>>> Thanks for looking into this. It seems like this issue has been
>>> present for quite a while.
>>> I believe your patch should have a stable tag for 3.15+ as well,
>>> unless you object I will add it.
>>
>> Yes, that probably makes sense, thanks.
> 
> Doesn't this patch break the drivers that call mmc_gpio_request_cd() after
> mmc_add_host() like mmc_spi.c or sdhci-sirf.c or tmio_mmc_pio.c ?

Ulf, this should be reverted.

--
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] memory cgroup: weak points of kmem accounting design

[Greg Thelen]

On Tue, Sep 16 2014, Vladimir Davydov wrote:

> Hi Suleiman,
>
> On Mon, Sep 15, 2014 at 12:13:33PM -0700, Suleiman Souhlal wrote:
>> On Mon, Sep 15, 2014 at 3:44 AM, Vladimir Davydov
>>  wrote:
>> > Hi,
>> >
>> > I'd like to discuss downsides of the kmem accounting part of the memory
>> > cgroup controller and a possible way to fix them. I'd really appreciate
>> > if you could share your thoughts on it.
>> >
>> > The idea lying behind the kmem accounting design is to provide each
>> > memory cgroup with its private copy of every kmem_cache and list_lru
>> > it's going to use. This is implemented by bundling these structures with
>> > arrays storing per-memcg copies. The arrays are referenced by css id.
>> > When a process in a cgroup tries to allocate an object from a kmem cache
>> > we first find out which cgroup the process resides in, then look up the
>> > cache copy corresponding to the cgroup, and finally allocate a new
>> > object from the private cache. Similarly, on addition/deletion of an
>> > object from a list_lru, we first obtain the kmem cache the object was
>> > allocated from, then look up the memory cgroup which the cache belongs
>> > to, and finally add/remove the object from the private copy of the
>> > list_lru corresponding to the cgroup.
>> >
>> > Though simple it looks from the first glance, it has a number of serious
>> > weaknesses:
>> >
>> >  - Providing each memory cgroup with its own kmem cache increases
>> >external fragmentation.
>> 
>> I haven't seen any evidence of this being a problem (but that doesn't
>> mean it doesn't exist).
>
> Actually, it's rather speculative. For example, if we have say a hundred
> of extra objects per cache (fragmented or in per-cpu stocks) of size 256
> bytes, then for one cache the overhead would be 25K, which is
> negligible. Now if there are thousand cgroups using the cache, we have
> to pay 25M, which is noticeable. Anyway, to estimate this exactly, one
> needs to run a typical workload inside a cgroup.
>
>>
>> >  - SLAB isn't ready to deal with thousands of caches: its algorithm
>> >walks over all system caches and shrinks them periodically, which may
>> >be really costly if we have thousands active memory cgroups.
>> 
>> This could be throttled.
>
> It could be, but then we'd have more objects in per-cpu stocks, which
> means more memory overhead.
>
>> 
>> >
>> >  - Caches may now be created/destroyed frequently and from various
>> >places: on system cache destruction, on cgroup offline, from a work
>> >struct scheduled by kmalloc. Synchronizing them properly is really
>> >difficult. I've fixed some places, but it's still desperately buggy.
>> 
>> Agreed.
>> 
>> >  - It's hard to determine when we should destroy a cache that belongs to
>> >a dead memory cgroup. The point is both SLAB and SLUB implementations
>> >always keep some pages in stock for performance reasons, so just
>> >scheduling cache destruction work from kfree once the last slab page
>> >is freed isn't enough - it will normally never happen for SLUB and
>> >may take really long for SLAB. Of course, we can forbid SL[AU]B
>> >algorithm to stock pages in dead caches, but it looks ugly and has
>> >negative impact on performance (I did this, but finally decided to
>> >revert). Another approach could be scanning dead caches periodically
>> >or on memory pressure, but that would be ugly too.
>> 
>> Not sure about slub, but for SLAB doesn't cache_reap take care of that?
>
> It is, but it takes some time. If we decide to throttle it, then it'll
> take even longer. Anyway, SLUB has nothing like that, therefore we'd
> have to handle different algorithms in different ways, which I
> particularly dislike.
>
>> 
>> >
>> >  - The arrays for storing per-memcg copies can get really large,
>> >especially if we finally decide to leave dead memory cgroups hanging
>> >until memory pressure reaps objects assigned to them and let them
>> >free. How can we deal with an array of, say, 20K elements? Simply
>> >allocating them with kmal^W vmalloc will result in memory wastes. It
>> >will be particularly funny if the user wants to provide each cgroup
>> >with a separate mount point: each super block will have a list_lru
>> >for every memory cgroup, but only one of them will be really used.
>> >That said we need a kind of dynamic reclaimable arrays. Radix trees
>> >would fit, but they are way slower than plain arrays, which is a
>> >no-go, because we want to look up on each kmalloc, list_lru_add/del,
>> >which are fast paths.
>> 
>> The initial design we had was to have an array indexed by "cache id"
>> in struct memcg, instead of the current array indexed by "css id" in
>> struct kmem_cache.
>> The initial design doesn't have the problem you're describing here, as
>> far as I can tell.
>
> It is indexed by "cache id", not "css id", but it doesn't matter
> actually. Suppose, when a cgroup is taken offli

[PATCH] asm/uapi: Add definition of TIOC[SG]RS485

[Ricardo Ribalda Delgado]

Commit: e676253b19b2d269cccf67fdb1592120a0cd0676 (serial/8250: Add
support for RS485 IOCTLs), adds support for RS485 ioctls for 825_core on
all the archs. Unfortunaltely the definition of TIOCSRS485 and
TIOCGRS485 was missing on the ioctls.h file

Reported-by: Guenter Roeck 
Signed-off-by: Ricardo Ribalda Delgado 
---
 arch/alpha/include/uapi/asm/ioctls.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/alpha/include/uapi/asm/ioctls.h 
b/arch/alpha/include/uapi/asm/ioctls.h
index 92c557b..f30c94a 100644
--- a/arch/alpha/include/uapi/asm/ioctls.h
+++ b/arch/alpha/include/uapi/asm/ioctls.h
@@ -90,6 +90,8 @@
 #define TIOCSBRK   0x5427  /* BSD compatibility */
 #define TIOCCBRK   0x5428  /* BSD compatibility */
 #define TIOCGSID   0x5429  /* Return the session ID of FD */
+#define TIOCGRS485 _IOR('T', 0x2E, struct serial_rs485)
+#define TIOCSRS485 _IOWR('T', 0x2F, struct serial_rs485)
 #define TIOCGPTN   _IOR('T',0x30, unsigned int) /* Get Pty Number (of 
pty-mux device) */
 #define TIOCSPTLCK _IOW('T',0x31, int)  /* Lock/unlock Pty */
 #define TIOCGDEV   _IOR('T',0x32, unsigned int) /* Get primary device node 
of /dev/console */
-- 
2.1.0

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

Re: [PATCH v13 net-next 07/11] bpf: verifier (add ability to receive verification log)

[Daniel Borkmann]

On 09/18/2014 01:45 AM, Alexei Starovoitov wrote:

On Wed, Sep 17, 2014 at 12:37 PM, Alexei Starovoitov  wrote:



Hm, thinking out loudly ... perhaps this could be made a library problem.
Such that the library which wraps the syscall needs to be aware of a
marker where the initial version ends, and if the application doesn't
make use of any of the new features, it would just pass in the length up
to the marker as size attribute into the syscall. Similarly, if new
features are always added to the end of a structure and the library
truncates the overall-length after the last used member we might have
a chance to load something on older kernels, haven't tried that though.


that's a 3rd option. I think it's cleaner than 2nd, since it solves it
completely from user space.
It can even be smarter than that. If this syscall wrapper library
sees that newer features are used and it can workaround them:
it can chop size and pass older fields into the older kernel
and when it returns, do a workaround based on newer fields.


the more I think about 'new user space + old kernel' problem,
the more certain I am that kernel should not try to help
user space, since most of the time it's not going to be enough,
but additional code in kernel would need to be maintained.

syscall commands and size of bpf_attr is the least of problems.
New map_type and prog_type will be added, new helper
functions will be available to programs.
One would think that md5 of uapi/linux/bpf.h would be
enough to say that user app is compatible... In reality,
it's not. The 'state pruning' verifier optimization I've talked
about will not change a single bit in bpf.h, but it will be
able to recognize more programs as safe.
A program developed on a new kernel with more
advanced verifier will load just fine on new kernel, but
this valid program will not load on old kernel, only because
verifier is not smart enough. Now we would need a version
of verifier exposed all the way to user space?!
imo that's too much. I think for eBPF infra kernel
should only guarantee backwards compatibility
(old user space must work with new kernel) and that's it.
That's what this patch is trying to do.
Thoughts?


Sure, you will never get a full compatibility on that regard
while backwards compatibility needs to be guaranteed on the
other hand. I looked at perf_copy_attr() implementation and I
think that we should mimic it in a very similar way as it
exactly solves what we need.

For example, it will return with -EINVAL for (size > PAGE_SIZE)
and (size < PERF_ATTR_SIZE_VER0) where PAGE_SIZE has been chosen
as an arbitrary hard upper limit where it is believed that it will
never grow beyond that large limit in future.

So this is a more loose constraint than what we currently do,
that is, -EINVAL on (size > sizeof(attr)) where attr is the
currently known size of a specific kernel. That would at least
be a start, you won't be able to cover everything though, but
it would allow to address the issue raised when running with
a basic feature set.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mtd: denali: fix include guard and license block of denali.h

[Brian Norris]

On Fri, Aug 29, 2014 at 08:00:51PM +0900, Masahiro Yamada wrote:
> It looks like this header file is a concatenation of two headers.
> Anyway, the include guard should be renamed and placed at the correct
> postion and the license block in the middle should be deleted.
> 
> Signed-off-by: Masahiro Yamada 

Pushed to l2-mtd.git. Thanks!

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

RE: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices

[li.xi...@freescale.com]

Hi Pankaj,

One more question:
For example:

regmap_read()
> _regmap_read()
> 2112 #ifdef LOG_DEVICE
> 2113 if (strcmp(dev_name(map->dev), LOG_DEVICE) 
== 0)
> 2114 dev_info(map->dev, "%x => %x\n", 
reg, *val);
> 2115 #endif 

In dev_name(map->dev) will also encounter the same crash core trace like in
regmap_get_val_endian(dev, ...).

Could there be another method, such as using 'dummy dev' instead of 'NULL dev' ?
Just one suggestion.


BRs
Xiubo


> -Original Message-
> From: Pankaj Dubey [mailto:pankaj.du...@samsung.com]
> Sent: Thursday, September 18, 2014 2:03 PM
> To: Dong Aisheng-B29396
> Cc: linux-arm-ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; kgene@samsung.com; li...@arm.linux.org.uk;
> a...@arndb.de; naus...@samsung.com; tomasz.f...@gmail.com; jo...@samsung.com;
> thomas...@samsung.com; vikas.saj...@samsung.com; chow@samsung.com;
> lee.jo...@linaro.org; 'Boris BREZILLON'; Xiubo Li-B47053; 'Geert 
> Uytterhoeven';
> 'Stephen Warren'
> Subject: RE: [PATCH v3] mfd: syscon: Decouple syscon interface from platform
> devices
> 
> Hi,
> 
> Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren.
> 
> On Thursday, September 18, 2014, Dong Aisheng wrote,
> > On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
> > > Hi,
> > >
> > > On Wednesday, September 17, 2014, Dong Aisheng Wrote,
> > > > >
> > > > > + regmap = regmap_init_mmio(NULL, base,
> &syscon_regmap_config);
> > > >
> > > > Does a NULL device pointer work?
> > >
> > > Yes, it is safe, at least we are able to test on Exynos based SoC.
> > > I have tested it with kgene/for-next kernel on Exynos3250.
> > > Also it has been tested on Exynos5250 based Snow board with 3.17-rc5
> > > based kernel by Vivek Gautam.
> > >
> > > Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
> > >
> > >
> >
> > The kernel i tested was next-20140915 of linux-next.
> >
> > please see regmap_get_val_endian called in regmap_init function.
> > static enum regmap_endian regmap_get_val_endian(struct device *dev,
> > const struct regmap_bus *bus,
> > const struct regmap_config
> *config) {
> > struct device_node *np = dev->of_node;
> > enum regmap_endian endian;
> > ...
> > }
> > It will crash at the first line of dev->of_node if dev is NULL.
> >
> > Can you check if you're using the same code as mine?
> 
> No, it's not same.
> My bad that I was not using linux-next for testing this patch.
> We tested on kgene/for-next where these changes still have not come.
> Just now I checked linux-next and found that it will crash at first line of
> "regmap_get_val_endian" as there is no check for NULL on dev.
> 
> I checked git history of regmap.c file and found recently this file has been
> modified
> for adding DT endianness binding support. Following are set of patches gone
> for this
> 
> cf673fb regmap: Split regmap_get_endian() in two functions
> 5844a8b regmap: Fix handling of volatile registers for format_write() chips
> 45e1a27 regmap: of_regmap_get_endian() cleanup
> ba1b53f regmap: Fix DT endianess parsing logic
> d647c19 regmap: add DT endianness binding support.
> 
> I think there should have been a check for NULL on "dev" in
> "regmap_get_val_endian", so that if dev pointer exist then only it makes
> sense to get
> endianness property from DT.
> 
> I will suggest following fix in regmap.c for this. With following fix I
> tested it and it works well
> on linux-next also. So if you can confirm following fix is working for you
> then I can post this
> patch.
> 
> 
> Subject: [PATCH] regmap: fix NULL pointer dereference in
>  regmap_get_val_endian
> 
> Recent commits for getting reg endianess causing NULL pointer
> dereference if dev is passed NULL in regmap_init_mmio. This patch
> fixes this issue, and allows to parse reg endianess only if dev
> and dev->of_node exist.
> 
> Signed-off-by: Pankaj Dubey 
> ---
>  drivers/base/regmap/regmap.c |   23 ++-
>  1 file changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
> index f2281af..455a877 100644
> --- a/drivers/base/regmap/regmap.c
> +++ b/drivers/base/regmap/regmap.c
> @@ -477,7 +477,7 @@ static enum regmap_endian regmap_get_val_endian(struct
> device *dev,
>   const struct regmap_bus *bus,
>   const struct regmap_config *config)
>  {
> - struct device_node *np = dev->of_node;
> + struct device_node *np;
>   enum regmap_endian endian;
> 
>   /* Retrieve the endianness specification from the regmap config */
> @@ -487,15 +487,20 @@ static enum regmap_endian regmap_get_val_endian(struct
> device *dev,
>   if (endian != 

Re: [PATCH] [trivial] treewide: Fix typos in Kconfig

[Randy Dunlap]

On 09/17/14 20:09, Masanari Iida wrote:
> This patch fix spelling typos found in Kconfig.
> 
> Signed-off-by: Masanari Iida 

Acked-by: Randy Dunlap 

Thanks.

> ---
>  arch/blackfin/Kconfig   | 2 +-
>  arch/mips/cavium-octeon/Kconfig | 2 +-
>  drivers/i2c/busses/Kconfig  | 2 +-
>  drivers/irqchip/Kconfig | 2 +-
>  drivers/platform/x86/Kconfig| 8 
>  drivers/usb/host/Kconfig| 2 +-
>  6 files changed, 9 insertions(+), 9 deletions(-)


-- 
~Randy
--
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 v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

[Dave Hansen]

On 09/18/2014 12:17 AM, Kevin Easton wrote:
> I was assuming that if an application did want to enable MPX after threads
> had already been created, it would generally want to enable it
> simultaneously across all threads.  This would be a lot easier for the
> kernel than for the application.

The current gcc setup mechanism would set up MPX even before main().  So
I think it's pretty unlikely that help is needed to coordinate threads.
--
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 v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

[Kevin Easton]

On Wed, Sep 17, 2014 at 09:43:09PM -0700, Dave Hansen wrote:
> On 09/17/2014 08:23 PM, Kevin Easton wrote:
> > I was actually thinking that the kernel would take care of the xsave / 
> > xrstor (for current), updating tsk->thread.fpu.state (for non-running
> > threads) and sending an IPI for threads running on other CPUs.
> > 
> > Of course userspace can always then manually change the bounds directory
> > address itself, but then it's quite clear that they're doing something
> > unsupported.  Just an idea, anyway.
> 
> What's the benefit of that?
> 
> As it stands now, MPX is likely to be enabled well before any threads
> are created, and the MPX enabling state will be inherited by the new
> thread at clone() time.  The current mechanism allows a thread to
> individually enable or disable MPX independently of the other threads.
> 
> I think it makes it both more complicated and less flexible.

I was assuming that if an application did want to enable MPX after threads
had already been created, it would generally want to enable it
simultaneously across all threads.  This would be a lot easier for the
kernel than for the application.

- Kevin
--
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] kvm: Faults which trigger IO release the mmap_sem

[Gleb Natapov]

On Wed, Sep 17, 2014 at 10:51:48AM -0700, Andres Lagar-Cavilla wrote:
> When KVM handles a tdp fault it uses FOLL_NOWAIT. If the guest memory
> has been swapped out or is behind a filemap, this will trigger async
> readahead and return immediately. The rationale is that KVM will kick
> back the guest with an "async page fault" and allow for some other
> guest process to take over.
> 
> If async PFs are enabled the fault is retried asap from an async
> workqueue. If not, it's retried immediately in the same code path. In
> either case the retry will not relinquish the mmap semaphore and will
> block on the IO. This is a bad thing, as other mmap semaphore users
> now stall as a function of swap or filemap latency.
> 
> This patch ensures both the regular and async PF path re-enter the
> fault allowing for the mmap semaphore to be relinquished in the case
> of IO wait.
> 
Reviewed-by: Gleb Natapov 

> Reviewed-by: Radim Krčmář 
> Signed-off-by: Andres Lagar-Cavilla 
> 
> ---
> v1 -> v2
> 
> * WARN_ON_ONCE -> VM_WARN_ON_ONCE
> * pagep == NULL skips the final retry
> * kvm_gup_retry -> kvm_gup_io
> * Comment updates throughout
> ---
>  include/linux/kvm_host.h | 11 +++
>  include/linux/mm.h   |  1 +
>  mm/gup.c |  4 
>  virt/kvm/async_pf.c  |  4 +---
>  virt/kvm/kvm_main.c  | 49 
> +---
>  5 files changed, 63 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 3addcbc..4c1991b 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -198,6 +198,17 @@ int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, 
> unsigned long hva,
>  int kvm_async_pf_wakeup_all(struct kvm_vcpu *vcpu);
>  #endif
>  
> +/*
> + * Carry out a gup that requires IO. Allow the mm to relinquish the mmap
> + * semaphore if the filemap/swap has to wait on a page lock. pagep == NULL
> + * controls whether we retry the gup one more time to completion in that 
> case.
> + * Typically this is called after a FAULT_FLAG_RETRY_NOWAIT in the main tdp
> + * handler.
> + */
> +int kvm_get_user_page_io(struct task_struct *tsk, struct mm_struct *mm,
> +  unsigned long addr, bool write_fault,
> +  struct page **pagep);
> +
>  enum {
>   OUTSIDE_GUEST_MODE,
>   IN_GUEST_MODE,
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ebc5f90..13e585f7 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2011,6 +2011,7 @@ static inline struct page *follow_page(struct 
> vm_area_struct *vma,
>  #define FOLL_HWPOISON0x100   /* check page is hwpoisoned */
>  #define FOLL_NUMA0x200   /* force NUMA hinting page fault */
>  #define FOLL_MIGRATION   0x400   /* wait for page to replace migration 
> entry */
> +#define FOLL_TRIED   0x800   /* a retry, previous pass started an IO */
>  
>  typedef int (*pte_fn_t)(pte_t *pte, pgtable_t token, unsigned long addr,
>   void *data);
> diff --git a/mm/gup.c b/mm/gup.c
> index 91d044b..af7ea3e 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -281,6 +281,10 @@ static int faultin_page(struct task_struct *tsk, struct 
> vm_area_struct *vma,
>   fault_flags |= FAULT_FLAG_ALLOW_RETRY;
>   if (*flags & FOLL_NOWAIT)
>   fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_RETRY_NOWAIT;
> + if (*flags & FOLL_TRIED) {
> + VM_WARN_ON_ONCE(fault_flags & FAULT_FLAG_ALLOW_RETRY);
> + fault_flags |= FAULT_FLAG_TRIED;
> + }
>  
>   ret = handle_mm_fault(mm, vma, address, fault_flags);
>   if (ret & VM_FAULT_ERROR) {
> diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
> index d6a3d09..5ff7f7f 100644
> --- a/virt/kvm/async_pf.c
> +++ b/virt/kvm/async_pf.c
> @@ -80,9 +80,7 @@ static void async_pf_execute(struct work_struct *work)
>  
>   might_sleep();
>  
> - down_read(&mm->mmap_sem);
> - get_user_pages(NULL, mm, addr, 1, 1, 0, NULL, NULL);
> - up_read(&mm->mmap_sem);
> + kvm_get_user_page_io(NULL, mm, addr, 1, NULL);
>   kvm_async_page_present_sync(vcpu, apf);
>  
>   spin_lock(&vcpu->async_pf.lock);
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 7ef6b48..fa8a565 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1115,6 +1115,43 @@ static int get_user_page_nowait(struct task_struct 
> *tsk, struct mm_struct *mm,
>   return __get_user_pages(tsk, mm, start, 1, flags, page, NULL, NULL);
>  }
>  
> +int kvm_get_user_page_io(struct task_struct *tsk, struct mm_struct *mm,
> +  unsigned long addr, bool write_fault,
> +  struct page **pagep)
> +{
> + int npages;
> + int locked = 1;
> + int flags = FOLL_TOUCH | FOLL_HWPOISON |
> + (pagep ? FOLL_GET : 0) |
> + (write_fault ? FOLL_WRITE : 0);
> +
> + /*
> +  * If retrying the fault, we get here *not* having allowed t

Re: [RFC Part2 v1 02/21] genirq: Introduce helper functions to support stacked irq_chip

[Jiang Liu]

On 2014/9/18 4:58, Thomas Gleixner wrote:
> On Wed, 17 Sep 2014, Jiang Liu wrote:
>> On 2014/9/17 1:45, Thomas Gleixner wrote:
>>> On Thu, 11 Sep 2014, Jiang Liu wrote:
 +#ifdefCONFIG_IRQ_DOMAIN_HIERARCHY
 +void irq_chip_ack_parent(struct irq_data *data)
 +{
 +  data = data->parent_data;
 +  if (data && data->chip && data->chip->irq_ack)
 +  data->chip->irq_ack(data);
>>>
>>> Why is this restricted to a single parent level and does not go down
>>> the whole stack?
>> Hi Thomas,
>>  It happens to work on x86, and we want to achieve a bit
>> performance advantage by not walking down the whole stack.
>> If preferred, I will change it to walk the whole stack.
> 
> Happens to work on my machine is always a bad argument :)
> 
> Now, I can see why you want to do that, but if we do an optimization
> like that then we should really get rid of the conditional.
> 
> You surely need a conditional on data->chip and data->chip->callback
> for a full stackq walk, but for an explicit request to use the parents
> ack the parent better has a chip with an ack function, right?
> 
> void irq_chip_ack_parent(struct irq_data *data)
> {
>   data = data->parent_data;
>   data->chip->irq_ack(data);
> }
Sure, will optimize it further as above code.
Regards!
Gerry
> 
> Thanks,
> 
>   tglx
> 
--
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] kvm: Faults which trigger IO release the mmap_sem

[Gleb Natapov]

On Thu, Sep 18, 2014 at 08:29:17AM +0800, Wanpeng Li wrote:
> Hi Andres,
> On Wed, Sep 17, 2014 at 10:51:48AM -0700, Andres Lagar-Cavilla wrote:
> [...]
> > static inline int check_user_page_hwpoison(unsigned long addr)
> > {
> > int rc, flags = FOLL_TOUCH | FOLL_HWPOISON | FOLL_WRITE;
> >@@ -1177,9 +1214,15 @@ static int hva_to_pfn_slow(unsigned long addr, bool 
> >*async, bool write_fault,
> > npages = get_user_page_nowait(current, current->mm,
> >   addr, write_fault, page);
> > up_read(¤t->mm->mmap_sem);
> >-} else
> >-npages = get_user_pages_fast(addr, 1, write_fault,
> >- page);
> >+} else {
> >+/*
> >+ * By now we have tried gup_fast, and possibly async_pf, and we
> >+ * are certainly not atomic. Time to retry the gup, allowing
> >+ * mmap semaphore to be relinquished in the case of IO.
> >+ */
> >+npages = kvm_get_user_page_io(current, current->mm, addr,
> >+  write_fault, page);
> >+}
> 
> try_async_pf 
>  gfn_to_pfn_async 
>   __gfn_to_pfnasync = false 
*async = false

>__gfn_to_pfn_memslot
> hva_to_pfn 
>hva_to_pfn_fast 
>hva_to_pfn_slow 
hva_to_pfn_slow checks async not *async.

> kvm_get_user_page_io
> 
> page will always be ready after kvm_get_user_page_io which leads to APF
> don't need to work any more.
> 
> Regards,
> Wanpeng Li
> 
> > if (npages != 1)
> > return npages;
> > 
> >-- 
> >2.1.0.rc2.206.gedb03e5
> >
> >--
> >To unsubscribe, send a message with 'unsubscribe linux-mm' in
> >the body to majord...@kvack.org.  For more info on Linux MM,
> >see: http://www.linux-mm.org/ .
> >Don't email: mailto:"d...@kvack.org";> em...@kvack.org 

--
Gleb.
--
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] mfd: syscon: Decouple syscon interface from platform devices

[Pankaj Dubey]

Hi,

Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren. 

On Thursday, September 18, 2014, Dong Aisheng wrote,
> On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
> > Hi,
> >
> > On Wednesday, September 17, 2014, Dong Aisheng Wrote,
> > > >
> > > > +   regmap = regmap_init_mmio(NULL, base,
&syscon_regmap_config);
> > >
> > > Does a NULL device pointer work?
> >
> > Yes, it is safe, at least we are able to test on Exynos based SoC.
> > I have tested it with kgene/for-next kernel on Exynos3250.
> > Also it has been tested on Exynos5250 based Snow board with 3.17-rc5
> > based kernel by Vivek Gautam.
> >
> > Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
> >
> >
> 
> The kernel i tested was next-20140915 of linux-next.
> 
> please see regmap_get_val_endian called in regmap_init function.
> static enum regmap_endian regmap_get_val_endian(struct device *dev,
> const struct regmap_bus *bus,
> const struct regmap_config
*config) {
> struct device_node *np = dev->of_node;
> enum regmap_endian endian;
> ...
> }
> It will crash at the first line of dev->of_node if dev is NULL.
> 
> Can you check if you're using the same code as mine?

No, it's not same.
My bad that I was not using linux-next for testing this patch.
We tested on kgene/for-next where these changes still have not come.
Just now I checked linux-next and found that it will crash at first line of 
"regmap_get_val_endian" as there is no check for NULL on dev.

I checked git history of regmap.c file and found recently this file has been
modified
for adding DT endianness binding support. Following are set of patches gone
for this

cf673fb regmap: Split regmap_get_endian() in two functions
5844a8b regmap: Fix handling of volatile registers for format_write() chips
45e1a27 regmap: of_regmap_get_endian() cleanup
ba1b53f regmap: Fix DT endianess parsing logic
d647c19 regmap: add DT endianness binding support.

I think there should have been a check for NULL on "dev" in
"regmap_get_val_endian", so that if dev pointer exist then only it makes
sense to get
endianness property from DT. 

I will suggest following fix in regmap.c for this. With following fix I
tested it and it works well
on linux-next also. So if you can confirm following fix is working for you
then I can post this
patch.


Subject: [PATCH] regmap: fix NULL pointer dereference in
 regmap_get_val_endian

Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev
and dev->of_node exist.

Signed-off-by: Pankaj Dubey 
---
 drivers/base/regmap/regmap.c |   23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index f2281af..455a877 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -477,7 +477,7 @@ static enum regmap_endian regmap_get_val_endian(struct
device *dev,
const struct regmap_bus *bus,
const struct regmap_config *config)
 {
-   struct device_node *np = dev->of_node;
+   struct device_node *np;
enum regmap_endian endian;
 
/* Retrieve the endianness specification from the regmap config */
@@ -487,15 +487,20 @@ static enum regmap_endian regmap_get_val_endian(struct
device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
 
-   /* Parse the device's DT node for an endianness specification */
-   if (of_property_read_bool(np, "big-endian"))
-   endian = REGMAP_ENDIAN_BIG;
-   else if (of_property_read_bool(np, "little-endian"))
-   endian = REGMAP_ENDIAN_LITTLE;
+   /* If the dev and dev->of_node exist try to get endianness from DT
*/
+   if (dev && dev->of_node) {
+   np = dev->of_node;
 
-   /* If the endianness was specified in DT, use that */
-   if (endian != REGMAP_ENDIAN_DEFAULT)
-   return endian;
+   /* Parse the device's DT node for an endianness
specification */
+   if (of_property_read_bool(np, "big-endian"))
+   endian = REGMAP_ENDIAN_BIG;
+   else if (of_property_read_bool(np, "little-endian"))
+   endian = REGMAP_ENDIAN_LITTLE;
+
+   /* If the endianness was specified in DT, use that */
+   if (endian != REGMAP_ENDIAN_DEFAULT)
+   return endian;
+   }
 
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--

Thanks,
Pankaj Dubey

> Regards
> Dong Aisheng
> 
> >
> > Thanks,
> > Pankaj Dubey
> >
> > > Regards
> > > Dong Aisheng
> > >
> > > >
> > > >

Re: [PATCH] arm:extend the reserved mrmory for initrd to be page aligned

[Uwe Kleine-König]

Hello,

just some commit log nit picking:

$Subject ~= s/mrmory/memory/

And also "ARM: " is the more typical prefix. Don't know if there is a
best practice for patches touching both arm and arm64. (But assuming
this will go through Russell's patch tracker this doesn't matter much.)

On Thu, Sep 18, 2014 at 09:58:10AM +0800, Wang, Yalin wrote:
> this patch extend the start and end address of initrd to be page aligned,
This patch extends ...

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] f2fs: update i_size when __allocate_data_block

[Jaegeuk Kim]

The f2fs_direct_IO uses __allocate_data_block, but inside the allocation path,
we should update i_size at the changed time to update its inode page.
Otherwise, we can get wrong i_size after roll-forward recovery.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7749f30..aaf22a9 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -572,9 +572,11 @@ put_err:
 static int __allocate_data_block(struct dnode_of_data *dn)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(dn->inode);
+   struct f2fs_inode_info *fi = F2FS_I(dn->inode);
struct f2fs_summary sum;
block_t new_blkaddr;
struct node_info ni;
+   pgoff_t fofs;
int type;
 
if (unlikely(is_inode_flag_set(F2FS_I(dn->inode), FI_NO_ALLOC)))
@@ -597,6 +599,12 @@ static int __allocate_data_block(struct dnode_of_data *dn)
update_extent_cache(new_blkaddr, dn);
clear_inode_flag(F2FS_I(dn->inode), FI_NO_EXTENT);
 
+   /* update i_size */
+   fofs = start_bidx_of_node(ofs_of_node(dn->node_page), fi) +
+   dn->ofs_in_node;
+   if (i_size_read(dn->inode) < ((fofs + 1) << PAGE_CACHE_SHIFT))
+   i_size_write(dn->inode, ((fofs + 1) << PAGE_CACHE_SHIFT));
+
dn->data_blkaddr = new_blkaddr;
return 0;
 }
-- 
1.8.5.2 (Apple Git-48)

--
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/3] f2fs: use more free segments until SSR is activated

[Jaegeuk Kim]

Previously, f2fs activates SSR if the # of free segments reaches to the # of
overprovisioned segments.
In this case, SSR starts to use dirty segments only, so that the overprovisoned
space cannot be selected for new data.
This means that we have no chance to utilizae the overprovisioned space at all.

This patch fixes that by allowing LFS allocations until the # of free segments
reaches to the last threshold, reserved space.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/segment.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index d317b61..a0e9207 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -437,8 +437,9 @@ static inline int reserved_sections(struct f2fs_sb_info 
*sbi)
 
 static inline bool need_SSR(struct f2fs_sb_info *sbi)
 {
-   return (prefree_segments(sbi) / sbi->segs_per_sec)
-   + free_sections(sbi) < overprovision_sections(sbi);
+   int node_secs = get_blocktype_secs(sbi, F2FS_DIRTY_NODES);
+   return (prefree_segments(sbi) / sbi->segs_per_sec) +
+   free_sections(sbi) < (reserved_sections(sbi) + node_secs);
 }
 
 static inline bool has_not_enough_free_secs(struct f2fs_sb_info *sbi, int 
freed)
-- 
1.8.5.2 (Apple Git-48)

--
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/3] f2fs: change the ipu_policy option to enable combinations

[Jaegeuk Kim]

This patch changes the ipu_policy setting to use any combination of orthogonal 
policies.

Signed-off-by: Changman Lee 
Signed-off-by: Jaegeuk Kim 
---
 Documentation/filesystems/f2fs.txt |  6 +++---
 fs/f2fs/segment.c  |  2 +-
 fs/f2fs/segment.h  | 39 --
 3 files changed, 20 insertions(+), 27 deletions(-)

diff --git a/Documentation/filesystems/f2fs.txt 
b/Documentation/filesystems/f2fs.txt
index d010da8..2cca5a2 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -192,9 +192,9 @@ Files in /sys/fs/f2fs/
 
  ipu_policy   This parameter controls the policy of in-place
   updates in f2fs. There are five policies:
-   0: F2FS_IPU_FORCE, 1: F2FS_IPU_SSR,
-   2: F2FS_IPU_UTIL,  3: F2FS_IPU_SSR_UTIL,
-   4: F2FS_IPU_FSYNC, 5: F2FS_IPU_DISABLE.
+   0x01: F2FS_IPU_FORCE, 0x02: F2FS_IPU_SSR,
+   0x04: F2FS_IPU_UTIL,  0x08: F2FS_IPU_SSR_UTIL,
+   0x10: F2FS_IPU_FSYNC.
 
  min_ipu_util This parameter controls the threshold to trigger
   in-place-updates. The number indicates percentage
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 24b768a..3125a3d 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1928,7 +1928,7 @@ int build_segment_manager(struct f2fs_sb_info *sbi)
sm_info->ssa_blkaddr = le32_to_cpu(raw_super->ssa_blkaddr);
sm_info->rec_prefree_segments = sm_info->main_segments *
DEF_RECLAIM_PREFREE_SEGMENTS / 100;
-   sm_info->ipu_policy = F2FS_IPU_FSYNC;
+   sm_info->ipu_policy = 1 << F2FS_IPU_FSYNC;
sm_info->min_ipu_util = DEF_MIN_IPU_UTIL;
sm_info->min_fsync_blocks = DEF_MIN_FSYNC_BLOCKS;
 
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 032c090..d317b61 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -487,40 +487,33 @@ enum {
F2FS_IPU_UTIL,
F2FS_IPU_SSR_UTIL,
F2FS_IPU_FSYNC,
-   F2FS_IPU_DISABLE,
 };
 
 static inline bool need_inplace_update(struct inode *inode)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+   unsigned int policy = SM_I(sbi)->ipu_policy;
 
/* IPU can be done only for the user data */
if (S_ISDIR(inode->i_mode))
return false;
 
-   switch (SM_I(sbi)->ipu_policy) {
-   case F2FS_IPU_FORCE:
+   if (policy & (0x1 << F2FS_IPU_FORCE))
return true;
-   case F2FS_IPU_SSR:
-   if (need_SSR(sbi))
-   return true;
-   break;
-   case F2FS_IPU_UTIL:
-   if (utilization(sbi) > SM_I(sbi)->min_ipu_util)
-   return true;
-   break;
-   case F2FS_IPU_SSR_UTIL:
-   if (need_SSR(sbi) && utilization(sbi) > SM_I(sbi)->min_ipu_util)
-   return true;
-   break;
-   case F2FS_IPU_FSYNC:
-   /* this is only set during fdatasync */
-   if (is_inode_flag_set(F2FS_I(inode), FI_NEED_IPU))
-   return true;
-   break;
-   case F2FS_IPU_DISABLE:
-   break;
-   }
+   if (policy & (0x1 << F2FS_IPU_SSR) && need_SSR(sbi))
+   return true;
+   if (policy & (0x1 << F2FS_IPU_UTIL) &&
+   utilization(sbi) > SM_I(sbi)->min_ipu_util)
+   return true;
+   if (policy & (0x1 << F2FS_IPU_SSR_UTIL) && need_SSR(sbi) &&
+   utilization(sbi) > SM_I(sbi)->min_ipu_util)
+   return true;
+
+   /* this is only set during fdatasync */
+   if (policy & (0x1 << F2FS_IPU_FSYNC) &&
+   is_inode_flag_set(F2FS_I(inode), FI_NEED_IPU))
+   return true;
+
return false;
 }
 
-- 
1.8.5.2 (Apple Git-48)

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

[PATCH 1/3] f2fs: introduce a flag to represent each nat entry information

[Jaegeuk Kim]

This patch introduces a flag in the nat entry structure to merge various
information such as checkpointed and fsync_done marks.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/node.c | 13 +++--
 fs/f2fs/node.h | 28 
 2 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index b32eb56..d19d6b1 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -131,7 +131,7 @@ int is_checkpointed_node(struct f2fs_sb_info *sbi, nid_t 
nid)
 
read_lock(&nm_i->nat_tree_lock);
e = __lookup_nat_cache(nm_i, nid);
-   if (e && !e->checkpointed)
+   if (e && !get_nat_flag(e, IS_CHECKPOINTED))
is_cp = 0;
read_unlock(&nm_i->nat_tree_lock);
return is_cp;
@@ -146,7 +146,7 @@ bool fsync_mark_done(struct f2fs_sb_info *sbi, nid_t nid)
read_lock(&nm_i->nat_tree_lock);
e = __lookup_nat_cache(nm_i, nid);
if (e)
-   fsync_done = e->fsync_done;
+   fsync_done = get_nat_flag(e, HAS_FSYNC_MARK);
read_unlock(&nm_i->nat_tree_lock);
return fsync_done;
 }
@@ -159,7 +159,7 @@ void fsync_mark_clear(struct f2fs_sb_info *sbi, nid_t nid)
write_lock(&nm_i->nat_tree_lock);
e = __lookup_nat_cache(nm_i, nid);
if (e)
-   e->fsync_done = false;
+   set_nat_flag(e, HAS_FSYNC_MARK, false);
write_unlock(&nm_i->nat_tree_lock);
 }
 
@@ -176,7 +176,7 @@ static struct nat_entry *grab_nat_entry(struct f2fs_nm_info 
*nm_i, nid_t nid)
}
memset(new, 0, sizeof(struct nat_entry));
nat_set_nid(new, nid);
-   new->checkpointed = true;
+   set_nat_flag(new, IS_CHECKPOINTED, true);
list_add_tail(&new->list, &nm_i->nat_entries);
nm_i->nat_cnt++;
return new;
@@ -249,7 +249,7 @@ retry:
/* update fsync_mark if its inode nat entry is still alive */
e = __lookup_nat_cache(nm_i, ni->ino);
if (e)
-   e->fsync_done = fsync_done;
+   set_nat_flag(e, HAS_FSYNC_MARK, fsync_done);
write_unlock(&nm_i->nat_tree_lock);
 }
 
@@ -1349,7 +1349,8 @@ static int add_free_nid(struct f2fs_sb_info *sbi, nid_t 
nid, bool build)
read_lock(&nm_i->nat_tree_lock);
ne = __lookup_nat_cache(nm_i, nid);
if (ne &&
-   (!ne->checkpointed || nat_get_blkaddr(ne) != NULL_ADDR))
+   (!get_nat_flag(ne, IS_CHECKPOINTED) ||
+   nat_get_blkaddr(ne) != NULL_ADDR))
allocated = true;
read_unlock(&nm_i->nat_tree_lock);
if (allocated)
diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
index 324917d..3043778 100644
--- a/fs/f2fs/node.h
+++ b/fs/f2fs/node.h
@@ -39,10 +39,14 @@ struct node_info {
unsigned char version;  /* version of the node */
 };
 
+enum {
+   IS_CHECKPOINTED,/* is it checkpointed before? */
+   HAS_FSYNC_MARK, /* has the latest node fsync mark? */
+};
+
 struct nat_entry {
struct list_head list;  /* for clean or dirty nat list */
-   bool checkpointed;  /* whether it is checkpointed or not */
-   bool fsync_done;/* whether the latest node has fsync mark */
+   unsigned char flag; /* for node information bits */
struct node_info ni;/* in-memory node information */
 };
 
@@ -57,16 +61,32 @@ struct nat_entry {
 
 #define __set_nat_cache_dirty(nm_i, ne)
\
do {\
-   ne->checkpointed = false;   \
+   set_nat_flag(ne, IS_CHECKPOINTED, false);   \
list_move_tail(&ne->list, &nm_i->dirty_nat_entries);\
} while (0)
 #define __clear_nat_cache_dirty(nm_i, ne)  \
do {\
-   ne->checkpointed = true;\
+   set_nat_flag(ne, IS_CHECKPOINTED, true);\
list_move_tail(&ne->list, &nm_i->nat_entries);  \
} while (0)
 #define inc_node_version(version)  (++version)
 
+static inline void set_nat_flag(struct nat_entry *ne,
+   unsigned int type, bool set)
+{
+   unsigned char mask = 0x01 << type;
+   if (set)
+   ne->flag |= mask;
+   else
+   ne->flag &= ~mask;
+}
+
+static inline bool get_nat_flag(struct nat_entry *ne, unsigned int type)
+{
+   unsigned char mask = 0x01 << type;
+   return ne->flag & mask;
+}
+
 static inline void node_info_from_raw_nat(struct node_info *ni,
struct f2fs_nat_entry *raw_ne)
 {
-- 
1.8.5.2 (Apple Git-48)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of 

Re: [PATCH] mfd: rtsx: fix PM suspend for 5227 & 5249

[micky]

On 09/18/2014 12:53 PM, Lee Jones wrote:

On Thu, 18 Sep 2014, micky_ch...@realsil.com.cn wrote:


From: Micky Ching 

Fix rts5227&5249 failed send buffer cmd after suspend,
PM_CTRL3 should reset before send any buffer cmd after suspend.
Otherwise, buffer cmd will failed, this will lead resume fail.

Signed-off-by: Micky Ching 
---
  drivers/mfd/rts5227.c|   19 +++
  drivers/mfd/rts5249.c|4 
  drivers/mfd/rtsx_pcr.h   |1 +
  include/linux/mfd/rtsx_pci.h |   12 
  4 files changed, 36 insertions(+)

I think you'll find you just broke the build.

What happens when you compile these as modules?

I build as modules with no warning or error, did you find anything wrong?

diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 9c8eec8..8222a31 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -128,8 +128,27 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
return rtsx_pci_send_cmd(pcr, 100);
  }
  
+int rts5227_pm_reset(struct rtsx_pcr *pcr)

+{
+   int err;
+
+   /* init aspm */
+   err = rtsx_pci_update_cfg_byte(pcr, LCTLR, 0xFC, 0);
+   if (err < 0)
+   return err;
+
+   /* reset PM_CTRL3 before send buffer cmd */
+   return rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x00);
+}
+
  static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
  {
+   int err;
+
+   err = rts5227_pm_reset(pcr);
+   if (err < 0)
+   return err;
+
/* Optimize RX sensitivity */
return rtsx_pci_write_phy_register(pcr, 0x00, 0xBA42);
  }
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 573de7b..0f1b0e6 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -130,6 +130,10 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
  {
int err;
  
+	err = rts5227_pm_reset(pcr);

+   if (err < 0)
+   return err;

I don't like this.  Place rts52xx_pm_reset() somewhere more central.
Perhaps an inline function in the header would be better?

Thanks, I will fix later.

err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 07e4c2e..acc7a1e 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -72,4 +72,5 @@ do {  
\
pcr->ms_pull_ctl_disable_tbl = __device##_ms_pull_ctl_disable_tbl; \
  } while (0)
  
+int rts5227_pm_reset(struct rtsx_pcr *pcr);

  #endif
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..b34fec8 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -967,4 +967,16 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr 
*pcr)
return (u8 *)(pcr->host_cmds_ptr);
  }
  
+static inline int rtsx_pci_update_cfg_byte(struct rtsx_pcr *pcr, int addr,

+   u8 mask, u8 append)
+{
+   int err;
+   u8 val;
+
+   err = pci_read_config_byte(pcr->pci, addr, &val);
+   if (err < 0)
+   return err;
+   return pci_write_config_byte(pcr->pci, addr, (val & mask) | append);
+}
+
  #endif


--
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 1/3] phy: exynos-dp-video: Use syscon support to control pmu register

[Kishon Vijay Abraham I]

On Thursday 18 September 2014 08:55 AM, Vivek Gautam wrote:
> Hi Kishon,
> 
> 
> On Wed, Sep 17, 2014 at 10:24 PM, Kishon Vijay Abraham I  
> wrote:
>>
>>
>> On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
>>> Currently the DP_PHY_ENABLE register is mapped in the driver,
>>> and accessed to control power to the PHY.
>>> With mfd-syscon and regmap interface available at our disposal,
>>> it's wise to use that instead of using a 'reg' property for the
>>> controller and allocating a memory resource for that.
>>>
>>> To facilitate this, we have added another compatible string
>>> for Exynso5420 SoC to acquire driver data which contains
>>> different DP-PHY-CONTROL register offset.
>>>
>>> Signed-off-by: Vivek Gautam 
>>> Cc: Jingoo Han 
>>> Cc: Kishon Vijay Abraham I 
>>
>> Taking this in linux-phy tree. If someone has already taken this patch, 
>> please
>> let me know.
> 
> Thanks for taking this. But just one check, i think i need to separate
> out the Documentation
> to a separate patch even before this driver patch. Isn't it ?

no.. that's alright.

Thanks
Kishon
> 
>>
>> Thanks
>> Kishon
>>
>>> ---
>>>
>>> Changes since v2:
>>>  - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
>>>since that's available with us in "linux/mfd/syscon/exynos5-pmu.h" file.
>>>
>>> Changes since v1:
>>>  - state->regs should have been "struct regmap *" instead of
>>>"void __iomem *". So corrected the same.
>>>
>>>  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>>>  drivers/phy/phy-exynos-dp-video.c  |   79 
>>> +---
>>>  2 files changed, 59 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
>>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> index 7a6feea..15e0f2c 100644
>>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
>>>  -
>>>
>>>  Required properties:
>>> -- compatible : should be "samsung,exynos5250-dp-video-phy";
>>> -- reg : offset and length of the Display Port PHY register set;
>>> +- compatible : should be one of the following supported values:
>>> +  - "samsung,exynos5250-dp-video-phy"
>>> +  - "samsung,exynos5420-dp-video-phy"
>>> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
>>> +   control pmu registers for power isolation.
>>>  - #phy-cells : from the generic PHY bindings, must be 0;
>>>
>>>  Samsung S5P/EXYNOS SoC series USB PHY
>>> diff --git a/drivers/phy/phy-exynos-dp-video.c 
>>> b/drivers/phy/phy-exynos-dp-video.c
>>> index 8b3026e..53f44a0 100644
>>> --- a/drivers/phy/phy-exynos-dp-video.c
>>> +++ b/drivers/phy/phy-exynos-dp-video.c
>>> @@ -13,44 +13,55 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>> -/* DPTX_PHY_CONTROL register */
>>> -#define EXYNOS_DPTX_PHY_ENABLE   (1 << 0)
>>> +struct exynos_dp_video_phy_drvdata {
>>> + u32 phy_ctrl_offset;
>>> +};
>>>
>>>  struct exynos_dp_video_phy {
>>> - void __iomem *regs;
>>> + struct regmap *regs;
>>> + const struct exynos_dp_video_phy_drvdata *drvdata;
>>>  };
>>>
>>> -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int 
>>> on)
>>> +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
>>> + unsigned int on)
>>>  {
>>> - u32 reg;
>>> + unsigned int val;
>>> +
>>> + if (IS_ERR(state->regs))
>>> + return;
>>>
>>> - reg = readl(state->regs);
>>> - if (on)
>>> - reg |= EXYNOS_DPTX_PHY_ENABLE;
>>> - else
>>> - reg &= ~EXYNOS_DPTX_PHY_ENABLE;
>>> - writel(reg, state->regs);
>>> + val = on ? 0 : EXYNOS5_PHY_ENABLE;
>>>
>>> - return 0;
>>> + regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
>>> +EXYNOS5_PHY_ENABLE, val);
>>>  }
>>>
>>>  static int exynos_dp_video_phy_power_on(struct phy *phy)
>>>  {
>>>   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>>
>>> - return __set_phy_state(state, 1);
>>> + /* Disable power isolation on DP-PHY */
>>> + exynos_dp_video_phy_pwr_isol(state, 0);
>>> +
>>> + return 0;
>>>  }
>>>
>>>  static int exynos_dp_video_phy_power_off(struct phy *phy)
>>>  {
>>>   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>>
>>> - return __set_phy_state(state, 0);
>>> + /* Enable power isolation on DP-PHY */
>>> + exynos_dp_video_phy_pwr_isol(state, 1);
>>> +
>>> + return 0;
>>>  }
>>>
>>>  static struct phy_ops exynos_dp_video_phy_ops = {
>>> @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
>>>   .owner  = THI

[PATCH 2/3] f2fs: fix conditions to remain recovery information in f2fs_sync_file

[Jaegeuk Kim]

This patch revisited whole the recovery information during the f2fs_sync_file.

In this patch, there are three information to make a decision.

a) IS_CHECKPOINTED, /* is it checkpointed before? */
b) HAS_FSYNCED_INODE,   /* is the inode fsynced before? */
c) HAS_LAST_FSYNC,  /* has the latest node fsync mark? */

And, the scenarios for our rule are based on:

[Term] F: fsync_mark, D: dentry_mark

1. inode(x) | CP | inode(x) | dnode(F)
2. inode(x) | CP | inode(F) | dnode(F)
3. inode(x) | CP | dnode(F) | inode(x) | inode(F)
4. inode(x) | CP | dnode(F) | inode(F)
5. CP | inode(x) | dnode(F) | inode(DF)
6. CP | inode(DF) | dnode(F)
7. CP | dnode(F) | inode(DF)
8. CP | dnode(F) | inode(x) | inode(DF)

For example, #3, the three conditions should be changed as follows.

   inode(x) | CP | dnode(F) | inode(x) | inode(F)
a)x   o  o  o  o
b)x   x  x  x  o
c)x   o  o  x  o

If f2fs_sync_file stops   --^,
 it should write inode(F)--^

So, the need_inode_block_update should return true, since
 c) get_nat_flag(e, HAS_LAST_FSYNC), is false.

For example, #8,
  CP | alloc | dnode(F) | inode(x) | inode(DF)
a)o  xx  x  x
b)x   x  x  o
c)o   o  x  o

If f2fs_sync_file stops   ---^,
 it should write inode(DF)--^

Note that, the roll-forward policy should follow this rule, which means,
if there are any missing blocks, we doesn't need to recover that inode.

Signed-off-by: Huang Ying 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c |  3 ---
 fs/f2fs/f2fs.h |  6 +++---
 fs/f2fs/file.c | 10 ++
 fs/f2fs/node.c | 56 +++-
 fs/f2fs/node.h | 21 -
 5 files changed, 56 insertions(+), 40 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 0e37658..fdc3dbe 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1089,9 +1089,6 @@ static ssize_t f2fs_direct_IO(int rw, struct kiocb *iocb,
if (check_direct_IO(inode, rw, iter, offset))
return 0;
 
-   /* clear fsync mark to recover these blocks */
-   fsync_mark_clear(F2FS_I_SB(inode), inode->i_ino);
-
trace_f2fs_direct_IO_enter(inode, offset, count, rw);
 
err = blockdev_direct_IO(rw, iocb, inode, iter, offset, get_data_block);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 9fc1bcd..fd44083 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1224,9 +1224,9 @@ struct dnode_of_data;
 struct node_info;
 
 bool available_free_memory(struct f2fs_sb_info *, int);
-int is_checkpointed_node(struct f2fs_sb_info *, nid_t);
-bool fsync_mark_done(struct f2fs_sb_info *, nid_t);
-void fsync_mark_clear(struct f2fs_sb_info *, nid_t);
+bool is_checkpointed_node(struct f2fs_sb_info *, nid_t);
+bool has_fsynced_inode(struct f2fs_sb_info *, nid_t);
+bool need_inode_block_update(struct f2fs_sb_info *, nid_t);
 void get_node_info(struct f2fs_sb_info *, nid_t, struct node_info *);
 int get_dnode_of_data(struct dnode_of_data *, pgoff_t, int);
 int truncate_inode_blocks(struct inode *, pgoff_t);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index af06e22..3035c79 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -207,15 +207,17 @@ int f2fs_sync_file(struct file *file, loff_t start, 
loff_t end, int datasync)
up_write(&fi->i_sem);
}
} else {
-   /* if there is no written node page, write its inode page */
-   while (!sync_node_pages(sbi, ino, &wbc)) {
-   if (fsync_mark_done(sbi, ino))
-   goto out;
+sync_nodes:
+   sync_node_pages(sbi, ino, &wbc);
+
+   if (need_inode_block_update(sbi, ino)) {
mark_inode_dirty_sync(inode);
ret = f2fs_write_inode(inode, NULL);
if (ret)
goto out;
+   goto sync_nodes;
}
+
ret = wait_on_node_pages_writeback(sbi, ino);
if (ret)
goto out;
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index d19d6b1..7a2d9c9 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -123,44 +123,48 @@ static void __del_from_nat_cache(struct f2fs_nm_info 
*nm_i, struct nat_entry *e)
kmem_cache_free(nat_entry_slab, e);
 }
 
-int is_checkpointed_node(struct f2fs_sb_info *sbi, nid_t nid)
+bool is_checkpointed_node(struct f2fs_sb_info *sbi, nid_t nid)
 {
struct f2fs_nm_info *nm_i = NM_I(sbi);
struct nat_entry *e;
-   int is_cp = 1;
+   bool is_cp = true;
 
read_lock(&nm_i->nat_tree_lock);
e = __lookup_nat_cache(nm_i, nid);
if (e && !get_nat_flag(e, IS_CHECKPOINTED))
-   is_cp = 0;
+   is_cp = false;
read_unlock(&nm_i->nat_tree_lock

[PATCH 3/3] f2fs: fix roll-forward missing scenarios

[Jaegeuk Kim]

We can summarize the roll forward recovery scenarios as follows.

[Term] F: fsync_mark, D: dentry_mark

1. inode(x) | CP | inode(x) | dnode(F)
-> Update the latest inode(x).

2. inode(x) | CP | inode(F) | dnode(F)
-> No problem.

3. inode(x) | CP | dnode(F) | inode(x)
-> Recover to the latest dnode(F), and drop the last inode(x)

4. inode(x) | CP | dnode(F) | inode(F)
-> No problem.

5. CP | inode(x) | dnode(F)
-> The inode(DF) was missing. Should drop this dnode(F).

6. CP | inode(DF) | dnode(F)
-> No problem.

7. CP | dnode(F) | inode(DF)
-> If f2fs_iget fails, then goto next to find inode(DF).

8. CP | dnode(F) | inode(x)
-> If f2fs_iget fails, then goto next to find inode(DF).
   But it will fail due to no inode(DF).

So, this patch adds some missing points such as #1, #5, #7, and #8.

Signed-off-by: Huang Ying 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/recovery.c | 71 +-
 1 file changed, 60 insertions(+), 11 deletions(-)

diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 36d4f73..a4eb978 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -14,6 +14,37 @@
 #include "node.h"
 #include "segment.h"
 
+/*
+ * Roll forward recovery scenarios.
+ *
+ * [Term] F: fsync_mark, D: dentry_mark
+ *
+ * 1. inode(x) | CP | inode(x) | dnode(F)
+ * -> Update the latest inode(x).
+ *
+ * 2. inode(x) | CP | inode(F) | dnode(F)
+ * -> No problem.
+ *
+ * 3. inode(x) | CP | dnode(F) | inode(x)
+ * -> Recover to the latest dnode(F), and drop the last inode(x)
+ *
+ * 4. inode(x) | CP | dnode(F) | inode(F)
+ * -> No problem.
+ *
+ * 5. CP | inode(x) | dnode(F)
+ * -> The inode(DF) was missing. Should drop this dnode(F).
+ *
+ * 6. CP | inode(DF) | dnode(F)
+ * -> No problem.
+ *
+ * 7. CP | dnode(F) | inode(DF)
+ * -> If f2fs_iget fails, then goto next to find inode(DF).
+ *
+ * 8. CP | dnode(F) | inode(x)
+ * -> If f2fs_iget fails, then goto next to find inode(DF).
+ *But it will fail due to no inode(DF).
+ */
+
 static struct kmem_cache *fsync_entry_slab;
 
 bool space_for_roll_forward(struct f2fs_sb_info *sbi)
@@ -110,27 +141,32 @@ out:
return err;
 }
 
-static int recover_inode(struct inode *inode, struct page *node_page)
+static void __recover_inode(struct inode *inode, struct page *page)
 {
-   struct f2fs_inode *raw_inode = F2FS_INODE(node_page);
+   struct f2fs_inode *raw = F2FS_INODE(page);
+
+   inode->i_mode = le16_to_cpu(raw->i_mode);
+   i_size_write(inode, le64_to_cpu(raw->i_size));
+   inode->i_atime.tv_sec = le64_to_cpu(raw->i_mtime);
+   inode->i_ctime.tv_sec = le64_to_cpu(raw->i_ctime);
+   inode->i_mtime.tv_sec = le64_to_cpu(raw->i_mtime);
+   inode->i_atime.tv_nsec = le32_to_cpu(raw->i_mtime_nsec);
+   inode->i_ctime.tv_nsec = le32_to_cpu(raw->i_ctime_nsec);
+   inode->i_mtime.tv_nsec = le32_to_cpu(raw->i_mtime_nsec);
+}
 
+static int recover_inode(struct inode *inode, struct page *node_page)
+{
if (!IS_INODE(node_page))
return 0;
 
-   inode->i_mode = le16_to_cpu(raw_inode->i_mode);
-   i_size_write(inode, le64_to_cpu(raw_inode->i_size));
-   inode->i_atime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
-   inode->i_ctime.tv_sec = le64_to_cpu(raw_inode->i_ctime);
-   inode->i_mtime.tv_sec = le64_to_cpu(raw_inode->i_mtime);
-   inode->i_atime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
-   inode->i_ctime.tv_nsec = le32_to_cpu(raw_inode->i_ctime_nsec);
-   inode->i_mtime.tv_nsec = le32_to_cpu(raw_inode->i_mtime_nsec);
+   __recover_inode(inode, node_page);
 
if (is_dent_dnode(node_page))
return recover_dentry(node_page, inode);
 
f2fs_msg(inode->i_sb, KERN_NOTICE, "recover_inode: ino = %x, name = %s",
-   ino_of_node(node_page), raw_inode->i_name);
+   ino_of_node(node_page), F2FS_INODE(node_page)->i_name);
return 0;
 }
 
@@ -183,10 +219,16 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi, 
struct list_head *head)
break;
}
 
+   /*
+* CP | dnode(F) | inode(DF)
+* For this case, we should not give up now.
+*/
entry->inode = f2fs_iget(sbi->sb, ino_of_node(page));
if (IS_ERR(entry->inode)) {
err = PTR_ERR(entry->inode);
kmem_cache_free(fsync_entry_slab, entry);
+   if (err == -ENOENT)
+   goto next;
break;
}
list_add_tail(&entry->list, head);
@@ -423,6 +465,13 @@ static int recover_data(struct f2fs_sb_info *sbi,
entry = get_fsync_inode(head, ino_of_node(page));
if (!entry)
goto next;
+   

Re: [PATCHv5] mtd: nand: atmel_nand: retrieve NFC clock

[Brian Norris]

On Sat, Sep 13, 2014 at 01:23:59AM +0200, Alexandre Belloni wrote:
> From: Boris BREZILLON 
> 
> Retrieve the NFC clock to make sure it is enabled. Make that optional to 
> ensure
> compatibility with previous device trees but document it as mandatory so newer
> device trees will include it.
> 
> Signed-off-by: Boris BREZILLON 
> Signed-off-by: Alexandre Belloni 
> Acked-by: Josh Wu 
> ---
> Changes in v5:
>  - Added a proper commit log

Pushed to l2-mtd.git. Thanks!

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

Re: [PATCH] f2fs: Fix recover when nid of non-inode dnode < nid of inode

[Jaegeuk Kim]

On Mon, Sep 15, 2014 at 01:14:09PM +0800, Huang Ying wrote:
> On Sun, 2014-09-14 at 00:48 -0700, Jaegeuk Kim wrote:
> > On Sat, Sep 13, 2014 at 10:23:18PM +0800, Huang Ying wrote:
> > > On Fri, 2014-09-12 at 15:34 +0800, Huang Ying wrote:
> > > > On Thu, 2014-09-11 at 22:13 -0700, Jaegeuk Kim wrote:
> > > > > On Thu, Sep 11, 2014 at 08:25:17PM +0800, Huang Ying wrote:
> > > > > > 
> > > > > > On Wed, 2014-09-10 at 22:37 -0700, Jaegeuk Kim wrote:
> > > > > > > On Wed, Sep 10, 2014 at 07:08:32PM +0800, huang ying wrote:
> > > > > > > > On Wed, Sep 10, 2014 at 3:21 PM, Jaegeuk Kim 
> > > > > > > >  wrote:
> > > > > > > > 
> > > > > > > > > On Tue, Sep 09, 2014 at 07:31:49PM +0800, huang ying wrote:
> > > > > > > > > > On Tue, Sep 9, 2014 at 3:09 PM, Jaegeuk Kim 
> > > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Sep 09, 2014 at 01:39:30PM +0800, Huang Ying 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Mon, 2014-09-08 at 22:23 -0700, Jaegeuk Kim wrote:
> > > > > > > > > > > > > Hi Huang,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Sep 08, 2014 at 07:38:26PM +0800, Huang Ying 
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > For fsync, if the nid of a non-inode dnode < nid of 
> > > > > > > > > > > > > > inode and the
> > > > > > > > > > > > > > inode is not checkpointed.  The non-inode dnode may 
> > > > > > > > > > > > > > be written
> > > > > > > > > before
> > > > > > > > > > > > > > inode.  So in find_fsync_dnodes, f2fs_iget will 
> > > > > > > > > > > > > > fail, cause the
> > > > > > > > > > > > > > recovery fail.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Usually, inode will be allocated before non-inode 
> > > > > > > > > > > > > > dnode, so the
> > > > > > > > > nid
> > > > > > > > > > > of
> > > > > > > > > > > > > > inode < nid of non-inode dnode.  But it is possible 
> > > > > > > > > > > > > > for the
> > > > > > > > > reverse.
> > > > > > > > > > > > > > For example, because of alloc_nid_failed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This is fixed via ignoring non-inode dnode before 
> > > > > > > > > > > > > > inode dnode in
> > > > > > > > > > > > > > find_fsync_dnodes.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The patch was tested via allocating nid reversely 
> > > > > > > > > > > > > > via a debugging
> > > > > > > > > > > > > > patch, that is, from big number to small number.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Huang, Ying 
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >  fs/f2fs/recovery.c |7 ---
> > > > > > > > > > > > > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --- a/fs/f2fs/recovery.c
> > > > > > > > > > > > > > +++ b/fs/f2fs/recovery.c
> > > > > > > > > > > > > > @@ -172,8 +172,8 @@ static int 
> > > > > > > > > > > > > > find_fsync_dnodes(struct f2fs
> > > > > > > > > > > > > >   if (IS_INODE(page) && 
> > > > > > > > > > > > > > is_dent_dnode(page))
> > > > > > > > > > > > > >   
> > > > > > > > > > > > > > set_inode_flag(F2FS_I(entry->inode),
> > > > > > > > > > > > > >   
> > > > > > > > > > > > > > FI_INC_LINK);
> > > > > > > > > > > > > > - } else {
> > > > > > > > > > > > > > - if (IS_INODE(page) && 
> > > > > > > > > > > > > > is_dent_dnode(page)) {
> > > > > > > > > > > > >
> > > > > > > > > > > > > If this is not inode block, we should add this inode 
> > > > > > > > > > > > > to recover its
> > > > > > > > > > > data blocks.
> > > > > > > > > > > >
> > > > > > > > > > > > Is it possible that there is only non-inode dnode but 
> > > > > > > > > > > > no inode when
> > > > > > > > > > > > find_fsync_dnodes checking dnodes?  Per my 
> > > > > > > > > > > > understanding, any
> > > > > > > > > changes to
> > > > > > > > > > > > file will cause inode page dirty (for example, mtime 
> > > > > > > > > > > > changed), so
> > > > > > > > > that
> > > > > > > > > > > > we will write inode block.  Is it right?  If so, the 
> > > > > > > > > > > > solution in this
> > > > > > > > > > > > patch should work too.
> > > > > > > > > > >
> > > > > > > > > > > Your description says that f2fs_iget will fail, which 
> > > > > > > > > > > causes the
> > > > > > > > > recovery
> > > > > > > > > > > fail.
> > > > > > > > > > > So, I thought it would be better to handle the f2fs_iget 
> > > > > > > > > > > failure
> > > > > > > > > directly.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Yes.  That is another way to fix the issue.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > In addition, we cannot guarantee the write order of dnode 
> > > > > > > > > > > and inode.
> > > > > > > > > > > For exmaple,
> > > > > > > > > > > 1. the inode is written by flusher or kswapd, then,
> > > > > > >

Re: [PATCH] [trivial] wireless:rtlwifi: Fix typo in rtl wifi drivers

[Larry Finger]

On 09/17/2014 10:29 PM, Masanari Iida wrote:

This patch fix spelling typo "sleeped" in printk, found in
multiple rtlwifi drivers.

Signed-off-by: Masanari Iida 
---
  drivers/net/wireless/rtlwifi/rtl8188ee/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8192ce/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8192cu/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8723ae/phy.c | 2 +-
  drivers/net/wireless/rtlwifi/rtl8723be/phy.c | 2 +-
  7 files changed, 7 insertions(+), 7 deletions(-)


John,

Please do not apply this patch for two reasons. (1) It would interfere with the 
major changes that I will be sending in the next few days. (2) I have been 
favoring "sleeping" over "slept" as a substitute for "sleeped". If I change my 
mind, I will resubmit this patch with Masanari as the author.


Thanks,

Larry

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

Re: [PATCH v4 1/3] mfd/axp20x: extend axp20x to support axp288 pmic

[Lee Jones]

On Tue, 16 Sep 2014, Jacob Pan wrote:

> X-Powers AXP288 is a customized PMIC for Intel Baytrail-CR platforms. Similar
> to AXP202/209, AXP288 comes with USB charger, more LDO and BUCK channels, and
> AD converters. It also provides extended status and interrupt reporting
> capabilities than the devices currently supported in axp20x.c.
> 
> In addition to feature extension, this patch also adds ACPI binding for
> enumeration.
> 
> This consolidated driver should support more X-Powers' PMICs in both device
> tree and ACPI enumerated platforms.
> 
> Signed-off-by: Jacob Pan 
> ---
>  drivers/mfd/Kconfig|   3 +-
>  drivers/mfd/axp20x.c   | 353 
> +
>  include/linux/mfd/axp20x.h |  58 
>  3 files changed, 354 insertions(+), 60 deletions(-)
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index de5abf2..c183edb 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -74,7 +74,8 @@ config MFD_AXP20X
>   select REGMAP_IRQ
>   depends on I2C=y
>   help
> -   If you say Y here you get support for the X-Powers AXP202 and AXP209.
> +   If you say Y here you get support for the X-Powers AXP202, AXP209 and
> +   AXP288 power management IC (PMIC).
> This driver include only the core APIs. You have to select individual
> components like regulators or the PEK (Power Enable Key) under the
> corresponding menus.

[...]

> -static const struct regmap_config axp20x_regmap_config = {

[...]

> +static struct regmap_config axp20x_regmap_config = {

Why have you removed const status?

>   .reg_bits   = 8,
>   .val_bits   = 8,
>   .wr_table   = &axp20x_writeable_table,
> @@ -70,47 +129,96 @@ static const struct regmap_config axp20x_regmap_config = 
> {
>   .cache_type = REGCACHE_RBTREE,
>  };
>  
> -#define AXP20X_IRQ(_irq, _off, _mask) \
> - [AXP20X_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
> +static struct regmap_config axp288_regmap_config = {

const?

> + .reg_bits   = 8,
> + .val_bits   = 8,
> + .wr_table   = &axp288_writeable_table,
> + .volatile_table = &axp288_volatile_table,
> + .max_register   = AXP288_FG_TUNE5,
> + .cache_type = REGCACHE_RBTREE,
> +};

[...]

> -static const struct regmap_irq_chip axp20x_regmap_irq_chip = {
> +static struct acpi_device_id axp20x_acpi_match[] = {
> + {
> + .id = "INT33F4",
> + .driver_data = (kernel_ulong_t)AXP288_ID,

Why do you need to cast this?

> + },
> + { },
> +};
> +MODULE_DEVICE_TABLE(acpi, axp20x_acpi_match);
> +
> +/* common irq chip attributes only */
> +static struct regmap_irq_chip axp20x_regmap_irq_chip = {
>   .name   = "axp20x_irq_chip",
>   .status_base= AXP20X_IRQ1_STATE,
>   .ack_base   = AXP20X_IRQ1_STATE,
>   .mask_base  = AXP20X_IRQ1_EN,
> - .num_regs   = 5,
> - .irqs   = axp20x_regmap_irqs,
> - .num_irqs   = ARRAY_SIZE(axp20x_regmap_irqs),
>   .mask_invert= true,
>   .init_ack_masked= true,
>  };
> @@ -161,36 +276,155 @@ static struct mfd_cell axp20x_cells[] = {
>   },
>  };

[...]

> +static int axp20x_match_device(struct axp20x_dev *axp20x, struct device *dev)
> +{
> + const struct acpi_device_id *acpi_id;
> + const struct of_device_id *of_id;
> +
> + of_id = of_match_device(axp20x_of_match, dev);
> + if (of_id)
> + axp20x->variant = (long) of_id->data;
> + else {
> + acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
> + if (!acpi_id || !acpi_id->driver_data) {
> + dev_err(dev, "Unable to determine ID\n");
> + return -ENODEV;
> + }
> + axp20x->variant = (long) acpi_id->driver_data;
> + }

We can do better error handling here and give the user a better sense
of what happened if anything were to go wrong.  Do:

if (dev->of_node)
  of_id = of_match_device()
  if (!of_id)
error()
  variant = of_id->data;
else
  acpi_id = acpi_match_device()
  if (!acpi_id)
error()
  variant = acpi_id->driver_data;

> + switch (axp20x->variant) {
> + case AXP202_ID:
> + case AXP209_ID:
> + axp20x->nr_cells = ARRAY_SIZE(axp20x_cells);
> + axp20x->cells = axp20x_cells;
> + axp20x->regmap_cfg = &axp20x_regmap_config;
> + axp20x_regmap_irq_chip.num_regs = 5;
> + axp20x_regmap_irq_chip.irqs = axp20x_regmap_irqs;
> + axp20x_regmap_irq_chip.num_irqs =
> + ARRAY_SIZE(axp20x_regmap_irqs);
> + break;
> + case AXP288_ID:
> + axp20x->cells = axp288_cells;
> + axp20x->nr_cells = ARRAY_SIZE(axp288_cells);
> + axp20x->regmap_cfg = &axp288_regmap_config;
> + axp20x_regmap_irq_chi

Re: [f2fs-dev] [PATCH 04/10] f2fs: give an option to enable in-place-updates during fsync to users

[Jaegeuk Kim]

On Mon, Sep 15, 2014 at 11:13:15AM +0900, Changman Lee wrote:
> Hi JK,
> 
> I think it' nicer if this can be used as 'OR' with other policy
> together. If so, we can also cover the weakness in high utilization.

Agreed.
I'll send another patch for that.
Thanks,

> 
> Regard,
> Changman
> 
> On Sun, Sep 14, 2014 at 03:14:18PM -0700, Jaegeuk Kim wrote:
> > If user wrote F2FS_IPU_FSYNC:4 in /sys/fs/f2fs/ipu_policy, f2fs_sync_file
> > only starts to try in-place-updates.
> > And, if the number of dirty pages is over /sys/fs/f2fs/min_fsync_blocks, it
> > keeps out-of-order manner. Otherwise, it triggers in-place-updates.
> > 
> > This may be used by storage showing very high random write performance.
> > 
> > For example, it can be used when,
> > 
> > Seq. writes (Data) + wait + Seq. writes (Node)
> > 
> > is pretty much slower than,
> > 
> > Rand. writes (Data)
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  Documentation/ABI/testing/sysfs-fs-f2fs |  7 +++
> >  Documentation/filesystems/f2fs.txt  |  9 -
> >  fs/f2fs/f2fs.h  |  1 +
> >  fs/f2fs/file.c  |  7 +++
> >  fs/f2fs/segment.c   |  3 ++-
> >  fs/f2fs/segment.h   | 14 ++
> >  fs/f2fs/super.c |  2 ++
> >  7 files changed, 33 insertions(+), 10 deletions(-)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs 
> > b/Documentation/ABI/testing/sysfs-fs-f2fs
> > index 62dd725..6f9157f 100644
> > --- a/Documentation/ABI/testing/sysfs-fs-f2fs
> > +++ b/Documentation/ABI/testing/sysfs-fs-f2fs
> > @@ -44,6 +44,13 @@ Description:
> >  Controls the FS utilization condition for the in-place-update
> >  policies.
> >  
> > +What:  /sys/fs/f2fs//min_fsync_blocks
> > +Date:  September 2014
> > +Contact:   "Jaegeuk Kim" 
> > +Description:
> > +Controls the dirty page count condition for the in-place-update
> > +policies.
> > +
> >  What:  /sys/fs/f2fs//max_small_discards
> >  Date:  November 2013
> >  Contact:   "Jaegeuk Kim" 
> > diff --git a/Documentation/filesystems/f2fs.txt 
> > b/Documentation/filesystems/f2fs.txt
> > index a2046a7..d010da8 100644
> > --- a/Documentation/filesystems/f2fs.txt
> > +++ b/Documentation/filesystems/f2fs.txt
> > @@ -194,13 +194,20 @@ Files in /sys/fs/f2fs/
> >updates in f2fs. There are five policies:
> > 0: F2FS_IPU_FORCE, 1: F2FS_IPU_SSR,
> > 2: F2FS_IPU_UTIL,  3: F2FS_IPU_SSR_UTIL,
> > -   4: F2FS_IPU_DISABLE.
> > +   4: F2FS_IPU_FSYNC, 5: F2FS_IPU_DISABLE.
> >  
> >   min_ipu_util This parameter controls the threshold to 
> > trigger
> >in-place-updates. The number indicates 
> > percentage
> >of the filesystem utilization, and used by
> >F2FS_IPU_UTIL and F2FS_IPU_SSR_UTIL policies.
> >  
> > + min_fsync_blocks This parameter controls the threshold to 
> > trigger
> > +  in-place-updates when F2FS_IPU_FSYNC mode is 
> > set.
> > + The number indicates the number of dirty pages
> > + when fsync needs to flush on its call path. If
> > + the number is less than this value, it triggers
> > + in-place-updates.
> > +
> >   max_victim_search   This parameter controls the number of trials to
> >   find a victim segment when conducting SSR and
> >   cleaning operations. The default value is 4096
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 2756c16..4f84d2a 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -386,6 +386,7 @@ struct f2fs_sm_info {
> >  
> > unsigned int ipu_policy;/* in-place-update policy */
> > unsigned int min_ipu_util;  /* in-place-update threshold */
> > +   unsigned int min_fsync_blocks;  /* threshold for fsync */
> >  
> > /* for flush command control */
> > struct flush_cmd_control *cmd_control_info;
> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > index 77426c7..af06e22 100644
> > --- a/fs/f2fs/file.c
> > +++ b/fs/f2fs/file.c
> > @@ -154,12 +154,11 @@ int f2fs_sync_file(struct file *file, loff_t start, 
> > loff_t end, int datasync)
> > trace_f2fs_sync_file_enter(inode);
> >  
> > /* if fdatasync is triggered, let's do in-place-update */
> > -   if (datasync)
> > +   if (get_dirty_pages(inode) <= SM_I(sbi)->min_fsync_blocks)
> > set_inode_flag(fi, FI_NEED_IPU);
> > -
> > ret = filemap_write_and_wait_range(inode->i_mapping, start, end);
> > -   if (datasync)
> > -   clear_inode_flag(fi, FI_NEED_IPU);
> > +   clear_inode_flag(fi, FI_NEED_IPU);
>

Re: [PATCH 09/10] f2fs: use MAX_BIO_BLOCKS(sbi)

[Jaegeuk Kim]

Hi,

Thank you for the review.
I changed the return value of MAX_BIO_BLOCKS to int.
IMO, it's the best way that I can do for now.

Thanks,

>From f3bcd1d658d1c4aa8178ddc2d4e6a7e45d8405cd Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Thu, 11 Sep 2014 14:37:35 -0700
Subject: [PATCH] f2fs: use MAX_BIO_BLOCKS(sbi)

Change log from v1:
 o change the return value of MAX_BIO_BLOCKS to int type.

This patch cleans up a simple macro.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 2 +-
 fs/f2fs/node.c | 2 +-
 fs/f2fs/recovery.c | 4 ++--
 fs/f2fs/segment.c  | 2 +-
 fs/f2fs/segment.h  | 8 
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index fdc3dbe..7749f30 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -193,7 +193,7 @@ void f2fs_submit_page_mbio(struct f2fs_sb_info *sbi, struct 
page *page,
__submit_merged_bio(io);
 alloc_new:
if (io->bio == NULL) {
-   int bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   int bio_blocks = MAX_BIO_BLOCKS(sbi);
 
io->bio = __bio_alloc(sbi, blk_addr, bio_blocks, is_read);
io->fio = *fio;
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 7a2d9c9..21ed91b 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1697,7 +1697,7 @@ int restore_node_summary(struct f2fs_sb_info *sbi,
struct f2fs_summary *sum_entry;
struct inode *inode = sbi->sb->s_bdev->bd_inode;
block_t addr;
-   int bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   int bio_blocks = MAX_BIO_BLOCKS(sbi);
struct page *pages[bio_blocks];
int i, idx, last_offset, nrpages, err = 0;
 
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 78ef10c..1ccee36 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -180,7 +180,7 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi, 
struct list_head *head)
page = get_meta_page(sbi, blkaddr);
 
ra_meta_pages(sbi, next_blkaddr_of_node(page),
-   MAX_BIO_BLOCKS(max_hw_blocks(sbi)), META_POR);
+   MAX_BIO_BLOCKS(sbi), META_POR);
 
if (cp_ver != cpver_of_node(page))
break;
@@ -444,7 +444,7 @@ static int recover_data(struct f2fs_sb_info *sbi,
page = get_meta_page(sbi, blkaddr);
 
ra_meta_pages(sbi, next_blkaddr_of_node(page),
-   MAX_BIO_BLOCKS(max_hw_blocks(sbi)), META_POR);
+   MAX_BIO_BLOCKS(sbi), META_POR);
 
if (cp_ver != cpver_of_node(page)) {
f2fs_put_page(page, 1);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index c6f627b..4ea53aa 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1757,7 +1757,7 @@ static void build_sit_entries(struct f2fs_sb_info *sbi)
int sit_blk_cnt = SIT_BLK_CNT(sbi);
unsigned int i, start, end;
unsigned int readed, start_blk = 0;
-   int nrpages = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   int nrpages = MAX_BIO_BLOCKS(sbi);
 
do {
readed = ra_meta_pages(sbi, start_blk, nrpages, META_SIT);
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index c6f37f2..633e822 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -93,8 +93,8 @@
(((sector_t)blk_addr) << (sbi)->log_sectors_per_block)
 #define SECTOR_TO_BLOCK(sbi, sectors)  \
(sectors >> (sbi)->log_sectors_per_block)
-#define MAX_BIO_BLOCKS(max_hw_blocks)  \
-   (min((int)max_hw_blocks, BIO_MAX_PAGES))
+#define MAX_BIO_BLOCKS(sbi)\
+   ((int)min(max_hw_blocks(sbi), BIO_MAX_PAGES))
 
 /*
  * indicate a block allocation direction: RIGHT and LEFT.
@@ -728,7 +728,7 @@ static inline int nr_pages_to_skip(struct f2fs_sb_info 
*sbi, int type)
else if (type == NODE)
return 3 * sbi->blocks_per_seg;
else if (type == META)
-   return MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   return MAX_BIO_BLOCKS(sbi);
else
return 0;
 }
@@ -751,7 +751,7 @@ static inline long nr_pages_to_write(struct f2fs_sb_info 
*sbi, int type,
else if (type == NODE)
desired = 3 * max_hw_blocks(sbi);
else
-   desired = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+   desired = MAX_BIO_BLOCKS(sbi);
 
wbc->nr_to_write = desired;
return desired - nr_to_write;
-- 
1.8.5.2 (Apple Git-48)

--
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 7/9] phy: remove .owner field for drivers using module_platform_driver

[Kishon Vijay Abraham I]

On Thursday 18 September 2014 12:34 AM, Peter Griffin wrote:
> Hi Kishon,
> 
> On Wed, 17 Sep 2014, Kishon Vijay Abraham I wrote:
> 
>> Hi,
>>
>> On Friday 15 August 2014 06:10 PM, Peter Griffin wrote:
>>> This patch removes the superflous .owner field for drivers which
>>> use the module_platform_driver or platform_driver_register api,
>>> as this is overriden in __platform_driver_register.
>>>
>>> Signed-off-by: Peter Griffin 
> 
> 
>>>  drivers/phy/phy-twl4030-usb.c   | 1 -
>>
>> twl4030-usb doesn't use module_platform_driver. Care to resend this patch
>> along? I've merged all other patches in this series.
> 
> That is true, but it does use platform_driver_register  whih overrides .owner.
> So the patch is stil good I think (fyi see include/linux/platform_device.h).

Indeed. Will merge this one.

Thanks
Kishon
--
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] mmc: don't request CD IRQ until mmc_start_host()

[Adrian Hunter]

On 09/17/2014 10:57 PM, Stephen Warren wrote:
> On 09/17/2014 01:55 PM, Ulf Hansson wrote:
>> On 12 September 2014 19:18, Stephen Warren  wrote:
>>> From: Stephen Warren 
>>>
>>> As soon as the CD IRQ is requested, it can trigger, since it's an
>>> externally controlled event. If it does, delayed_work host->detect will
>>> be scheduled.
>>>
>>> Many host controller probe()s are roughly structured as:
>>>
>>> *_probe() {
>>>  host = sdhci_pltfm_init();
>>>  mmc_of_parse(host->mmc);
>>>  rc = sdhci_add_host(host);
>>>  if (rc) {
>>>  sdhci_pltfm_free();
>>>  return rc;
>>>  }
>>>
>>> In 3.17, CD IRQs can are enabled quite early via *_probe() ->
>>> mmc_of_parse() -> mmc_gpio_request_cd() -> mmc_gpiod_request_cd_irq().
>>>
>>> Note that in linux-next, mmc_of_parse() calls mmc_gpio*d*_request_cd()
>>> rather than mmc_gpio_request_cd(), and mmc_gpio*d*_request_cd() doesn't
>>> call mmc_gpiod_request_cd_irq(). However, this issue still exists for
>>> any other direct users of mmc_gpio_request_cd().
>>>
>>> sdhci_add_host() may fail part way through (e.g. due to deferred
>>> probe for a vmmc regulator), and sdhci_pltfm_free() does nothing to
>>> unrequest the CD IRQ nor cancel the delayed_work. sdhci_pltfm_free() is
>>> coded to assume that if sdhci_add_host() failed, then the delayed_work
>>> cannot (or should not) have been triggered.
>>>
>>> This can lead to the following with CONFIG_DEBUG_OBJECTS_* enabled, when
>>> kfree(host) is eventually called inside sdhci_pltfm_free():
>>>
>>> WARNING: CPU: 2 PID: 6 at lib/debugobjects.c:263
>>> debug_print_object+0x8c/0xb4()
>>> ODEBUG: free active (active state 0) object type: timer_list hint:
>>> delayed_work_timer_fn+0x0/0x18
>>>
>>> The object being complained about is host->detect.
>>>
>>> There's no need to request the CD IRQ so early; mmc_start_host() already
>>> requests it, and I *assume* that mmc_start_host() is called somehow for
>>> all host controllers. For SDHCI hosts at least, the typical call path
>>> that does this is: *_probe() -> sdhci_add_host() -> mmc_add_host() ->
>>> mmc_start_host(). So, remove the call to mmc_gpiod_request_cd_irq() from
>>> mmc_gpio_request_cd(). This matches mmc_gpio*d*_request_cd(), which
>>> already doesn't call mmc_gpiod_request_cd_irq().
>>>
>>> This solves the problem (eliminates the kernel error message above),
>>> since it guarantees that the IRQ can't trigger before mmc_start_host()
>>> is called.
>>>
>>> The critical point here is that once sdhci_add_host() calls
>>> mmc_add_host() -> mmc_start_host(), sdhci_add_host() is coded not to
>>> fail. In other words, if there's a chance that mmc_start_host() may have
>>> been called, and CD IRQs triggered, and the delayed_work scheduled,
>>> sdhci_add_host() won't fail, and so cleanup is no longer via
>>> sdhci_pltfm_free() (which doesn't free the IRQ or cancel the work queue)
>>> but instead must be via sdhci_remove_host(), which calls mmc_remove_host()
>>> -> mmc_stop_host(), which does free the IRQ and cancel the work queue.
>>>
>>> This fixes what I might conclude to be a mistake in commit 740a221ef0e5
>>> ("mmc: slot-gpio: Add GPIO descriptor based CD GPIO API"), which added the
>>> call from mmc_start_host() to mmc_gpiod_request_cd_irq(), but also added
>>> incorrectly added a call from mmc_gpio_request_cd() to
>>> mmc_gpiod_request_cd_irq().
>>>
>>> CC: Russell King 
>>> Cc: Adrian Hunter 
>>> Cc: Alexandre Courbot 
>>> Cc: Linus Walleij 
>>> Signed-off-by: Stephen Warren 
>>
>> Hi Stephen,
>>
>> Thanks for looking into this. It seems like this issue has been
>> present for quite a while.
>> I believe your patch should have a stable tag for 3.15+ as well,
>> unless you object I will add it.
> 
> Yes, that probably makes sense, thanks.

Doesn't this patch break the drivers that call mmc_gpio_request_cd() after
mmc_add_host() like mmc_spi.c or sdhci-sirf.c or tmio_mmc_pio.c ?

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

[PATCH V2 2/3] x86: iosf: Add better description of IOSF driver in config

[David E. Box]

Adds better description of IOSF driver to determinine when it should be enabled.
Also moves the Kconfig option to "Processor type and features" menu from main
configuration menu.

Signed-off-by: David E. Box 
---
 arch/x86/Kconfig | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bcbb57d..b075873 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -480,6 +480,23 @@ config X86_INTEL_LPSS
  things like clock tree (common clock framework) and pincontrol
  which are needed by the LPSS peripheral drivers.
 
+config IOSF_MBI
+   tristate "Intel SoC IOSF Sideband support for SoC platforms"
+   depends on PCI
+   ---help---
+ This option enables sideband register access support for Intel SoC
+ platforms. On these platforms the IOSF sideband is used in lieu of
+ MSR's for some register accesses, mostly but not limited to thermal
+ and power. Drivers may query the availability of this device to
+ determine if they need the sideband in order to work on these
+ platforms. The sideband is available on the following SoC products.
+ This list is not meant to be exclusive.
+  - BayTrail
+  - Braswell
+  - Quark
+
+ You should say Y if you are running a kernel on one of these SoC's.
+
 config X86_RDC321X
bool "RDC R-321x SoC"
depends on X86_32
@@ -2443,21 +2460,6 @@ config X86_DMA_REMAP
bool
depends on STA2X11
 
-config IOSF_MBI
-   tristate "Intel System On Chip IOSF Sideband support"
-   depends on PCI
-   ---help---
- Enables sideband access to mailbox registers on SoC's. The sideband is
- available on the following platforms. This list is not meant to be
- exclusive.
-  - BayTrail
-  - Cherryview
-  - Braswell
-  - Quark
-
- You should say Y if you are running a kernel on one of these
- platforms.
-
 config PMC_ATOM
def_bool y
 depends on PCI
-- 
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 V2 1/3] x86: iosf: Add Braswell PCI ID

[David E. Box]

Add Braswell PCI ID to list of supported ID's for iosf driver.

Signed-off-by: David E. Box 
---
 arch/x86/kernel/iosf_mbi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/iosf_mbi.c b/arch/x86/kernel/iosf_mbi.c
index 0a2faa3..e01f741 100644
--- a/arch/x86/kernel/iosf_mbi.c
+++ b/arch/x86/kernel/iosf_mbi.c
@@ -28,6 +28,7 @@
 #include 
 
 #define PCI_DEVICE_ID_BAYTRAIL 0x0F00
+#define PCI_DEVICE_ID_BRASWELL 0x2280
 #define PCI_DEVICE_ID_QUARK_X1000  0x0958
 
 static DEFINE_SPINLOCK(iosf_mbi_lock);
@@ -275,6 +276,7 @@ static int iosf_mbi_probe(struct pci_dev *pdev,
 
 static const struct pci_device_id iosf_mbi_pci_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_BAYTRAIL) },
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_BRASWELL) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_QUARK_X1000) },
{ 0, },
 };
-- 
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 V2 3/3] x86: iosf: Add debugfs config option for iosf

[David E. Box]

Makes the iosf sideband available through debugfs. Allows developers to
experiment with using the sideband to provide debug and analytical tools for
units on the SoC.

Signed-off-by: David E. Box 
---
 arch/x86/Kconfig   | 13 +
 arch/x86/kernel/iosf_mbi.c | 23 +++
 2 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b075873..39489d6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -497,6 +497,19 @@ config IOSF_MBI
 
  You should say Y if you are running a kernel on one of these SoC's.
 
+config IOSF_MBI_DEBUG
+   bool "Enable IOSF sideband access through debugfs"
+   depends on IOSF_MBI && DEBUG_FS
+   ---help---
+ Select this option to expose the IOSF sideband access registers (MCR,
+ MDR, MCRX) through debugfs to write and read register information from
+ different units on the SoC. This is most useful for obtaining device
+ state information for debug and analysis. As this is a general access
+ mechanism, users of this option would have specific knowledge of the
+ device they want to access.
+
+ If you don't require the option or are in doubt, say N.
+
 config X86_RDC321X
bool "RDC R-321x SoC"
depends on X86_32
diff --git a/arch/x86/kernel/iosf_mbi.c b/arch/x86/kernel/iosf_mbi.c
index e01f741..82f8d02 100644
--- a/arch/x86/kernel/iosf_mbi.c
+++ b/arch/x86/kernel/iosf_mbi.c
@@ -190,7 +190,7 @@ bool iosf_mbi_available(void)
 }
 EXPORT_SYMBOL(iosf_mbi_available);
 
-/** debugfs begin /
+#ifdef CONFIG_IOSF_MBI_DEBUG
 static u32 dbg_mdr;
 static u32 dbg_mcr;
 static u32 dbg_mcrx;
@@ -229,6 +229,7 @@ static int mcr_set(void *data, u64 val)
 DEFINE_SIMPLE_ATTRIBUTE(iosf_mcr_fops, mcr_get, mcr_set , "%llx\n");
 
 static struct dentry *iosf_dbg;
+
 static void iosf_sideband_debug_init(void)
 {
struct dentry *d;
@@ -257,7 +258,20 @@ static void iosf_sideband_debug_init(void)
 cleanup:
debugfs_remove_recursive(d);
 }
-/** debugfs end /
+
+static void iosf_debugfs_init(void)
+{
+   iosf_sideband_debug_init();
+}
+
+static void iosf_debugfs_remove(void)
+{
+   debugfs_remove_recursive(iosf_dbg);
+}
+#else
+static inline void iosf_debugfs_init(void) { }
+static inline void iosf_debugfs_remove(void) { }
+#endif /* CONFIG_IOSF_MBI_DEBUG */
 
 static int iosf_mbi_probe(struct pci_dev *pdev,
  const struct pci_device_id *unused)
@@ -290,13 +304,14 @@ static struct pci_driver iosf_mbi_pci_driver = {
 
 static int __init iosf_mbi_init(void)
 {
-   iosf_sideband_debug_init();
+   iosf_debugfs_init();
+
return pci_register_driver(&iosf_mbi_pci_driver);
 }
 
 static void __exit iosf_mbi_exit(void)
 {
-   debugfs_remove_recursive(iosf_dbg);
+   iosf_debugfs_remove();
 
pci_unregister_driver(&iosf_mbi_pci_driver);
if (mbi_pdev) {
-- 
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 V2 0/3] x86: iosf: Additions to iosf patch set

[David E. Box]

These changes apply on top of the patches currently in Peter Anvin's tip tree.

V2: More descriptive Kconfig prompt for IOSF_MBI and IOSF_MBI_DEBUG
Cleaned up ifdef use on IOSF_MBI_DEBUG with DUMMY functions

David E. Box (3):
  x86: iosf: Add Braswell PCI ID
  x86: iosf: Add better description of IOSF driver in config
  x86: iosf: Add debugfs config option for iosf

 arch/x86/Kconfig   | 45 ++---
 arch/x86/kernel/iosf_mbi.c | 25 +
 2 files changed, 51 insertions(+), 19 deletions(-)

-- 
1.9.1

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

Re: [PATCH] serial: cadence: Add generic earlycon support

[Michal Simek]

On 09/17/2014 10:58 PM, Greg Kroah-Hartman wrote:
> On Wed, Sep 17, 2014 at 03:44:58PM +0200, Michal Simek wrote:
>> Hi Greg,
>>
>> On 09/10/2014 12:43 PM, Michal Simek wrote:
>>> Add earlycon support for the cadence serial port.
>>> This is based on recent patches:
>>> "tty/serial: pl011: add generic earlycon support"
>>> (sha1: 0d3c673e7881e691991b2a4745bd4f149603baa2)
>>> "tty/serial: add arm/arm64 semihosting earlycon"
>>> (sha1: d50d7269ebcb438afa346cdffce0f4e2a1b9e831)
>>>
>>> Signed-off-by: Michal Simek 
>>> ---
>>>
>>>  Documentation/kernel-parameters.txt |  6 ++
>>>  drivers/tty/serial/Kconfig  |  1 +
>>>  drivers/tty/serial/xilinx_uartps.c  | 19 +++
>>>  3 files changed, 26 insertions(+)
>>>
>>> diff --git a/Documentation/kernel-parameters.txt 
>>> b/Documentation/kernel-parameters.txt
>>> index a8eb6afce6a4..97055dc43167 100644
>>> --- a/Documentation/kernel-parameters.txt
>>> +++ b/Documentation/kernel-parameters.txt
>>> @@ -921,6 +921,12 @@ bytes respectively. Such letter suffixes can also be 
>>> entirely omitted.
>>>
>>> earlycon=   [KNL] Output early console device and options.
>>>
>>> +   cdns,
>>> +   Start an early, polled-mode console on a cadence serial
>>> +   port at the specified address. The cadence serial port
>>> +   must already be setup and configured. Options are not
>>> +   yet supported.
>>> +
>>> uart[8250],io,[,options]
>>> uart[8250],mmio,[,options]
>>> uart[8250],mmio32,[,options]
>>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>>> index b4d61e6bf28c..72fd2b6e2241 100644
>>> --- a/drivers/tty/serial/Kconfig
>>> +++ b/drivers/tty/serial/Kconfig
>>> @@ -1411,6 +1411,7 @@ config SERIAL_XILINX_PS_UART_CONSOLE
>>> bool "Cadence UART console support"
>>> depends on SERIAL_XILINX_PS_UART=y
>>> select SERIAL_CORE_CONSOLE
>>> +   select SERIAL_EARLYCON
>>> help
>>>   Enable a Cadence UART port to be the system console.
>>>
>>> diff --git a/drivers/tty/serial/xilinx_uartps.c 
>>> b/drivers/tty/serial/xilinx_uartps.c
>>> index 01951d27cc03..675f3fe068f6 100644
>>> --- a/drivers/tty/serial/xilinx_uartps.c
>>> +++ b/drivers/tty/serial/xilinx_uartps.c
>>> @@ -1051,6 +1051,25 @@ static void cdns_uart_console_putchar(struct 
>>> uart_port *port, int ch)
>>> cdns_uart_writel(ch, CDNS_UART_FIFO_OFFSET);
>>>  }
>>>
>>> +static void cdns_early_write(struct console *con, const char *s, unsigned 
>>> n)
>>> +{
>>> +   struct earlycon_device *dev = con->data;
>>> +
>>> +   uart_console_write(&dev->port, s, n, cdns_uart_console_putchar);
>>> +}
>>> +
>>> +static int __init cdns_early_console_setup(struct earlycon_device *device,
>>> +  const char *opt)
>>> +{
>>> +   if (!device->port.membase)
>>> +   return -ENODEV;
>>> +
>>> +   device->con->write = cdns_early_write;
>>> +
>>> +   return 0;
>>> +}
>>> +EARLYCON_DECLARE(cdns, cdns_early_console_setup);
>>> +
>>>  /**
>>>   * cdns_uart_console_write - perform write operation
>>>   * @co: Console handle
>>> --
>>> 1.8.2.3
>>>
>>
>> Any problem with this patch?
> 
> Don't know, it's in my todo queue which is really long at the moment...
> 

Thanks for confirmation that it is in your todo queue.
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 26/29] nios2: ptrace support

[Ley Foon Tan]

On Tue, Sep 16, 2014 at 5:43 PM, Tobias Klauser  wrote:
>
> This could be simplified to:
>
> long arch_ptrace(struct task_struct *child, long request, unsigned long addr,
>  unsigned long data)
> {
> return ptrace_request(child, request, addr, data);
> }
Okay, will change this.
--
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] devicetree: cadence_ttc: Document binding for timer width

[Michal Simek]

On 09/17/2014 06:17 PM, Mark Rutland wrote:
> On Wed, Sep 17, 2014 at 03:30:49PM +0100, Michal Simek wrote:
>> From: Peter Crosthwaite 
>>
>> Modern TTC implementations can extend the timer width to 32 bit. This
>> feature is not self identifying so the driver needs to be made aware
>> via device tree.
>>
>> Signed-off-by: Peter Crosthwaite 
>> Signed-off-by: Michal Simek 
>> ---
>>
>>  Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt 
>> b/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
>> index 993695c659e1..5439976eca6b 100644
>> --- a/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
>> +++ b/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
>> @@ -6,6 +6,9 @@ Required properties:
>>  - interrupts : A list of 3 interrupts; one per timer channel.
>>  - clocks: phandle to the source clock
>>
>> +Optional properties:
>> +- timer-width: Bit width of the timer. Either 16 or 32 (default 16).
> 
> Are we expecting TTC implementations with widths other than 16 or 32?

IRC if you use 32bit timer and setup for example 24bit width it should work
too and you are just ignoring that upper bits.

> 
> This looks sane to me, but we might be able to just have a 32-bit-timer
> property if we don't expect arbitrary widths.

Definitely model different timer width is easily possible to do in qemu
that's why I think having more generic property timer-width is just better than
having property used just for one case.

Thanks,
Michal




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 5/9] eeepc-laptop: tell sysfs that the disp attribute is write-only

[Frans Klaver]

On 18 September 2014 00:07:53 CEST, Greg Kroah-Hartman 
 wrote:
>On Wed, Sep 17, 2014 at 11:47:23PM +0200, Frans Klaver wrote:
>> The disp attribute is write-only, but sysfs doesn't know this.
>Currently
>> show_sys_acpi() is mimicking sysfs behavior, if the underlying acpi
>call
>> should fail. This was introduced in 6dff29b63a5bf2eaf3 "eeepc-laptop:
>> disp attribute should be write-only". This is not ideal; behaving
>like
>> sysfs is better left to sysfs.
>> 
>> Introduce EEEPC_CREATE_DEVICE_ATTR_WO() to instantiate a write-only
>> attribute, and declare the disp attribute with it. Sysfs makes sure
>> userspace can only write to disp at all times. This removes the need
>for
>> mimicking the sysfs behavior in show_sys_acpi() and store_sys_acpi(),
>> but we'll stick with -EIO, as changing sysfs return values should not
>be
>> taken lightly.
>> 
>> This change also causes EEEPC_CREATE_DEVICE_ATTR() to be used only
>for
>> R/W attributes. This enables us to drop the _mode argument from the
>> macro and use DEVICE_ATTR_RW() internally while we're at it. Append
>_RW
>> to the name for readability.
>> 
>> Signed-off-by: Frans Klaver 
>> ---
>> Here we're sticking with -EIO as return values. It should be said
>that the
>> commit mentioned above did change the error value from -ENODEV to
>-EIO. I'm
>> still in two minds about whether the show_sys_acpi and store_sys_acpi
>should go
>> back to returning ENODEV. We'll probably stick with -EIO, though, as
>there is
>> no strong reason other than "it was like that before".
>> 
>>  drivers/platform/x86/eeepc-laptop.c | 14 +-
>>  1 file changed, 9 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/platform/x86/eeepc-laptop.c
>b/drivers/platform/x86/eeepc-laptop.c
>> index c6d765f..a85da4f 100644
>> --- a/drivers/platform/x86/eeepc-laptop.c
>> +++ b/drivers/platform/x86/eeepc-laptop.c
>> @@ -311,14 +311,18 @@ static ssize_t show_sys_acpi(struct device
>*dev, int cm, char *buf)
>>  return store_sys_acpi(dev, _cm, buf, count);\
>>  }
>>  
>> -#define EEEPC_CREATE_DEVICE_ATTR(_name, _mode, _cm) \
>> +#define EEEPC_CREATE_DEVICE_ATTR_RW(_name, _cm) 
>> \
>>  EEEPC_ACPI_SHOW_FUNC(_name, _cm)\
>>  EEEPC_ACPI_STORE_FUNC(_name, _cm)   \
>> -static DEVICE_ATTR(_name, _mode, _name##_show, _name##_store)
>> +static DEVICE_ATTR_RW(_name)
>>  
>> -EEEPC_CREATE_DEVICE_ATTR(camera, 0644, CM_ASL_CAMERA);
>> -EEEPC_CREATE_DEVICE_ATTR(cardr, 0644, CM_ASL_CARDREADER);
>> -EEEPC_CREATE_DEVICE_ATTR(disp, 0200, CM_ASL_DISPLAYSWITCH);
>> +#define EEEPC_CREATE_DEVICE_ATTR_WO(_name, _cm) 
>> \
>> +EEEPC_ACPI_STORE_FUNC(_name, _cm)   \
>> +static DEVICE_ATTR_WO(_name)
>> +
>> +EEEPC_CREATE_DEVICE_ATTR_RW(camera, CM_ASL_CAMERA);
>> +EEEPC_CREATE_DEVICE_ATTR_RW(cardr, CM_ASL_CARDREADER);
>> +EEEPC_CREATE_DEVICE_ATTR_WO(disp, CM_ASL_DISPLAYSWITCH);
>>  
>>  struct eeepc_cpufv {
>>  int num;
>
>Ah, you did what I asked on a previous patch here, nevermind :)

Yea, I thought I'd make more sense this way. 

Thanks, 
Frans 


--
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/9] eeepc-laptop: clean up coding style

[Frans Klaver]

On 18 September 2014 00:06:52 CEST, Joe Perches  wrote:
>On Wed, 2014-09-17 at 23:47 +0200, Frans Klaver wrote:
>> Correct indentation and brace usage to comply with
>> Documentation/CodingStyle.
>> 
>> Signed-off-by: Frans Klaver 
>> ---
>>  drivers/platform/x86/eeepc-laptop.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/platform/x86/eeepc-laptop.c
>b/drivers/platform/x86/eeepc-laptop.c
>> index 3095d38..653999e 100644
>> --- a/drivers/platform/x86/eeepc-laptop.c
>> +++ b/drivers/platform/x86/eeepc-laptop.c
>> @@ -544,7 +544,7 @@ static int eeepc_led_init(struct eeepc_laptop
>*eeepc)
>>  eeepc->tpd_led.name = "eeepc::touchpad";
>>  eeepc->tpd_led.brightness_set = tpd_led_set;
>>  if (get_acpi(eeepc, CM_ASL_TPD) >= 0) /* if method is available */
>> -  eeepc->tpd_led.brightness_get = tpd_led_get;
>> +eeepc->tpd_led.brightness_get = tpd_led_get;
>>  eeepc->tpd_led.max_brightness = 1;
>>  
>>  rv = led_classdev_register(&eeepc->platform_device->dev,
>> @@ -692,8 +692,9 @@ static int eeepc_register_rfkill_notifier(struct
>eeepc_laptop *eeepc,
>>   * changed during setup.
>>   */
>>  eeepc_rfkill_hotplug(eeepc, handle);
>> -} else
>> +} else {
>>  return -ENODEV;
>> +}
>>  
>>  return 0;
>>  }
>
>This sort of code:
>
>   if (foo) {
>   [ do_something ]
>   } else
>   return -ERRVAL;
>
>is generally better rewritten as:
>
>   if (!foo)
>   return -ERRVAL;
>
>   [ do_something ]
>
>This gives immediacy to the error handler and
>as well reduces unnecessary indentation.

I fully agree. 

Darren, do you still take this in one patch? 

Frans

--
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] mfd: rtsx: fix PM suspend for 5227 & 5249

[Lee Jones]

On Thu, 18 Sep 2014, micky_ch...@realsil.com.cn wrote:

> From: Micky Ching 
> 
> Fix rts5227&5249 failed send buffer cmd after suspend,
> PM_CTRL3 should reset before send any buffer cmd after suspend.
> Otherwise, buffer cmd will failed, this will lead resume fail.
> 
> Signed-off-by: Micky Ching 
> ---
>  drivers/mfd/rts5227.c|   19 +++
>  drivers/mfd/rts5249.c|4 
>  drivers/mfd/rtsx_pcr.h   |1 +
>  include/linux/mfd/rtsx_pci.h |   12 
>  4 files changed, 36 insertions(+)

I think you'll find you just broke the build.

What happens when you compile these as modules?

> diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
> index 9c8eec8..8222a31 100644
> --- a/drivers/mfd/rts5227.c
> +++ b/drivers/mfd/rts5227.c
> @@ -128,8 +128,27 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
>   return rtsx_pci_send_cmd(pcr, 100);
>  }
>  
> +int rts5227_pm_reset(struct rtsx_pcr *pcr)
> +{
> + int err;
> +
> + /* init aspm */
> + err = rtsx_pci_update_cfg_byte(pcr, LCTLR, 0xFC, 0);
> + if (err < 0)
> + return err;
> +
> + /* reset PM_CTRL3 before send buffer cmd */
> + return rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x00);
> +}
> +
>  static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
>  {
> + int err;
> +
> + err = rts5227_pm_reset(pcr);
> + if (err < 0)
> + return err;
> +
>   /* Optimize RX sensitivity */
>   return rtsx_pci_write_phy_register(pcr, 0x00, 0xBA42);
>  }
> diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
> index 573de7b..0f1b0e6 100644
> --- a/drivers/mfd/rts5249.c
> +++ b/drivers/mfd/rts5249.c
> @@ -130,6 +130,10 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
>  {
>   int err;
>  
> + err = rts5227_pm_reset(pcr);
> + if (err < 0)
> + return err;

I don't like this.  Place rts52xx_pm_reset() somewhere more central.
Perhaps an inline function in the header would be better?

>   err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
>   PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
>   PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
> diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
> index 07e4c2e..acc7a1e 100644
> --- a/drivers/mfd/rtsx_pcr.h
> +++ b/drivers/mfd/rtsx_pcr.h
> @@ -72,4 +72,5 @@ do {
> \
>   pcr->ms_pull_ctl_disable_tbl = __device##_ms_pull_ctl_disable_tbl; \
>  } while (0)
>  
> +int rts5227_pm_reset(struct rtsx_pcr *pcr);
>  #endif
> diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
> index 74346d5..b34fec8 100644
> --- a/include/linux/mfd/rtsx_pci.h
> +++ b/include/linux/mfd/rtsx_pci.h
> @@ -967,4 +967,16 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr 
> *pcr)
>   return (u8 *)(pcr->host_cmds_ptr);
>  }
>  
> +static inline int rtsx_pci_update_cfg_byte(struct rtsx_pcr *pcr, int addr,
> + u8 mask, u8 append)
> +{
> + int err;
> + u8 val;
> +
> + err = pci_read_config_byte(pcr->pci, addr, &val);
> + if (err < 0)
> + return err;
> + return pci_write_config_byte(pcr->pci, addr, (val & mask) | append);
> +}
> +
>  #endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

[Dave Hansen]

On 09/17/2014 08:23 PM, Kevin Easton wrote:
> I was actually thinking that the kernel would take care of the xsave / 
> xrstor (for current), updating tsk->thread.fpu.state (for non-running
> threads) and sending an IPI for threads running on other CPUs.
> 
> Of course userspace can always then manually change the bounds directory
> address itself, but then it's quite clear that they're doing something
> unsupported.  Just an idea, anyway.

What's the benefit of that?

As it stands now, MPX is likely to be enabled well before any threads
are created, and the MPX enabling state will be inherited by the new
thread at clone() time.  The current mechanism allows a thread to
individually enable or disable MPX independently of the other threads.

I think it makes it both more complicated and less flexible.

--
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] Documentation: correct parameter error for dma_mapping_error

[Liu Hua]

dma_mapping_error takes two parameters, but some of examples
in Documentation/DMA-API-HOWTO.txt just takes one. So correct
it.

Signed-off-by: Liu Hua 
---
 Documentation/DMA-API-HOWTO.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index dcbbe36..0f7afb2 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -531,7 +531,7 @@ To map a single region, you do:
size_t size = buffer->len;
 
dma_handle = dma_map_single(dev, addr, size, direction);
-   if (dma_mapping_error(dma_handle)) {
+   if (dma_mapping_error(dev, dma_handle)) {
/*
 * reduce current DMA mapping usage,
 * delay and try again later or
@@ -588,7 +588,7 @@ Specifically:
size_t size = buffer->len;
 
dma_handle = dma_map_page(dev, page, offset, size, direction);
-   if (dma_mapping_error(dma_handle)) {
+   if (dma_mapping_error(dev, dma_handle)) {
/*
 * reduce current DMA mapping usage,
 * delay and try again later or
@@ -689,7 +689,7 @@ to use the dma_sync_*() interfaces.
dma_addr_t mapping;
 
mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE);
-   if (dma_mapping_error(dma_handle)) {
+   if (dma_mapping_error(cp->dev, dma_handle)) {
/*
 * reduce current DMA mapping usage,
 * delay and try again later or
-- 
1.9.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/

[PATCH v4 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support

[Vivek Gautam]

Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.

Signed-off-by: Vivek Gautam 
Acked-by: Jingoo Han 
Cc: Alan Stern 
---

Changes since v3:
 - Addressed review comments by Alan:
   -- Skipped renaming 'phy_number' variable,
   -- resorted to just adding minimal change required for phy assignment.
   -- updated patch description to mention EPROBE_DEFER support.

 drivers/usb/host/ohci-exynos.c |   81 ++--
 1 file changed, 20 insertions(+), 61 deletions(-)

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 7c48e3f..e8bf4bb 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,11 +19,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include "ohci.h"
 
@@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
 
 struct exynos_ohci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 static int exynos_ohci_get_phy(struct device *dev,
@@ -49,15 +44,9 @@ static int exynos_ohci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
-   int ret = 0;
+   int ret;
 
-   /*
-* Getting generic phy:
-* We are keeping both types of phys as a part of transiting OHCI
-* to generic phy framework, so as to maintain backward compatibilty
-* with old DTB too.
-* We fallback to older USB-PHYs when we fail to get generic PHYs.
-*/
+   /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", &phy_number);
if (ret) {
@@ -73,31 +62,21 @@ static int exynos_ohci_get_phy(struct device *dev,
}
 
phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ohci->phy[phy_number] = phy;
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ohci->phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ohci->phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ohci->phy)) {
-   ret = PTR_ERR(exynos_ohci->phy);
-   if (ret != -ENXIO && ret != -ENODEV) {
-   dev_err(dev, "no usb2 phy configured\n");
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   dev_err(dev,
+   "Error retrieving usb2 phy: %d\n", ret);
+   return PTR_ERR(phy);
+   }
}
-   dev_dbg(dev, "Failed to get usb2 phy\n");
-   } else {
-   exynos_ohci->otg = exynos_ohci->phy->otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ohci_phy_enable(struct device *dev)
@@ -107,16 +86,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ohci->phy))
-   return usb_phy_init(exynos_ohci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   ret = phy_power_on(exynos_ohci->phy_g[i]);
+   if (!IS_ERR(exynos_ohci->phy[i]))
+   ret = phy_power_on(exynos_ohci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   phy_power_off(exynos_ohci->phy_g[i]);
+   if (!IS_ERR(exynos_ohci->phy[i]))
+   phy_power_off(exynos_ohci->phy[i]);
 
return ret;
 }
@@ -127,14 +103,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ohci->phy)) {
-   usb_phy_shutdown(exynos_ohci->phy);
-   return;
-   }
-
for (i = 0; i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   phy_power_off(exynos_ohci->phy_g[i]);
+  

[PATCH v4 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

[Vivek Gautam]

Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.

Signed-off-by: Vivek Gautam 
Acked-by: Jingoo Han 
Cc: Alan Stern 
---

Changes since v3:
 - Addressed review comments by Alan:
   -- Skipped renaming 'phy_number' variable,
   -- resorted to just adding minimal change required for phy assignment.
   -- updated patch description to mention EPROBE_DEFER support.

 drivers/usb/host/ehci-exynos.c |   74 +++-
 1 file changed, 20 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..f293453 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include "ehci.h"
 
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
 struct exynos_ehci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
@@ -60,8 +55,9 @@ static int exynos_ehci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
-   int ret = 0;
+   int ret;
 
+   /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", &phy_number);
if (ret) {
@@ -77,31 +73,21 @@ static int exynos_ehci_get_phy(struct device *dev,
}
 
phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ehci->phy[phy_number] = phy;
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ehci->phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ehci->phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ehci->phy)) {
-   ret = PTR_ERR(exynos_ehci->phy);
-   if (ret != -ENXIO && ret != -ENODEV) {
-   dev_err(dev, "no usb2 phy configured\n");
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   dev_err(dev,
+   "Error retrieving usb2 phy: %d\n", ret);
+   return PTR_ERR(phy);
+   }
}
-   dev_dbg(dev, "Failed to get usb2 phy\n");
-   } else {
-   exynos_ehci->otg = exynos_ehci->phy->otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +97,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ehci->phy))
-   return usb_phy_init(exynos_ehci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   ret = phy_power_on(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   ret = phy_power_on(exynos_ehci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   phy_power_off(exynos_ehci->phy[i]);
 
return ret;
 }
@@ -131,14 +114,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ehci->phy)) {
-   usb_phy_shutdown(exynos_ehci->phy);
-   return;
-   }
-
for (i = 0; i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   phy_power_off(exynos_ehci->phy[i]);
 }
 
 static void exynos_setup_vbus_gpio(struct device *dev)
@@ -231,9 +209,6 @@ skip_phy:
goto fail_io;
}
 
-   if (exynos_ehci->otg)
-

Re: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs

[German Rivera]

On 09/15/2014 06:44 PM, Kim Phillips wrote:

On Thu, 11 Sep 2014 12:34:21 -0500
"J. German Rivera"  wrote:


From: "J. German Rivera" 

APIs to access the Management Complex (MC) hardware
module of Freescale LS2 SoCs. This patch includes
APIs to check the MC firmware version and to manipulate
DPRC objects in the MC.

Signed-off-by: J. German Rivera 
Signed-off-by: Stuart Yoder 
---
  drivers/bus/fsl-mc/dpmng.c |   93 +
  drivers/bus/fsl-mc/dprc.c  |  504 +++
  drivers/bus/fsl-mc/fsl_dpmng_cmd.h |   83 
  drivers/bus/fsl-mc/fsl_dprc_cmd.h  |  545 +
  drivers/bus/fsl-mc/fsl_mc_sys.c|  237 +++
  include/linux/fsl_dpmng.h  |  120 ++
  include/linux/fsl_dprc.h   |  790 
  include/linux/fsl_mc_cmd.h |  182 +
  include/linux/fsl_mc_sys.h |   81 
  9 files changed, 2635 insertions(+)
  create mode 100644 drivers/bus/fsl-mc/dpmng.c
  create mode 100644 drivers/bus/fsl-mc/dprc.c
  create mode 100644 drivers/bus/fsl-mc/fsl_dpmng_cmd.h
  create mode 100644 drivers/bus/fsl-mc/fsl_dprc_cmd.h
  create mode 100644 drivers/bus/fsl-mc/fsl_mc_sys.c
  create mode 100644 include/linux/fsl_dpmng.h
  create mode 100644 include/linux/fsl_dprc.h
  create mode 100644 include/linux/fsl_mc_cmd.h
  create mode 100644 include/linux/fsl_mc_sys.h


the fsl prefix in the filename fsl_dpmng_cmd.h is redundant with
its directory name fsl-mc/.  Note that I find dashes ('-') in
filenames make them easier to type: is there a reason we're using
underscores here?


This is a convention that we decided early on '-' for directory names
and '_' for file names.


Also, any reason why these and future include files aren't being put
in include/linux/fsl/, so as to not pollute the top level
include/linux/?  That way, we can also remove the fsl- prefix from
those filenames, too..

I would like to receive opinions from others about this before making 
any change here.



diff --git a/drivers/bus/fsl-mc/dpmng.c b/drivers/bus/fsl-mc/dpmng.c
new file mode 100644
index 000..c6ed27c
--- /dev/null
+++ b/drivers/bus/fsl-mc/dpmng.c
@@ -0,0 +1,93 @@
+/* Copyright 2013-2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY


interesting, normally this text reads:

"THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS"

...does that mean we're excluding non-Freescale copyright holders
and contributors from this warranty statement?  That doesn't seem
appropriate for an upstream kernel submission.

I would like to receive opinions from others about this before making 
any change here.



+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */


This dual BSD-3-clause/GPL license doesn't match that of patch 2's
drivers/bus/fsl-mc/fsl_mc_bus.c, GPLv2:

This is because the MC flib files in patch 1 can also be used in 
user-space code not just in the kernel. I will not make any change to 
the licenses of the MC flib files included in patch 1.



+/*
+ * Freescale Management Complex (MC) bus driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+

Re: About RK3288 i2c scl duty cycle

[Doug Anderson]

Addy,

On Wed, Sep 17, 2014 at 6:26 PM, addy ke  wrote:
> Add public list
>
> On 2014/9/17 23:17, Doug Anderson wrote:
>> Addy,
>>
>> On Tue, Sep 16, 2014 at 6:30 PM, addy...@rock-chips.com
>>  wrote:
>>> hi, all
>>
>> Any reason why you didn't add some public lists?  It seems like this
>> is a perfect discussion for linux-i2c.
>>
>>
>>> According to i2c-bus specification(version2.1, page 32, Table5, FAST-MODE):
>>> The minimum LOW period of the scl clock is <1.3us>, and the minimum HIGH
>>> period of the scl clock is <0.6us>.
>>> T(min_low) : T(min_high)  ~= 2 : 1
>>>
>>> If  in fast mode(scl rate = 400Khz)
>>> 1）Under ideal conditions, T(scl_low) = T(scl_high) = <1.25us>
>>> 2）Our measurement, T(scl_low) = <1.3us>, T(scl_high) = <1.25us>
>>>
>>> The low period of the scl clock is critical.
>>>
>>> Do we need set   to increase T(scl_low)?   // T(scl_low )
>>> : T(scl_High) = 2 : 1
>>
>> I can't say I've ever looked at that pat of the i2c spec before, but
>> what you say seems reasonable to me.  ...well for 400kHz, at least.
>> At 100kHz you shouldn't use the same 2:1 ratio.
>
> Yes, in normal-mode(100K) we can be only used 1:1 ratio.
> But in FAST-MODE maybe we must use 2:1 ratio.
> 
> In Table 5(Characteristics of the SDA and SCL bus lines for F/S-mode I2C-bus 
> devices)
>
> 1)FAST-MODE(400K):
>   The minimum LOW period of the scl clock1.3us
>   the minimum HIGH period of the scl clock   0.6us
>   T(min_low) : T(min_high)  ~= 2 : 1
>
>   But I can't see any ratio about In FAST-mode(400k) and Normal-mode(100k).
> 2)Normal-MODE(100K):
>   The minimum LOW period of the scl clock4.7us
>   the minimum HIGH period of the scl clock   4.0us
>   T(min_low) : T(min_high)  ~= 1 : 1

You might as well do the math all the way correctly.  That is for
clock > 100kHz use 47 / 87 and 40 / 87.  For clock <= 100kHz use 13 /
19 and 6 / 19

I think that'll give us a max margin, or (given perfect precision):
* a low of 5.4us (10 * 47 / 87.) and a high of 4.6us (10 * 40 / 87.) for 100kHz
* a low of 1.7us and a high of .8us for 400kHz


> 3) HS-mode(3.4M)
>   ratio of 1 to 2 is required, decribed as follows:
>   Hs-mode master devices generate a serial clock signal with a HIGH to LOW 
> ratio of 1 to 2

You forgot about Fast Mode Plus!  ;)  You should probably think of
that before High Speed (IMHO)...

...seriously, though, I think you should send up a patch to do 400kHz
right first, then worry about fast mode plus and high speed.  I
haven't read through the whole i2c-rk3x.c driver, but I can't quite
believe that HS mode is supported right now.  It requires a whole
bunch of extra negotiation.


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

Hello

[Heather Walker]

I am Heather Walker,This is my Third Email to you,I am at the end of the
road, and about to donate a huge amount through you. I promise that your
assistance would be rewarded. Please reply back to me for more
information. Remain Blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the kvm-arm tree with the kvm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/arm/vgic.c between commit c06a841bf363 ("KVM: ARM: vgic:
register kvm_device_ops dynamically") from the kvm tree and commit
de56fb1923ca ("KVM: vgic: declare probe function pointer as const")
from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc virt/kvm/arm/vgic.c
index 3ee3ce06bbec,efe6eee2e7eb..
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -1993,81 -2070,3 +1993,81 @@@ static struct kvm_device_ops kvm_arm_vg
.get_attr = vgic_get_attr,
.has_attr = vgic_has_attr,
  };
 +
 +static void vgic_init_maintenance_interrupt(void *info)
 +{
 +  enable_percpu_irq(vgic->maint_irq, 0);
 +}
 +
 +static int vgic_cpu_notify(struct notifier_block *self,
 + unsigned long action, void *cpu)
 +{
 +  switch (action) {
 +  case CPU_STARTING:
 +  case CPU_STARTING_FROZEN:
 +  vgic_init_maintenance_interrupt(NULL);
 +  break;
 +  case CPU_DYING:
 +  case CPU_DYING_FROZEN:
 +  disable_percpu_irq(vgic->maint_irq);
 +  break;
 +  }
 +
 +  return NOTIFY_OK;
 +}
 +
 +static struct notifier_block vgic_cpu_nb = {
 +  .notifier_call = vgic_cpu_notify,
 +};
 +
 +static const struct of_device_id vgic_ids[] = {
 +  { .compatible = "arm,cortex-a15-gic", .data = vgic_v2_probe, },
 +  { .compatible = "arm,gic-v3", .data = vgic_v3_probe, },
 +  {},
 +};
 +
 +int kvm_vgic_hyp_init(void)
 +{
 +  const struct of_device_id *matched_id;
-   int (*vgic_probe)(struct device_node *,const struct vgic_ops **,
++  const int (*vgic_probe)(struct device_node *,const struct vgic_ops **,
 +const struct vgic_params **);
 +  struct device_node *vgic_node;
 +  int ret;
 +
 +  vgic_node = of_find_matching_node_and_match(NULL,
 +  vgic_ids, &matched_id);
 +  if (!vgic_node) {
 +  kvm_err("error: no compatible GIC node found\n");
 +  return -ENODEV;
 +  }
 +
 +  vgic_probe = matched_id->data;
 +  ret = vgic_probe(vgic_node, &vgic_ops, &vgic);
 +  if (ret)
 +  return ret;
 +
 +  ret = request_percpu_irq(vgic->maint_irq, vgic_maintenance_handler,
 +   "vgic", kvm_get_running_vcpus());
 +  if (ret) {
 +  kvm_err("Cannot register interrupt %d\n", vgic->maint_irq);
 +  return ret;
 +  }
 +
 +  ret = __register_cpu_notifier(&vgic_cpu_nb);
 +  if (ret) {
 +  kvm_err("Cannot register vgic CPU notifier\n");
 +  goto out_free_irq;
 +  }
 +
 +  /* Callback into for arch code for setup */
 +  vgic_arch_setup(vgic);
 +
 +  on_each_cpu(vgic_init_maintenance_interrupt, NULL, 1);
 +
 +  return kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
 + KVM_DEV_TYPE_ARM_VGIC_V2);
 +
 +out_free_irq:
 +  free_percpu_irq(vgic->maint_irq, kvm_get_running_vcpus());
 +  return ret;
 +}


signature.asc
Description: PGP signature

Re: [PATCH v3 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

[Vivek Gautam]

Hi Alan,


On Wed, Sep 17, 2014 at 8:27 PM, Alan Stern  wrote:
> On Wed, 17 Sep 2014, Vivek Gautam wrote:
>
>> Now that we have completely moved from older USB-PHY drivers
>> to newer GENERIC-PHY drivers for PHYs available with USB controllers
>> on Exynos series of SoCs, we can remove the support for the same
>> in our host drivers too.
>>
>> Signed-off-by: Vivek Gautam 
>
> I don't see why you made your changes in this awkward way.  For
> instance...
>
>> @@ -59,49 +54,39 @@ static int exynos_ehci_get_phy(struct device *dev,
>>  {
>>   struct device_node *child;
>>   struct phy *phy;
>> - int phy_number;
>> - int ret = 0;
>> + int phy_num;
>
> Why rename this variable?  Wasn't the original name good enough?

fair enough, don't need to rename the variable.

>
>> + int ret;
>>
>>   for_each_available_child_of_node(dev->of_node, child) {
>> - ret = of_property_read_u32(child, "reg", &phy_number);
>> + ret = of_property_read_u32(child, "reg", &phy_num);
>>   if (ret) {
>>   dev_err(dev, "Failed to parse device tree\n");
>>   of_node_put(child);
>>   return ret;
>>   }
>>
>> - if (phy_number >= PHY_NUMBER) {
>> + if (phy_num >= PHY_NUMBER) {
>>   dev_err(dev, "Invalid number of PHYs\n");
>>   of_node_put(child);
>>   return -EINVAL;
>>   }
>>
>> - phy = devm_of_phy_get(dev, child, NULL);
>> + exynos_ehci->phy[phy_num] = devm_of_phy_get(dev, child, NULL);
>> + phy = exynos_ehci->phy[phy_num];
>
> Why make two changes, resulting in more code, when you could have made
> just one change?
>
> phy = devm_of_phy_get(dev, child, NULL);
> +   exynos_ehci->phy[phy_num] = phy;

Right. i don't know what state of mind i was in while making these changes.
i should have kept the changes to minimal.

>
> Also, the patch description should mention that you are adding support
> for EPROBE_DEFER.

Sure, will add that description.




-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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 07/24] ARM64:ILP32: Use the same size and layout of the signal structures for ILP32 as for LP64

[zhangjian]

On 2014/9/4 5:19, Andrew Pinski wrote:
> Defines the macros which allow the signal structures to be the same between 
> ILP32 and LP64.
> 
> Signed-off-by: Andrew Pinski 
> ---
>  arch/arm64/include/uapi/asm/siginfo.h |   33 
>  arch/arm64/include/uapi/asm/signal.h  |   34 
> +
>  2 files changed, 67 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm64/include/uapi/asm/siginfo.h 
> b/arch/arm64/include/uapi/asm/siginfo.h
> index 5a74a08..c80c612 100644
> --- a/arch/arm64/include/uapi/asm/siginfo.h
> +++ b/arch/arm64/include/uapi/asm/siginfo.h
> @@ -1,5 +1,6 @@
>  /*
>   * Copyright (C) 2012 ARM Ltd.
> + * Copyright (C) 2014 Cavium Inc.
>   *
>   * 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
> @@ -18,6 +19,38 @@
>  
>  #define __ARCH_SI_PREAMBLE_SIZE  (4 * sizeof(int))
>  
> +#ifdef __ILP32__
> +
> +/*
> + * For ILP32, the siginfo structures should share the same layout and
> + * alignement requirements as LP64 ABI.
> + * To do this, use an extra pad field and add aligned attribute
> + * to the structure.
> + */
> +
> +# ifdef __AARCH64EB__
> +#  define __SIGINFO_INNER(type, field)   \
> + int __pad#field;\
> + type field
> +# else
> +#  define __SIGINFO_INNER(type, field)   \
> + type field; \
> + int __pad#field
> +# endif
> +
> +# undef __SIGINFO_VOIDPTR
> +# define __SIGINFO_VOIDPTR(field)\
> + __SIGINFO_INNER(void __user*, field)
> +# undef __SIGINFO_BAND
> +
> +# define __SIGINFO_BAND(field)   \
> + __SIGINFO_INNER(long, field)
> +
> +/* Make the alignment of siginfo always 8 byte aligned. */
> +#define __ARCH_SI_ATTRIBUTES __attribute__((aligned(8)))
> +
> +#endif
> +
>  #include 
>  
>  #endif
> diff --git a/arch/arm64/include/uapi/asm/signal.h 
> b/arch/arm64/include/uapi/asm/signal.h
> index 8d1e723..d33a5f7 100644
> --- a/arch/arm64/include/uapi/asm/signal.h
> +++ b/arch/arm64/include/uapi/asm/signal.h
> @@ -16,9 +16,43 @@
>  #ifndef __ASM_SIGNAL_H
>  #define __ASM_SIGNAL_H
>  
> +#include 
typos here, it should be
#include 
> +
>  /* Required for AArch32 compatibility. */
>  #define SA_RESTORER  0x0400
>  
> +/*
> + * Since sigset is a bitmask, we need the same size fields for ILP32
> + * and LP64.  With big-endian, 32bit bitmask does not match up to
> + * 64bit bitmask (unlike with little-endian).
> + */
> +#ifdef __ILP32__
> +
> +#define __SIGSET_INNER_TYPE __kernel_ulong_t
> +#define _NSIG_BPW 64
> +
> +# ifdef __AARCH64EB__
> +#  define __SIGNAL_INNER(type, field)\
> + int __pad_##field;  \
> + type field;
> +# else
> +#  define __SIGNAL_INNER(type, field)\
> + type field; \
> + int __pad_##field;
> +# endif
> +
> +# define __SIGACTION_HANDLER(field)  \
> + __SIGNAL_INNER(__sighandler_t, field)
> +
> +
> +#define __SIGACTION_FLAGS(field) \
> + __kernel_ulong_t field
> +
> +#define __SIGACTION_RESTORER(field)  \
> + __SIGNAL_INNER(__sigrestore_t, field)
> +
> +#endif
> +
>  #include 
>  
>  #endif
> 


--
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] regulator: st-pwm: get voltage and duty table from dts

[Doug Anderson]

Chris,

On Wed, Sep 17, 2014 at 6:37 PM, Chris Zhong  wrote:
>> Chris: please change the order and make sure Mark is CCed on the
>> bindings.  Probably anyone CCed on the code change should be on the
>> bindings change (and probably vice versa, but maybe not as critical).
>>
>> -Doug
>>
>>
> Thanks.
> I should not only use patman's script to created cc list.

Yup, patman relies on get_maintainer and that's not perfect.  I tend
to rely heavily on it but it's good to sanity check...


Speaking of which: Lee, do you think it would be a good idea to add
yourself as a MAINTAINER for st-pwm?

  (next-20140917))$ ./scripts/get_maintainer.pl -f drivers/regulator/st-pwm.c
  Liam Girdwood  (supporter:VOLTAGE AND CURRE...)
  Mark Brown  (supporter:VOLTAGE AND CURRE...)
  Grant Likely  (maintainer:OPEN FIRMWARE AND...)
  Rob Herring  (maintainer:OPEN FIRMWARE AND...)
  linux-kernel@vger.kernel.org (open list:VOLTAGE AND CURRE...)
  devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND...)


...ideally whatever rule added would also catch the bindings file when
Chris adds it.


-Doug
--
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] mfd: syscon: Decouple syscon interface from platform devices

[Dong Aisheng]

On Thu, Sep 18, 2014 at 08:59:32AM +0530, Pankaj Dubey wrote:
> +CC: Dong Aisheng 
> 
> Hi Arnd,
> 
> On Wednesday, September 17, 2014, Arnd Bergmann wrote,
> > > V2 of this patchset and related discussion can be found here [1].
> > >
> > > Changes since v2:
> > >  - Added back platform device support from syscon, with one change that
> > >syscon will not be probed for DT based platform.
> > >  - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
> > >users of syscon will not be broken.
> > >  - Removed unwanted change in syscon.h.
> > >  - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
> > >Arnd Bergmann.
> > >  - Added Tested-by of Vivek Gautam for testing on Exynos platform.
> > 
> > Looks fine. Provided you can figure out the problem that Dong Aisheng
> reported,
> > please add my
> > 
> > Acked-by: Arnd Bergmann 
> >
> 
> Thanks. 
> After he reported I have again done code walk-through of regmap_init_mmio
> and 
> could not see any such fatal error.  At the same time I have replied to Dong
> Aisheng,
> asking for more details and waiting for his reply. 
>  

I just replied and gave the log.

Regards
Dong Aisheng

> > > -}
> > > +static struct syscon *of_syscon_register(struct device_node *np);
> > >
> > 
> > One  minor comment: please avoid doing forward declarations of local
> functions. It
> > took me a while to understand what is going on because I expect all
> functions to be
> > ordered such that they only get called by functions below, and don't need
> this.
> > 
> > Just move of_syscon_register() here directly.
> > 
> 
> OK, I will remove forward declaration of "of_syscon_register" and respin
> patch once again.
> 
> > Arnd
> 
> Thanks,
> Pankaj Dubey
> 
--
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] mfd: syscon: Decouple syscon interface from platform devices

[Dong Aisheng]

On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
> Hi,
> 
> On Wednesday, September 17, 2014, Dong Aisheng Wrote,
> > >
> > > +static struct syscon *of_syscon_register(struct device_node *np) {
> > > + struct syscon *syscon;
> > > + struct regmap *regmap;
> > > + void __iomem *base;
> > > +
> > > + if (!of_device_is_compatible(np, "syscon"))
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
> > > + if (!syscon)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + base = of_iomap(np, 0);
> > > + if (!base)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + regmap = regmap_init_mmio(NULL, base, &syscon_regmap_config);
> > 
> > Does a NULL device pointer work?
> 
> Yes, it is safe, at least we are able to test on Exynos based SoC. 
> I have tested it with kgene/for-next kernel on Exynos3250.
> Also it has been tested on Exynos5250 based Snow board with 3.17-rc5 based
> kernel
> by Vivek Gautam. 
> 
> Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
> 
> 

The kernel i tested was next-20140915 of linux-next.

please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config *config)
{
struct device_node *np = dev->of_node;
enum regmap_endian endian;
...
}
It will crash at the first line of dev->of_node if dev is NULL.

Can you check if you're using the same code as mine?

> > I just tested on MX6SX SDB board and it seemed crashed at here in
> regmap_init
> > function.
> > 
> 
> Can you please provide crash log which can give more information about the
> crash?
> 

My crash log is:

[0.225148] Unable to handle kernel NULL pointer dereference at virtual 
address 01d4
[0.233383] pgd = 80004000
[0.236185] [01d4] *pgd=
[0.239873] Internal error: Oops: 5 [#1] SMP ARM
[0.244588] Modules linked in:
[0.247753] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
3.17.0-rc4-next-20140915-6-g8ba2dd0-dirty #421
[0.257342] task: bd878000 ti: bd88 task.ti: bd88
[0.262848] PC is at regmap_init+0x21c/0xab4
[0.267221] LR is at vprintk_emit+0x254/0x5e0
[0.271677] pc : [<80389420>]lr : [<8006a4f8>]psr: 6153
[0.271677] sp : bd881ae0  ip : bd881a48  fp : bd881b1c
[0.283354] r10:   r9 : bd8e1850  r8 : 0003
[0.288678] r7 :   r6 : 8098fccc  r5 : 8098ee0c  r4 : bd8f4e00
[0.295307] r3 : bd878000  r2 : 01e5  r1 : 806ee8f0  r0 : 808762c0
[0.301938] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment 
kernel
[0.309438] Control: 10c5387d  Table: 8000404a  DAC: 0015
[0.315284] Process swapper/0 (pid: 1, stack limit = 0xbd880240)
[0.321391] Stack: (0xbd881ae0 to 0xbd882000)
[0.325851] 1ae0: bd8e1850  bd881b1c bd881af8 8038f580 8098fccc 
 be7d49b8
[0.334136] 1b00: 8098fca4 bd917000 bd8e1850  bd881b34 bd881b20 
8038f68c 80389210
[0.342422] 1b20: bd91b480 8098fcc4 bd881b5c bd881b38 80398b24 8038f664 
 bd91ac10
[0.350708] 1b40: be7d4bc0 bd917010 bd917000 bd8e1850 bd881bac bd881b60 
803185a4 80398a54
[0.358993] 1b60: bd881b94 bd881b70     
 
[0.367277] 1b80:   bd917010 80983a64  bd916c10 
80983a64 
[0.375563] 1ba0: bd881bc4 bd881bb0 8037bb44 80318510 811c65f0 bd917010 
bd881bec bd881bc8
[0.383848] 1bc0: 8037a104 8037bb1c 80983a64 bd917010 8037a23c bd916c10 
 
[0.392134] 1be0: bd881c04 bd881bf0 8037a284 8037a004  bd917010 
bd881c2c bd881c08
[0.400419] 1c00: 80378614 8037a248 bd8038d8 bd8af7d4 bd916c10 bd917010 
bd917044 8098e308
[0.408704] 1c20: bd881c4c bd881c30 80379fb8 803785c0 bd803800 bd917018 
bd917010 8098e308
[0.416990] 1c40: bd881c6c bd881c50 8037961c 80379f48  bd917018 
 bd917010
[0.425275] 1c60: bd881ca4 bd881c70 80377904 80379598 bd881cc8 bd881cc0 
bd881cb8 bd881c88
[0.433560] 1c80: be7d4bc0 bd916c10  0001 bd917000 be7d4c10 
bd881cb4 bd881ca8
[0.441845] 1ca0: 804f1708 803774e8 bd881cfc bd881cb8 804f1f2c 804f16dc 
bd881cdc bd881cc8
[0.450130] 1cc0: 806b6d7c 80060478 809b0220 6153 bd881cfc  
be7d4bc0 
[0.458415] 1ce0: 0001 8070bb80 bd916c10  bd881d5c bd881d00 
804f2068 804f1e5c
[0.466700] 1d00: bd878000 a153 809b0220  bd881d2c bd881d20 
80060480 80060284
[0.474985] 1d20: bd881d44 bd881d30 806b6d7c 80060478  be7d4bc0 
be7d49b8 
[0.483270] 1d40: 0001 8070bb80 bd916c10  bd881dbc bd881d60 
804f20c4 804f1f8c
[0.491556] 1d60: 0001 6153 809b0220  bd881d8c bd881d80 
80060480 80060284
[0.499841] 1d80: bd881da4 bd881d90 806b6d7c 80060478 be7d46f8 be7d49b8 
be7cf764

[PATCH] [trivial] wireless:rtlwifi: Fix typo in rtl wifi drivers

[Masanari Iida]

This patch fix spelling typo "sleeped" in printk, found in
multiple rtlwifi drivers.

Signed-off-by: Masanari Iida 
---
 drivers/net/wireless/rtlwifi/rtl8188ee/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8192ce/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8192cu/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8723ae/phy.c | 2 +-
 drivers/net/wireless/rtlwifi/rtl8723be/phy.c | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
index 1cd6c16..3d689e8 100644
--- a/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8188ee/phy.c
@@ -2019,7 +2019,7 @@ static bool _rtl88ee_phy_set_rf_power_state(struct 
ieee80211_hw *hw,
  RT_RF_OFF_LEVL_HALT_NIC);
} else {
RT_TRACE(rtlpriv, COMP_RF, DBG_DMESG,
-"Set ERFON sleeped:%d ms\n",
+"Set ERFON slept:%d ms\n",
 jiffies_to_msecs(jiffies - ppsc->
  last_sleep_jiffies));
ppsc->last_awake_jiffies = jiffies;
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
index 98b2230..ac3ffa2 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/phy.c
@@ -480,7 +480,7 @@ static bool _rtl92ce_phy_set_rf_power_state(struct 
ieee80211_hw *hw,
  RT_RF_OFF_LEVL_HALT_NIC);
} else {
RT_TRACE(rtlpriv, COMP_RF, DBG_DMESG,
-"Set ERFON sleeped:%d ms\n",
+"Set ERFON slept:%d ms\n",
 jiffies_to_msecs(jiffies -
  ppsc->
  last_sleep_jiffies));
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c
index 9831ff1..519d6e5 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/phy.c
@@ -437,7 +437,7 @@ static bool _rtl92cu_phy_set_rf_power_state(struct 
ieee80211_hw *hw,
  RT_RF_OFF_LEVL_HALT_NIC);
} else {
RT_TRACE(rtlpriv, COMP_RF, DBG_DMESG,
-"Set ERFON sleeped:%d ms\n",
+"Set ERFON slept:%d ms\n",
 jiffies_to_msecs(jiffies -
  ppsc->last_sleep_jiffies));
ppsc->last_awake_jiffies = jiffies;
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
index 592125a..7c02247 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
@@ -3121,7 +3121,7 @@ bool rtl92d_phy_set_rf_power_state(struct ieee80211_hw 
*hw,
  RT_RF_OFF_LEVL_HALT_NIC);
} else {
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG,
-"awake, sleeped:%d ms state_inap:%x\n",
+"awake, slept:%d ms state_inap:%x\n",
 jiffies_to_msecs(jiffies -
  ppsc->last_sleep_jiffies),
 rtlpriv->psc.state_inap);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
index 77c5b5f..6853ace 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
@@ -565,7 +565,7 @@ bool rtl92s_phy_set_rf_power_state(struct ieee80211_hw *hw,
  RT_RF_OFF_LEVL_HALT_NIC);
} else {
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG,
-"awake, sleeped:%d ms state_inap:%x\n",
+"awake, slept:%d ms state_inap:%x\n",
 jiffies_to_msecs(jiffies -
  ppsc->
  last_sleep_jiffies),
diff --git a/drivers/net/wireless/rtlwifi/rtl8723ae/phy.c 
b/drivers/net/wireless/rtlwifi/rtl8723ae/phy.c
index 3ea78af..95f9902 100644
--- a/drivers/net/wireless/rtlwifi/rtl8723ae/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8723ae/phy.c
@@ -1486,7 +1486,7 @@ static bool _rtl8723ae_phy_set_rf_power

RE: [PATCH v3] mfd: syscon: Decouple syscon interface from platform devices

[Pankaj Dubey]

+CC: Dong Aisheng 

Hi Arnd,

On Wednesday, September 17, 2014, Arnd Bergmann wrote,
> > V2 of this patchset and related discussion can be found here [1].
> >
> > Changes since v2:
> >  - Added back platform device support from syscon, with one change that
> >syscon will not be probed for DT based platform.
> >  - Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
> >users of syscon will not be broken.
> >  - Removed unwanted change in syscon.h.
> >  - Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
> >Arnd Bergmann.
> >  - Added Tested-by of Vivek Gautam for testing on Exynos platform.
> 
> Looks fine. Provided you can figure out the problem that Dong Aisheng
reported,
> please add my
> 
> Acked-by: Arnd Bergmann 
>

Thanks. 
After he reported I have again done code walk-through of regmap_init_mmio
and 
could not see any such fatal error.  At the same time I have replied to Dong
Aisheng,
asking for more details and waiting for his reply. 
 
> > -}
> > +static struct syscon *of_syscon_register(struct device_node *np);
> >
> 
> One  minor comment: please avoid doing forward declarations of local
functions. It
> took me a while to understand what is going on because I expect all
functions to be
> ordered such that they only get called by functions below, and don't need
this.
> 
> Just move of_syscon_register() here directly.
> 

OK, I will remove forward declaration of "of_syscon_register" and respin
patch once again.

>   Arnd

Thanks,
Pankaj Dubey

--
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 1/3] phy: exynos-dp-video: Use syscon support to control pmu register

[Vivek Gautam]

Hi Kishon,


On Wed, Sep 17, 2014 at 10:24 PM, Kishon Vijay Abraham I  wrote:
>
>
> On Tuesday 16 September 2014 10:32 AM, Vivek Gautam wrote:
>> Currently the DP_PHY_ENABLE register is mapped in the driver,
>> and accessed to control power to the PHY.
>> With mfd-syscon and regmap interface available at our disposal,
>> it's wise to use that instead of using a 'reg' property for the
>> controller and allocating a memory resource for that.
>>
>> To facilitate this, we have added another compatible string
>> for Exynso5420 SoC to acquire driver data which contains
>> different DP-PHY-CONTROL register offset.
>>
>> Signed-off-by: Vivek Gautam 
>> Cc: Jingoo Han 
>> Cc: Kishon Vijay Abraham I 
>
> Taking this in linux-phy tree. If someone has already taken this patch, please
> let me know.

Thanks for taking this. But just one check, i think i need to separate
out the Documentation
to a separate patch even before this driver patch. Isn't it ?

>
> Thanks
> Kishon
>
>> ---
>>
>> Changes since v2:
>>  - Using 'EXYNOS5_PHY_ENABLE' macro instead of 'EXYNOS_DPTX_PHY_ENABLE'
>>since that's available with us in "linux/mfd/syscon/exynos5-pmu.h" file.
>>
>> Changes since v1:
>>  - state->regs should have been "struct regmap *" instead of
>>"void __iomem *". So corrected the same.
>>
>>  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>>  drivers/phy/phy-exynos-dp-video.c  |   79 
>> +---
>>  2 files changed, 59 insertions(+), 27 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index 7a6feea..15e0f2c 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
>>  -
>>
>>  Required properties:
>> -- compatible : should be "samsung,exynos5250-dp-video-phy";
>> -- reg : offset and length of the Display Port PHY register set;
>> +- compatible : should be one of the following supported values:
>> +  - "samsung,exynos5250-dp-video-phy"
>> +  - "samsung,exynos5420-dp-video-phy"
>> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
>> +   control pmu registers for power isolation.
>>  - #phy-cells : from the generic PHY bindings, must be 0;
>>
>>  Samsung S5P/EXYNOS SoC series USB PHY
>> diff --git a/drivers/phy/phy-exynos-dp-video.c 
>> b/drivers/phy/phy-exynos-dp-video.c
>> index 8b3026e..53f44a0 100644
>> --- a/drivers/phy/phy-exynos-dp-video.c
>> +++ b/drivers/phy/phy-exynos-dp-video.c
>> @@ -13,44 +13,55 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>> -/* DPTX_PHY_CONTROL register */
>> -#define EXYNOS_DPTX_PHY_ENABLE   (1 << 0)
>> +struct exynos_dp_video_phy_drvdata {
>> + u32 phy_ctrl_offset;
>> +};
>>
>>  struct exynos_dp_video_phy {
>> - void __iomem *regs;
>> + struct regmap *regs;
>> + const struct exynos_dp_video_phy_drvdata *drvdata;
>>  };
>>
>> -static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int 
>> on)
>> +static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
>> + unsigned int on)
>>  {
>> - u32 reg;
>> + unsigned int val;
>> +
>> + if (IS_ERR(state->regs))
>> + return;
>>
>> - reg = readl(state->regs);
>> - if (on)
>> - reg |= EXYNOS_DPTX_PHY_ENABLE;
>> - else
>> - reg &= ~EXYNOS_DPTX_PHY_ENABLE;
>> - writel(reg, state->regs);
>> + val = on ? 0 : EXYNOS5_PHY_ENABLE;
>>
>> - return 0;
>> + regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
>> +EXYNOS5_PHY_ENABLE, val);
>>  }
>>
>>  static int exynos_dp_video_phy_power_on(struct phy *phy)
>>  {
>>   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>
>> - return __set_phy_state(state, 1);
>> + /* Disable power isolation on DP-PHY */
>> + exynos_dp_video_phy_pwr_isol(state, 0);
>> +
>> + return 0;
>>  }
>>
>>  static int exynos_dp_video_phy_power_off(struct phy *phy)
>>  {
>>   struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
>>
>> - return __set_phy_state(state, 0);
>> + /* Enable power isolation on DP-PHY */
>> + exynos_dp_video_phy_pwr_isol(state, 1);
>> +
>> + return 0;
>>  }
>>
>>  static struct phy_ops exynos_dp_video_phy_ops = {
>> @@ -59,11 +70,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
>>   .owner  = THIS_MODULE,
>>  };
>>
>> +static const struct exynos_dp_video_phy_drvdata exynos5250_dp_video_phy = {
>> + .phy_ctrl_offset= EXYNOS5_DPTX_PHY_CONTROL,
>> +};
>> +
>> +static const struct exynos_dp_video_phy_drvdata exynos5420_dp_video_phy = {
>> +  

[RFC PATCH 0/3] Early boot self tests for RCU

[Pranith Kumar]

Hi Paul,

Please find the following patches which enable RCU early boot tests. For now
all we do in these tests are enqueue test callbacks and check if they are being
invoked or not.

I was able to reproduce the hang which Amit reported after reverting the fix. So
this should catch such errors if they occur in the future.

I enabled the selftests in a few rcutorture configurations.

Thanks!
--
Pranith

Pranith Kumar (3):
  rcu: Add early boot self tests
  doc: Document RCU self test boot params
  rcutorture: Enable RCU self test in configs

 Documentation/kernel-parameters.txt| 12 +++
 kernel/rcu/rcu.h   |  2 +
 kernel/rcu/tiny.c  |  4 +-
 kernel/rcu/tree.c  |  2 +
 kernel/rcu/update.c| 91 ++
 .../selftests/rcutorture/configs/rcu/TINY02|  2 +
 .../selftests/rcutorture/configs/rcu/TINY02.boot   |  2 +
 .../selftests/rcutorture/configs/rcu/TREE05.boot   |  1 +
 .../selftests/rcutorture/configs/rcu/TREE06.boot   |  4 +
 .../selftests/rcutorture/configs/rcu/TREE08|  2 +
 .../selftests/rcutorture/configs/rcu/TREE08.boot   |  2 +
 11 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot

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

[RFC PATCH 0/3] Early boot self tests for RCU

[Pranith Kumar]

Hi Paul,

Please find the following patches which enable RCU early boot tests. For now
all we do in these tests are enqueue test callbacks and check if they are being
invoked or not.

I was able to reproduce the hang which Amit reported after reverting the fix. So
this should catch such errors if they occur in the future.

I enabled the selftests in a few rcutorture configurations.

Thanks!
--
Pranith

Pranith Kumar (3):
  rcu: Add early boot self tests
  doc: Document RCU self test boot params
  rcutorture: Enable RCU self test in configs

 Documentation/kernel-parameters.txt| 12 +++
 kernel/rcu/rcu.h   |  2 +
 kernel/rcu/tiny.c  |  4 +-
 kernel/rcu/tree.c  |  2 +
 kernel/rcu/update.c| 91 ++
 .../selftests/rcutorture/configs/rcu/TINY02|  2 +
 .../selftests/rcutorture/configs/rcu/TINY02.boot   |  2 +
 .../selftests/rcutorture/configs/rcu/TREE05.boot   |  1 +
 .../selftests/rcutorture/configs/rcu/TREE06.boot   |  4 +
 .../selftests/rcutorture/configs/rcu/TREE08|  2 +
 .../selftests/rcutorture/configs/rcu/TREE08.boot   |  2 +
 11 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot

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

[RFC PATCH 3/3] rcutorture: Enable RCU self test in configs

[Pranith Kumar]

Add config and boot parameters to enable the self tests in rcutorture testing.

Signed-off-by: Pranith Kumar 
---
 tools/testing/selftests/rcutorture/configs/rcu/TINY02  | 2 ++
 tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot | 2 ++
 tools/testing/selftests/rcutorture/configs/rcu/TREE05.boot | 1 +
 tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot | 4 
 tools/testing/selftests/rcutorture/configs/rcu/TREE08  | 2 ++
 tools/testing/selftests/rcutorture/configs/rcu/TREE08.boot | 2 ++
 6 files changed, 13 insertions(+)
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot
 create mode 100644 tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot

diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TINY02 
b/tools/testing/selftests/rcutorture/configs/rcu/TINY02
index f4feaee..36e41df 100644
--- a/tools/testing/selftests/rcutorture/configs/rcu/TINY02
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TINY02
@@ -7,6 +7,8 @@ CONFIG_HZ_PERIODIC=y
 CONFIG_NO_HZ_IDLE=n
 CONFIG_NO_HZ_FULL=n
 CONFIG_RCU_TRACE=y
+CONFIG_PROVE_LOCKING=y
+CONFIG_PROVE_RCU=y
 CONFIG_DEBUG_LOCK_ALLOC=y
 CONFIG_DEBUG_OBJECTS_RCU_HEAD=n
 CONFIG_PREEMPT_COUNT=y
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot 
b/tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot
new file mode 100644
index 000..0f08027
--- /dev/null
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TINY02.boot
@@ -0,0 +1,2 @@
+rcupdate.rcu_self_test=1
+rcupdate.rcu_self_test_bh=1
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TREE05.boot 
b/tools/testing/selftests/rcutorture/configs/rcu/TREE05.boot
index 3b42b8b..15b3e1a 100644
--- a/tools/testing/selftests/rcutorture/configs/rcu/TREE05.boot
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TREE05.boot
@@ -1 +1,2 @@
 rcutorture.torture_type=sched
+rcupdate.rcu_self_test_sched=1
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot 
b/tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot
new file mode 100644
index 000..0436e07
--- /dev/null
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TREE06.boot
@@ -0,0 +1,4 @@
+rcupdate.rcu_self_test=1
+rcupdate.rcu_self_test_bh=1
+rcupdate.rcu_self_test_sched=1
+rcupdate.rcu_self_test_srcu=1
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TREE08 
b/tools/testing/selftests/rcutorture/configs/rcu/TREE08
index 316aa6c..1a9303d 100644
--- a/tools/testing/selftests/rcutorture/configs/rcu/TREE08
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TREE08
@@ -18,6 +18,8 @@ CONFIG_RCU_FANOUT_LEAF=2
 CONFIG_RCU_NOCB_CPU=y
 CONFIG_RCU_NOCB_CPU_ALL=y
 CONFIG_DEBUG_LOCK_ALLOC=n
+CONFIG_PROVE_LOCKING=y
+CONFIG_PROVE_RCU=y
 CONFIG_RCU_CPU_STALL_INFO=n
 CONFIG_RCU_BOOST=n
 CONFIG_DEBUG_OBJECTS_RCU_HEAD=n
diff --git a/tools/testing/selftests/rcutorture/configs/rcu/TREE08.boot 
b/tools/testing/selftests/rcutorture/configs/rcu/TREE08.boot
index 3b42b8b..2561daf 100644
--- a/tools/testing/selftests/rcutorture/configs/rcu/TREE08.boot
+++ b/tools/testing/selftests/rcutorture/configs/rcu/TREE08.boot
@@ -1 +1,3 @@
 rcutorture.torture_type=sched
+rcupdate.rcu_self_test=1
+rcupdate.rcu_self_test_sched=1
-- 
2.1.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/

[RFC PATCH 2/3] doc: Document RCU self test boot params

[Pranith Kumar]

Document the RCU self test boot parameters in kernel-parameters.txt.

Signed-off-by: Pranith Kumar 
---
 Documentation/kernel-parameters.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index c403957..6f5c01b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3054,6 +3054,18 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
messages.  Disable with a value less than or equal
to zero.
 
+   rcupdate.rcu_self_test= [KNL]
+   Run the RCU early boot self tests
+
+   rcupdate.rcu_self_test_bh= [KNL]
+   Run the RCU bh early boot self tests
+
+   rcupdate.rcu_self_test_sched= [KNL]
+   Run the RCU sched early boot self tests
+
+   rcupdate.rcu_self_test_srcu= [KNL]
+   Run the SRCU early boot self tests
+
rdinit= [KNL]
Format: 
Run specified binary instead of /init from the ramdisk,
-- 
2.1.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/

[RFC PATCH 1/3] rcu: Add early boot self tests

[Pranith Kumar]

Add early boot self tests for RCU under CONFIG_PROVE_RCU.

Currently the only test is adding a dummy callback which increments a counter
which we then later verify after calling rcu_barrier*().

Signed-off-by: Pranith Kumar 
---
 kernel/rcu/rcu.h|  2 ++
 kernel/rcu/tiny.c   |  4 ++-
 kernel/rcu/tree.c   |  2 ++
 kernel/rcu/update.c | 91 +
 4 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index ff1a6de..07bb02e 100644
--- a/kernel/rcu/rcu.h
+++ b/kernel/rcu/rcu.h
@@ -135,4 +135,6 @@ int rcu_jiffies_till_stall_check(void);
  */
 #define TPS(x)  tracepoint_string(x)
 
+void rcu_early_boot_tests(void);
+
 #endif /* __LINUX_RCU_H */
diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
index c0623fc..d3d44c5 100644
--- a/kernel/rcu/tiny.c
+++ b/kernel/rcu/tiny.c
@@ -380,7 +380,9 @@ void call_rcu_bh(struct rcu_head *head, void (*func)(struct 
rcu_head *rcu))
 }
 EXPORT_SYMBOL_GPL(call_rcu_bh);
 
-void rcu_init(void)
+void __init rcu_init(void)
 {
open_softirq(RCU_SOFTIRQ, rcu_process_callbacks);
+
+   rcu_early_boot_tests();
 }
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index e4c6d60..f93a62c 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3766,6 +3766,8 @@ void __init rcu_init(void)
pm_notifier(rcu_pm_notify, 0);
for_each_online_cpu(cpu)
rcu_cpu_notify(NULL, CPU_UP_PREPARE, (void *)(long)cpu);
+
+   rcu_early_boot_tests();
 }
 
 #include "tree_plugin.h"
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 3ef8ba5..5929f0c 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -690,3 +690,94 @@ static void rcu_spawn_tasks_kthread(void)
 }
 
 #endif /* #ifdef CONFIG_TASKS_RCU */
+
+#ifdef CONFIG_PROVE_RCU
+
+/*
+ * Early boot self test parameters, one for each flavor
+ */
+static bool rcu_self_test;
+static bool rcu_self_test_bh;
+static bool rcu_self_test_sched;
+static bool rcu_self_test_srcu;
+
+module_param(rcu_self_test, bool, 0444);
+module_param(rcu_self_test_bh, bool, 0444);
+module_param(rcu_self_test_sched, bool, 0444);
+module_param(rcu_self_test_srcu, bool, 0444);
+
+static int rcu_self_test_counter;
+static struct rcu_head head;
+DEFINE_STATIC_SRCU(srcu_struct);
+
+static void test_callback(struct rcu_head *r)
+{
+   rcu_self_test_counter++;
+   pr_info("RCU test callback executed %d\n", rcu_self_test_counter);
+}
+
+static void early_boot_test_call_rcu(void)
+{
+   call_rcu(&head, test_callback);
+}
+
+static void early_boot_test_call_rcu_bh(void)
+{
+   call_rcu_bh(&head, test_callback);
+}
+
+static void early_boot_test_call_rcu_sched(void)
+{
+   call_rcu_sched(&head, test_callback);
+}
+
+static void early_boot_test_call_srcu(void)
+{
+   call_srcu(&srcu_struct, &head, test_callback);
+}
+
+void rcu_early_boot_tests(void)
+{
+   pr_info("Running RCU self tests\n");
+
+   if (rcu_self_test)
+   early_boot_test_call_rcu();
+   if (rcu_self_test_bh)
+   early_boot_test_call_rcu_bh();
+   if (rcu_self_test_sched)
+   early_boot_test_call_rcu_sched();
+   if (rcu_self_test_srcu)
+   early_boot_test_call_srcu();
+}
+
+static int rcu_verify_early_boot_tests(void)
+{
+   int ret = 0;
+   int early_boot_test_counter = 0;
+
+   if (rcu_self_test) {
+   early_boot_test_counter++;
+   rcu_barrier();
+   }
+   if (rcu_self_test_bh) {
+   early_boot_test_counter++;
+   rcu_barrier_bh();
+   }
+   if (rcu_self_test_sched) {
+   early_boot_test_counter++;
+   rcu_barrier_sched();
+   }
+   if (rcu_self_test_srcu) {
+   early_boot_test_counter++;
+   srcu_barrier(&srcu_struct);
+   }
+
+   if (rcu_self_test_counter != early_boot_test_counter)
+   ret = -1;
+
+   return ret;
+}
+late_initcall(rcu_verify_early_boot_tests);
+#else
+void rcu_early_boot_tests(void) {}
+#endif /* CONFIG_PROVE_RCU */
-- 
2.1.0

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

RE: [PATCH v2 3/4] net: stmmac: add support for Intel Quark X1000 [RESEND TO MAILING LIST]

[Kweh, Hock Leong]

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Wednesday, September 17, 2014 12:56 PM
> From: "Kweh, Hock Leong" 
> Date: Wed, 17 Sep 2014 02:41:39 +
> 
> > Thanks for the pointer. I did a quickly checking on the class number 
> > to see if I could use it for differentiation the ports number. 
> > Whereas I found them both have the same class number as well. Below 
> > shows the "lspci" dump to all the PCI devices on Quark X1000 Galileo 
> > board (Ethernet controllers are
> > 00:14.6 and 00:14.7). Very unfortunately we are unlikely to use the 
> > class number as well as pci_device_id for the differentiation.
>  ...
> > 00:14.6 "Class 0200" "8086" "0937" "8086" "0937"
> > 00:14.7 "Class 0200" "8086" "0937" "8086" "0937"
> 
> Are you kidding me?  It's a perfect way to identify this device, it 
> properly uses PCI_CLASS_NETWORK_ETHERNET (0x0200) in both cases and 
> this will not match any other function on this PCI device at all.
> 
> Please do as I suggested and use the PCI class for the differentiation 
> and matching during probing.

Hi David,

Thanks for your feedback so far. Appreciate it.

Sorry to my poorly written description that may have caused some confusion. My 
sincere apology here. 
Unfortunately, I don't really grasp your idea clearly based on your responses 
which I appreciate them a lot. 
Sorry for the long description below but I hope to clearly pen down my thinking 
process so that you can follow my thinking incrementally without being confused.

So, let's roll back a bit so that with my following description, you can help 
correct me if my understanding of using PCI function ID to differentiate PHY 
port that is associated with each Ethernet controller is wrong:

The high-level idea about the change that I made for STMMAC IP inside Quark is 
as follow:

(1) Based on Quark-specific PCI ID declared inside stmmac_id_table[],  the 
probe() function is
   called to continue setting-up STMMAC for Quark.

@@ -228,11 +303,13 @@ static int stmmac_pci_resume(struct pci_dev *pdev)
 
 #define STMMAC_VENDOR_ID 0x700
 #define STMMAC_DEVICE_ID 0x1108
+#define STMMAC_QUARK_X1000_ID 0x0937
 
 static const struct pci_device_id stmmac_id_table[] = {
{PCI_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID), PCI_ANY_ID,
PCI_ANY_ID, CHIP_STMICRO},
{PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_MAC), CHIP_STMICRO},
+   {PCI_VDEVICE(INTEL, STMMAC_QUARK_X1000_ID), CHIP_QUARK_X1000},
{}
 };

(2) Back-ground on STMMAC hardware configuration on Intel Galileo Gen 1 & Gen 2 
platforms:
Intel Quark SoC has 2 MAC controller as described by lspci output below:

00:14.6 Class 0200: 8086:0937> 1st MAC controller
00:14.7 Class 0200: 8086:0937> 2nd MAC controller

These Galileo boards use the same Intel Quark SoC and there is only one PHY 
connect to the 1st MAC [00:14.6 Class 0200: 8086:0937] The 2nd MAC [00:14.7 
Class 0200: 8086:0937] is NOT connected to any PHY at all.

So, it appears to me that the only way that I can differentiate between 1st & 
2nd MAC are based on PCI function ID, i.e. 14.6 & 14.7. Therefore, within the 
probe() function, for Intel Quark SoC only, the function performs next-level 
discovery of 1st or 2nd MAC controller through quark_run_time_config() 
function. 
For other PCI ID (currently STMICRO_MAC) there is NO next-level discovery 
involved as rt_config is NULL.
Changes shown below:

static struct platform_data platform_info[] = { @@ -59,15 +65,76 @@ static 
struct platform_data platform_info[] = {
.phy_reset = NULL,
.phy_mask = 0,
.pbl = 32,
+   .fixed_burst = 0,
.burst_len = DMA_AXI_BLEN_256,
+   .rt_config = NULL,  ===> no 2nd-level discovery 
for other PCI ID 
+   },
+   [CHIP_QUARK_X1000] = {
+   .phy_addr = 1,
+   .interface = PHY_INTERFACE_MODE_RMII,
+   .clk_csr = 2,
+   .has_gmac = 1,
+   .force_sf_dma_mode = 1,
+   .multicast_filter_bins = HASH_TABLE_SIZE,
+   .unicast_filter_entries = 1,
+   .phy_reset = NULL,
+   .phy_mask = 0,
+   .pbl = 16,
+   .fixed_burst = 1,
+   .burst_len = DMA_AXI_BLEN_256,
+   .rt_config = &quark_run_time_config,   ==> Quark 
specific 2nd-level discovery
+   },
+};

(3) Within quark_run_time_config(), due to the only way to differentiate 1st or 
2nd MAC controller according to difference in function ID explained above, the 
following changes are made:

+static void quark_run_time_config(int chip_id, struct pci_dev *pdev) {
+   const char *board_name = dmi_get_system_info(DMI_BOARD_NAME);
+   int i;
+   int func_num = PCI_FUNC(pdev->devfn);
+
+   if (!board_name)
+   return;
+
+   for (i = 0; i < ARRAY_SIZE(quark_x1000_phy_info); i++) {
+

Re: [PATCH 0/9] powerpc/powernv: Support for fastsleep and winkle

[Shreyas B Prabhu]

Hi,

In this patch series we use winkle for offlined cores. I successfully
tested the working of this with subcore functionality.

Test scenario was as follows:
1. Set SMT mode to 1, Set subores-per-core to 1
2. Offline a core, in this case cpu 32 (sending it to winkle)
3. Set subcores-per-core to 4
4. Online the core
5. Start a guest (Topology 1 core 2 threads) on a subcore, in this case
on cpu 36

This works without any glitch.

Thanks,
Shreyas

On Monday 25 August 2014 11:31 PM, Shreyas B. Prabhu wrote:
> Fast sleep is an idle state, where the core and the L1 and L2
> caches are brought down to a threshold voltage. This also means that
> the communication between L2 and L3 caches have to be fenced. However
> the current P8 chips have a bug wherein this fencing between L2 and
> L3 caches get delayed by a cpu cycle. This can delay L3 response to
> the other cpus if they request for data during this time. Thus they
> would fetch the same data from the memory which could lead to data
> corruption if L3 cache is not flushed.
> Patch 4 adds support to work around this.
> 
> 'Deep Winkle' is a deeper idle state where core and private L2 are powered
> off. While it offers higher power savings, it is at the cost of losing
> hypervisor register state and higher latency.
> Patch 5-9 adds support for winkle and uses it for offline cpus.
> 
> Patch 1 - Moves parameters required discover idle states to a location 
> common to both cpuidle driver and powernv core code
> Patch 2 - Populates idle state details from device tree
> Patch 3 - Enables cpus to run guest after waking up from fastsleep/winkle
> 
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Rafael J. Wysocki 
> Cc: Srivatsa S. Bhat 
> Cc: Preeti U. Murthy 
> Cc: Vaidyanathan Srinivasan 
> Cc: Rob Herring 
> Cc: Grant Likely 
> Cc: devicet...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> 
> Preeti U Murthy (2):
>   cpuidle/powernv: Populate cpuidle state details by querying the
> device-tree
>   powerpc/powernv/cpuidle: Add workaround to enable fastsleep
> 
> Shreyas B. Prabhu (6):
>   powerpc/kvm/book3s_hv: Enable CPUs to run guest after waking up from
> fast-sleep
>   powerpc/powernv: Add OPAL call to save and restore
>   powerpc: Adding macro for accessing Thread Switch Control Register
>   powerpc/powernv: Add winkle infrastructure
>   powerpc/powernv: Discover and enable winkle
>   powerpc/powernv: Enter deepest supported idle state in offline
> 
> Srivatsa S. Bhat (1):
>   powerpc/powernv: Enable Offline CPUs to enter deep idle states
> 
>  arch/powerpc/include/asm/machdep.h |   4 +
>  arch/powerpc/include/asm/opal.h|  10 ++
>  arch/powerpc/include/asm/paca.h|   3 +
>  arch/powerpc/include/asm/ppc-opcode.h  |   2 +
>  arch/powerpc/include/asm/processor.h   |   6 +-
>  arch/powerpc/include/asm/reg.h |   1 +
>  arch/powerpc/kernel/asm-offsets.c  |   1 +
>  arch/powerpc/kernel/exceptions-64s.S   |  37 ++---
>  arch/powerpc/kernel/idle.c |  30 
>  arch/powerpc/kernel/idle_power7.S  |  83 +-
>  arch/powerpc/platforms/powernv/opal-wrappers.S |   2 +
>  arch/powerpc/platforms/powernv/powernv.h   |   8 +
>  arch/powerpc/platforms/powernv/setup.c | 217 
> +
>  arch/powerpc/platforms/powernv/smp.c   |  13 +-
>  arch/powerpc/platforms/powernv/subcore.c   |  15 ++
>  drivers/cpuidle/cpuidle-powernv.c  |  40 -
>  16 files changed, 439 insertions(+), 33 deletions(-)
> 

--
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] [trivial] treewide: Fix typos in Kconfig

[Masanari Iida]

This patch fix spelling typos found in Kconfig.

Signed-off-by: Masanari Iida 
---
 arch/blackfin/Kconfig   | 2 +-
 arch/mips/cavium-octeon/Kconfig | 2 +-
 drivers/i2c/busses/Kconfig  | 2 +-
 drivers/irqchip/Kconfig | 2 +-
 drivers/platform/x86/Kconfig| 8 
 drivers/usb/host/Kconfig| 2 +-
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index ed30699..af76634 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -671,7 +671,7 @@ config TICKSOURCE_CORETMR
default y
 endmenu
 
-menu "Clock souce"
+menu "Clock source"
depends on GENERIC_CLOCKEVENTS
 config CYCLES_CLOCKSOURCE
bool "CYCLES"
diff --git a/arch/mips/cavium-octeon/Kconfig b/arch/mips/cavium-octeon/Kconfig
index 6028666..c370426 100644
--- a/arch/mips/cavium-octeon/Kconfig
+++ b/arch/mips/cavium-octeon/Kconfig
@@ -1,7 +1,7 @@
 if CPU_CAVIUM_OCTEON
 
 config CAVIUM_CN63XXP1
-   bool "Enable CN63XXP1 errata worarounds"
+   bool "Enable CN63XXP1 errata workarounds"
default "n"
help
  The CN63XXP1 chip requires build time workarounds to
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..2e45ae3 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -357,7 +357,7 @@ config I2C_BCM_KONA
  If you say yes to this option, support will be included for the
  I2C interface on the Broadcom Kona family of processors.
 
- If you do not need KONA I2C inteface, say N.
+ If you do not need KONA I2C interface, say N.
 
 config I2C_BLACKFIN_TWI
tristate "Blackfin TWI I2C support"
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index b8632bf..a31a9e4 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -109,7 +109,7 @@ config XTENSA_MX
 config IRQ_CROSSBAR
bool
help
- Support for a CROSSBAR ip that preceeds the main interrupt controller.
+ Support for a CROSSBAR ip that precedes the main interrupt controller.
  The primary irqchip invokes the crossbar's callback which inturn 
allocates
  a free irq and configures the IP. Thus the peripheral interrupts are
  routed to one of the free irqchip interrupt lines.
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 3bbcbf1..4dd2cd8 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -540,7 +540,7 @@ config ASUS_NB_WMI
  This is a driver for newer Asus notebooks. It adds extra features
  like wireless radio and bluetooth control, leds, hotkeys, backlight...
 
- For more informations, see
+ For more information, see
  
 
  If you have an ACPI-WMI compatible Asus Notebook, say Y or M
@@ -553,7 +553,7 @@ config EEEPC_WMI
  This is a driver for newer Eee PC laptops. It adds extra features
  like wireless radio and bluetooth control, leds, hotkeys, backlight...
 
- For more informations, see
+ For more information, see
  
 
  If you have an ACPI-WMI compatible Eee PC laptop (>= 1000), say Y or M
@@ -657,7 +657,7 @@ config TOSHIBA_HAPS
depends on ACPI
---help---
  This driver adds support for the built-in accelerometer
- found on recent Toshiba laptops equiped with HID TOS620A
+ found on recent Toshiba laptops equipped with HID TOS620A
  device.
 
  This driver receives ACPI notify events 0x80 when the sensor
@@ -666,7 +666,7 @@ config TOSHIBA_HAPS
  been stabilized.
 
  Also provides sysfs entries to get/set the desired protection
- level and reseting the HDD protection interface.
+ level and resetting the HDD protection interface.
 
  If you have a recent Toshiba laptop with a built-in accelerometer
  device, say Y.
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 82800a7..56f4336 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -126,7 +126,7 @@ config XPS_USB_HCD_XILINX
select USB_EHCI_BIG_ENDIAN_DESC
select USB_EHCI_BIG_ENDIAN_MMIO
---help---
-   Xilinx xps USB host controller core is EHCI compilant and has
+   Xilinx xps USB host controller core is EHCI compliant and has
transaction translator built-in. It can be configured to either
support both high speed and full speed devices, or high speed
devices only.
-- 
2.1.0.238.gce1d3a9

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

Re: [PATCH v3 0/7] mtd: denali: A collection of trivial coding style fixes

[Brian Norris]

On Thu, Sep 18, 2014 at 11:31:35AM +0900, Masahiro Yamada wrote:
> On Wed, 17 Sep 2014 10:13:08 -0700 Brian Norris  
> wrote:
> > On Tue, Sep 16, 2014 at 08:04:18PM +0900, Masahiro Yamada wrote:
> > > Masahiro Yamada (7):
> > >   mtd: denali: fix the format of comment blocks
> > >   mtd: denali: remove unnecessary variable initializations
> > >   mtd: denali: remove unnecessary casts
> > >   mtd: denali: change the type of iterators to int
> > >   mtd: denali: remove a set-but-unused variable
> > >   mtd: denali: remove unnecessary parentheses
> > >   mtd: denali: fix indents and other trivial things
> > 
> > This series still doesn't apply to l2-mtd.git.
> 
> I resent the last three patches as v3.
> 
> v3 5/7 mtd: denali: remove a set-but-unused variable
> v3 6/7 mtd: denali: remove unnecessary parentheses
> v3 7/7 mtd: denali: fix indents and other trivial things
> 
> I confirmed they are applicable onto
> commit 93e3c8adf6fcf2204ca334237b92c7f8cdafce6f
> of l2-mtd.git
> 
> You said as follow:
> 
> On Mon, 15 Sep 2014 22:07:32 -0700
> Brian Norris  wrote:
> 
> > > Is there a chance for me to resend 5/7 to include this fix?
> > > Or is it too late?
> > 
> > Just send a new patch, please.

I mean "a new patch [on top of l2-mtd.git]", but I see that wasn't
clear.

> That's why I sent a new patch (v3 5/7) to replace
> commit 55ab9ec99bbfb4450dfa9bc0fd9e2c5052f4c3f7
> 
> 
> Did I do wrong?

Eh, just miscommunication from my end.

I don't like to back out patches for no good reason, but I suppose I can
back out patch 5/7 v2, and look at applying v3 instead.

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

Re: debug_dma_assert_idle - ohci - cpu touching an active dma mapped cacheline

[poma]

[ cut here ]
WARNING: CPU: 2 PID: 1065 at lib/dma-debug.c:593 
debug_dma_assert_idle+0x159/0x1d0()
ohci-pci :00:04.0: DMA-API: cpu touching an active dma mapped cacheline 
[cln=0x03004180]
CPU: 2 PID: 1065 Comm: tumblerd Not tainted 3.17.0-0.rc5.git1.1.fc22.i686 #1
Call Trace:
 [] dump_stack+0x48/0x60
 [] warn_slowpath_common+0x82/0xa0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] warn_slowpath_fmt+0x3e/0x60
 [] debug_dma_assert_idle+0x159/0x1d0
 [] ? anon_vma_prepare+0x29/0x140
 [] do_wp_page+0xe4/0x8c0
 [] handle_mm_fault+0x662/0xba0
 [] __do_page_fault+0x208/0x5d0
 [] ? vm_mmap_pgoff+0x9b/0xc0
 [] ? SyS_mmap_pgoff+0xe8/0x220
 [] ? trace_hardirqs_on_caller+0x13c/0x1e0
 [] ? __do_page_fault+0x5d0/0x5d0
 [] do_page_fault+0x1a/0x20
 [] error_code+0x6c/0x74
---[ end trace ce8b30fb8a3415c9 ]---
Mapped at:
 [] debug_dma_alloc_coherent+0x22/0x70
 [] ohci_init+0x22c/0x450
 [] ohci_setup+0x59/0x60
 [] ohci_pci_reset+0x4f/0x60
 [] usb_add_hcd+0x29a/0x8c0

$ lsusb -s 004:
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


poma


--
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/5] hw_random: don't double-check old_rng.

[Rusty Russell]

Interesting anti-pattern.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index b4a21e9521cf..6a34feca6b43 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -472,14 +472,13 @@ int hwrng_register(struct hwrng *rng)
}
 
old_rng = current_rng;
+   err = 0;
if (!old_rng) {
err = hwrng_init(rng);
if (err)
goto out_unlock;
set_current_rng(rng);
-   }
-   err = 0;
-   if (!old_rng) {
+
err = register_miscdev();
if (err) {
drop_current_rng();
-- 
1.9.1

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

[PATCH 3/5] hw_random: fix unregister race.

[Rusty Russell]

The previous patch added one potential problem: we can still be
reading from a hwrng when it's unregistered.  Add a wait for zero
in the hwrng_unregister path.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index dc9092a1075d..b4a21e9521cf 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -60,6 +60,7 @@ static DEFINE_MUTEX(rng_mutex);
 static DEFINE_MUTEX(reading_mutex);
 static int data_avail;
 static u8 *rng_buffer, *rng_fillbuf;
+static DECLARE_WAIT_QUEUE_HEAD(rng_done);
 static unsigned short current_quality;
 static unsigned short default_quality; /* = 0; default to "off" */
 
@@ -98,6 +99,7 @@ static inline void cleanup_rng(struct kref *kref)
 
if (rng->cleanup)
rng->cleanup(rng);
+   wake_up_all(&rng_done);
 }
 
 static void set_current_rng(struct hwrng *rng)
@@ -529,6 +531,9 @@ void hwrng_unregister(struct hwrng *rng)
}
 
mutex_unlock(&rng_mutex);
+
+   /* Just in case rng is reading right now, wait. */
+   wait_event(rng_done, atomic_read(&rng->ref.refcount) == 0);
 }
 EXPORT_SYMBOL_GPL(hwrng_unregister);
 
-- 
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/5] hw_random: use reference counts on each struct hwrng.

[Rusty Russell]

current_rng holds one reference, and we bump it every time we want
to do a read from it.

This means we only hold the rng_mutex to grab or drop a reference,
so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't
block on read of /dev/hwrng.

Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.

This also solves the problem that the hwrng_fillfn thread was
accessing current_rng without a lock, which could change (eg. to NULL)
underneath it.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 135 --
 include/linux/hw_random.h |   2 +
 2 files changed, 94 insertions(+), 43 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index b1b6042ad85c..dc9092a1075d 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -91,6 +92,59 @@ static void add_early_randomness(struct hwrng *rng)
add_device_randomness(bytes, bytes_read);
 }
 
+static inline void cleanup_rng(struct kref *kref)
+{
+   struct hwrng *rng = container_of(kref, struct hwrng, ref);
+
+   if (rng->cleanup)
+   rng->cleanup(rng);
+}
+
+static void set_current_rng(struct hwrng *rng)
+{
+   BUG_ON(!mutex_is_locked(&rng_mutex));
+   kref_get(&rng->ref);
+   current_rng = rng;
+}
+
+static void drop_current_rng(void)
+{
+   BUG_ON(!mutex_is_locked(&rng_mutex));
+   if (!current_rng)
+   return;
+
+   kref_put(¤t_rng->ref, cleanup_rng);
+   current_rng = NULL;
+}
+
+/* Returns ERR_PTR(), NULL or refcounted hwrng */
+static struct hwrng *get_current_rng(void)
+{
+   struct hwrng *rng;
+
+   if (mutex_lock_interruptible(&rng_mutex))
+   return ERR_PTR(-ERESTARTSYS);
+
+   rng = current_rng;
+   if (rng)
+   kref_get(&rng->ref);
+
+   mutex_unlock(&rng_mutex);
+   return rng;
+}
+
+static void put_rng(struct hwrng *rng)
+{
+   /*
+* Hold rng_mutex here so we serialize in case they set_current_rng
+* on rng again immediately.
+*/
+   mutex_lock(&rng_mutex);
+   if (rng)
+   kref_put(&rng->ref, cleanup_rng);
+   mutex_unlock(&rng_mutex);
+}
+
 static inline int hwrng_init(struct hwrng *rng)
 {
if (rng->init) {
@@ -113,12 +167,6 @@ static inline int hwrng_init(struct hwrng *rng)
return 0;
 }
 
-static inline void hwrng_cleanup(struct hwrng *rng)
-{
-   if (rng && rng->cleanup)
-   rng->cleanup(rng);
-}
-
 static int rng_dev_open(struct inode *inode, struct file *filp)
 {
/* enforce read-only access to this chrdev */
@@ -154,21 +202,22 @@ static ssize_t rng_dev_read(struct file *filp, char 
__user *buf,
ssize_t ret = 0;
int err = 0;
int bytes_read, len;
+   struct hwrng *rng;
 
while (size) {
-   if (mutex_lock_interruptible(&rng_mutex)) {
-   err = -ERESTARTSYS;
+   rng = get_current_rng();
+   if (IS_ERR(rng)) {
+   err = PTR_ERR(rng);
goto out;
}
-
-   if (!current_rng) {
+   if (!rng) {
err = -ENODEV;
-   goto out_unlock;
+   goto out;
}
 
mutex_lock(&reading_mutex);
if (!data_avail) {
-   bytes_read = rng_get_data(current_rng, rng_buffer,
+   bytes_read = rng_get_data(rng, rng_buffer,
rng_buffer_size(),
!(filp->f_flags & O_NONBLOCK));
if (bytes_read < 0) {
@@ -200,7 +249,6 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
ret += len;
}
 
-   mutex_unlock(&rng_mutex);
mutex_unlock(&reading_mutex);
 
if (need_resched())
@@ -210,15 +258,16 @@ static ssize_t rng_dev_read(struct file *filp, char 
__user *buf,
err = -ERESTARTSYS;
goto out;
}
+
+   put_rng(rng);
}
 out:
return ret ? : err;
-out_unlock:
-   mutex_unlock(&rng_mutex);
-   goto out;
+
 out_unlock_reading:
mutex_unlock(&reading_mutex);
-   goto out_unlock;
+   put_rng(rng);
+   goto out;
 }
 
 
@@ -257,8 +306,8 @@ static ssize_t hwrng_attr_current_store(struct device *dev,
err = hwrng_init(rng);
if (err)
break;
-   hwrng_cleanup(current_rng);
-   current_rng = rng;
+   drop_current_rng();
+   set_current_rng(rng);
err = 0;
   

[PATCH 1/5] hw_random: place mutex around read functions and buffers.

[Rusty Russell]

There's currently a big lock around everything, and it means that we
can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current)
while the rng is reading.  This is a real problem when the rng is slow,
or blocked (eg. virtio_rng with qemu's default /dev/random backend)

This doesn't help (it leaves the current lock untouched), just adds a
lock to protect the read function and the static buffers, in preparation
for transition.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aa30a25c8d49..b1b6042ad85c 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -53,7 +53,10 @@
 static struct hwrng *current_rng;
 static struct task_struct *hwrng_fill;
 static LIST_HEAD(rng_list);
+/* Protects rng_list and current_rng */
 static DEFINE_MUTEX(rng_mutex);
+/* Protects rng read functions, data_avail, rng_buffer and rng_fillbuf */
+static DEFINE_MUTEX(reading_mutex);
 static int data_avail;
 static u8 *rng_buffer, *rng_fillbuf;
 static unsigned short current_quality;
@@ -81,7 +84,9 @@ static void add_early_randomness(struct hwrng *rng)
unsigned char bytes[16];
int bytes_read;
 
+   mutex_lock(&reading_mutex);
bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
+   mutex_unlock(&reading_mutex);
if (bytes_read > 0)
add_device_randomness(bytes, bytes_read);
 }
@@ -128,6 +133,7 @@ static inline int rng_get_data(struct hwrng *rng, u8 
*buffer, size_t size,
int wait) {
int present;
 
+   BUG_ON(!mutex_is_locked(&reading_mutex));
if (rng->read)
return rng->read(rng, (void *)buffer, size, wait);
 
@@ -160,13 +166,14 @@ static ssize_t rng_dev_read(struct file *filp, char 
__user *buf,
goto out_unlock;
}
 
+   mutex_lock(&reading_mutex);
if (!data_avail) {
bytes_read = rng_get_data(current_rng, rng_buffer,
rng_buffer_size(),
!(filp->f_flags & O_NONBLOCK));
if (bytes_read < 0) {
err = bytes_read;
-   goto out_unlock;
+   goto out_unlock_reading;
}
data_avail = bytes_read;
}
@@ -174,7 +181,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
if (!data_avail) {
if (filp->f_flags & O_NONBLOCK) {
err = -EAGAIN;
-   goto out_unlock;
+   goto out_unlock_reading;
}
} else {
len = data_avail;
@@ -186,7 +193,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
if (copy_to_user(buf + ret, rng_buffer + data_avail,
len)) {
err = -EFAULT;
-   goto out_unlock;
+   goto out_unlock_reading;
}
 
size -= len;
@@ -194,6 +201,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user 
*buf,
}
 
mutex_unlock(&rng_mutex);
+   mutex_unlock(&reading_mutex);
 
if (need_resched())
schedule_timeout_interruptible(1);
@@ -208,6 +216,9 @@ out:
 out_unlock:
mutex_unlock(&rng_mutex);
goto out;
+out_unlock_reading:
+   mutex_unlock(&reading_mutex);
+   goto out_unlock;
 }
 
 
@@ -348,13 +359,16 @@ static int hwrng_fillfn(void *unused)
while (!kthread_should_stop()) {
if (!current_rng)
break;
+   mutex_lock(&reading_mutex);
rc = rng_get_data(current_rng, rng_fillbuf,
  rng_buffer_size(), 1);
+   mutex_unlock(&reading_mutex);
if (rc <= 0) {
pr_warn("hwrng: no data available\n");
msleep_interruptible(1);
continue;
}
+   /* Outside lock, sure, but y'know: randomness. */
add_hwgenerator_randomness((void *)rng_fillbuf, rc,
   rc * current_quality * 8 >> 10);
}
-- 
1.9.1

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

[PATCH 5/5] hw_random: don't init list element we're about to add to list.

[Rusty Russell]

Another interesting anti-pattern.

Signed-off-by: Rusty Russell 
---
 drivers/char/hw_random/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 6a34feca6b43..96fa06716e95 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -485,7 +485,6 @@ int hwrng_register(struct hwrng *rng)
goto out_unlock;
}
}
-   INIT_LIST_HEAD(&rng->list);
list_add_tail(&rng->list, &rng_list);
 
if (old_rng && !rng->init) {
-- 
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 v2 2/3] hw_random: fix stuck in catting hwrng attributes

[Rusty Russell]

Amos Kong  writes:

> I started a QEMU (non-smp) guest with one virtio-rng device, and read
> random data from /dev/hwrng by dd:
>
>  # dd if=/dev/hwrng of=/dev/null &
>
> In the same time, if I check hwrng attributes from sysfs by cat:
>
>  # cat /sys/class/misc/hw_random/rng_*
>
> The cat process always gets stuck with slow backend (5 k/s), if we
> use a quick backend (1.2 M/s), the cat process will cost 1 to 2
> minutes. The stuck doesn't exist for smp guest.
>
> Reading syscall enters kernel and call rng_dev_read(), it's user
> context. We used need_resched() to check if other tasks need to
> be run, but it almost always return false, and re-hold the mutex
> lock. The attributes accessing process always fails to hold the
> lock, so the cat gets stuck.
>
> User context doesn't allow other user contexts run on that CPU,
> unless the kernel code sleeps for some reason. This is why the
> need_reshed() always return false here.
>
> This patch removed need_resched() and always schedule other tasks
> then other tasks can have chance to hold the lock and execute
> protected code.

OK, this is going to be a rant.

Your explanation doesn't make sense at all.  Worse, your solution breaks
the advice of Kernighan & Plaugher: "Don't patch bad code - rewrite
it.".

But worst of all, this detailed explanation might have convinced me you
understood the problem better than I did, and applied your patch.

I did some tests.  For me, as expected, the process spends its time
inside the virtio rng read function, holding the mutex and thus blocking
sysfs access; it's not a failure of this code at all.

Your schedule_timeout() "fix" probably just helps by letting the host
refresh entropy, so we spend less time waiting in the read fn.

I will post a series, which unfortunately is only lightly tested, then
I'm going to have some beer to begin my holiday.  That may help me
forget my disappointment at seeing respected fellow developers
monkey-patching random code they don't understand.

Grrr
Rusty.

> Signed-off-by: Amos Kong 
> ---
>  drivers/char/hw_random/core.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index c591d7e..263a370 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -195,8 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char 
> __user *buf,
>  
>   mutex_unlock(&rng_mutex);
>  
> - if (need_resched())
> - schedule_timeout_interruptible(1);
> + schedule_timeout_interruptible(1);
>  
>   if (signal_pending(current)) {
>   err = -ERESTARTSYS;
> -- 
> 1.9.3

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

RE: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

[Ren, Qiaowei]

On 2014-09-18, Kevin Easton wrote:
> On Thu, Sep 18, 2014 at 12:40:29AM +, Ren, Qiaowei wrote:
>>> Would it be prudent to use an error code other than EINVAL for the
>>> "hardware doesn't support it" case?
>>> 
>> Seems like no specific error code for this case.
> 
> ENXIO would probably be OK.  It's not too important as long as it's
> documented.
> 
Yes. Looks like that ENXIO will be better.

Thanks,
Qiaowei
--
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/4] dt-bindings: document Rockchip thermal

[Caesar Wang]

在 2014年09月18日 04:13, Dmitry Torokhov 写道:

On Wed, Sep 17, 2014 at 12:48:16PM -0700, Doug Anderson wrote:

Caesar,

On Tue, Sep 16, 2014 at 8:59 PM, Caesar Wang  wrote:

This add the necessary binding documentation for the thermal
found on Rockchip SoCs

Signed-off-by: zhaoyifeng 
Signed-off-by: Caesar Wang 
---
  .../bindings/thermal/rockchip-thermal.txt  | 41 ++
  1 file changed, 41 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
new file mode 100644
index 000..6fc8bc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -0,0 +1,41 @@
+* Temperature Sensor ADC (TSADC) on rockchip SoCs
+
+Required properties:
+- compatible: "rockchip,rk3288-tsadc"
+- reg: physical base address of the controller and length of memory mapped
+   region.
+- interrupts: The interrupt number to the cpu. The interrupt specifier format
+ depends on the interrupt controller.
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Shall be "tsadc" for the converter-clock, and "apb_pclk" for
+  the peripheral clock.
+- num-trips:  number of total trip points, this is required, set it 0 if none,
+ if greater than 0, the following properties must be defined;

nit: there is whitespace damage (space before tab) on the line before
this one.  It's more obvious in the patch you uploaded to gerrit which
highlights this in red:

https://chromium-review.googlesource.com/#/c/213967/5/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt

Did you run your patches through checkpatch before submitting?

FWIW vim users like me can put the following in their .vimrc file to
have whitespace damage visible right away:

:highlight RedundantSpaces ctermbg=red guibg=red
:match RedundantSpaces /\s\+$\| \+\ze\t/

Thanks.


It's a very useful, Thank you  for sharing.


--
Best regards,
Caesar


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

Re: [PATCH v3 0/7] mtd: denali: A collection of trivial coding style fixes

[Masahiro Yamada]

Hi Brian,



On Wed, 17 Sep 2014 10:13:08 -0700
Brian Norris  wrote:

> On Tue, Sep 16, 2014 at 08:04:18PM +0900, Masahiro Yamada wrote:
> > 
> > 
> > Masahiro Yamada (7):
> >   mtd: denali: fix the format of comment blocks
> >   mtd: denali: remove unnecessary variable initializations
> >   mtd: denali: remove unnecessary casts
> >   mtd: denali: change the type of iterators to int
> >   mtd: denali: remove a set-but-unused variable
> >   mtd: denali: remove unnecessary parentheses
> >   mtd: denali: fix indents and other trivial things
> 
> This series still doesn't apply to l2-mtd.git.
> 
> Brian


I resent the last three patches as v3.

v3 5/7 mtd: denali: remove a set-but-unused variable
v3 6/7 mtd: denali: remove unnecessary parentheses
v3 7/7 mtd: denali: fix indents and other trivial things


I confirmed they are applicable onto
commit 93e3c8adf6fcf2204ca334237b92c7f8cdafce6f
of l2-mtd.git



You said as follow:

On Mon, 15 Sep 2014 22:07:32 -0700
Brian Norris  wrote:

> > Is there a chance for me to resend 5/7 to include this fix?
> > Or is it too late?
> 
> Just send a new patch, please.


That's why I sent a new patch (v3 5/7) to replace
commit 55ab9ec99bbfb4450dfa9bc0fd9e2c5052f4c3f7


Did I do wrong?



Best Regards
Masahiro Yamada

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

Re: [PATCH v4 14/18] ARM64 / ACPI: Add GICv2 specific ACPI boot support

[Arnd Bergmann]

On Wednesday 17 September 2014, Catalin Marinas wrote:
> > > I think it gets worse, this function is called from irqchip_init(). I
> > > would have been slightly happier if it was called from the arm64
> > > init_IRQ(). But putting an ARM specific GIC initialisation call in a
> > > generic irqchip_init() just looks weird. Can we do anything better here?
> > 
> > Yes this was discussed, please have a look at: 
> > https://lkml.org/lkml/2014/9/1/555
> > We had this in init_IRQ() in previous patch set, then we got feedback 
> > irqchip_init() is more appropriate. We can move it back to init_IRQ() 
> > and I am sold on this.
> 
> The irqchip_init() is indeed the place to call other interrupt
> controller initialisation functions but what I don't particularly like
> is calling the GIC one directly while the OF ones are checked against a
> match string. For GICv3 and later, do you plan to use the same
> acpi_gic_init() functions? Otherwise we could do something like
> ACPI_IRQCHIP_DECLARE() similar to the OF ones and a common function that
> probes whatever is built into the kernel.

I talked abouto this with Marc Z the other day, and I think it really
comes down to how we expect this to develop in the future:

If this is going to stay with the GICv2/v3/v4 line of interrupt controllers,
I see the ACPI_IRQCHIP_DECLARE() as total overdesign, since we wouldn't
ever need more than two entry points.

Doing ACPI_IRQCHIP_DECLARE() makes it possible to deal with other
incompatible irqchips as they come along, but also seems to invite
those.

Marc believes that it's inevitable that people will add lots of crazy
interrupt controllers to systems using ACPI and at that point I agree
it would be the right way to deal with it. However, I also think that
as long as people expect to be able to add lots of crazy interrupt
controller drivers, we are not ready to merge ACPI in the first place,
because it must first be clear to everybody that we are not going to
allow those nonstandard controller drivers to get merged.

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

Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER

[Kevin Easton]

On Thu, Sep 18, 2014 at 12:40:29AM +, Ren, Qiaowei wrote:
> > Would it be prudent to use an error code other than EINVAL for the
> > "hardware doesn't support it" case?
> >
> Seems like no specific error code for this case.

ENXIO would probably be OK.  It's not too important as long as it's
documented.

> 
> >> @@ -2011,6 +2017,12 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned
> > long, arg2, unsigned long, arg3,
> >>me->mm->def_flags &= ~VM_NOHUGEPAGE;
> >>up_write(&me->mm->mmap_sem);
> >>break;
> >> +  case PR_MPX_REGISTER:
> >> +  error = MPX_REGISTER(me);
> >> +  break;
> >> +  case PR_MPX_UNREGISTER:
> >> +  error = MPX_UNREGISTER(me);
> >> +  break;
> > 
> > If you pass me->mm from prctl, that makes it clear that it's
> > per-process not per-thread, just like PR_SET_DUMPABLE / PR_GET_DUMPABLE.
> > 
> > This code should also enforce nulls in arg2 / arg3 / arg4,/ arg5 if
> > it's not using them, otherwise you'll be sunk if you ever want to use them 
> > later.
> > 
> > It seems like it only makes sense for all threads using the mm to have
> > the same bounds directory set.  If the interface was changed to
> > directly pass the address, then could the kernel take care of setting
> > it for *all* of the threads in the process? This seems like something
> > that would be easier for the kernel to do than userspace.
> > 
> If the interface was changed to this, it will be possible for insane 
> application to pass error bounds directory address to kernel. We still 
> have to call fpu_xsave() to check this.

I was actually thinking that the kernel would take care of the xsave / 
xrstor (for current), updating tsk->thread.fpu.state (for non-running
threads) and sending an IPI for threads running on other CPUs.

Of course userspace can always then manually change the bounds directory
address itself, but then it's quite clear that they're doing something
unsupported.  Just an idea, anyway.

- Kevin
--
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] audit: vfs: fix audit records error when write to a file

[hujianyang]

>
> Could you add me to your Cc: list on this thread, please?  I'm
> interested in the outcome...  Thanks!
>

Hi Richard,

I've resend a v2 patch and now quote it in the end of this mail
for you.

I'm sorry to say the previously work of mine seems useless. Moving
audit_inode() to the O_CREAT case in lookup_open() may miss some
conditions when we create a file.

fs/namei.c lookup_open() line 2828
"""
if ((nd->flags & LOOKUP_OPEN) && dir_inode->i_op->atomic_open) {
return atomic_open(nd, dentry, path, file, op, got_write,
   need_lookup, opened);
}
"""

We will miss this branch and other potential cases if we apply my
patch.

There is something wrong with audit, I think. But I don't know where.
One good way to solve this problem is go back to commit bfcec708 as
Jeff mentioned in commit 33e2208a and find the reason why the audit
of create operations is wrong. Do we have another way to fix it than
changing the third parameter of audit_inode() to LOOKUP_PARENT which
lead the audit of write confused?

I don't know much about audit. One of my colleagues is dealing with
this problem now. I'm very glad if someone else could help us.

Thanks~!

Hu


On 2014/9/9 10:34, hujianyang wrote:
> Changes from v1:
> 
>* Move audit_inode() to the beginning of O_CREAT case in
>  lookup_open() to avoid missing audit for ROFS error. This
>  lack is spotted by Jeff Layton 
> 
> commit 33e2208acfc1
> 
> audit: vfs: fix audit_inode call in O_CREAT case of do_last
> 
> fix a regression in auditing of open(..., O_CREAT) syscalls but
> introduce a new problem which lead the records of write operation
> confusion.
> 
> This error can be reproduced by these steps:
> 
>   touch /etc/test
>   echo "-w /etc/test" >>/etc/audit/audit.rules
>   /etc/init.d/auditd restart
> 
>   echo "abc" >> /etc/test
> 
> audit_name records are:
> 
> type=PATH msg=audit(1409764556.196:67): item=0 name="/etc/" inode=5097 
> dev=00:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT
> type=PATH msg=audit(1409764556.196:67): item=1 name=(null) inode=23161 
> dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
> type=PATH msg=audit(1409764556.196:67): item=2 name=(null) inode=23161 
> dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
> 
> but if we revert commit 33e2208acfc1, records are correct:
> 
> type=PATH msg=audit(1409763058.192:219): item=0 name="/etc/test" inode=1275 
> dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
> 
> We shouldn't leave audit_inode(.., LOOKUP_PARENT) in O_CREAT case
> of do_last() because this branch don't really know if vfs need to
> create a new file. There is no need to do vfs_create() if we open
> an existing file with O_CREAT flag and write to it. But this
> audit_inode() in O_CREAT case will record a msg as we create a new
> file and confuse the records of write.
> 
> This patch moves the audit for create operation to where a file
> really need to be created, the O_CREAT case in lookup_open().
> We have to add the pointer of struct filename as a parameter of
> lookup_open(). By doing this, the records of both create and write
> are correct.
> 
> Signed-off-by: hujianyang 
> ---
>  fs/namei.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index a996bb4..ca4a831 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2808,7 +2808,8 @@ looked_up:
>  static int lookup_open(struct nameidata *nd, struct path *path,
>   struct file *file,
>   const struct open_flags *op,
> - bool got_write, int *opened)
> + bool got_write, int *opened,
> + struct filename *name)
>  {
>   struct dentry *dir = nd->path.dentry;
>   struct inode *dir_inode = dir->d_inode;
> @@ -2841,6 +2842,8 @@ static int lookup_open(struct nameidata *nd, struct 
> path *path,
>   /* Negative dentry, just create the file */
>   if (!dentry->d_inode && (op->open_flag & O_CREAT)) {
>   umode_t mode = op->mode;
> +
> + audit_inode(name, dir, LOOKUP_PARENT);
>   if (!IS_POSIXACL(dir->d_inode))
>   mode &= ~current_umask();
>   /*
> @@ -2926,7 +2929,6 @@ static int do_last(struct nameidata *nd, struct path 
> *path,
>   if (error)
>   return error;
> 
> - audit_inode(name, dir, LOOKUP_PARENT);
>   error = -EISDIR;
>   /* trailing slashes? */
>   if (nd->last.name[nd->last.len])
> @@ -2945,7 +2947,7 @@ retry_lookup:
>*/
>   }
>   mutex_lock(&dir->d_inode->i_mutex);
> - error = lookup_open(nd, path, file, op, got_write, opened);
> + error = lookup_open(nd, path, file, op, got_write, opened, name);
>   mutex_unlock(&dir->d_inode->i_mutex);
> 
>   if (error <= 0) {
> 


--
To unsubscribe fro

Re: [PATCH v3 2/3] power: reset: imx-snvs-poweroff: add power off driver for i.mx6

[Robin Gong]

On Wed, Sep 17, 2014 at 06:52:44PM +0100, Mark Rutland wrote:
> On Wed, Sep 17, 2014 at 10:57:59AM +0100, Robin Gong wrote:
> > This driver register pm_power_off with snvs power off function. If
> > your boards NOT use PMIC_ON_REQ to turn on/off external pmic, or use
> > other pin to do, please disable the driver in dts, otherwise, your
> > pm_power_off maybe overwrote by this driver.
> > 
> > Signed-off-by: Robin Gong 
> > ---
> >  .../bindings/power_supply/imx-snvs-poweroff.txt|   23 +++
> >  drivers/power/reset/Kconfig|9 +++
> >  drivers/power/reset/Makefile   |1 +
> >  drivers/power/reset/imx-snvs-poweroff.c|   66 
> > 
> >  4 files changed, 99 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/power_supply/imx-snvs-poweroff.txt
> >  create mode 100644 drivers/power/reset/imx-snvs-poweroff.c
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/power_supply/imx-snvs-poweroff.txt 
> > b/Documentation/devicetree/bindings/power_supply/imx-snvs-poweroff.txt
> > new file mode 100644
> > index 000..6caf64e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power_supply/imx-snvs-poweroff.txt
> > @@ -0,0 +1,23 @@
> > +i.mx6 Poweroff Driver
> > +
> > +SNVS_LPCR in SNVS module can power off the whole system by pull
> > +PMIC_ON_REQ low if PMIC_ON_REQ is connected with external PMIC.
> > +If you don't want to use PMIC_ON_REQ as power on/off control,
> > +please set status='disabled' to disable this driver.
> > +
> > +Required Properties:
> > +-compatible: "fsl,sec-v4.0-poweroff"
> > +-reg: Specifies the physical address of the SNVS_LPCR register
> 
> As you describe above, this is part of the SNVS module. So why does this
> need a separate node?
> 
> Surely there should just be a property on the SNVS node that desribers
> whether or not this can be used?
> 
> Mark.
>
Yes, put this function in rtc-snvs make things easier, honestly,this is our way
in internal tree. But looks more and more power off driver put in drivers/power
/reset,so we decided to add new power off driver. If it is ok to register
pm_power_off hook in drivers/rtc/rtc-snvs.c, I can drop this patch.
> > +
> > +Example:
> > +   snvs@020cc000 {
> > +   compatible = "fsl,sec-v4.0-mon", "simple-bus";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges = <0 0x020cc000 0x4000>;
> > +   .
> > +   snvs-poweroff@38 {
> > +   compatible = "fsl,sec-v4.0-poweroff";
> > +   reg = <0x38 0x4>;
> > +   };
> > +   }
> > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> > index ca41523..b26c547 100644
> > --- a/drivers/power/reset/Kconfig
> > +++ b/drivers/power/reset/Kconfig
> > @@ -45,6 +45,15 @@ config POWER_RESET_HISI
> > help
> >   Reboot support for Hisilicon boards.
> >  
> > +config POWER_RESET_IMX
> > +   bool "IMX6 power-off driver"
> > +   depends on POWER_RESET && SOC_IMX6
> > +   help
> > + This driver support power off external PMIC by PMIC_ON_REQ on i.mx6
> > + boards.If you want to use other pin to control external power,please
> > + say N here or disable in dts to make sure pm_power_off never be
> > + overwrote wrongly by this driver.
> > +
> >  config POWER_RESET_MSM
> > bool "Qualcomm MSM power-off driver"
> > depends on POWER_RESET && ARCH_QCOM
> > diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> > index a42e70e..2524daf 100644
> > --- a/drivers/power/reset/Makefile
> > +++ b/drivers/power/reset/Makefile
> > @@ -3,6 +3,7 @@ obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
> >  obj-$(CONFIG_POWER_RESET_BRCMSTB) += brcmstb-reboot.o
> >  obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
> >  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
> > +obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
> >  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> >  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
> >  obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
> > diff --git a/drivers/power/reset/imx-snvs-poweroff.c 
> > b/drivers/power/reset/imx-snvs-poweroff.c
> > new file mode 100644
> > index 000..d726ac4
> > --- /dev/null
> > +++ b/drivers/power/reset/imx-snvs-poweroff.c
> > @@ -0,0 +1,66 @@
> > +/* Power off driver for i.mx6
> > + * Copyright (c) 2014, FREESCALE CORPORATION.  All rights reserved.
> > + *
> > + * based on msm-poweroff.c
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only 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 f

[PATCH 2/2 V7] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

ARM GICv2m specification extends GICv2 to support MSI(-X) with
a new set of register frame. This patch introduces support for
the non-secure GICv2m register frame. Currently, GICV2m is available
in certain version of GIC-400.

The patch introduces a new property in ARM gic binding, the v2m subnode.
It is optional.

Signed-off-by: Suravee Suthikulpanit 
Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: Jason Cooper 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 Documentation/devicetree/bindings/arm/gic.txt |  55 
 arch/arm64/Kconfig|   1 +
 drivers/irqchip/Kconfig   |   7 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-gic-common.c  |  12 +
 drivers/irqchip/irq-gic-common.h  |   4 +
 drivers/irqchip/irq-gic-v2m.c | 356 ++
 drivers/irqchip/irq-gic.c |  82 +++---
 drivers/irqchip/irq-gic.h |  54 
 9 files changed, 542 insertions(+), 30 deletions(-)
 create mode 100644 drivers/irqchip/irq-gic-v2m.c
 create mode 100644 drivers/irqchip/irq-gic.h

diff --git a/Documentation/devicetree/bindings/arm/gic.txt 
b/Documentation/devicetree/bindings/arm/gic.txt
index c7d2fa1..38b2156 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -96,3 +96,58 @@ Example:
  <0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
};
+
+
+* GICv2m extension for MSI/MSI-x support (Optional)
+
+Certain revision of GIC-400 supports MSI/MSI-x via V2M register frame.
+This is enabled by specifying v2m sub-node.
+
+Required properties:
+
+- compatible: The value here should be "arm,gic-v2m-frame".
+
+- msi-controller: Identifies the node as an MSI controller.
+
+- reg   : GICv2m MSI interface register base and size
+
+Optional properties:
+
+- arm,msi-base-spi  : Specify base SPI the MSI frame.
+  The SPI base value can be from 32 to 1019.
+
+- arm,msi-num-spi   : Returns the number of contiguous SPIs assigned
+ to the frame.
+
+Note: "arm,msi-base-spi" and "arm,msi-num-spi" are used mainly for
+   providing HW workaround in the case where the MSI_TYPER register
+   is corrupted.
+
+Example:
+
+   interrupt-controller@e1101000 {
+   compatible = "arm,gic-400";
+   #interrupt-cells = <3>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-controller;
+   interrupts = <1 8 0xf04>;
+   ranges = <0 0 0 0xe110 0 0x10>;
+   reg = <0x0 0xe111 0 0x01000>,
+ <0x0 0xe112f000 0 0x02000>,
+ <0x0 0xe114 0 0x1>,
+ <0x0 0xe116 0 0x1>;
+   v2m0: v2m@0x8000 {
+   compatible = "arm,gic-v2m-frame";
+   msi-controller;
+   reg = <0x0 0x8 0 0x1000>;
+   };
+
+   
+
+   v2mN: v2m@0x9000 {
+   compatible = "arm,gic-v2m-frame";
+   msi-controller;
+   reg = <0x0 0x9 0 0x1000>;
+   };
+   };
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fd4e81a..83d5556 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -12,6 +12,7 @@ config ARM64
select ARM_ARCH_TIMER
select ARM_GIC
select AUDIT_ARCH_COMPAT_GENERIC
+   select ARM_GIC_V2M
select ARM_GIC_V3
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index b8632bf..ddb31ee 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -7,6 +7,13 @@ config ARM_GIC
select IRQ_DOMAIN
select MULTI_IRQ_HANDLER
 
+config ARM_GIC_V2M
+   bool
+   select IRQ_DOMAIN
+   select MULTI_IRQ_HANDLER
+   depends on ARM_GIC
+   depends on PCI && PCI_MSI
+
 config GIC_NON_BANKED
bool
 
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 73052ba..3bda951 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_SUNXI)  += irq-sun4i.o
 obj-$(CONFIG_ARCH_SUNXI)   += irq-sunxi-nmi.o
 obj-$(CONFIG_ARCH_SPEAR3XX)+= spear-shirq.o
 obj-$(CONFIG_ARM_GIC)  += irq-gic.o irq-gic-common.o
+obj-$(CONFIG_ARM_GIC_V2M)  += irq-gic-v2m.o
 obj-$(CONFIG_ARM_GIC_V3)   += irq-gic-v3.o irq-gic-common.o
 obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
 obj-$(CONFIG_ARM_VIC)  += irq-vic.o
diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index 60ac704..4b8cff2 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ b/drivers/irqchip/irq-gic

[PATCH 1/2 V7] irqchip: gic: Add support for multiple MSI for ARM64

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

This patch implelments the ARM64 version of arch_setup_msi_irqs(),
which does not return 1 for when PCI_CAP_ID_MSI and nvec > 1.

Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: Jason Cooper 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suravee Suthikulpanit 
---
 arch/arm64/kernel/Makefile |  1 +
 arch/arm64/kernel/msi.c| 41 +
 2 files changed, 42 insertions(+)
 create mode 100644 arch/arm64/kernel/msi.c

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index df7ef87..a921c42 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
 arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
 arm64-obj-$(CONFIG_KGDB)   += kgdb.o
 arm64-obj-$(CONFIG_EFI)+= efi.o efi-stub.o efi-entry.o
+arm64-obj-$(CONFIG_PCI_MSI)+= msi.o
 
 obj-y  += $(arm64-obj-y) vdso/
 obj-m  += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/msi.c b/arch/arm64/kernel/msi.c
new file mode 100644
index 000..a295862
--- /dev/null
+++ b/arch/arm64/kernel/msi.c
@@ -0,0 +1,41 @@
+/*
+ * ARM64 architectural MSI implemention
+ *
+ * Support for Message Signalelled Interrupts for systems that
+ * implement ARM Generic Interrupt Controller: GICv2m.
+ *
+ * Copyright (C) 2014 Advanced Micro Devices, Inc.
+ * Authors: Suravee Suthikulpanit 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * ARM64 function for seting up MSI irqs.
+ * Based on driver/pci/msi.c: arch_setup_msi_irqs().
+ *
+ * Note:
+ * Current implementation assumes that all interrupt controller used in
+ * ARM64 architecture _MUST_ supports multi-MSI.
+ */
+int arm64_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+   struct msi_desc *entry;
+   int ret;
+
+   list_for_each_entry(entry, &dev->msi_list, list) {
+   ret = arch_setup_msi_irq(dev, entry);
+   if (ret < 0)
+   return ret;
+   if (ret > 0)
+   return -ENOSPC;
+   }
+
+   return 0;
+}
-- 
1.9.3

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

[PATCH 0/2 V7] irqchip: gic: Introduce ARM GICv2m MSI(-X) support

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

NOTE: Resend w/ proper subject for the 2/2 patch.

This patch set introduces support for MSI(-X) in GICv2m specification,
which is implemented in some variation of GIC400.

This depends on and has been tested with the following patch set which
implements PCI supports for ARM64:

[PATCH v10 00/10] Support for creating generic PCI host bridges from DT
https://lkml.org/lkml/2014/9/8/333

[PATCH v10] Add support for PCI in AArch64
https://lkml.org/lkml/2014/9/8/325
 
Changes in V7:
* Fix error handling logic in gicv2m_of_init() and gicv2m_init_one().
  per Marc suggestions.
* Restructure the patch to integrate the multi-MSI support for V2m
  into the patch 2/2.
* Introduce "arm,gic-v2m-frame" compatible ID for the v2m DT binding.
* Introduce "arm,msi-base-spi" and "arm,msi-num-spi" property in the
  v2m DT binding for overwriting value in MSI_TYPER register.
* Add irq-gic-v2m.c: is_msi_spi_valid() to validate the SPI base and
  number of SPIs.
* Fix various comments from Marc (Many thanks).
* Add the missing CONFIG_ARM_GICV2M (per Marcin Juszkiewicz comment)

Suravee Suthikulpanit (2):
  irqchip: gic: Add support for multiple MSI for ARM64
  irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)

 Documentation/devicetree/bindings/arm/gic.txt |  55 
 arch/arm64/Kconfig|   1 +
 arch/arm64/kernel/Makefile|   1 +
 arch/arm64/kernel/msi.c   |  41 +++
 drivers/irqchip/Kconfig   |   7 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-gic-common.c  |  12 +
 drivers/irqchip/irq-gic-common.h  |   4 +
 drivers/irqchip/irq-gic-v2m.c | 356 ++
 drivers/irqchip/irq-gic.c |  82 +++---
 drivers/irqchip/irq-gic.h |  54 
 11 files changed, 584 insertions(+), 30 deletions(-)
 create mode 100644 arch/arm64/kernel/msi.c
 create mode 100644 drivers/irqchip/irq-gic-v2m.c
 create mode 100644 drivers/irqchip/irq-gic.h

-- 
1.9.3

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

Re: blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)

[Ming Lei]

On Thu, Sep 18, 2014 at 3:09 AM, David Hildenbrand
 wrote:
>> On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe  wrote:
>> >
>> > Another way would be to ensure that the timeout handler doesn't touch 
>> > hw_ctx
>> > or tag_sets that aren't fully initialized yet. But I think this is
>> > safer/cleaner.
>>
>> That may not be easy or enough to check if hw_ctx/tag_sets are
>> fully initialized if you mean all requests have been used one time.
>>
>> On Wed, Sep 17, 2014 at 10:11 PM, David Hildenbrand
>> > I was playing with a simple patch that just sets cmd_flags and 
>> > action_flags to
>>
>> What is action_flags?
>
> atomic_flags, sorry :)
>
> Otherwise e.g. REQ_ATOM_STARTED could already be set due to the randomness. I
> am not sure if this is really necessary, or if it is completely shielded by 
> the
> tag-handling code, but seemed to be clean for me to do it (and I remember it
> not being set within blk_mq_rq_ctx_init).

You are right, both cmd_flags and atomic_flags should be cleared
in blk_mq_init_rq_map().

>
>>
>> > 0. That should already be sufficient to hinder blk_mq_tag_to_rq and the 
>> > calling
>> > method to do the wrong thing.
>>
>> Yes, clearing rq->cmd_flags should be enough.
>>
>> And looks better to move rq initialization to __blk_mq_free_request()
>> too, otherwise timeout still may see old cmd_flags and rq->q before
>> rq's new initialization.
>
> Yes, __blk_mq_free_request() should also reset at least rq->cmd_flags, and I
> think we can remove the initialization from  __blk_mq_alloc_request().
>
> David
>
>>
>>
>> Thanks,
>



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

[PATCH 1/1] kdump: fix compiling error: undefined elfcorehdr_addr

[Li, Zhen-Hua]

While debugging the kdump kernel, I found there is a compiling error:
If is_kdump_kernel() is called in some driver(for example, add it in
debugging code in module qla2xxx), there will be a compiling error:

ERROR: "elfcorehdr_addr" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined!

Add EXPORT_SYMBOL for elfcorehdr_addr will fix this.

Signed-off-by: Li, Zhen-Hua 
---
 kernel/crash_dump.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/crash_dump.c b/kernel/crash_dump.c
index c766ee5..8cb4838 100644
--- a/kernel/crash_dump.c
+++ b/kernel/crash_dump.c
@@ -18,6 +18,7 @@ unsigned long saved_max_pfn;
  * it under CONFIG_CRASH_DUMP and not CONFIG_PROC_VMCORE.
  */
 unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+EXPORT_SYMBOL(elfcorehdr_addr);
 
 /*
  * stores the size of elf header of crash image
-- 
2.0.0-rc0

--
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 V7] irqchip: gic: Add support for multiple MSI for ARM64

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

This patch implelments the ARM64 version of arch_setup_msi_irqs(),
which does not return 1 for when PCI_CAP_ID_MSI and nvec > 1.

Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: Jason Cooper 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suravee Suthikulpanit 
---
 arch/arm64/kernel/Makefile |  1 +
 arch/arm64/kernel/msi.c| 41 +
 2 files changed, 42 insertions(+)
 create mode 100644 arch/arm64/kernel/msi.c

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index df7ef87..a921c42 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
 arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
 arm64-obj-$(CONFIG_KGDB)   += kgdb.o
 arm64-obj-$(CONFIG_EFI)+= efi.o efi-stub.o efi-entry.o
+arm64-obj-$(CONFIG_PCI_MSI)+= msi.o
 
 obj-y  += $(arm64-obj-y) vdso/
 obj-m  += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/msi.c b/arch/arm64/kernel/msi.c
new file mode 100644
index 000..a295862
--- /dev/null
+++ b/arch/arm64/kernel/msi.c
@@ -0,0 +1,41 @@
+/*
+ * ARM64 architectural MSI implemention
+ *
+ * Support for Message Signalelled Interrupts for systems that
+ * implement ARM Generic Interrupt Controller: GICv2m.
+ *
+ * Copyright (C) 2014 Advanced Micro Devices, Inc.
+ * Authors: Suravee Suthikulpanit 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * ARM64 function for seting up MSI irqs.
+ * Based on driver/pci/msi.c: arch_setup_msi_irqs().
+ *
+ * Note:
+ * Current implementation assumes that all interrupt controller used in
+ * ARM64 architecture _MUST_ supports multi-MSI.
+ */
+int arm64_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+   struct msi_desc *entry;
+   int ret;
+
+   list_for_each_entry(entry, &dev->msi_list, list) {
+   ret = arch_setup_msi_irq(dev, entry);
+   if (ret < 0)
+   return ret;
+   if (ret > 0)
+   return -ENOSPC;
+   }
+
+   return 0;
+}
-- 
1.9.3

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

[PATCH 2/2] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

ARM GICv2m specification extends GICv2 to support MSI(-X) with
a new set of register frame. This patch introduces support for
the non-secure GICv2m register frame. Currently, GICV2m is available
in certain version of GIC-400.

The patch introduces a new property in ARM gic binding, the v2m subnode.
It is optional.

Signed-off-by: Suravee Suthikulpanit 
Cc: Mark Rutland 
Cc: Marc Zyngier 
Cc: Jason Cooper 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 Documentation/devicetree/bindings/arm/gic.txt |  55 
 arch/arm64/Kconfig|   1 +
 drivers/irqchip/Kconfig   |   7 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-gic-common.c  |  12 +
 drivers/irqchip/irq-gic-common.h  |   4 +
 drivers/irqchip/irq-gic-v2m.c | 356 ++
 drivers/irqchip/irq-gic.c |  82 +++---
 drivers/irqchip/irq-gic.h |  54 
 9 files changed, 542 insertions(+), 30 deletions(-)
 create mode 100644 drivers/irqchip/irq-gic-v2m.c
 create mode 100644 drivers/irqchip/irq-gic.h

diff --git a/Documentation/devicetree/bindings/arm/gic.txt 
b/Documentation/devicetree/bindings/arm/gic.txt
index c7d2fa1..38b2156 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -96,3 +96,58 @@ Example:
  <0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
};
+
+
+* GICv2m extension for MSI/MSI-x support (Optional)
+
+Certain revision of GIC-400 supports MSI/MSI-x via V2M register frame.
+This is enabled by specifying v2m sub-node.
+
+Required properties:
+
+- compatible: The value here should be "arm,gic-v2m-frame".
+
+- msi-controller: Identifies the node as an MSI controller.
+
+- reg   : GICv2m MSI interface register base and size
+
+Optional properties:
+
+- arm,msi-base-spi  : Specify base SPI the MSI frame.
+  The SPI base value can be from 32 to 1019.
+
+- arm,msi-num-spi   : Returns the number of contiguous SPIs assigned
+ to the frame.
+
+Note: "arm,msi-base-spi" and "arm,msi-num-spi" are used mainly for
+   providing HW workaround in the case where the MSI_TYPER register
+   is corrupted.
+
+Example:
+
+   interrupt-controller@e1101000 {
+   compatible = "arm,gic-400";
+   #interrupt-cells = <3>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-controller;
+   interrupts = <1 8 0xf04>;
+   ranges = <0 0 0 0xe110 0 0x10>;
+   reg = <0x0 0xe111 0 0x01000>,
+ <0x0 0xe112f000 0 0x02000>,
+ <0x0 0xe114 0 0x1>,
+ <0x0 0xe116 0 0x1>;
+   v2m0: v2m@0x8000 {
+   compatible = "arm,gic-v2m-frame";
+   msi-controller;
+   reg = <0x0 0x8 0 0x1000>;
+   };
+
+   
+
+   v2mN: v2m@0x9000 {
+   compatible = "arm,gic-v2m-frame";
+   msi-controller;
+   reg = <0x0 0x9 0 0x1000>;
+   };
+   };
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fd4e81a..83d5556 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -12,6 +12,7 @@ config ARM64
select ARM_ARCH_TIMER
select ARM_GIC
select AUDIT_ARCH_COMPAT_GENERIC
+   select ARM_GIC_V2M
select ARM_GIC_V3
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index b8632bf..ddb31ee 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -7,6 +7,13 @@ config ARM_GIC
select IRQ_DOMAIN
select MULTI_IRQ_HANDLER
 
+config ARM_GIC_V2M
+   bool
+   select IRQ_DOMAIN
+   select MULTI_IRQ_HANDLER
+   depends on ARM_GIC
+   depends on PCI && PCI_MSI
+
 config GIC_NON_BANKED
bool
 
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 73052ba..3bda951 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_SUNXI)  += irq-sun4i.o
 obj-$(CONFIG_ARCH_SUNXI)   += irq-sunxi-nmi.o
 obj-$(CONFIG_ARCH_SPEAR3XX)+= spear-shirq.o
 obj-$(CONFIG_ARM_GIC)  += irq-gic.o irq-gic-common.o
+obj-$(CONFIG_ARM_GIC_V2M)  += irq-gic-v2m.o
 obj-$(CONFIG_ARM_GIC_V3)   += irq-gic-v3.o irq-gic-common.o
 obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
 obj-$(CONFIG_ARM_VIC)  += irq-vic.o
diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index 60ac704..4b8cff2 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ b/drivers/irqchip/irq-gic

[PATCH 0/2 V7] irqchip: gic: Introduce ARM GICv2m MSI(-X) support

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

This patch set introduces support for MSI(-X) in GICv2m specification,
which is implemented in some variation of GIC400.

This depends on and has been tested with the following patch set which
implements PCI supports for ARM64:

[PATCH v10 00/10] Support for creating generic PCI host bridges from DT
https://lkml.org/lkml/2014/9/8/333

[PATCH v10] Add support for PCI in AArch64
https://lkml.org/lkml/2014/9/8/325
 
Changes in V7:
* Fix error handling logic in gicv2m_of_init() and gicv2m_init_one().
  per Marc suggestions.
* Restructure the patch to integrate the multi-MSI support for V2m
  into the patch 2/2.
* Introduce "arm,gic-v2m-frame" compatible ID for the v2m DT binding.
* Introduce "arm,msi-base-spi" and "arm,msi-num-spi" property in the
  v2m DT binding for overwriting value in MSI_TYPER register.
* Add irq-gic-v2m.c: is_msi_spi_valid() to validate the SPI base and
  number of SPIs.
* Fix various comments from Marc (Many thanks).
* Add the missing CONFIG_ARM_GICV2M (per Marcin Juszkiewicz comment)

Suravee Suthikulpanit (2):
  irqchip: gic: Add support for multiple MSI for ARM64
  irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)

 Documentation/devicetree/bindings/arm/gic.txt |  55 
 arch/arm64/Kconfig|   1 +
 arch/arm64/kernel/Makefile|   1 +
 arch/arm64/kernel/msi.c   |  41 +++
 drivers/irqchip/Kconfig   |   7 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-gic-common.c  |  12 +
 drivers/irqchip/irq-gic-common.h  |   4 +
 drivers/irqchip/irq-gic-v2m.c | 356 ++
 drivers/irqchip/irq-gic.c |  82 +++---
 drivers/irqchip/irq-gic.h |  54 
 11 files changed, 584 insertions(+), 30 deletions(-)
 create mode 100644 arch/arm64/kernel/msi.c
 create mode 100644 drivers/irqchip/irq-gic-v2m.c
 create mode 100644 drivers/irqchip/irq-gic.h

-- 
1.9.3

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

Re: [RESEND PATCH] arm: exynos: Allow rtc alarm and tick wakeup irq for exynos3250.

[jonghwa3 . lee]

On 2014년 09월 17일 17:53, Vikas Sajjan wrote:

> Hi,
> 
> On Wed, Sep 17, 2014 at 8:52 AM, Jonghwa Lee  wrote:
>> Add rtc alarm and tick irq to wakeup sources in exynos3250.
>>
>> Signed-off-by: Jonghwa Lee 
>> Acked-by : Chanwoo choi 
>> ---
>>  arch/arm/mach-exynos/pm.c |9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
>> index fa7218a..d78dcf9 100644
>> --- a/arch/arm/mach-exynos/pm.c
>> +++ b/arch/arm/mach-exynos/pm.c
>> @@ -66,6 +66,12 @@ static struct sleep_save exynos_core_save[] = {
>>
>>  static u32 exynos_irqwake_intmask = 0x;
>>
>> +static const struct exynos_wkup_irq exynos3250_wkup_irq[] = {
>> +   { 105, BIT(1) }, /* RTC alarm */
>> +   { 106, BIT(2) }, /* RTC tick */
>> +   { /* sentinel */ },
>> +};
>> +
>>  static const struct exynos_wkup_irq exynos4_wkup_irq[] = {
>> { 76, BIT(1) }, /* RTC alarm */
>> { 77, BIT(2) }, /* RTC tick */
>> @@ -81,9 +87,10 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[] 
>> = {
>>  static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
>>  {
>> const struct exynos_wkup_irq *wkup_irq;
>> -
>> if (soc_is_exynos5250())
>> wkup_irq = exynos5250_wkup_irq;
>> +   else if (soc_is_exynos3250())
>> +   wkup_irq = exynos3250_wkup_irq;
> 
> 
> Don't add anymore soc_is_exynosxxx() checks, please rebase on [1],
> which refactors the pm.c to use DT based lookup.
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg355266.html
>


Okay, I'll wait those patches are merged, then I'll rebase and repost it.

Thanks,
Jonghwa.

--
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] hwmon: ntc_thermistor: Add ntc thermistor to thermal subsystem as a sensor.

[jonghwa3 . lee]

On 2014년 09월 18일 00:48, Guenter Roeck wrote:

> On Wed, Sep 17, 2014 at 02:54:37PM +0900, Jonghwa Lee wrote:
>> To get more comprehensive and integrated thermal management, it adds ntc
>> thermistor to thermal framework as a thermal sensor. It's governed thermal
>> susbsystem only if it is described in DT node. Otherwise, it just notifies
>> temperature to userspace via sysfs as it used to be.
>>
>> Signed-off-by: Jonghwa Lee 
> 
> Looks ok as far as I can see. I applied it to hwmon-next. I'll let you know
> if there are any problems.
> 
> Guenter


Okay, thanks ;)

Best regards,
Jonghwa

> 
>> ---
>> Changes:
>> v3:
>>  - Add dependencies of thermal subsystem for proper building.
>> v2:
>>  - Remove NULL pointer checking already done by 
>> thermal_zone_of_sensor_unregister().
>>
>>  .../devicetree/bindings/hwmon/ntc_thermistor.txt   |3 +++
>>  drivers/hwmon/Kconfig  |1 +
>>  drivers/hwmon/ntc_thermistor.c |   25 
>> 
>>  3 files changed, 29 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
>> b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> index 2391e5c..fcca8e7 100644
>> --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> @@ -25,6 +25,9 @@ Requires node properties:
>>  - "io-channels" Channel node of ADC to be used for
>>  conversion.
>>  
>> +Optional node properties:
>> +- "#thermal-sensor-cells" Used to expose itself to thermal fw.
>> +
>>  Read more about iio bindings at
>>  Documentation/devicetree/bindings/iio/iio-bindings.txt
>>  
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 4289a4f..f790b41 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -1077,6 +1077,7 @@ config SENSORS_PC87427
>>  config SENSORS_NTC_THERMISTOR
>>  tristate "NTC thermistor support from Murata"
>>  depends on !OF || IIO=n || IIO
>> +depends on THERMAL || !THERMAL_OF
>>  help
>>This driver supports NTC thermistors sensor reading and its
>>interpretation. The driver can also monitor the temperature and
>> diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
>> index bd41072..4ff89b2 100644
>> --- a/drivers/hwmon/ntc_thermistor.c
>> +++ b/drivers/hwmon/ntc_thermistor.c
>> @@ -38,6 +38,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  
>>  struct ntc_compensation {
>>  int temp_c;
>> @@ -182,6 +183,7 @@ struct ntc_data {
>>  struct device *dev;
>>  int n_comp;
>>  char name[PLATFORM_NAME_SIZE];
>> +struct thermal_zone_device *tz;
>>  };
>>  
>>  #if defined(CONFIG_OF) && IS_ENABLED(CONFIG_IIO)
>> @@ -428,6 +430,20 @@ static int ntc_thermistor_get_ohm(struct ntc_data *data)
>>  return -EINVAL;
>>  }
>>  
>> +static int ntc_read_temp(void *dev, long *temp)
>> +{
>> +struct ntc_data *data = dev_get_drvdata(dev);
>> +int ohm;
>> +
>> +ohm = ntc_thermistor_get_ohm(data);
>> +if (ohm < 0)
>> +return ohm;
>> +
>> +*temp = get_temp_mc(data, ohm);
>> +
>> +return 0;
>> +}
>> +
>>  static ssize_t ntc_show_name(struct device *dev,
>>  struct device_attribute *attr, char *buf)
>>  {
>> @@ -562,6 +578,13 @@ static int ntc_thermistor_probe(struct platform_device 
>> *pdev)
>>  dev_info(&pdev->dev, "Thermistor type: %s successfully probed.\n",
>>  pdev_id->name);
>>  
>> +data->tz = thermal_zone_of_sensor_register(data->dev, 0, data->dev,
>> +ntc_read_temp, NULL);
>> +if (IS_ERR(data->tz)) {
>> +dev_dbg(&pdev->dev, "Failed to register to thermal fw.\n");
>> +data->tz = NULL;
>> +}
>> +
>>  return 0;
>>  err_after_sysfs:
>>  sysfs_remove_group(&data->dev->kobj, &ntc_attr_group);
>> @@ -578,6 +601,8 @@ static int ntc_thermistor_remove(struct platform_device 
>> *pdev)
>>  sysfs_remove_group(&data->dev->kobj, &ntc_attr_group);
>>  ntc_iio_channel_release(pdata);
>>  
>> +thermal_zone_of_sensor_unregister(data->dev, data->tz);
>> +
>>  return 0;
>>  }
>>  
>> -- 
>> 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] arm:extend the reserved mrmory for initrd to be page aligned

[Wang, Yalin]

this patch extend the start and end address of initrd to be page aligned,
so that we can free all memory including the un-page aligned head or tail
page of initrd, if the start or end address of initrd are not page
aligned, the page can't be freed by free_initrd_mem() function.

Signed-off-by: Yalin Wang 
---
 arch/arm/mm/init.c   | 5 +
 arch/arm64/mm/init.c | 8 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 659c75d..9221645 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -636,6 +636,11 @@ static int keep_initrd;
 void free_initrd_mem(unsigned long start, unsigned long end)
 {
if (!keep_initrd) {
+   if (start == initrd_start)
+   start = round_down(start, PAGE_SIZE);
+   if (end == initrd_end)
+   end = round_up(end, PAGE_SIZE);
+
poison_init_mem((void *)start, PAGE_ALIGN(end) - start);
free_reserved_area((void *)start, (void *)end, -1, "initrd");
}
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5472c24..c5512f6 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -334,8 +334,14 @@ static int keep_initrd;
 
 void free_initrd_mem(unsigned long start, unsigned long end)
 {
-   if (!keep_initrd)
+   if (!keep_initrd) {
+   if (start == initrd_start)
+   start = round_down(start, PAGE_SIZE);
+   if (end == initrd_end)
+   end = round_up(end, PAGE_SIZE);
+
free_reserved_area((void *)start, (void *)end, 0, "initrd");
+   }
 }
 
 static int __init keepinitrd_setup(char *__unused)
-- 
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/7] test: add firmware_class loader test

[Sasha Levin]

On 07/14/2014 05:38 PM, Kees Cook wrote:
> This provides a simple interface to trigger the firmware_class loader
> to test built-in, filesystem, and user helper modes. Additionally adds
> tests via the new interface to the selftests tree.
> 
> Signed-off-by: Kees Cook 

Hi folks,

While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following spew:

[  413.999779] misc test_firmware: Falling back to user helper
[  414.003728] WARNING: CPU: 25 PID: 9860 at lib/kobject.c:209 
kobject_add_internal+0x3a3/0x450()
[  414.006815] kobject: (8807b4ef5dc8): attempted to be registered with 
empty name!
[  414.009482] Modules linked in:
[  414.010818] CPU: 25 PID: 9860 Comm: trinity-c662 Tainted: GW      
3.17.0-rc5-next-20140917-sasha-00041-gd01267b #1198
[  414.014626]  0009 880236547a68 9d56d655 

[  414.017585]  880236547ab8 880236547aa8 9a15f3d1 
001e3540
[  414.020733]  8807b4ef5dc8 ffea 88043d114108 
8807b4ef5db8
[  414.023345] Call Trace:
[  414.024254] dump_stack (lib/dump_stack.c:52)
[  414.026232] warn_slowpath_common (kernel/panic.c:432)
[  414.028355] warn_slowpath_fmt (kernel/panic.c:446)
[  414.030366] ? __raw_spin_lock_init (kernel/locking/spinlock_debug.c:24)
[  414.032369] kobject_add_internal (lib/kobject.c:211 (discriminator 1))
[  414.034313] ? __dynamic_pr_debug (lib/dynamic_debug.c:561)
[  414.036254] kobject_add (lib/kobject.c:403)
[  414.038017] ? device_private_init (drivers/base/core.c:929)
[  414.040340] ? klist_init (lib/klist.c:90)
[  414.044729] device_add (drivers/base/core.c:1010)
[  414.049854] ? dev_set_name (drivers/base/core.c:876)
[  414.060790] _request_firmware (drivers/base/firmware_class.c:892 
drivers/base/firmware_class.c:957 drivers/base/firmware_class.c:1139)
[  414.062814] request_firmware (drivers/base/firmware_class.c:1189)
[  414.064796] trigger_request_store (lib/test_firmware.c:68)
[  414.066774] dev_attr_store (drivers/base/core.c:138)
[  414.068531] sysfs_kf_write (fs/sysfs/file.c:115)
[  414.070826] kernfs_fop_write (fs/kernfs/file.c:308)
[  414.074648] ? kernfs_vma_page_mkwrite (fs/kernfs/file.c:267)
[  414.076864] do_loop_readv_writev (fs/read_write.c:710)
[  414.078947] ? kernfs_vma_page_mkwrite (fs/kernfs/file.c:267)
[  414.081269] do_readv_writev (fs/read_write.c:842)
[  414.083281] ? preempt_count_sub (kernel/sched/core.c:2634)
[  414.085380] ? mutex_lock_nested (./arch/x86/include/asm/preempt.h:98 
kernel/locking/mutex.c:599 kernel/locking/mutex.c:616)
[  414.087401] ? __fdget_pos (fs/file.c:714)
[  414.089286] vfs_writev (fs/read_write.c:881)
[  414.091243] SyS_writev (fs/read_write.c:914 fs/read_write.c:905)
[  414.093053] tracesys_phase2 (arch/x86/kernel/entry_64.S:529)


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

[PATCH] cgroup/kmemleak: add kmemleak_free() for cgroup deallocations.

[Wang Nan]

Commit ff7ee93f4 introduces kmemleak_alloc() for alloc_page_cgroup(),
but corresponding kmemleak_free() is missing, which makes kmemleak be
wrongly disabled after memory offlining. Log is pasted at the end of
this commit message.

This patch add kmemleak_free() into free_page_cgroup(). During page
offlining, this patch removes corresponding entries in kmemleak rbtree.
After that, the freed memory can be allocated again by other subsystems
without killing kmemleak.

bash # for x in 1 2 3 4; do echo offline > 
/sys/devices/system/memory/memory$x/state ; sleep 1; done ; dmesg | grep leak
[   45.537934] Offlined Pages 32768
[   46.617892] kmemleak: Cannot insert 0x880016969000 into the object 
search tree (overlaps existing)
[   46.617892] CPU: 0 PID: 412 Comm: sleep Not tainted 3.17.0-rc5+ #86
[   46.617892] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   46.617892]  880016823d10 880018bdfc38 81725d2c 
88001780e950
[   46.617892]  880016969000 880018bdfc88 8117a9e6 
880018bdfc78
[   46.617892]  0096 880017812800 81c2eda0 
880016969000
[   46.617892] Call Trace:
[   46.617892]  [] dump_stack+0x46/0x58
[   46.617892]  [] create_object+0x266/0x2c0
[   46.617892]  [] kmemleak_alloc+0x26/0x50
[   46.617892]  [] kmem_cache_alloc+0xd3/0x160
[   46.617892]  [] __sigqueue_alloc+0x49/0xd0
[   46.617892]  [] __send_signal+0xcb/0x410
[   46.617892]  [] send_signal+0x45/0x90
[   46.617892]  [] __group_send_sig_info+0x13/0x20
[   46.617892]  [] do_notify_parent+0x1bb/0x260
[   46.617892]  [] ? sched_move_task+0xaa/0x130
[   46.617892]  [] do_exit+0x767/0xa40
[   46.617892]  [] do_group_exit+0x44/0xa0
[   46.617892]  [] SyS_exit_group+0x17/0x20
[   46.617892]  [] system_call_fastpath+0x16/0x1b
[   46.617892] kmemleak: Kernel memory leak detector disabled
[   46.617892] kmemleak: Object 0x88001690 (size 524288):
[   46.617892] kmemleak:   comm "swapper/0", pid 0, jiffies 4294667296
[   46.617892] kmemleak:   min_count = 0
[   46.617892] kmemleak:   count = 0
[   46.617892] kmemleak:   flags = 0x1
[   46.617892] kmemleak:   checksum = 0
[   46.617892] kmemleak:   backtrace:
[   46.617892]  [] log_early+0x63/0x77
[   46.617892]  [] kmemleak_alloc+0x4b/0x50
[   46.617892]  [] init_section_page_cgroup+0x7f/0xf5
[   46.617892]  [] page_cgroup_init+0xc5/0xd0
[   46.617892]  [] start_kernel+0x333/0x408
[   46.617892]  [] x86_64_start_reservations+0x2a/0x2c
[   46.617892]  [] x86_64_start_kernel+0xf5/0xfc
[   46.617892]  [] 0x

Signed-off-by: Wang Nan 
Cc: Steven Rostedt 
---
 mm/page_cgroup.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 3708264..5331c2b 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -171,6 +171,7 @@ static void free_page_cgroup(void *addr)
sizeof(struct page_cgroup) * PAGES_PER_SECTION;
 
BUG_ON(PageReserved(page));
+   kmemleak_free(addr);
free_pages_exact(addr, table_size);
}
 }
-- 
1.8.4

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

[PATCH] X86: add IPI tracepoints

[Nicolas Pitre]

On X86 there are already tracepoints for IRQ vectors through which IPIs
are handled.  However this is highly X86 specific, and the IPI signaling
is not currently traced.

This is an attempt at adding generic IPI tracepoints to X86.

Signed-off-by: Nicolas Pitre 
Acked-by: Daniel Lezcano 
---

This is a resent.  This patch was part of a larger series that got 
merged during the last merge window.

diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index be8e1bde07..d193609bea 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -31,6 +31,16 @@
 #include 
 #include 
 #include 
+
+#define CREATE_TRACE_POINTS
+/*
+ * Those were defined in  and cause problems
+ * when including .
+ */
+#undef TRACE_INCLUDE_PATH
+#undef TRACE_INCLUDE_FILE
+#include 
+
 /*
  * Some notes on x86 processor bugs affecting SMP operation:
  *
@@ -124,11 +134,13 @@ static void native_smp_send_reschedule(int cpu)
WARN_ON(1);
return;
}
+   trace_ipi_raise(cpumask_of(cpu), tracepoint_string("RESCHEDULE"));
apic->send_IPI_mask(cpumask_of(cpu), RESCHEDULE_VECTOR);
 }
 
 void native_send_call_func_single_ipi(int cpu)
 {
+   trace_ipi_raise(cpumask_of(cpu), 
tracepoint_string("CALL_FUNCTION_SINGLE"));
apic->send_IPI_mask(cpumask_of(cpu), CALL_FUNCTION_SINGLE_VECTOR);
 }
 
@@ -136,6 +148,8 @@ void native_send_call_func_ipi(const struct cpumask *mask)
 {
cpumask_var_t allbutself;
 
+   trace_ipi_raise(mask, tracepoint_string("CALL_FUNCTION"));
+
if (!alloc_cpumask_var(&allbutself, GFP_ATOMIC)) {
apic->send_IPI_mask(mask, CALL_FUNCTION_VECTOR);
return;
@@ -252,8 +266,10 @@ finish:
  */
 static inline void __smp_reschedule_interrupt(void)
 {
+   trace_ipi_entry(tracepoint_string("RESCHEDULE"));
inc_irq_stat(irq_resched_count);
scheduler_ipi();
+   trace_ipi_exit(tracepoint_string("RESCHEDULE"));
 }
 
 __visible void smp_reschedule_interrupt(struct pt_regs *regs)
@@ -291,8 +307,10 @@ __visible void smp_trace_reschedule_interrupt(struct 
pt_regs *regs)
 
 static inline void __smp_call_function_interrupt(void)
 {
+   trace_ipi_entry(tracepoint_string("CALL_FUNCTION"));
generic_smp_call_function_interrupt();
inc_irq_stat(irq_call_count);
+   trace_ipi_exit(tracepoint_string("CALL_FUNCTION"));
 }
 
 __visible void smp_call_function_interrupt(struct pt_regs *regs)
@@ -313,8 +331,10 @@ __visible void smp_trace_call_function_interrupt(struct 
pt_regs *regs)
 
 static inline void __smp_call_function_single_interrupt(void)
 {
+   trace_ipi_entry(tracepoint_string("CALL_FUNCTION_SINGLE"));
generic_smp_call_function_single_interrupt();
inc_irq_stat(irq_call_count);
+   trace_ipi_exit(tracepoint_string("CALL_FUNCTION_SINGLE"));
 }
 
 __visible void smp_call_function_single_interrupt(struct pt_regs *regs)
--
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] msm:rpm-smd:change msm_rpm_smd_work method

[Wang, Yalin]

Hi Bjorn,

I see,
Thanks for your kind remind :)

-Original Message-
On Tue, Sep 16, 2014 at 7:05 PM, Wang, Yalin  wrote:
[..]
> diff --git a/arch/arm/mach-msm/rpm-smd.c b/arch/arm/mach-msm/rpm-smd.c

Hi Yalin,

This file does not exist in mainline and this is not the forum for sending 
patches to codeaurora.
Also note that your commit messages may not include "Change-id" when sending to 
LKML.

Regards,
Bjorn

Re: [PATCH 1/2] regulator: st-pwm: get voltage and duty table from dts

[Chris Zhong]

On 09/18/2014 12:54 AM, Doug Anderson wrote:

Hi,

On Wed, Sep 17, 2014 at 9:51 AM, Mark Brown  wrote:

On Wed, Sep 17, 2014 at 09:07:59PM +0800, Chris Zhong wrote:

Get voltage & duty table from device tree might be better, other platforms can 
also use this
driver without any modify.

Signed-off-by: Chris Zhong 
---

  drivers/regulator/Kconfig  |1 -
  drivers/regulator/st-pwm.c |   80 +++-

You need to update the binding document if you're updating the DT
bindings.

Mark: See part 2 .
Unfortunately you weren't CCed on that.  It also should have been
patch #1, not patch #2.

Chris: please change the order and make sure Mark is CCed on the
bindings.  Probably anyone CCed on the code change should be on the
bindings change (and probably vice versa, but maybe not as critical).

-Doug



Thanks.
I should not only use patman's script to created cc list.
--
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/