[PATCH v3 01/10] mmc: core: Add DT bindings for eMMC hardware reset support

[Chaotian Jing]

Sometime only need set MMC_CAP_HW_RESET for one of MMC hosts,
So set it in device tree is better.

Signed-off-by: Chaotian Jing 
---
 Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
 drivers/mmc/core/host.c   | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 0384fc3..f693baf 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -37,6 +37,7 @@ Optional properties:
 - sd-uhs-sdr104: SD UHS SDR104 speed is supported
 - sd-uhs-ddr50: SD UHS DDR50 speed is supported
 - cap-power-off-card: powering off the card is safe
+- cap-mmc-hw-reset: eMMC hardware reset is supported
 - cap-sdio-irq: enable SDIO IRQ signalling on this interface
 - full-pwr-cycle: full power cycle of the card is supported
 - mmc-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index abd933b..04fdc2f 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -507,6 +507,8 @@ int mmc_of_parse(struct mmc_host *host)
host->caps |= MMC_CAP_UHS_DDR50;
if (of_property_read_bool(np, "cap-power-off-card"))
host->caps |= MMC_CAP_POWER_OFF_CARD;
+   if (of_property_read_bool(np, "cap-mmc-hw-reset"))
+   host->caps |= MMC_CAP_HW_RESET;
if (of_property_read_bool(np, "cap-sdio-irq"))
host->caps |= MMC_CAP_SDIO_IRQ;
if (of_property_read_bool(np, "full-pwr-cycle"))
-- 
1.8.1.1.dirty

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

[PATCH v3 04/10] mmc: mediatek: change the argument "ddr" to "timing"

[Chaotian Jing]

use the ios->timing directly is better
It can reflect current timing and do settings by timing

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 8b3e15d..c877ded 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -297,7 +297,7 @@ struct msdc_host {
u32 mclk;   /* mmc subsystem clock frequency */
u32 src_clk_freq;   /* source clock frequency */
u32 sclk;   /* SD/MS bus clock frequency */
-   bool ddr;
+   unsigned char timing;
bool vqmmc_enabled;
struct msdc_save_para save_para; /* used when gate HCLK */
 };
@@ -488,7 +488,7 @@ static void msdc_ungate_clock(struct msdc_host *host)
cpu_relax();
 }
 
-static void msdc_set_mclk(struct msdc_host *host, int ddr, u32 hz)
+static void msdc_set_mclk(struct msdc_host *host, unsigned char timing, u32 hz)
 {
u32 mode;
u32 flags;
@@ -504,7 +504,8 @@ static void msdc_set_mclk(struct msdc_host *host, int ddr, 
u32 hz)
 
flags = readl(host->base + MSDC_INTEN);
sdr_clr_bits(host->base + MSDC_INTEN, flags);
-   if (ddr) { /* may need to modify later */
+   if (timing == MMC_TIMING_UHS_DDR50 ||
+   timing == MMC_TIMING_MMC_DDR52) {
mode = 0x2; /* ddr mode and use divisor */
if (hz >= (host->src_clk_freq >> 2)) {
div = 0; /* mean div = 1/4 */
@@ -535,12 +536,12 @@ static void msdc_set_mclk(struct msdc_host *host, int 
ddr, u32 hz)
cpu_relax();
host->sclk = sclk;
host->mclk = hz;
-   host->ddr = ddr;
+   host->timing = timing;
/* need because clk changed. */
msdc_set_timeout(host, host->timeout_ns, host->timeout_clks);
sdr_set_bits(host->base + MSDC_INTEN, flags);
 
-   dev_dbg(host->dev, "sclk: %d, ddr: %d\n", host->sclk, ddr);
+   dev_dbg(host->dev, "sclk: %d, timing: %d\n", host->sclk, timing);
 }
 
 static inline u32 msdc_cmd_find_resp(struct msdc_host *host,
@@ -1158,14 +1159,9 @@ static void msdc_ops_set_ios(struct mmc_host *mmc, 
struct mmc_ios *ios)
 {
struct msdc_host *host = mmc_priv(mmc);
int ret;
-   u32 ddr = 0;
 
pm_runtime_get_sync(host->dev);
 
-   if (ios->timing == MMC_TIMING_UHS_DDR50 ||
-   ios->timing == MMC_TIMING_MMC_DDR52)
-   ddr = 1;
-
msdc_set_buswidth(host, ios->bus_width);
 
/* Suspend/Resume will do power off/on */
@@ -1202,8 +1198,8 @@ static void msdc_ops_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
break;
}
 
-   if (host->mclk != ios->clock || host->ddr != ddr)
-   msdc_set_mclk(host, ddr, ios->clock);
+   if (host->mclk != ios->clock || host->timing != ios->timing)
+   msdc_set_mclk(host, ios->timing, ios->clock);
 
 end:
pm_runtime_mark_last_busy(host->dev);
-- 
1.8.1.1.dirty

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

[PATCH v3 05/10] mmc: mediatek: fix got GPD checksum error interrupt when data transfer

[Chaotian Jing]

Even if we only use one gpd, we need alloc 2 gpd and make
the gpd->next pointer to the second gpd, or may get gpd checksum
error, this was checked by hardware

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index c877ded..3858163 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1145,11 +1145,14 @@ static void msdc_init_gpd_bd(struct msdc_host *host, 
struct msdc_dma *dma)
struct mt_bdma_desc *bd = dma->bd;
int i;
 
-   memset(gpd, 0, sizeof(struct mt_gpdma_desc));
+   memset(gpd, 0, sizeof(struct mt_gpdma_desc) * 2);
 
gpd->gpd_info = GPDMA_DESC_BDP; /* hwo, cs, bd pointer */
gpd->ptr = (u32)dma->bd_addr; /* physical address */
-
+   /* gpd->next is must set for desc DMA
+* That's why must alloc 2 gpd structure.
+*/
+   gpd->next = (u32)dma->gpd_addr + sizeof(struct mt_gpdma_desc);
memset(bd, 0, sizeof(struct mt_bdma_desc) * MAX_BD_NUM);
for (i = 0; i < (MAX_BD_NUM - 1); i++)
bd[i].next = (u32)dma->bd_addr + sizeof(*bd) * (i + 1);
@@ -1306,7 +1309,7 @@ static int msdc_drv_probe(struct platform_device *pdev)
 
host->timeout_clks = 3 * 1048576;
host->dma.gpd = dma_alloc_coherent(>dev,
-   sizeof(struct mt_gpdma_desc),
+   2 * sizeof(struct mt_gpdma_desc),
>dma.gpd_addr, GFP_KERNEL);
host->dma.bd = dma_alloc_coherent(>dev,
MAX_BD_NUM * sizeof(struct mt_bdma_desc),
@@ -1347,7 +1350,7 @@ release:
 release_mem:
if (host->dma.gpd)
dma_free_coherent(>dev,
-   sizeof(struct mt_gpdma_desc),
+   2 * sizeof(struct mt_gpdma_desc),
host->dma.gpd, host->dma.gpd_addr);
if (host->dma.bd)
dma_free_coherent(>dev,
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v12 4/6] QE/CPM: move muram management functions to qe_common

[Zhao Qiang]

On Tue, Oct 27, 2015 at 12:48 PM, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, October 27, 2015 12:48 PM
> To: Zhao Qiang-B45475 
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> pau...@samba.org
> Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management functions to
> qe_common
> 
> On Sun, 2015-10-25 at 21:42 -0500, Zhao Qiang-B45475 wrote:
> > On Sat, Oct 24, 2015 at 04:56 AM, Wood Scott-B07421 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Saturday, October 24, 2015 4:56 AM
> > > To: Zhao Qiang-B45475 
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > > pau...@samba.org
> > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> functions
> > > to qe_common
> > >
> > > On Fri, 2015-10-23 at 02:45 -0500, Zhao Qiang-B45475 wrote:
> > > > On Fri, 2015-10-23 at 11:10 AM, Wood Scott-B07421
> > > > 
> > > > wrote:
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Friday, October 23, 2015 11:10 AM
> > > > > To: Zhao Qiang-B45475 
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472
> > > > > ; pau...@samba.org
> > > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> > > functions
> > > > > to qe_common
> > > > >
> > > > > On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote:
> > > > > > QE and CPM have the same muram, they use the same management
> > > > > > functions. Now QE support both ARM and PowerPC, it is
> > > > > > necessary to move QE to "driver/soc", so move the muram
> > > > > > management functions from cpm_common to qe_common for
> > > > > > preparing to move QE code to
> > > "driver/soc"
> > > > > >
> > > > > > Signed-off-by: Zhao Qiang 
> > > > > > ---
> > > > > > Changes for v2:
> > > > > >   - no changes
> > > > > > Changes for v3:
> > > > > >   - no changes
> > > > > > Changes for v4:
> > > > > >   - no changes
> > > > > > Changes for v5:
> > > > > >   - no changes
> > > > > > Changes for v6:
> > > > > >   - using genalloc instead rheap to manage QE MURAM
> > > > > >   - remove qe_reset from platform file, using
> > > > > >   - subsys_initcall to call qe_init function.
> > > > > > Changes for v7:
> > > > > >   - move this patch from 3/3 to 2/3
> > > > > >   - convert cpm with genalloc
> > > > > >   - check for gen_pool allocation failure Changes for v8:
> > > > > >   - rebase
> > > > > >   - move BD_SC_* macro instead of copy Changes for v9:
> > > > > >   - doesn't modify CPM, add a new patch to modify.
> > > > > >   - rebase
> > > > > > Changes for v10:
> > > > > >   - rebase
> > > > > > Changes for v11:
> > > > > >   - remove renaming
> > > > > >   - delete removing qe_reset and delete adding qe_init.
> > > > > > Changes for v12:
> > > > > >   - SPI_FSL_CPM depends on QE-MURAM, select QUICC_ENGINE for
> it.
> > > > >
> > > > > Why is the SPI change part of this patch?  Why is it even part
> > > > > of this patchset, rather than an independent patch sent to the
> > > > > SPI list and maintainer?  If it's tied to other changes you're
> > > > > making, explain that.  As is, there is zero mention of the SPI
> > > > > change in the part of the e-mail that will become the git changelog.
> > > > >
> > > > This SPI_FSL_CPM is cpm-spi, it is part of CPM.
> > >
> > > So then why are you selecting QUICC_ENGINE?  And again, what does it
> > > have to do with this patch?
> >
> > Cpm-spi is dependent on qe_muram, if not select it, Cpm-spi will
> > failed to build.
> 
> Why QUICC_ENGINE and not CPM?

QE and CPM use the same muram, and it has been moved to qe_muram from cpm_muram.

> 
> -Scott

Re: [PATCH v4 5/7] usb: gadget: f_midi: set altsettings only for MIDIStreaming interface

[Robert Baldyga]

On 10/26/2015 11:53 PM, Felipe Tonello wrote:
> Hi Robert,
> 
> On Mon, Oct 26, 2015 at 10:30 PM, Robert Baldyga
>  wrote:
>> On 10/26/2015 05:55 PM, Felipe F. Tonello wrote:
>>> This avoids duplication of USB requests for OUT endpoint and
>>> re-enabling endpoints.
>>>
>>> Signed-off-by: Felipe F. Tonello 
>>> ---
>>>  drivers/usb/gadget/function/f_midi.c | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>>> b/drivers/usb/gadget/function/f_midi.c
>>> index 0e9cdeb..a617df3 100644
>>> --- a/drivers/usb/gadget/function/f_midi.c
>>> +++ b/drivers/usb/gadget/function/f_midi.c
>>> @@ -323,6 +323,10 @@ static int f_midi_set_alt(struct usb_function *f, 
>>> unsigned intf, unsigned alt)
>>>   unsigned i;
>>>   int err;
>>>
>>> + /* We don't care if it is not MIDIStreaming interface */
>>> + if (intf != ms_interface_desc.bInterfaceNumber)
>>> + return 0;
>>> +
>>
>> These global descriptors are overwritten in bind() of each instance of
>> f_midi, so you have no guarantee that your bInterfaceNumber is correct
>> for your current instance. Instead you should store value obtained from
>> usb_interface_id() during bind().
> 
> Ok.
> 
> But then this interface descriptors shouldn't be global static,
> because they will always reflect the latest bind() only. Right?

They are copied for each instance of USB function, so they are actually
template to fill and copy in bind(). I'm currently working on some
patches changing a bit behavior of set_alt() to make it clearer, but for
now the only way to distinguish between altsettings properly is to store
bInterfaceNumber value for each function instance in its bind().

Best regards,
Robert

> 
>>
>>>   err = f_midi_start_ep(midi, f, midi->in_ep);
>>>   if (err)
>>>   return err;
>>>
> 
> Felipe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add iommu node for hi6220 SoC platform

[Chen Feng]

arm64: dts: Add dts node for hi6220 smmu driver

Signed-off-by: Chen Feng 
Signed-off-by: Yu Dongbin 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..7ae0984 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,18 @@
clocks = <_ctrl 36>, <_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+   iommu: iommu@f421 {
+   compatible = "hisilicon,hi6220-smmu";
+   reg = <0x0 0xf421 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_ctrl HI6220_MMU_CLK>,
+<_ctrl HI6220_MED_MMU>,
+<_ctrl HI6220_MEDIA_PLL_SRC>;
+   clock-names = "smmu",
+ "media-sc",
+ "smmu-peri";
+   #iommu-cells = <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 2/3] Add iommu driver for hi6220 SoC platform

[Chen Feng]

iommu/hisilicon: Add hi6220-SoC smmu driver

The smmu on hi6220 SoC is for media system.And the
media IP use the same page-table. It supports only
one-to-one mapping from iova to phys address.

Signed-off-by: Chen Feng 
Signed-off-by: Yu Dongbin 
---
 drivers/iommu/Kconfig|  11 +
 drivers/iommu/Makefile   |   1 +
 drivers/iommu/hi6220_iommu.c | 492 +++
 3 files changed, 504 insertions(+)
 create mode 100644 drivers/iommu/hi6220_iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index cbe6a89..6ca24db 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -342,6 +342,17 @@ config SPAPR_TCE_IOMMU
  Enables bits of IOMMU API required by VFIO. The iommu_ops
  is not implemented as it is not necessary for VFIO.
 
+config HI6220_IOMMU
+   bool "Hi6220 IOMMU Support"
+   depends on ARM64
+   select IOMMU_API
+   select IOMMU_IOVA
+   help
+ Enable IOMMU Driver for hi6220 SoC. The IOMMU API and IOMMU IOVA
+ is also selected.
+
+ If unsure, say N.
+
 # ARM IOMMU support
 config ARM_SMMU
bool "ARM Ltd. System MMU (SMMU) Support"
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index c6dcc51..db68fb3 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o
 obj-$(CONFIG_ARM_SMMU) += arm-smmu.o
 obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
 obj-$(CONFIG_DMAR_TABLE) += dmar.o
+obj-$(CONFIG_HI6220_IOMMU) += hi6220_iommu.o
 obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o
 obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
 obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
diff --git a/drivers/iommu/hi6220_iommu.c b/drivers/iommu/hi6220_iommu.c
new file mode 100644
index 000..47eb390
--- /dev/null
+++ b/drivers/iommu/hi6220_iommu.c
@@ -0,0 +1,492 @@
+/*
+ * Hisilicon Hi6220 IOMMU driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Chen Feng 
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) "IOMMU: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SMMU_CTRL_OFFSET (0x)
+#define SMMU_ENABLE_OFFSET   (0x0004)
+#define SMMU_PTBR_OFFSET (0x0008)
+#define SMMU_START_OFFSET(0x000C)
+#define SMMU_END_OFFSET  (0x0010)
+#define SMMU_INTMASK_OFFSET  (0x0014)
+#define SMMU_RINTSTS_OFFSET  (0x0018)
+#define SMMU_MINTSTS_OFFSET  (0x001C)
+#define SMMU_INTCLR_OFFSET   (0x0020)
+#define SMMU_STATUS_OFFSET   (0x0024)
+#define SMMU_AXIID_OFFSET(0x0028)
+#define SMMU_CNTCTRL_OFFSET  (0x002C)
+#define SMMU_TRANSCNT_OFFSET (0x0030)
+#define SMMU_L0TLBHITCNT_OFFSET  (0x0034)
+#define SMMU_L1TLBHITCNT_OFFSET  (0x0038)
+#define SMMU_WRAPCNT_OFFSET  (0x003C)
+#define SMMU_SEC_START_OFFSET(0x0040)
+#define SMMU_SEC_END_OFFSET  (0x0044)
+#define SMMU_VERSION_OFFSET  (0x0048)
+#define SMMU_IPTSRC_OFFSET   (0x004C)
+#define SMMU_IPTPA_OFFSET(0x0050)
+#define SMMU_TRBA_OFFSET (0x0054)
+#define SMMU_BYS_START_OFFSET(0x0058)
+#define SMMU_BYS_END_OFFSET  (0x005C)
+#define SMMU_RAM_OFFSET  (0x1000)
+
+#define SMMU_CTRL_INVALID(BIT(10))
+#define SMMU_SR_REGS_NUM (15)
+#define SMMU_REGS_SGMT_END   (0x60)
+#define PAGE_ENTRY_VALID (0x1)
+#define IOPAGE_SHIFT (12)
+#define IOVA_PFN(addr)   ((addr) >> IOPAGE_SHIFT)
+#define IOVA_PAGE_SZ (SZ_4K)
+
+/**
+ * The iova address from 0 ~ 2G
+ */
+#define IOVA_START   (0x0)
+#define IOVA_END (0x8000)
+
+struct hi6220_smmu {
+   unsigned int irq;
+   void __iomem *reg_base;
+   struct clk *smmu_peri_clk;
+   struct clk *smmu_clk;
+   struct clk *media_sc_clk;
+   spinlock_t spinlock; /*spinlock for tlb invalid*/
+   dma_addr_t pgtable_phy;
+   void *pgtable_virt;
+   u32  pgtable_size;
+   u32  *sr_data;
+};
+
+struct hi6220_domain {
+   struct hi6220_smmu *smmu_dev;
+   struct iommu_domain io_domain;
+};
+
+static struct hi6220_smmu *smmu_dev_handle;
+static struct iova_domain iova_allocator;
+
+static struct hi6220_domain *to_hi6220_domain(struct iommu_domain *dom)
+{
+   return container_of(dom, struct hi6220_domain, io_domain);
+}
+
+static inline void __smmu_writel(struct hi6220_smmu *smmu_dev, u32 value,
+unsigned long offset)
+{
+   writel(value, smmu_dev->reg_base 

Re: [PATCH v12 4/6] QE/CPM: move muram management functions to qe_common

[Scott Wood]

On Tue, 2015-10-27 at 02:34 -0500, Zhao Qiang-B45475 wrote:
> On Tue, Oct 27, 2015 at 2:50 PM, Wood Scott-B07421 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, October 27, 2015 2:50 PM
> > To: Zhao Qiang-B45475 
> > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > pau...@samba.org
> > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management functions to
> > qe_common
> > 
> > On Tue, 2015-10-27 at 01:24 -0500, Zhao Qiang-B45475 wrote:
> > > On Tue, Oct 27, 2015 at 12:48 PM, Wood Scott-B07421 wrote:
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Tuesday, October 27, 2015 12:48 PM
> > > > To: Zhao Qiang-B45475 
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > > > pau...@samba.org
> > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> > functions
> > > > to qe_common
> > > > 
> > > > On Sun, 2015-10-25 at 21:42 -0500, Zhao Qiang-B45475 wrote:
> > > > > On Sat, Oct 24, 2015 at 04:56 AM, Wood Scott-B07421 wrote:
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Saturday, October 24, 2015 4:56 AM
> > > > > > To: Zhao Qiang-B45475 
> > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472
> > > > > > ; pau...@samba.org
> > > > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> > > > functions
> > > > > > to qe_common
> > > > > > 
> > > > > > On Fri, 2015-10-23 at 02:45 -0500, Zhao Qiang-B45475 wrote:
> > > > > > > On Fri, 2015-10-23 at 11:10 AM, Wood Scott-B07421
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: Wood Scott-B07421
> > > > > > > > Sent: Friday, October 23, 2015 11:10 AM
> > > > > > > > To: Zhao Qiang-B45475 
> > > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > > linuxppc-...@lists.ozlabs.org; lau...@codeaurora.org; Xie
> > > > > > > > Xiaobo-R63061 ;
> > > > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472
> > > > > > > > ; pau...@samba.org
> > > > > > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> > > > > > functions
> > > > > > > > to qe_common
> > > > > > > > 
> > > > > > So then why are you selecting QUICC_ENGINE?  And again, what
> > > > > > does it have to do with this patch?
> > > > > 
> > > > > Cpm-spi is dependent on qe_muram, if not select it, Cpm-spi will
> > > > > failed to build.
> > > > 
> > > > Why QUICC_ENGINE and not CPM?
> > > 
> > > QE and CPM use the same muram, and it has been moved to qe_muram
> > from
> > > cpm_muram.
> > 
> > Fix the makefiles so that the muram code continues to be built for both
> > QUICC_ENGINE and CPM.  It's not acceptable to have to bring in the entire 
> > QE
> > code just for the muram.
> > 
> How about to define and CONFIG_QE_MURAM in Kconfig for muram?

That's fine.

-Scott

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: serial: sa1100.c: use UPIO_MEM rather than SERIAL_IO_MEM

[Saurabh Sengar]

use UPIO_MEM rather then SERIAL_IO_MEM.
both have the same value

Signed-off-by: Saurabh Sengar 
---
 drivers/tty/serial/sa1100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sa1100.c b/drivers/tty/serial/sa1100.c
index fd3d132..283c7e0 100644
--- a/drivers/tty/serial/sa1100.c
+++ b/drivers/tty/serial/sa1100.c
@@ -579,7 +579,7 @@ sa1100_verify_port(struct uart_port *port, struct 
serial_struct *ser)
ret = -EINVAL;
if (sport->port.irq != ser->irq)
ret = -EINVAL;
-   if (ser->io_type != SERIAL_IO_MEM)
+   if (ser->io_type != UPIO_MEM)
ret = -EINVAL;
if (sport->port.uartclk / 16 != ser->baud_base)
ret = -EINVAL;
-- 
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] libata: enable LBA flag in taskfile for ata_scsi_pass_thru()

[Vinayak Kale]

On Tue, Oct 27, 2015 at 1:19 PM, Tejun Heo  wrote:
> On Tue, Oct 27, 2015 at 01:11:46PM +0530, vinayak.k...@gmail.com wrote:
>> From: Vinayak Kale 
>>
>> Enable LBA in taskfile flags for ata_scsi_pass_thru()
>>
>> Signed-off-by: Vinayak Kale 
>
> Applied to libata/for-4.4.

Thanks Tejun!!

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

Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Roger Quadros]

On 26/10/15 22:49, Brian Norris wrote:
> + others
> 
> A few comments below.
> 
> On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
>> The GPMC WAIT pin status are now available over gpiolib.
>> Update the omap_dev_ready() function to use gpio instead of
>> directly accessing GPMC register space.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/mtd/nand/omap2.c | 29 
>> +---
>>  include/linux/platform_data/mtd-nand-omap2.h |  2 +-
>>  2 files changed, 19 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index 228f498..d0f2620 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -12,6 +12,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -184,6 +185,8 @@ struct omap_nand_info {
>>  /* fields specific for BCHx_HW ECC scheme */
>>  struct device   *elm_dev;
>>  struct device_node  *of_node;
>> +/* NAND ready gpio */
>> +struct gpio_desc*ready_gpiod;
>>  };
>>  
>>  /**
>> @@ -1047,22 +1050,17 @@ static int omap_wait(struct mtd_info *mtd, struct 
>> nand_chip *chip)
>>  }
>>  
>>  /**
>> - * omap_dev_ready - calls the platform specific dev_ready function
>> + * omap_dev_ready - checks the NAND Ready GPIO line
>>   * @mtd: MTD device structure
>> + *
>> + * Returns true if ready and false if busy.
>>   */
>>  static int omap_dev_ready(struct mtd_info *mtd)
>>  {
>> -unsigned int val = 0;
>>  struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
>>  mtd);
>>  
>> -val = readl(info->reg.gpmc_status);
>> -
>> -if ((val & 0x100) == 0x100) {
>> -return 1;
>> -} else {
>> -return 0;
>> -}
>> +return gpiod_get_value(info->ready_gpiod);
>>  }
>>  
>>  /**
>> @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device 
>> *pdev)
>>  info->reg = pdata->reg;
>>  info->of_node = pdata->of_node;
>>  info->ecc_opt = pdata->ecc_opt;
>> -info->dev_ready = pdata->dev_ready;
>> +if (pdata->dev_ready)
>> +dev_info(>dev, "pdata->dev_ready is 
>> deprecated\n");
>> +
>>  info->xfer_type = pdata->xfer_type;
>>  info->devsize = pdata->devsize;
>>  info->elm_of_node = pdata->elm_of_node;
>> @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device 
>> *pdev)
>>  nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
>>  nand_chip->cmd_ctrl  = omap_hwcontrol;
>>  
>> +info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
>> +GPIOD_IN);
> 
> Others have been looking at using GPIOs for the ready/busy pin too. At a
> minimum, we need an updated DT binding doc for this, since I see you're
> adding this via device tree in a later patch (I don't see any DT binding
> patch for this; but I could just be overlooking it). It'd also be great
> if this support was moved to nand_dt_init() so other platforms can
> benefit, but I won't require that.
> 
> Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio'
> (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't
> really care, but the name should be going into a doc, so we can choose
> the same one everywhere.
> 
> EDIT: looks like the discussion was partly here [1] and it seems we're
> landing on "rb-gpios" in the latest version [2]. Can we stick with that?

Why should it be "rb-gpios" and not "rb-gpio"?
I don't think there are multiple gpios for r/b# function.

cheers,
-roger

> 
> Regards,
> Brian
> 
> [0] "Previous" may be subject to debate, as both series have been going
> for several revisions.
> [1] http://patchwork.ozlabs.org/patch/515327/
> [2] http://patchwork.ozlabs.org/patch/526819/
> 
>> +if (IS_ERR(info->ready_gpiod)) {
>> +dev_err(dev, "failed to get ready gpio\n");
>> +return PTR_ERR(info->ready_gpiod);
>> +}
>> +
>>  /*
>>   * If RDY/BSY line is connected to OMAP then use the omap ready
>>   * function and the generic nand_wait function which reads the status
>> @@ -1822,7 +1829,7 @@ static int omap_nand_probe(struct platform_device 
>> *pdev)
>>   * chip delay which is slightly more than tR (AC Timing) of the NAND
>>   * device and read status register until you get a failure or success
>>   */
>> -if (info->dev_ready) {
>> +if (info->ready_gpiod) {
>>  nand_chip->dev_ready = omap_dev_ready;
>>  nand_chip->chip_delay = 0;
>>  } else {
>> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
>> b/include/linux/platform_data/mtd-nand-omap2.h
>> index ff27e5a..19e509d 100644
>> --- a/include/linux/platform_data/mtd-nand-omap2.h
>> +++ 

Re: [PATCH v4 14/15] net: wireless: ath: Remove unneeded variable ret returning 0

[Kalle Valo]

punit vara  writes:

> Will my other patches which are already correct be added to wireless
> tree ? or I have to resend everything ?

Yes, please resend the whole patchset. I don't apply patches
individually from a patchset, it's just too time consuming and error
prone.

Also, as you seem to be new here, I don't recommend sending big
patchsets in the beginning. Start slow, send just few a patch or two at
a time, and once you gain more experience send bigger patchsets.

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

Re: [linux-sunxi] Re: [PATCH 5/6] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Hans de Goede]

Hi,

On 26-10-15 22:06, Maxime Ripard wrote:

On Sat, Oct 24, 2015 at 10:47:49AM +0200, Jean-Francois Moine wrote:

On Sat, 24 Oct 2015 09:13:28 +0200
Maxime Ripard  wrote:


Or simply

bus_gates {
clocks = <>, <>;
clock-indices = <5>, <6>, <8>, ...
clock-output-names = "bus_ce", "bus_dma", "bus_mmc0"
};


I don't understand: the apb1, apb2, ahb1 and ahb2 clocks may be
programmed independently to different frequencies


I don't understand why you're talking about frequencies here.


and you have to know which of them is the parent of each leaf clock.


Indeed, but that's also doable here. Just not in the DT.


So, either you hard-code the parents as Jens did in a first proposal,
or you define the full list of parents in the DT as in the last
proposal, or you use a container per parent in the DT as I proposed.

There could be an other solution using the output clock name to define
the parent clock:

bus_gates {
clocks = <>, <>, <>, <>;
clock-indices = <5>, <6>, <8>, ...
clock-output-names = "ahb1_ce", "ahb1_dma", "ahb1_mmc0"
};

with the documentation:

"the clocks MUST be defined in order: ahb1, ahb2, apb1, apb2."

and the code

if (strncmp(clock_name, "ahb1", 4) == 0)
clk_parent = of_clk_get_parent_name(node, 0);
else if (..)

but it seems a bit hacky.


It's exactly what I suggested, without the string comparison, but
relying on the ID instead.


I'm not following you here, what do you mean with "the ID" ?

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Boris Brezillon]

Hi Roger,

On Tue, 27 Oct 2015 10:03:02 +0200
Roger Quadros  wrote:

> On 26/10/15 22:49, Brian Norris wrote:
> > 
> > Others have been looking at using GPIOs for the ready/busy pin too. At a
> > minimum, we need an updated DT binding doc for this, since I see you're
> > adding this via device tree in a later patch (I don't see any DT binding
> > patch for this; but I could just be overlooking it). It'd also be great
> > if this support was moved to nand_dt_init() so other platforms can
> > benefit, but I won't require that.
> > 
> > Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio'
> > (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't
> > really care, but the name should be going into a doc, so we can choose
> > the same one everywhere.
> > 
> > EDIT: looks like the discussion was partly here [1] and it seems we're
> > landing on "rb-gpios" in the latest version [2]. Can we stick with that?
> 
> Why should it be "rb-gpios" and not "rb-gpio"?
> I don't think there are multiple gpios for r/b# function.

Because it's supposed to be a generic binding, and some NAND chips
embed several dies, thus exposing several CS and RB pins, hence the
rb-gpios name.
Also, as described here [1], the convention is to name your property
-gpios even if you only need one gpio.

Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/gpio/gpio.txt#L16



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 5/5] iio: Documentation: Add IIO configfs documentation

[Crt Mori]

(as my last comment was sufficiently explained and kinda forgot to add it)
Acked-by: Crt Mori 

On 23 October 2015 at 17:33, Daniel Baluta  wrote:
> Signed-off-by: Daniel Baluta 
> ---
>  Documentation/ABI/testing/configfs-iio | 21 
>  Documentation/iio/iio_configfs.txt | 93 
> ++
>  2 files changed, 114 insertions(+)
>  create mode 100644 Documentation/ABI/testing/configfs-iio
>  create mode 100644 Documentation/iio/iio_configfs.txt
>
> diff --git a/Documentation/ABI/testing/configfs-iio 
> b/Documentation/ABI/testing/configfs-iio
> new file mode 100644
> index 000..2483756
> --- /dev/null
> +++ b/Documentation/ABI/testing/configfs-iio
> @@ -0,0 +1,21 @@
> +What:  /config/iio
> +Date:  October 2015
> +KernelVersion: 4.4
> +Contact:   linux-...@vger.kernel.org
> +Description:
> +   This represents Industrial IO configuration entry point
> +   directory. It contains sub-groups corresponding to IIO
> +   objects.
> +
> +What:  /config/iio/triggers
> +Date:  October 2015
> +KernelVersion: 4.4
> +Description:
> +   Industrial IO software triggers directory.
> +
> +What:  /config/iio/triggers/hrtimers
> +Date:  October 2015
> +KernelVersion: 4.4
> +Description:
> +   High resolution timers directory. Creating a directory here
> +   will result in creating a hrtimer trigger in the IIO 
> subsystem.
> diff --git a/Documentation/iio/iio_configfs.txt 
> b/Documentation/iio/iio_configfs.txt
> new file mode 100644
> index 000..f0add35
> --- /dev/null
> +++ b/Documentation/iio/iio_configfs.txt
> @@ -0,0 +1,93 @@
> +Industrial IIO configfs support
> +
> +1. Overview
> +
> +Configfs is a filesystem-based manager of kernel objects. IIO uses some
> +objects that could be easily configured using configfs (e.g.: devices,
> +triggers).
> +
> +See Documentation/filesystems/configfs/configfs.txt for more information
> +about how configfs works.
> +
> +2. Usage
> +
> +In order to use configfs support in IIO we need to select it at compile
> +time via CONFIG_IIO_CONFIGFS config option.
> +
> +Then, mount the configfs filesystem (usually under /config directory):
> +
> +$ mkdir /config
> +$ mount -t configfs none /config
> +
> +At this point, all default IIO groups will be created and can be accessed
> +under /config/iio. Next chapters will describe available IIO configuration
> +objects.
> +
> +3. Software triggers
> +
> +One of the IIO default configfs groups is the "triggers" group. It is
> +automagically accessible when the configfs is mounted and can be found
> +under /config/iio/triggers.
> +
> +IIO software triggers implementation offers support for creating multiple
> +trigger types. A new trigger type is usually implemented as a separate
> +kernel module following the interface in include/linux/iio/sw_trigger.h:
> +
> +/*
> + * drivers/iio/trigger/iio-trig-sample.c
> + * sample kernel module implementing a new trigger type
> + */
> +#include 
> +
> +
> +static struct iio_sw_trigger *iio_trig_sample_probe(const char *name)
> +{
> +   /*
> +* This allocates and registers an IIO trigger plus other
> +* trigger type specific initialization.
> +*/
> +}
> +
> +static int iio_trig_hrtimer_remove(struct iio_sw_trigger *swt)
> +{
> +   /*
> +* This undoes the actions in iio_trig_sample_probe
> +*/
> +}
> +
> +static const struct iio_sw_trigger_ops iio_trig_sample_ops = {
> +   .probe  = iio_trig_sample_probe,
> +   .remove = iio_trig_sample_remove,
> +};
> +
> +static struct iio_sw_trigger_type iio_trig_sample = {
> +   .name = "trig-sample",
> +   .owner = THIS_MODULE,
> +   .ops = _trig_sample_ops,
> +};
> +
> +module_iio_sw_trigger_driver(iio_trig_sample);
> +
> +Each trigger type has its own directory under /config/iio/triggers. Loading
> +iio-trig-sample module will create 'trig-sample' trigger type directory
> +/config/iio/triggers/trig-sample.
> +
> +We support the following interrupt sources (trigger types):
> +   * hrtimer, uses high resolution timers as interrupt source
> +
> +3.1 Hrtimer triggers creation and destruction
> +
> +Loading iio-trig-hrtimer module will register hrtimer trigger types allowing
> +users to create hrtimer triggers under /config/iio/triggers/hrtimer.
> +
> +e.g:
> +
> +$ mkdir /config/triggers/hrtimer/instance1
> +$ rmdir /config/triggers/hrtimer/instance1
> +
> +Each trigger can have one or more attributes specific to the trigger type.
> +
> +3.2 "hrtimer" trigger types attributes
> +
> +"hrtimer" trigger type doesn't have any configurable attribute from /config 
> dir.
> +It does introduce the sampling_frequency attribute to trigger directory.
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to 

Re: [PATCH 2/3] lib/string_helpers.c: don't lose precision in string_get_size()

[Vitaly Kuznetsov]

Andy Shevchenko  writes:

> On Mon, 2015-10-26 at 14:55 +0100, Vitaly Kuznetsov wrote:
>> string_get_size() loses precision when there is a remainder for
>> blk_size / divisor[units] and size is big enough. E.g
>> string_get_size(8192, 4096, STRING_UNITS_10, ...) returns "32.7 MB"
>> while it is supposed to return "33.5 MB". For some artificial inputs
>> the result can be ridiculously wrong, e.g.
>> string_get_size(3000, 1900, STRING_UNITS_10, ...) returns "3.00 MB"
>> when "5.70 MB" is expected.
>> 
>> The issues comes from the fact than we through away
>> blk_size / divisor[units] remainder when size is > exp. This can be
>> fixed
>> by saving it and doing some non-trivial calculations later to fix the
>> error
>> but that would make this function even more cumbersome. Slightly re-
>> factor
>> the function to not lose the precision for all inputs.
>> 
>> The overall complexity of this function comes from the fact that size
>> can
>> be huge and we don't want to do size * blk_size as it can overflow.
>> Do the
>> math in two steps:
>> 1) Reduce size to something < blk_size * divisor[units]
>> 2) Multiply the result (and the remainder) by blk_size and do final
>>    calculations.
>> 
>> Reported-by: Rasmus Villemoes 
>> Signed-off-by: Vitaly Kuznetsov 
>> ---
>>  lib/string_helpers.c | 46 +-
>> 
>>  1 file changed, 25 insertions(+), 21 deletions(-)
>> 
>> diff --git a/lib/string_helpers.c b/lib/string_helpers.c
>> index f6c27dc..0658994 100644
>> --- a/lib/string_helpers.c
>> +++ b/lib/string_helpers.c
>> @@ -43,41 +43,43 @@ void string_get_size(u64 size, u32 blk_size,
>> const enum string_size_units units,
>>  [STRING_UNITS_10] = 1000,
>>  [STRING_UNITS_2] = 1024,
>>  };
>> -int i, j;
>> -u32 remainder = 0, sf_cap, exp;
>> +int order = 0, j;
>> +u64 remainder = 0;
>> +u32 sf_cap;
>>  char tmp[8];
>>  const char *unit;
>>  
>>  tmp[0] = '\0';
>> -i = 0;
>
> Maybe leave i naming as is. Your order is not strictly speaking an
> order, rather 3x order. I will make patch neater.
>

While reading the original function I found meaningless 'i' and 'j' here
a bit consufing but yes, strictly speaking 'i' is a power of
divisor[units], not 'order' and I don't have a good name for it
(div_power?). I'll revert back to 'i' in v2.


>>  if (!size)
>>  goto out;
>>  
>> -while (blk_size >= divisor[units]) {
>> -remainder = do_div(blk_size, divisor[units]);
>> -i++;
>> -}
>> -
>> -exp = divisor[units] / blk_size;
>>  /*
>> - * size must be strictly greater than exp here to ensure
>> that remainder
>> - * is greater than divisor[units] coming out of the if
>> below.
>> + * size can be huge and doing size * blk_size right away can
>> overflow.
>> + * As a first step reduce huge size to something less than
>> + * blk_size * divisor[units].
>>   */
>> -if (size > exp) {
>> +while (size > (u64)blk_size * divisor[units]) {
>>  remainder = do_div(size, divisor[units]);
>> -remainder *= blk_size;
>> -i++;
>> -} else {
>> -remainder *= size;
>> +order++;
>>  }
>>  
>> +/* Now we're OK with doing size * blk_size, it won't
>> overflow. */
>>  size *= blk_size;
>> +remainder *= blk_size;
>> +/*
>> + * We were doing partial multiplication by blk_size.
>> + * remainder >= divisor[units] here means size should be
>> increased.
>> + */
>>  size += remainder / divisor[units];
>> -remainder %= divisor[units];
>> +remainder -= (remainder / divisor[units]) * divisor[units];
>
>>  
>> +/*
>> + * Normalize. size >= divisor[units] means we still have
>> enough
>> + * precision and dropping remainder is fine.
>> + */
>>  while (size >= divisor[units]) {
>>  remainder = do_div(size, divisor[units]);
>> -i++;
>> +order++;
>>  }
>>  
>>  sf_cap = size;
>> @@ -87,16 +89,18 @@ void string_get_size(u64 size, u32 blk_size,
>> const enum string_size_units units,
>>  if (j) {
>>  remainder *= 1000;
>>  remainder /= divisor[units];
>> -snprintf(tmp, sizeof(tmp), ".%03u", remainder);
>> +/* remainder is < divisor[units] here, (u32) is
>> legit */
>> +snprintf(tmp, sizeof(tmp), ".%03u", (u32)remainder);
>>  tmp[j+1] = '\0';
>>  }
>>  
>>   out:
>> -if (i >= ARRAY_SIZE(units_2))
>> +if (order >= ARRAY_SIZE(units_2))
>>  unit = "UNK";
>>  else
>> -unit = units_str[units][i];
>> +unit = units_str[units][order];
>>  
>> +/* size is < divisor[units] here, (u32) is legit */
>>  snprintf(buf, len, "%u%s %s", (u32)size,
>>   tmp, unit);
>>  }

-- 
  Vitaly
--
To unsubscribe from 

Re: [PATCH] scripts/package/Makefile: Restore the RPMOPTS variable

[Alaa Hleihel]

hi

On 10/26/2015 23:21, Michal Marek wrote:
> Dne 17.10.2015 v 02:09 Jim Davis napsal(a):
>> Restore the RPMOPTS variable to the rpm-pkg and binrpm-pkg targets
>> that commit 21a59991ce0c ("scripts/package/Makefile: rpmbuild is
>> needed for rpm targets") removed.
>>
>> Reported-by: Alaa Hleihel 
>> Signed-off-by: Jim Davis 
> If this is a regression fix, please add a Fixes: hash ("commit message")
> line to the signoff area.
>
> Out of curiosity, what options do you need to pass to rpmbuild?
>

A common usage will be to change the default _topdir (RPMOPTS="--define 
\"_topdir /tmp/build\"").

Regards,
Alaa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] input: keychord: Add keychord driver

[Bálint Czobor]

From: Mike Lockwood 

This driver allows userspace to receive notification when client
specified key combinations are pressed.
The client opens /dev/keychord and writes a list of keychords
for the driver to monitor.
The client then reads or polls /dev/keychord for notifications.
A client specified ID for the keychord is returned from read()
when a keychord press is detected.

Signed-off-by: Mike Lockwood 

keychord: fix to build without CONFIG_PREEMPT

Change-Id: I911f13aeda4224b6fa57863bc7e8972fec8837fb
Signed-off-by: Bálint Czobor 
---
 drivers/input/misc/Kconfig|   11 ++
 drivers/input/misc/Makefile   |1 +
 drivers/input/misc/keychord.c |  387 +
 include/linux/keychord.h  |   52 ++
 4 files changed, 451 insertions(+)
 create mode 100644 drivers/input/misc/keychord.c
 create mode 100644 include/linux/keychord.h

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 906dd1b..caf4b04 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -341,6 +341,17 @@ config INPUT_ATI_REMOTE2
  To compile this driver as a module, choose M here: the module will be
  called ati_remote2.
 
+config INPUT_KEYCHORD
+   tristate "Key chord input driver support"
+   help
+ Say Y here if you want to enable the key chord driver
+ accessible at /dev/keychord.  This driver can be used
+ for receiving notifications when client specified key
+ combinations are pressed.
+
+ To compile this driver as a module, choose M here: the
+ module will be called keychord.
+
 config INPUT_KEYSPAN_REMOTE
tristate "Keyspan DMR USB remote control"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 0357a08..c521e82 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_INPUT_GPIO_TILT_POLLED)  += gpio_tilt_polled.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
 obj-$(CONFIG_INPUT_IMS_PCU)+= ims-pcu.o
 obj-$(CONFIG_INPUT_IXP4XX_BEEPER)  += ixp4xx-beeper.o
+obj-$(CONFIG_INPUT_KEYCHORD)   += keychord.o
 obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o
 obj-$(CONFIG_INPUT_KXTJ9)  += kxtj9.o
 obj-$(CONFIG_INPUT_M68K_BEEP)  += m68kspkr.o
diff --git a/drivers/input/misc/keychord.c b/drivers/input/misc/keychord.c
new file mode 100644
index 000..3ffab6d
--- /dev/null
+++ b/drivers/input/misc/keychord.c
@@ -0,0 +1,387 @@
+/*
+ *  drivers/input/misc/keychord.c
+ *
+ * Copyright (C) 2008 Google, Inc.
+ * Author: Mike Lockwood 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define KEYCHORD_NAME  "keychord"
+#define BUFFER_SIZE16
+
+MODULE_AUTHOR("Mike Lockwood ");
+MODULE_DESCRIPTION("Key chord input driver");
+MODULE_SUPPORTED_DEVICE("keychord");
+MODULE_LICENSE("GPL");
+
+#define NEXT_KEYCHORD(kc) ((struct input_keychord *) \
+   ((char *)kc + sizeof(struct input_keychord) + \
+   kc->count * sizeof(kc->keycodes[0])))
+
+struct keychord_device {
+   struct input_handlerinput_handler;
+   int registered;
+
+   /* list of keychords to monitor */
+   struct input_keychord   *keychords;
+   int keychord_count;
+
+   /* bitmask of keys contained in our keychords */
+   unsigned long keybit[BITS_TO_LONGS(KEY_CNT)];
+   /* current state of the keys */
+   unsigned long keystate[BITS_TO_LONGS(KEY_CNT)];
+   /* number of keys that are currently pressed */
+   int key_down;
+
+   /* second input_device_id is needed for null termination */
+   struct input_device_id  device_ids[2];
+
+   spinlock_t  lock;
+   wait_queue_head_t   waitq;
+   unsigned char   head;
+   unsigned char   tail;
+   __u16   buff[BUFFER_SIZE];
+};
+
+static int check_keychord(struct keychord_device *kdev,
+   struct input_keychord *keychord)
+{
+   int i;
+
+   if (keychord->count != kdev->key_down)
+   return 0;
+
+   for (i = 0; i < keychord->count; i++) {
+   if (!test_bit(keychord->keycodes[i], kdev->keystate))
+   return 0;
+

[PATCH 2/3] input: misc: keychord: log when keychord triggered

[Bálint Czobor]

From: JP Abgrall 

log keychord id at info level just before waking up processes.

Signed-off-by: JP Abgrall 
Signed-off-by: Bálint Czobor 
---
 drivers/input/misc/keychord.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/input/misc/keychord.c b/drivers/input/misc/keychord.c
index 3ffab6d..a5ea27a 100644
--- a/drivers/input/misc/keychord.c
+++ b/drivers/input/misc/keychord.c
@@ -126,8 +126,12 @@ static void keychord_event(struct input_handle *handle, 
unsigned int type,
 done:
spin_unlock_irqrestore(>lock, flags);
 
-   if (got_chord)
+   if (got_chord) {
+   pr_info("keychord: got keychord id %d. Any tasks: %d\n",
+   keychord->id,
+   !list_empty_careful(>waitq.task_list));
wake_up_interruptible(>waitq);
+   }
 }
 
 static int keychord_connect(struct input_handler *handler,
-- 
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 3/3] lib/test-string_helpers.c: add string_get_size() tests

[Vitaly Kuznetsov]

Rasmus Villemoes  writes:

> On Mon, Oct 26 2015, Vitaly Kuznetsov  wrote:
>
>> Add a couple of simple tests for string_get_size().
>>
>> Signed-off-by: Vitaly Kuznetsov 
>> ---
>>  lib/test-string_helpers.c | 44 
>>  1 file changed, 44 insertions(+)
>>
>> diff --git a/lib/test-string_helpers.c b/lib/test-string_helpers.c
>> index 8e376ef..a158cb3 100644
>> --- a/lib/test-string_helpers.c
>> +++ b/lib/test-string_helpers.c
>> @@ -326,6 +326,47 @@ out:
>>  kfree(out_test);
>>  }
>>  
>> +#define string_get_size_maxbuf 16
>> +#define test_string_get_size_one(size, blk_size, units, exp_result) 
>>\
>> +do {   \
>> +BUILD_BUG_ON(sizeof(exp_result) >= string_get_size_maxbuf);\
>> +__test_string_get_size((size), (blk_size), (units),\
>> +   (exp_result));  \
>> +} while (0)
>> +
>> +
>> +static __init void __test_string_get_size(const u64 size, const u32 
>> blk_size,
>> +  const enum string_size_units units,
>> +  const char *exp_result)
>> +{
>> +char buf[string_get_size_maxbuf];
>> +
>> +string_get_size(size, blk_size, units, buf, sizeof(buf));
>> +if (!memcmp(buf, exp_result, strlen(exp_result) + 1))
>> +return;
>> +
>> +buf[sizeof(buf) - 1] = '\0';
>> +pr_warn("Test 'test_string_get_size_one' failed!\n");
>> +pr_warn("string_get_size(size = %llu, blk_size = %u, units = %d\n",
>> +size, blk_size, units);
>> +pr_warn("expected: '%s', got '%s'\n", exp_result, buf);
>> +}
>> +
>> +static __init void test_string_get_size(void)
>> +{
>> +test_string_get_size_one(16384, 512, STRING_UNITS_2, "8.00 MiB");
>> +test_string_get_size_one(500118192, 512, STRING_UNITS_2, "238 GiB");
>> +test_string_get_size_one(8192, 4096, STRING_UNITS_10, "33.5 MB");
>> +test_string_get_size_one(1100, 1, STRING_UNITS_10, "1.10 kB");
>> +test_string_get_size_one(3000, 1900, STRING_UNITS_10, "5.70 MB");
>> +test_string_get_size_one(151234561234657, 3456789, STRING_UNITS_10,
>> + "522 EB");
>
> Since we're changing this anyway, can't we test every pair of
> (size,blk_size) with both units? That'll be twice the number of tests
> for less horizontal real estate. E.g.
>
>   test_string_get_size_one(8192, 4096, "32.0 MiB", "33.5 MB");
>

Nice idea, will do.

> Do we really care how and if string_get_size works for a non-power-of-2
> blk_size? 

Probably not but there is nothing in current algorithm which prevents it
from working correctly with a non-power-of-2 blk_sizes. The issue you
found is even more visible on (3000, 1900) test.

> I certainly assume that we're passed a non-zero value.

Oh crap, we don't have a check for blk_size = 0 and this leads to an
infinite loop now... will do something in v2.

>
> Rasmus

-- 
  Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: sd: When resuming, try a little harder to init the card

[Bálint Czobor]

From: San Mehat 

Signed-off-by: San Mehat 
Signed-off-by: Bálint Czobor 
---
 drivers/mmc/core/sd.c |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index dcbbd33..359facd 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -1115,6 +1115,9 @@ static int mmc_sd_suspend(struct mmc_host *host)
 static int _mmc_sd_resume(struct mmc_host *host)
 {
int err = 0;
+#ifdef CONFIG_MMC_PARANOID_SD_INIT
+   int retries;
+#endif
 
BUG_ON(!host);
BUG_ON(!host->card);
@@ -1125,7 +1128,23 @@ static int _mmc_sd_resume(struct mmc_host *host)
goto out;
 
mmc_power_up(host, host->card->ocr);
+#ifdef CONFIG_MMC_PARANOID_SD_INIT
+   retries = 5;
+   while (retries) {
+   err = mmc_sd_init_card(host, host->card->ocr, host->card);
+
+   if (err) {
+   printk(KERN_ERR "%s: Re-init card rc = %d (retries = 
%d)\n",
+  mmc_hostname(host), err, retries);
+   mdelay(5);
+   retries--;
+   continue;
+   }
+   break;
+   }
+#else
err = mmc_sd_init_card(host, host->card->ocr, host->card);
+#endif
mmc_card_clr_suspended(host->card);
 
 out:
-- 
1.7.9.5

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

[PATCH 3/3] mmc: sd: Add retries in re-detection

[Bálint Czobor]

From: San Mehat 

Signed-off-by: San Mehat 

mmc: sd: Remove debugging printk

Signed-off-by: Dima Zavin 
Signed-off-by: Bálint Czobor 
---
 drivers/mmc/core/sd.c |   42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 359facd..5b77494 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -1043,7 +1043,10 @@ static int mmc_sd_alive(struct mmc_host *host)
  */
 static void mmc_sd_detect(struct mmc_host *host)
 {
-   int err;
+   int err = 0;
+#ifdef CONFIG_MMC_PARANOID_SD_INIT
+   int retries = 5;
+#endif
 
BUG_ON(!host);
BUG_ON(!host->card);
@@ -1053,7 +1056,23 @@ static void mmc_sd_detect(struct mmc_host *host)
/*
 * Just check if our card has been removed.
 */
+#ifdef CONFIG_MMC_PARANOID_SD_INIT
+   while(retries) {
+   err = mmc_send_status(host->card, NULL);
+   if (err) {
+   retries--;
+   udelay(5);
+   continue;
+   }
+   break;
+   }
+   if (!retries) {
+   printk(KERN_ERR "%s(%s): Unable to re-detect card (%d)\n",
+  __func__, mmc_hostname(host), err);
+   }
+#else
err = _mmc_detect_card_removed(host);
+#endif
 
mmc_put_card(host->card);
 
@@ -1230,6 +1249,9 @@ int mmc_attach_sd(struct mmc_host *host)
 {
int err;
u32 ocr, rocr;
+#ifdef CONFIG_MMC_PARANOID_SD_INIT
+   int retries;
+#endif
 
BUG_ON(!host);
WARN_ON(!host->claimed);
@@ -1266,9 +1288,27 @@ int mmc_attach_sd(struct mmc_host *host)
/*
 * Detect and init the card.
 */
+#ifdef CONFIG_MMC_PARANOID_SD_INIT
+   retries = 5;
+   while (retries) {
+   err = mmc_sd_init_card(host, rocr, NULL);
+   if (err) {
+   retries--;
+   continue;
+   }
+   break;
+   }
+
+   if (!retries) {
+   printk(KERN_ERR "%s: mmc_sd_init_card() failure (err = %d)\n",
+  mmc_hostname(host), err);
+   goto err;
+   }
+#else
err = mmc_sd_init_card(host, rocr, NULL);
if (err)
goto err;
+#endif
 
mmc_release_host(host);
err = mmc_add_card(host->card);
-- 
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 1/2] i2c: mediatek: add i2c first write then read optimization

[Liguo Zhang]

For platform with auto restart support, between every transfer,
i2c controller will trigger an interrupt and SW need to handle
it to start new transfer. When doing write-then-read transfer,
instead of restart mechanism, using WRRD mode to have controller
send both transfer in one request to reduce latency.

Signed-off-by: Liguo Zhang 
---
 drivers/i2c/busses/i2c-mt65xx.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 9b86716..dc4aac6 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -132,6 +132,7 @@ struct mtk_i2c_compatible {
unsigned char pmic_i2c: 1;
unsigned char dcm: 1;
unsigned char auto_restart: 1;
+   unsigned char aux_len_reg: 1;
 };
 
 struct mtk_i2c {
@@ -153,6 +154,7 @@ struct mtk_i2c {
enum mtk_trans_op op;
u16 timing_reg;
u16 high_speed_reg;
+   unsigned char auto_restart;
const struct mtk_i2c_compatible *dev_comp;
 };
 
@@ -178,6 +180,7 @@ static const struct mtk_i2c_compatible mt6577_compat = {
.pmic_i2c = 0,
.dcm = 1,
.auto_restart = 0,
+   .aux_len_reg = 0,
 };
 
 static const struct mtk_i2c_compatible mt6589_compat = {
@@ -185,6 +188,7 @@ static const struct mtk_i2c_compatible mt6589_compat = {
.pmic_i2c = 1,
.dcm = 0,
.auto_restart = 0,
+   .aux_len_reg = 0,
 };
 
 static const struct mtk_i2c_compatible mt8173_compat = {
@@ -192,6 +196,7 @@ static const struct mtk_i2c_compatible mt8173_compat = {
.pmic_i2c = 0,
.dcm = 1,
.auto_restart = 1,
+   .aux_len_reg = 1,
 };
 
 static const struct of_device_id mtk_i2c_of_match[] = {
@@ -373,7 +378,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs,
 
i2c->irq_stat = 0;
 
-   if (i2c->dev_comp->auto_restart)
+   if (i2c->auto_restart)
restart_flag = I2C_RS_TRANSFER;
 
reinit_completion(>msg_complete);
@@ -411,8 +416,14 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs,
 
/* Set transfer and transaction len */
if (i2c->op == I2C_MASTER_WRRD) {
-   writew(msgs->len | ((msgs + 1)->len) << 8,
-  i2c->base + OFFSET_TRANSFER_LEN);
+   if (i2c->dev_comp->aux_len_reg) {
+   writew(msgs->len, i2c->base + OFFSET_TRANSFER_LEN);
+   writew((msgs + 1)->len, i2c->base +
+  OFFSET_TRANSFER_LEN_AUX);
+   } else {
+   writew(msgs->len | ((msgs + 1)->len) << 8,
+  i2c->base + OFFSET_TRANSFER_LEN);
+   }
writew(I2C_WRRD_TRANAC_VALUE, i2c->base + OFFSET_TRANSAC_LEN);
} else {
writew(msgs->len, i2c->base + OFFSET_TRANSFER_LEN);
@@ -461,7 +472,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs,
 
writel(I2C_DMA_START_EN, i2c->pdmabase + OFFSET_EN);
 
-   if (!i2c->dev_comp->auto_restart) {
+   if (!i2c->auto_restart) {
start_reg = I2C_TRANSAC_START;
} else {
start_reg = I2C_TRANSAC_START | I2C_RS_MUL_TRIG;
@@ -518,6 +529,16 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
if (ret)
return ret;
 
+   i2c->auto_restart = i2c->dev_comp->auto_restart;
+
+   /* checking if we can skip restart and optimize using WRRD mode */
+   if (i2c->auto_restart && num == 2) {
+   if (!(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
+   msgs[0].addr == msgs[1].addr) {
+   i2c->auto_restart = 0;
+   }
+   }
+
while (left_num--) {
if (!msgs->buf) {
dev_dbg(i2c->dev, "data buffer is NULL.\n");
@@ -530,7 +551,7 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
else
i2c->op = I2C_MASTER_WR;
 
-   if (!i2c->dev_comp->auto_restart) {
+   if (!i2c->auto_restart) {
if (num > 1) {
/* combined two messages into one transaction */
i2c->op = I2C_MASTER_WRRD;
@@ -559,7 +580,7 @@ static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id)
u16 restart_flag = 0;
u16 intr_stat;
 
-   if (i2c->dev_comp->auto_restart)
+   if (i2c->auto_restart)
restart_flag = I2C_RS_TRANSFER;
 
intr_stat = readw(i2c->base + OFFSET_INTR_STAT);
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i2c: mediatek: fix i2c multi transfer issue in high speed mode

[Liguo Zhang]

For platform with auto restart support, when doing i2c multi transfer
in high speed, for example, doing write-then-read transfer, the master
code will occupy the first transfer, and the second transfer will be
the read transfer, the write transfer will be discarded. So we should
first send the master code, and then start i2c multi transfer.

Signed-off-by: Liguo Zhang 
---
 drivers/i2c/busses/i2c-mt65xx.c | 44 +
 1 file changed, 44 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index dc4aac6..0b9e9f5 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -53,6 +53,8 @@
 #define I2C_FS_TIME_INIT_VALUE 0x1303
 #define I2C_WRRD_TRANAC_VALUE  0x0002
 #define I2C_RD_TRANAC_VALUE0x0001
+#define I2C_TRAN_DEFAULT_VALUE 0x0001
+#define I2C_TRANAC_DEFAULT_VALUE   0x0001
 
 #define I2C_DMA_CON_TX 0x
 #define I2C_DMA_CON_RX 0x0001
@@ -365,6 +367,42 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned 
int parent_clk,
return 0;
 }
 
+static int mtk_i2c_send_master_code(struct mtk_i2c *i2c)
+{
+   int ret = 0;
+
+   reinit_completion(>msg_complete);
+
+   writew(I2C_CONTROL_RS | I2C_CONTROL_ACKERR_DET_EN |
+  I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN,
+  i2c->base + OFFSET_CONTROL);
+
+   /* Clear interrupt status */
+   writew(I2C_RS_TRANSFER | I2C_TRANSAC_COMP | I2C_HS_NACKERR | I2C_ACKERR,
+  i2c->base + OFFSET_INTR_STAT);
+
+   /* Enable interrupt */
+   writew(I2C_RS_TRANSFER | I2C_TRANSAC_COMP, i2c->base + 
OFFSET_INTR_MASK);
+
+   writew(I2C_TRAN_DEFAULT_VALUE, i2c->base + OFFSET_TRANSFER_LEN);
+   writew(I2C_TRANAC_DEFAULT_VALUE, i2c->base + OFFSET_TRANSAC_LEN);
+
+   writew(I2C_TRANSAC_START | I2C_RS_MUL_CNFG, i2c->base + OFFSET_START);
+
+   ret = wait_for_completion_timeout(>msg_complete,
+ i2c->adap.timeout);
+
+   completion_done(>msg_complete);
+
+   if (ret == 0) {
+   dev_dbg(i2c->dev, "send master code timeout.\n");
+   mtk_i2c_init_hw(i2c);
+   return -ETIMEDOUT;
+   }
+
+   return 0;
+}
+
 static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
   int num, int left_num)
 {
@@ -539,6 +577,12 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
}
}
 
+   if (i2c->auto_restart && i2c->speed_hz > 40) {
+   ret = mtk_i2c_send_master_code(i2c);
+   if (ret)
+   return ret;
+   }
+
while (left_num--) {
if (!msgs->buf) {
dev_dbg(i2c->dev, "data buffer is NULL.\n");
-- 
1.8.1.1.dirty

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

[PATCH v3 09/10] mmc: mediatek: add HS400 support

[Chaotian Jing]

add HS400 mode and tune support

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 249 +-
 1 file changed, 244 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 5627644..39568cc 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -72,6 +73,8 @@
 #define MSDC_PATCH_BIT   0xb0
 #define MSDC_PATCH_BIT1  0xb4
 #define MSDC_PAD_TUNE0xec
+#define PAD_DS_TUNE  0x188
+#define EMMC50_CFG0  0x208
 
 /*--*/
 /* Register Mask*/
@@ -88,6 +91,7 @@
 #define MSDC_CFG_CKSTB  (0x1 << 7) /* R  */
 #define MSDC_CFG_CKDIV  (0xff << 8)/* RW */
 #define MSDC_CFG_CKMOD  (0x3 << 16)/* RW */
+#define MSDC_CFG_HS400_CK_MODE  (0x1 << 18)/* RW */
 
 /* MSDC_IOCON mask */
 #define MSDC_IOCON_SDR104CKS(0x1 << 0) /* RW */
@@ -205,6 +209,17 @@
 #define MSDC_PATCH_BIT_SPCPUSH(0x1 << 29)  /* RW */
 #define MSDC_PATCH_BIT_DECRCTMO   (0x1 << 30)  /* RW */
 
+#define MSDC_PAD_TUNE_DATRRDLY   (0x1f <<  8)  /* RW */
+#define MSDC_PAD_TUNE_CMDRDLY(0x1f << 16)  /* RW */
+
+#define PAD_DS_TUNE_DLY1 (0x1f << 2)   /* RW */
+#define PAD_DS_TUNE_DLY2 (0x1f << 7)   /* RW */
+#define PAD_DS_TUNE_DLY3 (0x1f << 12)  /* RW */
+
+#define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0)   /* RW */
+#define EMMC50_CFG_CRCSTS_EDGE(0x1 << 3)   /* RW */
+#define EMMC50_CFG_CFCSTS_SEL (0x1 << 4)   /* RW */
+
 #define REQ_CMD_EIO  (0x1 << 0)
 #define REQ_CMD_TMO  (0x1 << 1)
 #define REQ_DAT_ERR  (0x1 << 2)
@@ -220,6 +235,7 @@
 #define CMD_TIMEOUT (HZ/10 * 5)/* 100ms x5 */
 #define DAT_TIMEOUT (HZ* 5)/* 1000ms x5 */
 
+#define PAD_DELAY_MAX  32 /* PAD delay cells */
 /*--*/
 /* Descriptor Structure */
 /*--*/
@@ -266,6 +282,14 @@ struct msdc_save_para {
u32 pad_tune;
u32 patch_bit0;
u32 patch_bit1;
+   u32 pad_ds_tune;
+   u32 emmc50_cfg0;
+};
+
+struct msdc_delay_phase {
+   u8 maxlen;
+   u8 start;
+   u8 final_phase;
 };
 
 struct msdc_host {
@@ -300,6 +324,7 @@ struct msdc_host {
u32 sclk;   /* SD/MS bus clock frequency */
unsigned char timing;
bool vqmmc_enabled;
+   u32 hs400_ds_delay;
struct msdc_save_para save_para; /* used when gate HCLK */
 };
 
@@ -505,9 +530,15 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned 
char timing, u32 hz)
 
flags = readl(host->base + MSDC_INTEN);
sdr_clr_bits(host->base + MSDC_INTEN, flags);
+   sdr_clr_bits(host->base + MSDC_CFG, MSDC_CFG_HS400_CK_MODE);
if (timing == MMC_TIMING_UHS_DDR50 ||
-   timing == MMC_TIMING_MMC_DDR52) {
-   mode = 0x2; /* ddr mode and use divisor */
+   timing == MMC_TIMING_MMC_DDR52 ||
+   timing == MMC_TIMING_MMC_HS400) {
+   if (timing == MMC_TIMING_MMC_HS400)
+   mode = 0x3;
+   else
+   mode = 0x2; /* ddr mode and use divisor */
+
if (hz >= (host->src_clk_freq >> 2)) {
div = 0; /* mean div = 1/4 */
sclk = host->src_clk_freq >> 2; /* sclk = clk / 4 */
@@ -516,6 +547,14 @@ static void msdc_set_mclk(struct msdc_host *host, unsigned 
char timing, u32 hz)
sclk = (host->src_clk_freq >> 2) / div;
div = (div >> 1);
}
+
+   if (timing == MMC_TIMING_MMC_HS400 &&
+   hz >= (host->src_clk_freq >> 1)) {
+   sdr_set_bits(host->base + MSDC_CFG,
+MSDC_CFG_HS400_CK_MODE);
+   sclk = host->src_clk_freq >> 1;
+   div = 0; /* div is ignore when bit18 is set */
+   }
} else if (hz >= host->src_clk_freq) {
mode = 0x1; /* no divisor */
div = 0;
@@ -894,7 +933,7 @@ static void msdc_data_xfer_next(struct msdc_host *host,
struct mmc_request *mrq, struct mmc_data *data)
 {
if (mmc_op_multi(mrq->cmd->opcode) && mrq->stop && !mrq->stop->error &&
-   (!data->bytes_xfered || !mrq->sbc))
+   !mrq->sbc)
msdc_start_command(host, mrq, mrq->stop);
else
msdc_request_done(host, mrq);
@@ -940,6 +979,8 @@ static bool msdc_data_xfer_done(struct msdc_host *host, u32 
events,
 
if (events & MSDC_INT_DATTMO)
  

[PATCH v3 07/10] arm64: dts: mediatek: add eMMC hw reset support

[Chaotian Jing]

Add eMMC hardware reset support

Signed-off-by: Chaotian Jing 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 4be66ca..6d79ffc 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -72,6 +72,7 @@
bus-width = <8>;
max-frequency = <5000>;
cap-mmc-highspeed;
+   cap-mmc-hw-reset;
vmmc-supply = <_vemc_3v3_reg>;
vqmmc-supply = <_vio18_reg>;
non-removable;
-- 
1.8.1.1.dirty

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

[PATCH v3 06/10] mmc: mediatek: add implement of ops->hw_reset()

[Chaotian Jing]

add implement of ops->hw_reset() for eMMC

Signed-off-by: Chaotian Jing 

---
 drivers/mmc/host/mtk-sd.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 3858163..5627644 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -64,6 +64,7 @@
 #define SDC_RESP20x48
 #define SDC_RESP30x4c
 #define SDC_BLK_NUM  0x50
+#define EMMC_IOCON   0x7c
 #define SDC_ACMD_RESP0x80
 #define MSDC_DMA_SA  0x90
 #define MSDC_DMA_CTRL0x98
@@ -1209,6 +1210,15 @@ end:
pm_runtime_put_autosuspend(host->dev);
 }
 
+static void msdc_hw_reset(struct mmc_host *mmc)
+{
+   struct msdc_host *host = mmc_priv(mmc);
+
+   sdr_set_bits(host->base + EMMC_IOCON, 1);
+   udelay(10); /* 10us is enough */
+   sdr_clr_bits(host->base + EMMC_IOCON, 1);
+}
+
 static struct mmc_host_ops mt_msdc_ops = {
.post_req = msdc_post_req,
.pre_req = msdc_pre_req,
@@ -1216,6 +1226,7 @@ static struct mmc_host_ops mt_msdc_ops = {
.set_ios = msdc_ops_set_ios,
.start_signal_voltage_switch = msdc_ops_switch_volt,
.card_busy = msdc_card_busy,
+   .hw_reset = msdc_hw_reset,
 };
 
 static int msdc_drv_probe(struct platform_device *pdev)
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

[xiakaixu]

于 2015/10/23 23:12, Peter Zijlstra 写道:
> On Fri, Oct 23, 2015 at 02:52:11PM +0200, Peter Zijlstra wrote:
>> On Thu, Oct 22, 2015 at 06:28:22PM +0800, Wangnan (F) wrote:
>>> information to analysis when glitch happen. Another way we are trying to
>>> implement
>>> now is to dynamically turn events on and off, or at least enable/disable
>>> sampling dynamically because the overhead of copying those samples
>>> is a big part of perf's total overhead. After that we can trace as many
>>> event as possible, but only fetch data from them when we detect a glitch.
>>
>> So why don't you 'fix' the flight recorder mode and just leave the data
>> in memory and not bother copying it out until a glitch happens?
>>
>> Something like this:
>>
>> lkml.kernel.org/r/20130708121557.ga17...@twins.programming.kicks-ass.net
>>
>> it appears we never quite finished that.
> 
> Updated to current sources, compile tested only.
> 
> It obviously needs testing and performance numbers..  and some
> userspace.
> 
> ---
> Subject: perf: Update event buffer tail when overwriting old events
> From: Peter Zijlstra 
> 
>> From: "Yan, Zheng" 
>>
>> If perf event buffer is in overwrite mode, the kernel only updates
>> the data head when it overwrites old samples. The program that owns
>> the buffer need periodically check the buffer and update a variable
>> that tracks the date tail. If the program fails to do this in time,
>> the data tail can be overwritted by new samples. The program has to
>> rewind the buffer because it does not know where is the first vaild
>> sample.
>>
>> This patch makes the kernel update the date tail when it overwrites
>> old events. So the program that owns the event buffer can always
>> read the latest samples. This is convenient for programs that use
>> perf to do branch tracing. One use case is GDB branch tracing:
>> (http://sourceware.org/ml/gdb-patches/2012-06/msg00172.html)
>> It uses perf interface to read BTS, but only cares the branches
>> before the ptrace event.
> 
> Original-patch-by: "Yan, Zheng" 
> Signed-off-by: Peter Zijlstra (Intel) 
> ---
>  arch/x86/kernel/cpu/perf_event_intel_ds.c |2 
>  include/linux/perf_event.h|6 --
>  kernel/events/core.c  |   56 +
>  kernel/events/internal.h  |2 
>  kernel/events/ring_buffer.c   |   77 
> +-
>  5 files changed, 107 insertions(+), 36 deletions(-)
> 
> --- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
> @@ -1140,7 +1140,7 @@ static void __intel_pmu_pebs_event(struc
>  
>   while (count > 1) {
>   setup_pebs_sample_data(event, iregs, at, , );
> - perf_event_output(event, , );
> + event->overflow_handler(event, , );
>   at += x86_pmu.pebs_record_size;
>   at = get_next_pebs_record_by_bit(at, top, bit);
>   count--;
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -828,10 +828,6 @@ extern int perf_event_overflow(struct pe
>struct perf_sample_data *data,
>struct pt_regs *regs);
>  
> -extern void perf_event_output(struct perf_event *event,
> - struct perf_sample_data *data,
> - struct pt_regs *regs);
> -
>  extern void
>  perf_event_header__init_id(struct perf_event_header *header,
>  struct perf_sample_data *data,
> @@ -1032,6 +1028,8 @@ static inline bool has_aux(struct perf_e
>  
>  extern int perf_output_begin(struct perf_output_handle *handle,
>struct perf_event *event, unsigned int size);
> +extern int perf_output_begin_overwrite(struct perf_output_handle *handle,
> +  struct perf_event *event, unsigned int size);
>  extern void perf_output_end(struct perf_output_handle *handle);
>  extern unsigned int perf_output_copy(struct perf_output_handle *handle,
>const void *buf, unsigned int len);
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4515,6 +4515,8 @@ static int perf_mmap_fault(struct vm_are
>   return ret;
>  }
>  
> +static void perf_event_set_overflow(struct perf_event *event, struct 
> ring_buffer *rb);
> +
>  static void ring_buffer_attach(struct perf_event *event,
>  struct ring_buffer *rb)
>  {
> @@ -4546,6 +4548,8 @@ static void ring_buffer_attach(struct pe
>   spin_lock_irqsave(>event_lock, flags);
>   list_add_rcu(>rb_entry, >event_list);
>   spin_unlock_irqrestore(>event_lock, flags);
> +
> + perf_event_set_overflow(event, rb);
>   }
>  
>   rcu_assign_pointer(event->rb, rb);
> @@ -5579,9 +5583,12 @@ void perf_prepare_sample(struct perf_eve
>   }
>  }
>  
> 

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

[Yunhong Jiang]

On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote:
> On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote:
> > An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ,
> > even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when
> > assigning a device to a guest with low latency requirement since it
> > reduce the context switch to/from the IRQ thread.
> 
> Is there any way we can do this automatically?  Perhaps detecting that
> we're on a RT kernel or maybe that the user is running with RT priority?
> I find that module options are mostly misunderstood and misused.

Alex, thanks for review.

It's not easy to detect if the user is running with RT priority, since 
sometimes the user start the thread and then set the scheduler priority 
late.

Also should we do this only for in kernel irqchip scenario and not for user 
space handler, since in kernel irqchip has lower overhead?

> 
> > An experiment was conducted on a HSW platform for 1 minutes, with the
> > guest vCPU bound to isolated pCPU. The assigned device triggered the
> > interrupt every 1ms. The average EXTERNAL_INTERRUPT exit handling time
> > is dropped from 5.3us to 2.2us.
> > 
> > Another choice is to change VFIO_DEVICE_SET_IRQS ioctl, to apply this
> > option only to specific devices when in kernel irq_chip is enabled. It
> > provides more flexibility but is more complex, not sure if we need go
> > through that way.
> 
> Allowing the user to decide whether or not to use a threaded IRQ seems
> like a privilege violation; a chance for the user to game the system and
> give themselves better latency, maybe at the cost of others.  I think

Yes, you are right. One benefit of the ioctl change is to have a 
per-device-option thus is more flexible.

> we're better off trying to infer the privilege from the task priority or

I'd think system admin may make decision after some tunning, like you said 
it "maybe at the cost of others" and not sure if we should make decision 
based on task priority or kernel config.

Thanks
--jyh 

> kernel config or, if we run out of options, make a module option as you
> have here requiring the system admin to provide the privilege.  Thanks,
> 
> Alex
> 
> 
> > Signed-off-by: Yunhong Jiang 
> > ---
> >  drivers/vfio/pci/vfio_pci_intrs.c | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/vfio/pci/vfio_pci_intrs.c 
> > b/drivers/vfio/pci/vfio_pci_intrs.c
> > index 1f577b4..ca1f95a 100644
> > --- a/drivers/vfio/pci/vfio_pci_intrs.c
> > +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> > @@ -22,9 +22,13 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "vfio_pci_private.h"
> >  
> > +static bool nonthread_msi = 1;
> > +module_param(nonthread_msi, bool, 0444);
> > +
> >  /*
> >   * INTx
> >   */
> > @@ -313,6 +317,7 @@ static int vfio_msi_set_vector_signal(struct 
> > vfio_pci_device *vdev,
> > char *name = msix ? "vfio-msix" : "vfio-msi";
> > struct eventfd_ctx *trigger;
> > int ret;
> > +   unsigned long irqflags = 0;
> >  
> > if (vector >= vdev->num_ctx)
> > return -EINVAL;
> > @@ -352,7 +357,10 @@ static int vfio_msi_set_vector_signal(struct 
> > vfio_pci_device *vdev,
> > pci_write_msi_msg(irq, );
> > }
> >  
> > -   ret = request_irq(irq, vfio_msihandler, 0,
> > +   if (nonthread_msi)
> > +   irqflags = IRQF_NO_THREAD;
> > +
> > +   ret = request_irq(irq, vfio_msihandler, irqflags,
> >   vdev->ctx[vector].name, trigger);
> > if (ret) {
> > kfree(vdev->ctx[vector].name);
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scsi_sysfs: Fix queue_ramp_up_period return code

[Hannes Reinecke]

On 10/26/2015 03:54 PM, Peter Oberparleiter wrote:
> Writing a number to /sys/bus/scsi/devices//queue_ramp_up_period
> returns the value of that number instead of the number of bytes written.
> This behavior can confuse programs expecting POSIX write() semantics.
> Fix this by returning the number of bytes written instead.
> 
> Signed-off-by: Peter Oberparleiter 
> ---
>  drivers/scsi/scsi_sysfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index b89..6b0f292 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -898,7 +898,7 @@ sdev_store_queue_ramp_up_period(struct device *dev,
>   return -EINVAL;
> 
>   sdev->queue_ramp_up_period = msecs_to_jiffies(period);
> - return period;
> + return count;
>  }
> 
>  static DEVICE_ATTR(queue_ramp_up_period, S_IRUGO | S_IWUSR,
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/5] mm: simplify reclaim path for MADV_FREE

[Minchan Kim]

Hello Yalin,

Sorry for missing you in Cc list.
IIRC, mails to send your previous mail address(yalin.w...@sonymobile.com)
were returned.

On Tue, Oct 27, 2015 at 11:44:09AM +0800, yalin wang wrote:
> 
> > On Oct 27, 2015, at 10:09, Hugh Dickins  wrote:
> > 
> > On Mon, 19 Oct 2015, Minchan Kim wrote:
> > 
> >> I made reclaim path mess to check and free MADV_FREEed page.
> >> This patch simplify it with tweaking add_to_swap.
> >> 
> >> So far, we mark page as PG_dirty when we add the page into
> >> swap cache(ie, add_to_swap) to page out to swap device but
> >> this patch moves PG_dirty marking under try_to_unmap_one
> >> when we decide to change pte from anon to swapent so if
> >> any process's pte has swapent for the page, the page must
> >> be swapped out. IOW, there should be no funcional behavior
> >> change. It makes relcaim path really simple for MADV_FREE
> >> because we just need to check PG_dirty of page to decide
> >> discarding the page or not.
> >> 
> >> Other thing this patch does is to pass TTU_BATCH_FLUSH to
> >> try_to_unmap when we handle freeable page because I don't
> >> see any reason to prevent it.
> >> 
> >> Cc: Hugh Dickins 
> >> Cc: Mel Gorman 
> >> Signed-off-by: Minchan Kim 
> > 
> > Acked-by: Hugh Dickins 
> > 
> > This is sooo much nicer than the code it replaces!  Really good.
> > Kudos also to Hannes for suggesting this approach originally, I think.
> > 
> > I hope this implementation satisfies a good proportion of the people
> > who have been wanting MADV_FREE: I'm not among them, and have long
> > lost touch with those discussions, so won't judge how usable it is.
> > 
> > I assume you'll refactor the series again before it goes to Linus,
> > so the previous messier implementations vanish?  I notice Andrew
> > has this "mm: simplify reclaim path for MADV_FREE" in mmotm as
> > mm-dont-split-thp-page-when-syscall-is-called-fix-6.patch:
> > I guess it all got much too messy to divide up in a hurry.
> > 
> > I've noticed no problems in testing (unlike the first time you moved
> > to working with pte_dirty); though of course I've not been using
> > MADV_FREE itself at all.
> > 
> > One aspect has worried me for a while, but I think I've reached the
> > conclusion that it doesn't matter at all.  The swap that's allocated
> > in add_to_swap() would normally get freed again (after try_to_unmap
> > found it was a MADV_FREE !pte_dirty !PageDirty case) at the bottom
> > of shrink_page_list(), in __remove_mapping(), yes?
> > 
> > The bit that worried me is that on rare occasions, something unknown
> > might take a speculative reference to the page, and __remove_mapping()
> > fail to freeze refs for that reason.  Much too rare to worry over not
> > freeing that page immediately, but it leaves us with a PageUptodate
> > PageSwapCache !PageDirty page, yet its contents are not the contents
> > of that location on swap.
> > 
> > But since this can only happen when you have *not* inserted the
> > corresponding swapent anywhere, I cannot think of anything that would
> > have a legitimate interest in its contents matching that location on swap.
> > So I don't think it's worth looking for somewhere to add a SetPageDirty
> > (or a delete_from_swap_cache) just to regularize that case.
> > 
> >> ---
> >> include/linux/rmap.h |  6 +
> >> mm/huge_memory.c |  5 
> >> mm/rmap.c| 42 ++
> >> mm/swap_state.c  |  5 ++--
> >> mm/vmscan.c  | 64 
> >> 
> >> 5 files changed, 30 insertions(+), 92 deletions(-)
> >> 



You added comment bottom line so I'm not sure what PageDirty you meant.

> it is wrong here if you only check PageDirty() to decide if the page is 
> freezable or not .
> The Anon page are shared by multiple process, _mapcount > 1 ,
> so you must check all pt_dirty bit during page_referenced() function,
> see this mail thread:
> http://ns1.ske-art.com/lists/kernel/msg1934021.html

If one of pte among process sharing the page was dirty, the dirtiness should
be propagated from pte to PG_dirty by try_to_unmap_one.
IOW, if the page doesn't have PG_dirty flag, it means all of process did
MADV_FREE.

Am I missing something from you question?
If so, could you show exact scenario I am missing?

Thanks for the interest.


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

RE: [PATCH v5 0/8] Add support for Exynos SROM Controller driver

[Pavel Fedin]

 Hello!

> You may need to fetch again?
> Anyway the branch is v4.4-next/driver-samsung or tags/samsung-driver...
> Or just for-next should be fine I think.

 Thank you very much, already found it, and even posted my series, you should 
have already seen it.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

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

[PATCH V3 RESEND 2/3] Add iommu driver for hi6220 SoC platform

[Chen Feng]

iommu/hisilicon: Add hi6220-SoC smmu driver

The smmu on hi6220 SoC is for media system.And the
media IP use the same page-table. It supports only
one-to-one mapping from iova to phys address.

Signed-off-by: Chen Feng 
Signed-off-by: Yu Dongbin 
---
 drivers/iommu/Kconfig|  11 +
 drivers/iommu/Makefile   |   1 +
 drivers/iommu/hi6220_iommu.c | 492 +++
 3 files changed, 504 insertions(+)
 create mode 100644 drivers/iommu/hi6220_iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index cbe6a89..6ca24db 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -342,6 +342,17 @@ config SPAPR_TCE_IOMMU
  Enables bits of IOMMU API required by VFIO. The iommu_ops
  is not implemented as it is not necessary for VFIO.
 
+config HI6220_IOMMU
+   bool "Hi6220 IOMMU Support"
+   depends on ARM64
+   select IOMMU_API
+   select IOMMU_IOVA
+   help
+ Enable IOMMU Driver for hi6220 SoC. The IOMMU API and IOMMU IOVA
+ is also selected.
+
+ If unsure, say N.
+
 # ARM IOMMU support
 config ARM_SMMU
bool "ARM Ltd. System MMU (SMMU) Support"
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index c6dcc51..db68fb3 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o
 obj-$(CONFIG_ARM_SMMU) += arm-smmu.o
 obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
 obj-$(CONFIG_DMAR_TABLE) += dmar.o
+obj-$(CONFIG_HI6220_IOMMU) += hi6220_iommu.o
 obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o
 obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
 obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
diff --git a/drivers/iommu/hi6220_iommu.c b/drivers/iommu/hi6220_iommu.c
new file mode 100644
index 000..47eb390
--- /dev/null
+++ b/drivers/iommu/hi6220_iommu.c
@@ -0,0 +1,492 @@
+/*
+ * Hisilicon Hi6220 IOMMU driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Chen Feng 
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) "IOMMU: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SMMU_CTRL_OFFSET (0x)
+#define SMMU_ENABLE_OFFSET   (0x0004)
+#define SMMU_PTBR_OFFSET (0x0008)
+#define SMMU_START_OFFSET(0x000C)
+#define SMMU_END_OFFSET  (0x0010)
+#define SMMU_INTMASK_OFFSET  (0x0014)
+#define SMMU_RINTSTS_OFFSET  (0x0018)
+#define SMMU_MINTSTS_OFFSET  (0x001C)
+#define SMMU_INTCLR_OFFSET   (0x0020)
+#define SMMU_STATUS_OFFSET   (0x0024)
+#define SMMU_AXIID_OFFSET(0x0028)
+#define SMMU_CNTCTRL_OFFSET  (0x002C)
+#define SMMU_TRANSCNT_OFFSET (0x0030)
+#define SMMU_L0TLBHITCNT_OFFSET  (0x0034)
+#define SMMU_L1TLBHITCNT_OFFSET  (0x0038)
+#define SMMU_WRAPCNT_OFFSET  (0x003C)
+#define SMMU_SEC_START_OFFSET(0x0040)
+#define SMMU_SEC_END_OFFSET  (0x0044)
+#define SMMU_VERSION_OFFSET  (0x0048)
+#define SMMU_IPTSRC_OFFSET   (0x004C)
+#define SMMU_IPTPA_OFFSET(0x0050)
+#define SMMU_TRBA_OFFSET (0x0054)
+#define SMMU_BYS_START_OFFSET(0x0058)
+#define SMMU_BYS_END_OFFSET  (0x005C)
+#define SMMU_RAM_OFFSET  (0x1000)
+
+#define SMMU_CTRL_INVALID(BIT(10))
+#define SMMU_SR_REGS_NUM (15)
+#define SMMU_REGS_SGMT_END   (0x60)
+#define PAGE_ENTRY_VALID (0x1)
+#define IOPAGE_SHIFT (12)
+#define IOVA_PFN(addr)   ((addr) >> IOPAGE_SHIFT)
+#define IOVA_PAGE_SZ (SZ_4K)
+
+/**
+ * The iova address from 0 ~ 2G
+ */
+#define IOVA_START   (0x0)
+#define IOVA_END (0x8000)
+
+struct hi6220_smmu {
+   unsigned int irq;
+   void __iomem *reg_base;
+   struct clk *smmu_peri_clk;
+   struct clk *smmu_clk;
+   struct clk *media_sc_clk;
+   spinlock_t spinlock; /*spinlock for tlb invalid*/
+   dma_addr_t pgtable_phy;
+   void *pgtable_virt;
+   u32  pgtable_size;
+   u32  *sr_data;
+};
+
+struct hi6220_domain {
+   struct hi6220_smmu *smmu_dev;
+   struct iommu_domain io_domain;
+};
+
+static struct hi6220_smmu *smmu_dev_handle;
+static struct iova_domain iova_allocator;
+
+static struct hi6220_domain *to_hi6220_domain(struct iommu_domain *dom)
+{
+   return container_of(dom, struct hi6220_domain, io_domain);
+}
+
+static inline void __smmu_writel(struct hi6220_smmu *smmu_dev, u32 value,
+unsigned long offset)
+{
+   writel(value, smmu_dev->reg_base 

Re: [PATCH v3] regulator, dt: add dt support for tps6502x regulator

[Mark Brown]

On Tue, Oct 27, 2015 at 07:23:09AM +0100, Heiko Schocher wrote:
> Am 27.10.2015 um 03:12 schrieb Mark Brown:

> >Please use subject lines matching the style for the subsystem.

> Would be "regulator: tps6520x:" correct?

Yes.

> >>+   regulators = of_get_child_by_name(np, "regulators");
> >>+   if (!regulators) {
> >>+   dev_err(dev, "regulator node not found\n");
> >>+   return NULL;
> >>+   }

> >Please use the generic support for locating the DT information for
> >regulators using regulators_node and of_match in the regulator_desc
> >rather than open coding this.

> Hmm.. could you point me to a correct example? Seems I overlook sth.

$ grep -l regulators_node drivers/regulator/*.c
drivers/regulator/88pm800.c
drivers/regulator/axp20x-regulator.c
drivers/regulator/da9062-regulator.c
drivers/regulator/isl9305.c
drivers/regulator/max14577.c
drivers/regulator/max77686.c
drivers/regulator/max77693.c
drivers/regulator/max77802.c
drivers/regulator/mt6311-regulator.c
drivers/regulator/of_regulator.c
drivers/regulator/rn5t618-regulator.c
drivers/regulator/rt5033-regulator.c
drivers/regulator/sky81452-regulator.c
drivers/regulator/tps65217-regulator.c


signature.asc
Description: PGP signature

RE: [PATCH v12 4/6] QE/CPM: move muram management functions to qe_common

[Zhao Qiang]

On Tue, Oct 27, 2015 at 2:50 PM, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, October 27, 2015 2:50 PM
> To: Zhao Qiang-B45475 
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> pau...@samba.org
> Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management functions to
> qe_common
> 
> On Tue, 2015-10-27 at 01:24 -0500, Zhao Qiang-B45475 wrote:
> > On Tue, Oct 27, 2015 at 12:48 PM, Wood Scott-B07421 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, October 27, 2015 12:48 PM
> > > To: Zhao Qiang-B45475 
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > > pau...@samba.org
> > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> functions
> > > to qe_common
> > >
> > > On Sun, 2015-10-25 at 21:42 -0500, Zhao Qiang-B45475 wrote:
> > > > On Sat, Oct 24, 2015 at 04:56 AM, Wood Scott-B07421 wrote:
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Saturday, October 24, 2015 4:56 AM
> > > > > To: Zhao Qiang-B45475 
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472
> > > > > ; pau...@samba.org
> > > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> > > functions
> > > > > to qe_common
> > > > >
> > > > > On Fri, 2015-10-23 at 02:45 -0500, Zhao Qiang-B45475 wrote:
> > > > > > On Fri, 2015-10-23 at 11:10 AM, Wood Scott-B07421
> > > > > > 
> > > > > > wrote:
> > > > > > > -Original Message-
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Friday, October 23, 2015 11:10 AM
> > > > > > > To: Zhao Qiang-B45475 
> > > > > > > Cc: linux-kernel@vger.kernel.org;
> > > > > > > linuxppc-...@lists.ozlabs.org; lau...@codeaurora.org; Xie
> > > > > > > Xiaobo-R63061 ;
> > > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472
> > > > > > > ; pau...@samba.org
> > > > > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> > > > > functions
> > > > > > > to qe_common
> > > > > > >
> > > > > So then why are you selecting QUICC_ENGINE?  And again, what
> > > > > does it have to do with this patch?
> > > >
> > > > Cpm-spi is dependent on qe_muram, if not select it, Cpm-spi will
> > > > failed to build.
> > >
> > > Why QUICC_ENGINE and not CPM?
> >
> > QE and CPM use the same muram, and it has been moved to qe_muram
> from
> > cpm_muram.
> 
> Fix the makefiles so that the muram code continues to be built for both
> QUICC_ENGINE and CPM.  It's not acceptable to have to bring in the entire QE
> code just for the muram.
> 
How about to define and CONFIG_QE_MURAM in Kconfig for muram?

-Zhao
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

[Boris Brezillon]

Hi Brian,

On Mon, 26 Oct 2015 19:31:06 -0700
Brian Norris  wrote:

> It seems more logical to use a device node directly associated with the
> MTD master device (i.e., mtd->dev.of_node field) rather than requiring
> auxiliary partition parser information to be passed in by the driver in
> a separate struct.
> 
> This patch supports the mtd->dev.of_node field, deprecates the parser
> data 'of_node' field, and begins using the new convention for nand_base.
> Other NAND driver conversions may now follow.
> 
> Additional side benefit to assigning mtd->dev.of_node rather than using
> parser data: the driver core will automatically create a device -> node
> symlink for us.

I like the idea, but how about pushing the solution even further and
killing the ->flash_node field which AFAICT is rendered useless by
your patch?

Best Regards,

Boris

> 
> Signed-off-by: Brian Norris 
> ---
>  drivers/mtd/nand/nand_base.c   |  3 +++
>  drivers/mtd/ofpart.c   | 18 ++
>  drivers/mtd/spi-nor/spi-nor.c  |  1 +
>  include/linux/mtd/partitions.h |  4 +++-
>  4 files changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index cc74142938b0..d2e7fee2ac37 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -3990,6 +3990,9 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
>   int ret;
>  
>   if (chip->flash_node) {
> + /* MTD can automatically handle DT partitions, etc. */
> + mtd->dev.of_node = chip->flash_node;
> +
>   ret = nand_dt_init(mtd, chip, chip->flash_node);
>   if (ret)
>   return ret;
> diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
> index aa26c32e1bc2..a5dfd73cfc7d 100644
> --- a/drivers/mtd/ofpart.c
> +++ b/drivers/mtd/ofpart.c
> @@ -35,10 +35,11 @@ static int parse_ofpart_partitions(struct mtd_info 
> *master,
>   int nr_parts, i;
>  
>  
> - if (!data)
> - return 0;
> -
> - node = data->of_node;
> + /*
> +  * of_node can be provided through auxiliary parser data or (preferred)
> +  * by assigning the master device
> +  */
> + node = data && data->of_node ? data->of_node : master->dev.of_node;
>   if (!node)
>   return 0;
>  
> @@ -120,10 +121,11 @@ static int parse_ofoldpart_partitions(struct mtd_info 
> *master,
>   } *part;
>   const char *names;
>  
> - if (!data)
> - return 0;
> -
> - dp = data->of_node;
> + /*
> +  * of_node can be provided through auxiliary parser data or (preferred)
> +  * by assigning the master device
> +  */
> + dp = data && data->of_node ? data->of_node : master->dev.of_node;
>   if (!dp)
>   return 0;
>  
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 49883905a434..8f9080c6db63 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -1258,6 +1258,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, 
> enum read_mode mode)
>   mtd->flags |= MTD_NO_ERASE;
>  
>   mtd->dev.parent = dev;
> + mtd->dev.of_node = np;
>   nor->page_size = info->page_size;
>   mtd->writebufsize = nor->page_size;
>  
> diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
> index 6a35e6de5da1..e742f34b67eb 100644
> --- a/include/linux/mtd/partitions.h
> +++ b/include/linux/mtd/partitions.h
> @@ -56,7 +56,9 @@ struct device_node;
>  /**
>   * struct mtd_part_parser_data - used to pass data to MTD partition parsers.
>   * @origin: for RedBoot, start address of MTD device
> - * @of_node: for OF parsers, device node containing partitioning information
> + * @of_node: for OF parsers, device node containing partitioning information.
> + *   This field is deprecated, as the device node should simply be
> + *   assigned to the master struct device.
>   */
>  struct mtd_part_parser_data {
>   unsigned long origin;



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] dynamic_debug: fix boot parameters parse

[Peter Chen]

The parse_args will delete space between boot parameters, so
if we add dyndbg="file drivers/usb/* +p" at bootargs, the parse_args
will split it as three parameters, and only "file" is for dyndbg,
then below error will occur at ddebug, it causes all non-module
ddebug fail during the boot process.

===
dynamic_debug:ddebug_parse_flags: bad flag-op f, at start of file
dynamic_debug:ddebug_exec_query: flags parse failed
===

As a solution, we can use comma to split parameters for ddebug booting
parameter, and replace comma with space at code, in that case, the ddebug
core can handle it with the same way we do it for /sys.

Signed-off-by: Peter Chen 
Cc: 
---
 lib/dynamic_debug.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index e491e02..da4883b 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -880,6 +880,8 @@ static int ddebug_dyndbg_param_cb(char *param, char *val,
if (strcmp(param, "dyndbg"))
return on_err; /* determined by caller */
 
+   /* relace comma with space */
+   strreplace(val, ',', ' ');
ddebug_exec_queries((val ? val : "+p"), modname);
 
return 0; /* query failure shouldnt stop module load */
-- 
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] libata: enable LBA flag in taskfile for ata_scsi_pass_thru()

[vinayak . kale]

From: Vinayak Kale 

Enable LBA in taskfile flags for ata_scsi_pass_thru()

Signed-off-by: Vinayak Kale 
---
 drivers/ata/libata-scsi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index c2af592..ff75cb6 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -2949,6 +2949,9 @@ static unsigned int ata_scsi_pass_thru(struct 
ata_queued_cmd *qc)
if ((tf->protocol = ata_scsi_map_proto(cdb[1])) == ATA_PROT_UNKNOWN)
goto invalid_fld;
 
+   /* enable LBA */
+   tf->flags |= ATA_TFLAG_LBA;
+
/*
 * 12 and 16 byte CDBs use different offsets to
 * provide the various register values.
-- 
1.9.1

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

[PATCH 2/2] Doc: dynamic-debug-howto: fix the way to enable ddebug during boot process

[Peter Chen]

Current non-module ddebug during boot process will fail due to
parse_args will delete space and give ddebug only the first
parameter, the code changes using comma to split ddebug parameters
for boot process, and we change documentation accordingly.

Signed-off-by: Peter Chen 
Cc: 
---
 Documentation/dynamic-debug-howto.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/dynamic-debug-howto.txt 
b/Documentation/dynamic-debug-howto.txt
index 9417871..fcd9ca6 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -242,7 +242,7 @@ messages in all code run after this arch_initcall via this 
boot
 parameter.
 
 On an x86 system for example ACPI enablement is a subsys_initcall and
-   dyndbg="file ec.c +p"
+   dyndbg="file,ec.c,+p"
 will show early Embedded Controller transactions during ACPI setup if
 your machine (typically a laptop) has an Embedded Controller.
 PCI (or other devices) initialization also is a hot candidate for using
-- 
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] libata: enable LBA flag in taskfile for ata_scsi_pass_thru()

[Tejun Heo]

On Tue, Oct 27, 2015 at 01:11:46PM +0530, vinayak.k...@gmail.com wrote:
> From: Vinayak Kale 
> 
> Enable LBA in taskfile flags for ata_scsi_pass_thru()
> 
> Signed-off-by: Vinayak Kale 

Applied to libata/for-4.4.

Thanks.

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

Re: [PATCH 1/3] devicetree: mfd: Add binding for the TI LM3533

[Rob Herring]

On Sun, Oct 25, 2015 at 1:09 PM, Bjorn Andersson
 wrote:
> Add the binding for the Texas Instruments LM3533 lighting power
> solution.
>
> Signed-off-by: Bjorn Andersson 
> ---
>  Documentation/devicetree/bindings/mfd/lm3533.txt | 183 
> +++
>  1 file changed, 183 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt 
> b/Documentation/devicetree/bindings/mfd/lm3533.txt
> new file mode 100644
> index ..3cc41695a544
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
> @@ -0,0 +1,183 @@
> +Texas Instruments LM3533 binding
> +
> +This binding describes the Texas Instruments LM3533, a lighting power 
> solution
> +for smartphone handsets. The common properties are described directly in the
> +node, while each individual component are described in an optional subnode.
> +
> +- compatible:
> +   Usage: required
> +   Value type: 
> +   Definition: must be:
> +   "ti,lm3533"
> +
> +- reg:
> +   Usage: required
> +   Value type: 
> +   Definition: i2c address of the LM3533 chip
> +
> +- ti,hwen-gpios:
> +   Usage: required
> +   Value type: 
> +   Definition: reference to gpio pin connected to the HWEN input; as
> +   specified in "gpio/gpio.txt"
> +
> +- ti,als-supply:
> +   Usage: optional
> +   Value type: 
> +   Definition: reference to regulator powering the V_als input; as
> +   specified in "regulator/regulator.txt"
> +
> +- ti,boost-freq:

Append "-hz".

> +   Usage: required
> +   Value type: 
> +   Definition: switch-frequency of the boost converter, must be either:
> +   50 or 100
> +
> +- ti,boost-ovp:
> +   Usage: required
> +   Value type: 
> +   Definition: over voltage protection limit, must be one of: 16, 24, 32
> +   or 40
> +
> +- #address-cells:
> +   Usage: required
> +   Value type: 
> +   Definition: must be 1
> +
> +- #size-cells:
> +   Usage: required
> +   Value type: 
> +   Definition: must be 0
> +
> += ALS SUBNODE
> +The als subnode must be named "als", it carries the als related properties.
> +
> +- ti,als-resistance:
> +   Usage: required (unless ti,pwm-mode is specified)
> +   Value type: 
> +   Definition: specifies the resistor value (R_als), in Ohm. Valid values
> +   ranges from 200kOhm to 1574Ohm.

So append "-kohm"?

> +
> +- ti,pwm-mode:
> +   Usage: optional
> +   Value type: 
> +   Definition: specifies, if present, that the als should operate in pwm
> +   mode - rather than analog mode
> +
> += BACKLIGHT NODES
> +Backlight subnodes must be named "backlight", they carry the backlight 
> related
> +properties.
> +
> +- reg:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies which of the two backlights this node 
> corresponds
> +   to
> +
> +- default-brightness:
> +   Usage: optional
> +   Value type: <32>
> +   Definition: specifies the default brightness for the backlight, in
> +   units of brightness [0-255]
> +
> +- label:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies a name of this backlight
> +
> +- led-max-microamp:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies the max current for this backlight, in uA, as
> +   described in "leds/common.txt"
> +
> +- ti,pwm-zones:
> +   Usage: optional
> +   Value type: 
> +   Definition: lists the ALS zones to be PWM controlled for this 
> backlight,
> +   the values in the list are in the range [0 - 4]
> +
> += LED NODES
> +LED subnodes must be named "led", they carry the LED related properties.
> +
> +- reg:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies which of the four LEDs this node corresponds to
> +
> +- linux,default-trigger:
> +   Usage: optional
> +   Value type: 
> +   Definition: specifies the default trigger for the LED, as described in
> +   "leds/common.txt"
> +
> +- label:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies a name of this LED, as described in
> +   "leds/common.txt"
> +
> +- led-max-microamp:
> +   Usage: required
> +   Value type: 
> +   Definition: specifies the max current for this LED, in uA, as 
> described
> +   in "leds/common.txt"
> +
> +- ti,pwm-zones:
> +   Usage: optional
> +   Value type: 
> +   Definition: lists the ALS zones to be PWM controlled for this LED, the
> +   values in the list are in the range [0 - 4]
> +
> += EXAMPLE
> +
> +i2c@1246 {
> +   compatible = 

Re: [Linux v4.3-rc6] i915: issues with Skylake integrated graphics

[Jani Nikula]

On Tue, 27 Oct 2015, Eric Biggers  wrote:
> On Mon, Oct 26, 2015 at 03:28:37PM +0200, Jani Nikula wrote:
>> Please file two separate bugs at [1], one for the above, and another for
>> the below. Please add drm.debug=14 module parameter, and attach dmesg
>> all the way from boot to the problem.
>
> I have filed https://bugs.freedesktop.org/show_bug.cgi?id=92685 for the second
> part.  I did not, however, re-experience the first warning (the
> "WARN_ON(p->pixel_rate == 0)") after upgrading to Linux v4.3-rc7 and rebooting
> several times.

Thanks for the report.

BR,
Jani.

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

Re: [PATCH] Staging:drivers:wlan_ng: code style issues

[Greg KH]

On Mon, Oct 26, 2015 at 05:36:55PM +0100, Bogicevic Sasa wrote:
> Fixed coding style issues
> Signed-off-by: Bogicevic Sasa 
> ---
>  drivers/staging/wlan-ng/hfa384x_usb.c | 189 
> +-
>  1 file changed, 95 insertions(+), 94 deletions(-)

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

Re: [PATCH 2/2] Drivers:staging:wlan_ng: fix all coding style isuues in file prism2usb.c

[Greg KH]

On Mon, Oct 26, 2015 at 10:47:37PM +0100, Bogicevic Sasa wrote:
> Fixed all coding style issues based on checkpatch.pl warnings and errors
> 
> Signed-off-by: Bogicevic Sasa 
> ---
>  drivers/staging/wlan-ng/prism2usb.c | 40 
> ++---
>  1 file changed, 24 insertions(+), 16 deletions(-)

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

Re: [PATCH] Staging:drivers:wlan_ng: fix all coding style issues in hfa384x_usb.c file

[Greg KH]

On Mon, Oct 26, 2015 at 09:45:37PM +0100, Bogicevic Sasa wrote:
> Fix all coding style issues in file so checkpatch.pl doesen't cry no more
> 
> Signed-off-by: Bogicevic Sasa 

Please break this up into specific pieces.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] get_maintainer: Don't fallback to git by default

[Lee Jones]

On Mon, 26 Oct 2015, j...@perches.com wrote:
> On 2015-10-26 19:47, Theodore Ts'o wrote:
> >What if we have a git_fallback "auto" mode which only falls back to
> >using git if there is no entry in the MAINTAINERS file?  That might
> >address the concern which Laura raised, without blocking this
> >change until the MAINTAINERS file is fully populated.
> 
> That's what happens already right now.

I think it can be done better.

FYI, this patch came about because I keep complaining about submitters
sending me patches I really shouldn't have to care about.

Here is the most recent offending command output:

  $ ./scripts/get_maintainer.pl -f drivers/i2c/busses/Kconfig
  Wolfram Sang  (maintainer:I2C 
SUBSYSTEM,commit_signer:26/26=100%,authored:3/26=12%,removed_lines:3/11=27%)
  Lee Jones  (commit_signer:3/26=12%)
  Geert Uytterhoeven  
(commit_signer:3/26=12%,authored:3/26=12%,removed_lines:2/11=18%)
  David Box  
(commit_signer:3/26=12%,added_lines:11/146=8%)
  Jean Delvare  (commit_signer:2/26=8%)
  Javier Martinez Canillas  
(authored:2/26=8%,removed_lines:2/11=18%)
  Neelesh Gupta  (added_lines:11/146=8%)
  James Hogan  (added_lines:10/146=7%)
  Ray Jui  (added_lines:10/146=7%)
  Joachim Eastwood  (added_lines:10/146=7%)
  Andrew Bresticker  (removed_lines:2/11=18%)
  Zhangfei Gao  (removed_lines:1/11=9%)
  linux-...@vger.kernel.org (open list:I2C SUBSYSTEM)
  linux-kernel@vger.kernel.org (open list)

Anyone south of Wolfram and north of the I2C ML is unlikely to care.

Please find a way to make this better.  For the sake of our sanity.

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

[PATCH 1/3] megaraid_sas: Convert dev_printk to dev_

[Weidong Wang]

Reduce object size a little by using dev_
calls instead of dev_printk(KERN_.

Signed-off-by: Weidong Wang 
---
 drivers/scsi/megaraid/megaraid_sas_base.c | 68 +++
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index eaa81e5..ed9846d 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1884,7 +1884,7 @@ static int megasas_get_ld_vf_affiliation_111(struct 
megasas_instance *instance,
cmd = megasas_get_cmd(instance);
 
if (!cmd) {
-   dev_printk(KERN_DEBUG, >pdev->dev, 
"megasas_get_ld_vf_affiliation_111:"
+   dev_dbg(>pdev->dev, 
"megasas_get_ld_vf_affiliation_111:"
   "Failed to get cmd for scsi%d\n",
instance->host->host_no);
return -ENOMEM;
@@ -1908,7 +1908,7 @@ static int megasas_get_ld_vf_affiliation_111(struct 
megasas_instance *instance,
 sizeof(struct 
MR_LD_VF_AFFILIATION_111),
 _affiliation_111_h);
if (!new_affiliation_111) {
-   dev_printk(KERN_DEBUG, >pdev->dev, "SR-IOV: 
Couldn't allocate "
+   dev_dbg(>pdev->dev, "SR-IOV: Couldn't 
allocate "
   "memory for new affiliation for scsi%d\n",
   instance->host->host_no);
megasas_return_cmd(instance, cmd);
@@ -1995,7 +1995,7 @@ static int megasas_get_ld_vf_affiliation_12(struct 
megasas_instance *instance,
cmd = megasas_get_cmd(instance);
 
if (!cmd) {
-   dev_printk(KERN_DEBUG, >pdev->dev, 
"megasas_get_ld_vf_affiliation12: "
+   dev_dbg(>pdev->dev, "megasas_get_ld_vf_affiliation12: 
"
   "Failed to get cmd for scsi%d\n",
   instance->host->host_no);
return -ENOMEM;
@@ -2020,7 +2020,7 @@ static int megasas_get_ld_vf_affiliation_12(struct 
megasas_instance *instance,
 sizeof(struct 
MR_LD_VF_AFFILIATION),
 _affiliation_h);
if (!new_affiliation) {
-   dev_printk(KERN_DEBUG, >pdev->dev, "SR-IOV: 
Couldn't allocate "
+   dev_dbg(>pdev->dev, "SR-IOV: Couldn't 
allocate "
   "memory for new affiliation for scsi%d\n",
   instance->host->host_no);
megasas_return_cmd(instance, cmd);
@@ -2174,7 +2174,7 @@ int megasas_sriov_start_heartbeat(struct megasas_instance 
*instance,
cmd = megasas_get_cmd(instance);
 
if (!cmd) {
-   dev_printk(KERN_DEBUG, >pdev->dev, 
"megasas_sriov_start_heartbeat: "
+   dev_dbg(>pdev->dev, "megasas_sriov_start_heartbeat: "
   "Failed to get cmd for scsi%d\n",
   instance->host->host_no);
return -ENOMEM;
@@ -2188,7 +2188,7 @@ int megasas_sriov_start_heartbeat(struct megasas_instance 
*instance,
  sizeof(struct 
MR_CTRL_HB_HOST_MEM),
  >hb_host_mem_h);
if (!instance->hb_host_mem) {
-   dev_printk(KERN_DEBUG, >pdev->dev, "SR-IOV: 
Couldn't allocate"
+   dev_dbg(>pdev->dev, "SR-IOV: Couldn't 
allocate"
   " memory for heartbeat host memory for scsi%d\n",
   instance->host->host_no);
retval = -ENOMEM;
@@ -2922,7 +2922,7 @@ megasas_complete_cmd(struct megasas_instance *instance, 
struct megasas_cmd *cmd,
break;
 
default:
-   dev_printk(KERN_DEBUG, >pdev->dev, "MFI FW 
status %#x\n",
+   dev_dbg(>pdev->dev, "MFI FW status %#x\n",
   hdr->cmd_status);
cmd->scmd->result = DID_ERROR << 16;
break;
@@ -3332,7 +3332,7 @@ megasas_transition_to_ready(struct megasas_instance 
*instance, int ocr)
switch (fw_state) {
 
case MFI_STATE_FAULT:
-   dev_printk(KERN_DEBUG, >pdev->dev, "FW in 
FAULT state!!\n");
+   dev_dbg(>pdev->dev, "FW in FAULT state!!\n");
if (ocr) {
max_wait = MEGASAS_RESET_WAIT_TIME;
cur_state = MFI_STATE_FAULT;
@@ -3471,7 +3471,7 @@ megasas_transition_to_ready(struct megasas_instance 
*instance, int ocr)
break;
 
default:
-   dev_printk(KERN_DEBUG, >pdev->dev, "Unknown 
state 0x%x\n",
+   

Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Boris Brezillon]

Hi Brian,

On Mon, 26 Oct 2015 13:49:00 -0700
Brian Norris  wrote:

> + others
> 
> A few comments below.
> 
> On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
> > The GPMC WAIT pin status are now available over gpiolib.
> > Update the omap_dev_ready() function to use gpio instead of
> > directly accessing GPMC register space.
> > 
> > Signed-off-by: Roger Quadros 
> > ---
> >  drivers/mtd/nand/omap2.c | 29 
> > +---
> >  include/linux/platform_data/mtd-nand-omap2.h |  2 +-
> >  2 files changed, 19 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> > index 228f498..d0f2620 100644
> > --- a/drivers/mtd/nand/omap2.c
> > +++ b/drivers/mtd/nand/omap2.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -184,6 +185,8 @@ struct omap_nand_info {
> > /* fields specific for BCHx_HW ECC scheme */
> > struct device   *elm_dev;
> > struct device_node  *of_node;
> > +   /* NAND ready gpio */
> > +   struct gpio_desc*ready_gpiod;
> >  };
> >  
> >  /**
> > @@ -1047,22 +1050,17 @@ static int omap_wait(struct mtd_info *mtd, struct 
> > nand_chip *chip)
> >  }
> >  
> >  /**
> > - * omap_dev_ready - calls the platform specific dev_ready function
> > + * omap_dev_ready - checks the NAND Ready GPIO line
> >   * @mtd: MTD device structure
> > + *
> > + * Returns true if ready and false if busy.
> >   */
> >  static int omap_dev_ready(struct mtd_info *mtd)
> >  {
> > -   unsigned int val = 0;
> > struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
> > mtd);
> >  
> > -   val = readl(info->reg.gpmc_status);
> > -
> > -   if ((val & 0x100) == 0x100) {
> > -   return 1;
> > -   } else {
> > -   return 0;
> > -   }
> > +   return gpiod_get_value(info->ready_gpiod);
> >  }
> >  
> >  /**
> > @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device 
> > *pdev)
> > info->reg = pdata->reg;
> > info->of_node = pdata->of_node;
> > info->ecc_opt = pdata->ecc_opt;
> > -   info->dev_ready = pdata->dev_ready;
> > +   if (pdata->dev_ready)
> > +   dev_info(>dev, "pdata->dev_ready is 
> > deprecated\n");
> > +
> > info->xfer_type = pdata->xfer_type;
> > info->devsize = pdata->devsize;
> > info->elm_of_node = pdata->elm_of_node;
> > @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device 
> > *pdev)
> > nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
> > nand_chip->cmd_ctrl  = omap_hwcontrol;
> >  
> > +   info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
> > +   GPIOD_IN);
> 
> Others have been looking at using GPIOs for the ready/busy pin too. At a
> minimum, we need an updated DT binding doc for this, since I see you're
> adding this via device tree in a later patch (I don't see any DT binding
> patch for this; but I could just be overlooking it). It'd also be great
> if this support was moved to nand_dt_init() so other platforms can
> benefit, but I won't require that.

Actually I started to work on a generic solution parsing the DT and
creating CS, WP and RB gpios when they are provided, but I think it's a
bit more complicated than just moving the rb-gpios parsing into
nand_dt_init().
First you'll need something to store your gpio_desc pointers, which
means you'll have to allocate a table of gpio_desc pointers (or a table
of struct embedding a gpio_desc pointer).
The other blocking point is that when nand_scan_ident() is called, the
caller is supposed to have filled the ->dev_ready() or ->waitfunc()
fields, and to choose how to implement it he may need to know
which kind of RB handler should be used (this is the case in the sunxi
driver, where the user can either use a GPIO or native R/B pin directly
connected to the controller).

All this makes me think that maybe nand_dt_init() should be called
separately or in a different helper (nand_init() ?) taking care of the
basic nand_chip initializations/allocations without interacting with
the NAND itself.

Another solution would be to add an ->init() function to nand_chip
and call it after the generic initialization has been done (but before
NAND chip detection). This way the NAND controller driver could adapt
some fields and parse controller specific properties.

What do you think?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  

[PATCH 3/3] megaraid_sas: return -ENOMEM when create DMA pool for cmd frames failed

[Weidong Wang]

when create DMA pool for cmd frames failed, we should return -ENOMEM,
instead of 0.
In some case in:

megasas_init_adapter_fusion()

-->megasas_alloc_cmds()
   -->megasas_create_frame_pool
  create DMA pool failed,
--> megasas_free_cmds() [1]

-->megasas_alloc_cmds_fusion()
   failed, then goto fail_alloc_cmds.
-->megasas_free_cmds() [2]

we will call megasas_free_cmds twice, [1] will kfree cmd_list,
[2] will use cmd_list.it will cause a problem:

Unable to handle kernel NULL pointer dereference at virtual address 
pgd = ffc000f7
[] *pgd=001fbf893003, *pud=001fbf893003, *pmd=001fbf894003, 
*pte=00606d000707
Internal error: Oops: 9605 [#1] SMP
 Modules linked in:
 CPU: 18 PID: 1 Comm: swapper/0 Not tainted
 task: ffdfb929 ti: ffdfb923c000 task.ti: ffdfb923c000
 PC is at megasas_free_cmds+0x30/0x70
 LR is at megasas_free_cmds+0x24/0x70

 ...

 Call trace:
 [] megasas_free_cmds+0x30/0x70
 [] megasas_init_adapter_fusion+0x2f4/0x4d8
 [] megasas_init_fw+0x2dc/0x760
 [] megasas_probe_one+0x3c0/0xcd8
 [] local_pci_probe+0x4c/0xb4
 [] pci_device_probe+0x11c/0x14c
 [] driver_probe_device+0x1ec/0x430
 [] __driver_attach+0xa8/0xb0
 [] bus_for_each_dev+0x74/0xc8
  [] driver_attach+0x28/0x34
 [] bus_add_driver+0x16c/0x248
 [] driver_register+0x6c/0x138
 [] __pci_register_driver+0x5c/0x6c
 [] megasas_init+0xc0/0x1a8
 [] do_one_initcall+0xe8/0x1ec
 [] kernel_init_freeable+0x1c8/0x284
 [] kernel_init+0x1c/0xe4

Signed-off-by: Weidong Wang 
---
 drivers/scsi/megaraid/megaraid_sas_base.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 2287aa1..8215218 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -3746,8 +3746,9 @@ int megasas_alloc_cmds(struct megasas_instance *instance)
 * Create a frame pool and assign one frame to each cmd
 */
if (megasas_create_frame_pool(instance)) {
-   dev_dbg(>pdev->dev, "Error creating frame DMA 
pool\n");
+   dev_err(>pdev->dev, "Error creating frame DMA 
pool\n");
megasas_free_cmds(instance);
+   return -ENOMEM;
}
 
return 0;
-- 
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 2/3] input: Changed keyreset to act as a wrapper for keycombo.

[Bálint Czobor]

From: Daniel Rosenberg 

keyreset now registers a keycombo driver that acts as the old
keyreset driver acted.

Signed-off-by: Daniel Rosenberg 
Signed-off-by: Bálint Czobor 
---
 drivers/input/Kconfig|1 +
 drivers/input/keyreset.c |  206 +-
 include/linux/keyreset.h |3 +-
 3 files changed, 58 insertions(+), 152 deletions(-)

diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
index 47a5143..3898074 100644
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -190,6 +190,7 @@ config INPUT_APMPOWER
 config INPUT_KEYRESET
tristate "Reset key"
depends on INPUT
+   select INPUT_KEYCOMBO
---help---
  Say Y here if you want to reboot when some keys are pressed;

diff --git a/drivers/input/keyreset.c b/drivers/input/keyreset.c
index 36208fe..eaaccde 100644
--- a/drivers/input/keyreset.c
+++ b/drivers/input/keyreset.c
@@ -1,6 +1,6 @@
 /* drivers/input/keyreset.c
  *
- * Copyright (C) 2008 Google, Inc.
+ * Copyright (C) 2014 Google, Inc.
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -21,200 +21,104 @@
 #include 
 #include 
 #include 
-
+#include 

 struct keyreset_state {
-   struct input_handler input_handler;
-   unsigned long keybit[BITS_TO_LONGS(KEY_CNT)];
-   unsigned long upbit[BITS_TO_LONGS(KEY_CNT)];
-   unsigned long key[BITS_TO_LONGS(KEY_CNT)];
-   spinlock_t lock;
-   int key_down_target;
-   int key_down;
-   int key_up;
-   int restart_disabled;
+   int restart_requested;
int (*reset_fn)(void);
+   struct platform_device *pdev_child;
 };

-int restart_requested;
-static void deferred_restart(struct work_struct *dummy)
+static void do_restart(void)
 {
-   restart_requested = 2;
sys_sync();
-   restart_requested = 3;
kernel_restart(NULL);
 }
-static DECLARE_WORK(restart_work, deferred_restart);

-static void keyreset_event(struct input_handle *handle, unsigned int type,
-  unsigned int code, int value)
+static void do_reset_fn(void *priv)
 {
-   unsigned long flags;
-   struct keyreset_state *state = handle->private;
-
-   if (type != EV_KEY)
-   return;
-
-   if (code >= KEY_MAX)
-   return;
-
-   if (!test_bit(code, state->keybit))
-   return;
-
-   spin_lock_irqsave(>lock, flags);
-   if (!test_bit(code, state->key) == !value)
-   goto done;
-   __change_bit(code, state->key);
-   if (test_bit(code, state->upbit)) {
-   if (value) {
-   state->restart_disabled = 1;
-   state->key_up++;
-   } else
-   state->key_up--;
+   struct keyreset_state *state = priv;
+   if (state->restart_requested)
+   panic("keyboard reset failed, %d", state->restart_requested);
+   if (state->reset_fn) {
+   state->restart_requested = state->reset_fn();
} else {
-   if (value)
-   state->key_down++;
-   else
-   state->key_down--;
+   pr_info("keyboard reset\n");
+   do_restart();
+   state->restart_requested = 1;
}
-   if (state->key_down == 0 && state->key_up == 0)
-   state->restart_disabled = 0;
-
-   pr_debug("reset key changed %d %d new state %d-%d-%d\n", code, value,
-state->key_down, state->key_up, state->restart_disabled);
-
-   if (value && !state->restart_disabled &&
-   state->key_down == state->key_down_target) {
-   state->restart_disabled = 1;
-   if (restart_requested)
-   panic("keyboard reset failed, %d", restart_requested);
-   if (state->reset_fn) {
-   restart_requested = state->reset_fn();
-   } else {
-   pr_info("keyboard reset\n");
-   schedule_work(_work);
-   restart_requested = 1;
-   }
-   }
-done:
-   spin_unlock_irqrestore(>lock, flags);
 }

-static int keyreset_connect(struct input_handler *handler,
- struct input_dev *dev,
- const struct input_device_id *id)
-{
-   int i;
-   int ret;
-   struct input_handle *handle;
-   struct keyreset_state *state =
-   container_of(handler, struct keyreset_state, input_handler);
-
-   for (i = 0; i < KEY_MAX; i++) {
-   if (test_bit(i, state->keybit) && test_bit(i, dev->keybit))
-   break;
-   }
-   if (i == KEY_MAX)
-   return -ENODEV;
-
-   handle = kzalloc(sizeof(*handle), GFP_KERNEL);
-   if 

[PATCH 1/3] input: Add keyreset driver.

[Bálint Czobor]

From: Arve Hjønnevåg 

Add a platform device in the board file to specify a reset key-combo.
The first time the key-combo is detected a work function that syncs
the filesystems is scheduled. If all the keys are released and then
pressed again, it calls panic. Reboot on panic should be set for
this to work.

Signed-off-by: Arve Hjønnevåg 
Signed-off-by: Bálint Czobor 
---
 drivers/input/Kconfig|9 ++
 drivers/input/Makefile   |1 +
 drivers/input/keyreset.c |  239 ++
 include/linux/keyreset.h |   28 ++
 4 files changed, 277 insertions(+)
 create mode 100644 drivers/input/keyreset.c
 create mode 100644 include/linux/keyreset.h

diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
index a35532e..47a5143 100644
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -187,6 +187,15 @@ config INPUT_APMPOWER
  To compile this driver as a module, choose M here: the
  module will be called apm-power.

+config INPUT_KEYRESET
+   tristate "Reset key"
+   depends on INPUT
+   ---help---
+ Say Y here if you want to reboot when some keys are pressed;
+
+ To compile this driver as a module, choose M here: the
+ module will be called keyreset.
+
 comment "Input Device Drivers"

 source "drivers/input/keyboard/Kconfig"
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index 0c9302c..f3749d5 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -26,3 +26,4 @@ obj-$(CONFIG_INPUT_TOUCHSCREEN)   += touchscreen/
 obj-$(CONFIG_INPUT_MISC)   += misc/

 obj-$(CONFIG_INPUT_APMPOWER)   += apm-power.o
+obj-$(CONFIG_INPUT_KEYRESET)   += keyreset.o
diff --git a/drivers/input/keyreset.c b/drivers/input/keyreset.c
new file mode 100644
index 000..36208fe
--- /dev/null
+++ b/drivers/input/keyreset.c
@@ -0,0 +1,239 @@
+/* drivers/input/keyreset.c
+ *
+ * Copyright (C) 2008 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+struct keyreset_state {
+   struct input_handler input_handler;
+   unsigned long keybit[BITS_TO_LONGS(KEY_CNT)];
+   unsigned long upbit[BITS_TO_LONGS(KEY_CNT)];
+   unsigned long key[BITS_TO_LONGS(KEY_CNT)];
+   spinlock_t lock;
+   int key_down_target;
+   int key_down;
+   int key_up;
+   int restart_disabled;
+   int (*reset_fn)(void);
+};
+
+int restart_requested;
+static void deferred_restart(struct work_struct *dummy)
+{
+   restart_requested = 2;
+   sys_sync();
+   restart_requested = 3;
+   kernel_restart(NULL);
+}
+static DECLARE_WORK(restart_work, deferred_restart);
+
+static void keyreset_event(struct input_handle *handle, unsigned int type,
+  unsigned int code, int value)
+{
+   unsigned long flags;
+   struct keyreset_state *state = handle->private;
+
+   if (type != EV_KEY)
+   return;
+
+   if (code >= KEY_MAX)
+   return;
+
+   if (!test_bit(code, state->keybit))
+   return;
+
+   spin_lock_irqsave(>lock, flags);
+   if (!test_bit(code, state->key) == !value)
+   goto done;
+   __change_bit(code, state->key);
+   if (test_bit(code, state->upbit)) {
+   if (value) {
+   state->restart_disabled = 1;
+   state->key_up++;
+   } else
+   state->key_up--;
+   } else {
+   if (value)
+   state->key_down++;
+   else
+   state->key_down--;
+   }
+   if (state->key_down == 0 && state->key_up == 0)
+   state->restart_disabled = 0;
+
+   pr_debug("reset key changed %d %d new state %d-%d-%d\n", code, value,
+state->key_down, state->key_up, state->restart_disabled);
+
+   if (value && !state->restart_disabled &&
+   state->key_down == state->key_down_target) {
+   state->restart_disabled = 1;
+   if (restart_requested)
+   panic("keyboard reset failed, %d", restart_requested);
+   if (state->reset_fn) {
+   restart_requested = state->reset_fn();
+   } else {
+   pr_info("keyboard reset\n");
+   schedule_work(_work);
+   restart_requested = 1;
+   }
+   }

Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

[Baoquan He]

Hi,

I just have a look at this thread. I am wondering why we don't use
existing is_kdump_kernel() directly to disable external NMI if it's
in kdump kernel. Then no need to introduce another boot option "noextnmi"
which is used only for kdump kernel.

Thanks
Baoquan

On 09/25/15 at 08:28pm, Hidehiro Kawai wrote:
> This patch introduces new boot option "noextnmi" which disables
> external NMI.  This option is useful for the dump capture kernel
> so that an HA application or administrator wouldn't mistakenly
> shoot down the kernel by NMI.
> 
> Currently, only x86 supports this option.
> 
> Signed-off-by: Hidehiro Kawai 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Jonathan Corbet 
> ---
>  Documentation/kernel-parameters.txt |4 
>  arch/x86/kernel/apic/apic.c |   17 -
>  2 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 22a4b68..8bcaccd 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2379,6 +2379,10 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   noexec=on: enable non-executable mappings (default)
>   noexec=off: disable non-executable mappings
>  
> + noextnmi[X86]
> + Mask external NMI.  This option is useful for a
> + dump capture kernel to be shot down by NMI.
> +
>   nosmap  [X86]
>   Disable SMAP (Supervisor Mode Access Prevention)
>   even if it is supported by processor.
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 24e94ce..fd47128 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -82,6 +82,12 @@
>  static unsigned int disabled_cpu_apicid __read_mostly = BAD_APICID;
>  
>  /*
> + * Don't enable external NMI via LINT1 on BSP.  This is useful for
> + * the dump capture kernel.
> + */
> +static bool apic_noextnmi;
> +
> +/*
>   * Map cpu index to physical APIC ID
>   */
>  DEFINE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid, BAD_APICID);
> @@ -1161,6 +1167,8 @@ void __init init_bsp_APIC(void)
>   value = APIC_DM_NMI;
>   if (!lapic_is_integrated()) /* 82489DX */
>   value |= APIC_LVT_LEVEL_TRIGGER;
> + if (apic_noextnmi)
> + value |= APIC_LVT_MASKED;
>   apic_write(APIC_LVT1, value);
>  }
>  
> @@ -1380,7 +1388,7 @@ void setup_local_APIC(void)
>   /*
>* only the BP should see the LINT1 NMI signal, obviously.
>*/
> - if (!cpu)
> + if (!cpu && !apic_noextnmi)
>   value = APIC_DM_NMI;
>   else
>   value = APIC_DM_NMI | APIC_LVT_MASKED;
> @@ -2548,3 +2556,10 @@ static int __init apic_set_disabled_cpu_apicid(char 
> *arg)
>   return 0;
>  }
>  early_param("disable_cpu_apicid", apic_set_disabled_cpu_apicid);
> +
> +static int __init apic_set_noextnmi(char *arg)
> +{
> + apic_noextnmi = true;
> + return 0;
> +}
> +early_param("noextnmi", apic_set_noextnmi);
> 
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] lib/string_helpers.c: don't lose precision in string_get_size()

[Vitaly Kuznetsov]

Rasmus Villemoes  writes:

> So I also played with this over the weekend, and also threw together a
> stupid script to check the output. I see you have more or less the same
> idea I used, namely to combine size and blk_size earlier.
>
> I put some code on github, https://github.com/Villemoes/get_size. All
> versions still fail a very simply case, size=1594323, blk_size=1, for
> which the correct answer is "1.52 MiB", but we get "1.51 MiB".

Yes, the algorithm still has minor glitches (e.g. rounding issues) but
I'd say keeping it simple enough here is worth it.

> But both
> your version and my two attempts seem to have the property that they are
> always at most one ULP (unit in the last place) too low, and never too
> high. ATM, my version 2 fails 70 of the 13598 test cases, while yours
> fail 86 (the former being a strict subset of the latter), so they're
> very similar.
>
> Regardless of which algorithm we go with, I have some cleanups I'd like
> to do, but they're mostly independent and can wait.
>
> Rasmus

-- 
  Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: hns: fixes the bug tested XGE by ethtool -p

[yankejian]

From: Li Peng 

delete action of ETHTOOL_ID_ON/ETHTOOL_ID_OFF in XGE ethtool -p,
so Hardware control the LED state instead of software.

Signed-off-by: Li Peng 
Signed-off-by: Yisen Zhuang 
Signed-off-by: yankejian 
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
index d611388..523e9b8 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
@@ -64,17 +64,10 @@ int cpld_set_led_id(struct hns_mac_cb *mac_cb,
switch (status) {
case HNAE_LED_ACTIVE:
mac_cb->cpld_led_value = dsaf_read_b(mac_cb->cpld_vaddr);
-   return 2;
-   case HNAE_LED_ON:
dsaf_set_bit(mac_cb->cpld_led_value, DSAF_LED_ANCHOR_B,
 CPLD_LED_ON_VALUE);
dsaf_write_b(mac_cb->cpld_vaddr, mac_cb->cpld_led_value);
-   break;
-   case HNAE_LED_OFF:
-   dsaf_set_bit(mac_cb->cpld_led_value, DSAF_LED_ANCHOR_B,
-CPLD_LED_DEFAULT_VALUE);
-   dsaf_write_b(mac_cb->cpld_vaddr, mac_cb->cpld_led_value);
-   break;
+   return 2;
case HNAE_LED_INACTIVE:
dsaf_set_bit(mac_cb->cpld_led_value, DSAF_LED_ANCHOR_B,
 CPLD_LED_DEFAULT_VALUE);
-- 
1.9.1

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

Re: [PATCH 1/3] input: keychord: Add keychord driver

[Dmitry Torokhov]

On Tue, Oct 27, 2015 at 09:47:26AM +0100, Bálint Czobor wrote:
> From: Mike Lockwood 
> 
> This driver allows userspace to receive notification when client
> specified key combinations are pressed.
> The client opens /dev/keychord and writes a list of keychords
> for the driver to monitor.
> The client then reads or polls /dev/keychord for notifications.
> A client specified ID for the keychord is returned from read()
> when a keychord press is detected.
> 
> Signed-off-by: Mike Lockwood 
> 
> keychord: fix to build without CONFIG_PREEMPT

Why does this need to be in the kernel?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regulator: tps65217: remove tps65217.dtsi file

[Heiko Schocher]

Hello Keerthy,

Am 27.10.2015 um 07:06 schrieb Keerthy:

Hi Heiko,

On Monday 26 October 2015 02:43 PM, Heiko Schocher wrote:

remove tps65217.dtsi and adapt all boards, which
used it.



I boot tested this on am335x-bone and am335x-boneblack boards and could 
successfully boot and i even
checked the regulators registered am335x-bone:

cat /sys/class/regulator/regulator.*/name
regulator-dummy
vmmcsd_fixed
DCDC1
DCDC2
DCDC3
LDO1
LDO2
LDO3
LDO4

Looks good to me. For am335x-bone and am335x-boneblack you can add

Tested-by: Keerthy 


Thanks for testing!

bye,
Heiko


Best Regards,
Keerthy


Signed-off-by: Heiko Schocher 
---
Suggested by Mark Brown, see:
https://lkml.org/lkml/2015/10/21/581

  .../devicetree/bindings/regulator/tps65217.txt | 78 --
  arch/arm/boot/dts/am335x-bone-common.dtsi  | 14 +++-
  arch/arm/boot/dts/am335x-chilisom.dtsi | 14 +++-
  arch/arm/boot/dts/am335x-nano.dts  | 14 +++-
  arch/arm/boot/dts/am335x-pepper.dts| 14 +++-
  arch/arm/boot/dts/am335x-sl50.dts  | 13 +++-
  arch/arm/boot/dts/tps65217.dtsi| 56 
  7 files changed, 58 insertions(+), 145 deletions(-)
  delete mode 100644 Documentation/devicetree/bindings/regulator/tps65217.txt
  delete mode 100644 arch/arm/boot/dts/tps65217.dtsi

diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
deleted file mode 100644
index 4f05d20..000
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-TPS65217 family of regulators
-
-Required properties:
-- compatible: "ti,tps65217"
-- reg: I2C slave address
-- regulators: list of regulators provided by this controller, must be named
-  after their hardware counterparts: dcdc[1-3] and ldo[1-4]
-- regulators: This is the list of child nodes that specify the regulator
-  initialization data for defined regulators. Not all regulators for the given
-  device need to be present. The definition for each of these nodes is defined
-  using the standard binding for regulators found at
-  Documentation/devicetree/bindings/regulator/regulator.txt.
-
-Optional properties:
-- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
-
-  The valid names for regulators are:
-  tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
-tps: tps@24 {
-compatible = "ti,tps65217";
-ti,pmic-shutdown-controller;
-
-regulators {
-dcdc1_reg: dcdc1 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <180>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-dcdc2_reg: dcdc2 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-dcdc3_reg: dcc3 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <150>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo1_reg: ldo1 {
-regulator-min-microvolt = <100>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo2_reg: ldo2 {
-regulator-min-microvolt = <90>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo3_reg: ldo3 {
-regulator-min-microvolt = <180>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-
-ldo4_reg: ldo4 {
-regulator-min-microvolt = <180>;
-regulator-max-microvolt = <330>;
-regulator-boot-on;
-regulator-always-on;
-};
-};
-};
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index fec7834..0c4bde0 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -285,10 +285,8 @@
  };
  };

-
-/include/ "tps65217.dtsi"
-
   {
+compatible = "ti,tps65217";
  /*
   * Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
   * mode") at poweroff.  Most BeagleBone versions do not support RTC-only
@@ -309,12 +307,17 @@
  ti,pmic-shutdown-controller;

  regulators {
+#address-cells = <1>;
+#size-cells = <0>;
+
  dcdc1_reg: regulator@0 {
+reg = <0>;
   

[PATCH v3 00/10] Add tune support of Mediatek MMC driver

[Chaotian Jing]

Change in v3:
Fix checkpatch errors and warnings for patch 8
Split patch 9, make DT parts enabling hw reset separately

Change in v2:
Drop the 400mhz and use assigned-clock-parents to instead
Split the original tune patch to several independent patches
Re-write the mmc_send_tuning()
Fix GPD checksum error
Move the HS400 setting to ops->prepare_hs400_tuning()   
Modify SD driving settings

Change in v1:
Add DT bindings for eMMC hardware reset
Add pinctrl of data strobe pin for HS400 mode
Modify eMMC driving settings
Add 400mhz source clock for HS400 mode
Add eMMC HS200/HS400 mode support
Add SD SDR50/SDR104 mode support
Add implement of tune function with CMD19/CMD21

Chaotian Jing (10):
  mmc: core: Add DT bindings for eMMC hardware reset support
  mmc: dt-bindings: update Mediatek MMC bindings
  mmc: mediatek: make cmd_ints_mask to const
  mmc: mediatek: change the argument "ddr" to "timing"
  mmc: mediatek: fix got GPD checksum error interrupt when data transfer
  mmc: mediatek: add implement of ops->hw_reset()
  arm64: dts: mediatek: add eMMC hw reset support
  mmc: mmc: extend the mmc_send_tuning()
  mmc: mediatek: add HS400 support
  arm64: dts: mediatek: add HS200/HS400/SDR50/SDR104 support

 Documentation/devicetree/bindings/mmc/mmc.txt|   1 +
 Documentation/devicetree/bindings/mmc/mtk-sd.txt |  11 +-
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts  |  27 +-
 drivers/mmc/core/host.c  |   2 +
 drivers/mmc/core/mmc_ops.c   |   8 +-
 drivers/mmc/host/dw_mmc-exynos.c |   4 +-
 drivers/mmc/host/dw_mmc.c|   2 +-
 drivers/mmc/host/dw_mmc.h|   2 +-
 drivers/mmc/host/mtk-sd.c| 304 ---
 drivers/mmc/host/sdhci-esdhc-imx.c   |   6 +-
 drivers/mmc/host/sdhci-msm.c |   2 +-
 drivers/mmc/host/sdhci-sirf.c|   2 +-
 include/linux/mmc/core.h |   2 +-
 13 files changed, 322 insertions(+), 51 deletions(-)

-- 
1.8.1.1.dirty

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

[PATCH v3 03/10] mmc: mediatek: make cmd_ints_mask to const

[Chaotian Jing]

cmd_ints_mask and data_ints_mask are constant value,
so make it to const

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index b2e89d3..8b3e15d 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -353,7 +353,10 @@ static void msdc_reset_hw(struct msdc_host *host)
 static void msdc_cmd_next(struct msdc_host *host,
struct mmc_request *mrq, struct mmc_command *cmd);
 
-static u32 data_ints_mask = MSDC_INTEN_XFER_COMPL | MSDC_INTEN_DATTMO |
+static const u32 cmd_ints_mask = MSDC_INTEN_CMDRDY | MSDC_INTEN_RSPCRCERR |
+   MSDC_INTEN_CMDTMO | MSDC_INTEN_ACMDRDY |
+   MSDC_INTEN_ACMDCRCERR | MSDC_INTEN_ACMDTMO;
+static const u32 data_ints_mask = MSDC_INTEN_XFER_COMPL | MSDC_INTEN_DATTMO |
MSDC_INTEN_DATCRCERR | MSDC_INTEN_DMA_BDCSERR |
MSDC_INTEN_DMA_GPDCSERR | MSDC_INTEN_DMA_PROTECT;
 
@@ -725,10 +728,7 @@ static bool msdc_cmd_done(struct msdc_host *host, int 
events,
if (done)
return true;
 
-   sdr_clr_bits(host->base + MSDC_INTEN, MSDC_INTEN_CMDRDY |
-   MSDC_INTEN_RSPCRCERR | MSDC_INTEN_CMDTMO |
-   MSDC_INTEN_ACMDRDY | MSDC_INTEN_ACMDCRCERR |
-   MSDC_INTEN_ACMDTMO);
+   sdr_clr_bits(host->base + MSDC_INTEN, cmd_ints_mask);
 
if (cmd->flags & MMC_RSP_PRESENT) {
if (cmd->flags & MMC_RSP_136) {
@@ -818,10 +818,7 @@ static void msdc_start_command(struct msdc_host *host,
rawcmd = msdc_cmd_prepare_raw_cmd(host, mrq, cmd);
mod_delayed_work(system_wq, >req_timeout, DAT_TIMEOUT);
 
-   sdr_set_bits(host->base + MSDC_INTEN, MSDC_INTEN_CMDRDY |
-   MSDC_INTEN_RSPCRCERR | MSDC_INTEN_CMDTMO |
-   MSDC_INTEN_ACMDRDY | MSDC_INTEN_ACMDCRCERR |
-   MSDC_INTEN_ACMDTMO);
+   sdr_set_bits(host->base + MSDC_INTEN, cmd_ints_mask);
writel(cmd->arg, host->base + SDC_ARG);
writel(rawcmd, host->base + SDC_CMD);
 }
-- 
1.8.1.1.dirty

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

[PATCH v3 10/10] arm64: dts: mediatek: add HS200/HS400/SDR50/SDR104 support

[Chaotian Jing]

add HS200/HS400 support for eMMC
add SDR50/SDR104 support for SD

Signed-off-by: Chaotian Jing 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 6d79ffc..a061221 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -70,11 +70,16 @@
pinctrl-0 = <_pins_default>;
pinctrl-1 = <_pins_uhs>;
bus-width = <8>;
-   max-frequency = <5000>;
+   max-frequency = <2>;
cap-mmc-highspeed;
+   mmc-hs200-1_8v;
+   mmc-hs400-1_8v;
cap-mmc-hw-reset;
+   hs400-ds-delay = <0x14015>;
vmmc-supply = <_vemc_3v3_reg>;
vqmmc-supply = <_vio18_reg>;
+   assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
+   assigned-clock-parents = < CLK_TOP_MSDCPLL_D2>;
non-removable;
 };
 
@@ -84,9 +89,10 @@
pinctrl-0 = <_pins_default>;
pinctrl-1 = <_pins_uhs>;
bus-width = <4>;
-   max-frequency = <5000>;
+   max-frequency = <2>;
cap-sd-highspeed;
-   sd-uhs-sdr25;
+   sd-uhs-sdr50;
+   sd-uhs-sdr104;
cd-gpios = < 132 0>;
vmmc-supply = <_vmch_reg>;
vqmmc-supply = <_vmc_reg>;
@@ -155,13 +161,19 @@
 ,
 ;
input-enable;
-   drive-strength = ;
+   drive-strength = ;
bias-pull-up = ;
};
 
pins_clk {
pinmux = ;
-   drive-strength = ;
+   drive-strength = ;
+   bias-pull-down = ;
+   };
+
+   pins_ds {
+   pinmux = ;
+   drive-strength = ;
bias-pull-down = ;
};
 
@@ -179,13 +191,13 @@
 ,
 ;
input-enable;
-   drive-strength = ;
+   drive-strength = ;
bias-pull-up = ;
};
 
pins_clk {
pinmux = ;
-   drive-strength = ;
+   drive-strength = ;
bias-pull-down = ;
};
};
-- 
1.8.1.1.dirty

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

[PATCH v3 02/10] mmc: dt-bindings: update Mediatek MMC bindings

[Chaotian Jing]

Add 400Mhz clock source for HS400 mode

Signed-off-by: Chaotian Jing 
---
 Documentation/devicetree/bindings/mmc/mtk-sd.txt | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index a1adfa4..0120c7f 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -17,6 +17,11 @@ Required properties:
 - vmmc-supply: power to the Core
 - vqmmc-supply: power to the IO
 
+Optional properties:
+- assigned-clocks: PLL of the source clock
+- assigned-clock-parents: parent of source clock, used for HS400 mode to get 
400Mhz source clock
+- hs400-ds-delay: HS400 DS delay setting
+
 Examples:
 mmc0: mmc@1123 {
compatible = "mediatek,mt8173-mmc", "mediatek,mt8135-mmc";
@@ -24,9 +29,13 @@ mmc0: mmc@1123 {
interrupts = ;
vmmc-supply = <_vemc_3v3_reg>;
vqmmc-supply = <_vio18_reg>;
-   clocks = < CLK_PERI_MSDC30_0>, < 
CLK_TOP_MSDC50_0_H_SEL>;
+   clocks = < CLK_PERI_MSDC30_0>,
+< CLK_TOP_MSDC50_0_H_SEL>;
clock-names = "source", "hclk";
pinctrl-names = "default", "state_uhs";
pinctrl-0 = <_pins_default>;
pinctrl-1 = <_pins_uhs>;
+   assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
+   assigned-clock-parents = < CLK_TOP_MSDCPLL_D2>;
+   hs400-ds-delay = <0x14015>;
 };
-- 
1.8.1.1.dirty

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

[PATCH v3 08/10] mmc: mmc: extend the mmc_send_tuning()

[Chaotian Jing]

The mmc_execute_tuning() has already prepared the opcode,
there is no need to prepare it again at mmc_send_tuning(),
and, there is a BUG of mmc_send_tuning() to determine the opcode
by bus width, assume eMMC was running at HS200, 4bit mode,
then the mmc_send_tuning() will overwrite the opcode from CMD21
to CMD19, then got error.

in addition, extend an argument of "cmd_error" to allow getting
if there was cmd error when tune response.

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/core/mmc_ops.c | 8 
 drivers/mmc/host/dw_mmc-exynos.c   | 4 ++--
 drivers/mmc/host/dw_mmc.c  | 2 +-
 drivers/mmc/host/dw_mmc.h  | 2 +-
 drivers/mmc/host/sdhci-esdhc-imx.c | 6 +++---
 drivers/mmc/host/sdhci-msm.c   | 2 +-
 drivers/mmc/host/sdhci-sirf.c  | 2 +-
 include/linux/mmc/core.h   | 2 +-
 8 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 0e9ae1c..4305f75 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -589,7 +589,7 @@ int mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 
value,
 }
 EXPORT_SYMBOL_GPL(mmc_switch);
 
-int mmc_send_tuning(struct mmc_host *host)
+int mmc_send_tuning(struct mmc_host *host, u32 opcode, int *cmd_error)
 {
struct mmc_request mrq = {NULL};
struct mmc_command cmd = {0};
@@ -599,16 +599,13 @@ int mmc_send_tuning(struct mmc_host *host)
const u8 *tuning_block_pattern;
int size, err = 0;
u8 *data_buf;
-   u32 opcode;
 
if (ios->bus_width == MMC_BUS_WIDTH_8) {
tuning_block_pattern = tuning_blk_pattern_8bit;
size = sizeof(tuning_blk_pattern_8bit);
-   opcode = MMC_SEND_TUNING_BLOCK_HS200;
} else if (ios->bus_width == MMC_BUS_WIDTH_4) {
tuning_block_pattern = tuning_blk_pattern_4bit;
size = sizeof(tuning_blk_pattern_4bit);
-   opcode = MMC_SEND_TUNING_BLOCK;
} else
return -EINVAL;
 
@@ -639,6 +636,9 @@ int mmc_send_tuning(struct mmc_host *host)
 
mmc_wait_for_req(host, );
 
+   if (cmd_error)
+   *cmd_error = cmd.error;
+
if (cmd.error) {
err = cmd.error;
goto out;
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 1e75309..3a7e835 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -446,7 +446,7 @@ out:
return loc;
 }
 
-static int dw_mci_exynos_execute_tuning(struct dw_mci_slot *slot)
+static int dw_mci_exynos_execute_tuning(struct dw_mci_slot *slot, u32 opcode)
 {
struct dw_mci *host = slot->host;
struct dw_mci_exynos_priv_data *priv = host->priv;
@@ -461,7 +461,7 @@ static int dw_mci_exynos_execute_tuning(struct dw_mci_slot 
*slot)
mci_writel(host, TMOUT, ~0);
smpl = dw_mci_exynos_move_next_clksmpl(host);
 
-   if (!mmc_send_tuning(mmc))
+   if (!mmc_send_tuning(mmc, opcode, NULL))
candiates |= (1 << smpl);
 
} while (start_smpl != smpl);
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index fcbf552..be8441d 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1427,7 +1427,7 @@ static int dw_mci_execute_tuning(struct mmc_host *mmc, 
u32 opcode)
int err = -EINVAL;
 
if (drv_data && drv_data->execute_tuning)
-   err = drv_data->execute_tuning(slot);
+   err = drv_data->execute_tuning(slot, opcode);
return err;
 }
 
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 8ce4674..394340f 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -281,7 +281,7 @@ struct dw_mci_drv_data {
void(*prepare_command)(struct dw_mci *host, u32 *cmdr);
void(*set_ios)(struct dw_mci *host, struct mmc_ios *ios);
int (*parse_dt)(struct dw_mci *host);
-   int (*execute_tuning)(struct dw_mci_slot *slot);
+   int (*execute_tuning)(struct dw_mci_slot *slot, u32 opcode);
int (*prepare_hs400_tuning)(struct dw_mci *host,
struct mmc_ios *ios);
int (*switch_voltage)(struct mmc_host *mmc,
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 886d230..1f1582f 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -759,7 +759,7 @@ static int esdhc_executing_tuning(struct sdhci_host *host, 
u32 opcode)
min = ESDHC_TUNE_CTRL_MIN;
while (min < ESDHC_TUNE_CTRL_MAX) {
esdhc_prepare_tuning(host, min);
-   if (!mmc_send_tuning(host->mmc))
+   if (!mmc_send_tuning(host->mmc, opcode, NULL))
break;
 

Re: [PATCH v4 1/7] usb: gadget: f_midi: Transmit data only when IN ep is enabled

[Robert Baldyga]

On 10/26/2015 11:49 PM, Felipe Tonello wrote:
> Hi Robert,
> 
> On Mon, Oct 26, 2015 at 10:13 PM, Robert Baldyga
>  wrote:
>> Hi Felipe,
>>
>> On 10/26/2015 05:55 PM, Felipe F. Tonello wrote:
>>> This makes sure f_midi doesn't try to enqueue data when the IN endpoint is
>>> disabled, ie, USB cable is disconnected.
>>>
>>> Signed-off-by: Felipe F. Tonello 
>>> ---
>>>  drivers/usb/gadget/function/f_midi.c | 7 ++-
>>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>>> b/drivers/usb/gadget/function/f_midi.c
>>> index edb84ca..e08f365 100644
>>> --- a/drivers/usb/gadget/function/f_midi.c
>>> +++ b/drivers/usb/gadget/function/f_midi.c
>>> @@ -87,6 +87,7 @@ struct f_midi {
>>>   int index;
>>>   char *id;
>>>   unsigned int buflen, qlen;
>>> + bool in_ep_enabled;
>>
>> It's not necessary, you can use ep->enabled flag instead.
> 
> There is no such flag in usb_ep struct[1].
> 
> [1] http://lxr.free-electrons.com/source/include/linux/usb/gadget.h#L170

It's already in next branch of Felipe Balbi's tree.

Look here:
https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/

Best regards,
Robert

> 
>>
>>>  };
>>>
>>>  static inline struct f_midi *func_to_midi(struct usb_function *f)
>>> @@ -332,6 +333,7 @@ static int f_midi_set_alt(struct usb_function *f, 
>>> unsigned intf, unsigned alt)
>>>   err = f_midi_start_ep(midi, f, midi->in_ep);
>>>   if (err)
>>>   return err;
>>> + midi->in_ep_enabled = true;
>>>
>>>   err = f_midi_start_ep(midi, f, midi->out_ep);
>>>   if (err)
>>> @@ -387,6 +389,8 @@ static void f_midi_disable(struct usb_function *f)
>>>*/
>>>   usb_ep_disable(midi->in_ep);
>>>   usb_ep_disable(midi->out_ep);
>>> +
>>> + midi->in_ep_enabled = false;
>>>  }
>>>
>>>  static int f_midi_snd_free(struct snd_device *device)
>>> @@ -543,7 +547,7 @@ static void f_midi_transmit(struct f_midi *midi, struct 
>>> usb_request *req)
>>>   }
>>>   }
>>>
>>> - if (req->length > 0) {
>>> + if (req->length > 0 && midi->in_ep_enabled) {
>>
>> You should rather test it at the beginning of this function. Or, even
>> better, when tasklet is scheduled, because tasklet is the only way this
>> function can be called when endpoints are disabled.
> 
> Not in this case, because this function needs to consume the triggered
> data from ALSA, otherwise a timeout will happen (which is worse).
> Of course this is not the best solution, but it is an incremental improvement.
> 
> Patch 7 has the proper solution, which checks this flag at the
> beginning of the function as expected. Also, it is more optimal
> because it drops all substreams buffers, instead of copying it.
> 
>>
>>>   int err;
>>>
>>>   err = usb_ep_queue(ep, req, GFP_ATOMIC);
>>> @@ -1158,6 +1162,7 @@ static struct usb_function *f_midi_alloc(struct 
>>> usb_function_instance *fi)
>>>   midi->index = opts->index;
>>>   midi->buflen = opts->buflen;
>>>   midi->qlen = opts->qlen;
>>> + midi->in_ep_enabled = false;
>>>   ++opts->refcnt;
>>>   mutex_unlock(>lock);
>>>
>>>
>>
> 
> Felipe
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

Re: [PATCH v2] libata: add support for NCQ commands for SG interface

[Vinayak Kale]

On Tue, Oct 27, 2015 at 11:46 AM, Tejun Heo  wrote:
> On Tue, Oct 27, 2015 at 11:19:15AM +0530, vinayak.k...@gmail.com wrote:
>> From: Vinayak Kale 
>>
>> This patch is needed to make NCQ commands with FPDMA protocol value
>> (eg READ/WRITE FPDMA) work over SCSI Generic (SG) interface.
>>
>> Signed-off-by: Vinayak Kale 
>
> Applied to libata/for-4.4.

Thanks Tejun :-)

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

Re: [PATCH 3/5] mm: clear PG_dirty to mark page freeable

[Minchan Kim]

On Mon, Oct 26, 2015 at 06:28:13PM -0700, Hugh Dickins wrote:
> On Mon, 19 Oct 2015, Minchan Kim wrote:
> 
> > Basically, MADV_FREE relies on dirty bit in page table entry
> > to decide whether VM allows to discard the page or not.
> > IOW, if page table entry includes marked dirty bit, VM shouldn't
> > discard the page.
> > 
> > However, as a example, if swap-in by read fault happens,
> > page table entry doesn't have dirty bit so MADV_FREE could discard
> > the page wrongly.
> > 
> > For avoiding the problem, MADV_FREE did more checks with PageDirty
> > and PageSwapCache. It worked out because swapped-in page lives on
> > swap cache and since it is evicted from the swap cache, the page has
> > PG_dirty flag. So both page flags check effectively prevent
> > wrong discarding by MADV_FREE.
> > 
> > However, a problem in above logic is that swapped-in page has
> > PG_dirty still after they are removed from swap cache so VM cannot
> > consider the page as freeable any more even if madvise_free is
> > called in future.
> > 
> > Look at below example for detail.
> > 
> > ptr = malloc();
> > memset(ptr);
> > ..
> > ..
> > .. heavy memory pressure so all of pages are swapped out
> > ..
> > ..
> > var = *ptr; -> a page swapped-in and could be removed from
> >swapcache. Then, page table doesn't mark
> >dirty bit and page descriptor includes PG_dirty
> > ..
> > ..
> > madvise_free(ptr); -> It doesn't clear PG_dirty of the page.
> > ..
> > ..
> > ..
> > .. heavy memory pressure again.
> > .. In this time, VM cannot discard the page because the page
> > .. has *PG_dirty*
> > 
> > To solve the problem, this patch clears PG_dirty if only the page
> > is owned exclusively by current process when madvise is called
> > because PG_dirty represents ptes's dirtiness in several processes
> > so we could clear it only if we own it exclusively.
> > 
> > Cc: Hugh Dickins 
> > Signed-off-by: Minchan Kim 
> 
> Acked-by: Hugh Dickins 
> 
> (and patches 1/5 and 2/5 too if you like)
> 

Thanks for the review, Hugh!

I will rebase all series from the beginning as you suggested
and will add your Acked-by because I feel you just reviewed
all of MADV_FREE code line and you have no found any problem.

If something happens(ie, I abuse your Acked-by) wrong, please
shout me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v12 4/6] QE/CPM: move muram management functions to qe_common

[Scott Wood]

On Tue, 2015-10-27 at 01:24 -0500, Zhao Qiang-B45475 wrote:
> On Tue, Oct 27, 2015 at 12:48 PM, Wood Scott-B07421 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, October 27, 2015 12:48 PM
> > To: Zhao Qiang-B45475 
> > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > pau...@samba.org
> > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management functions to
> > qe_common
> > 
> > On Sun, 2015-10-25 at 21:42 -0500, Zhao Qiang-B45475 wrote:
> > > On Sat, Oct 24, 2015 at 04:56 AM, Wood Scott-B07421 wrote:
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Saturday, October 24, 2015 4:56 AM
> > > > To: Zhao Qiang-B45475 
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > > b...@kernel.crashing.org; Li Yang-Leo-R58472 ;
> > > > pau...@samba.org
> > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> > functions
> > > > to qe_common
> > > > 
> > > > On Fri, 2015-10-23 at 02:45 -0500, Zhao Qiang-B45475 wrote:
> > > > > On Fri, 2015-10-23 at 11:10 AM, Wood Scott-B07421
> > > > > 
> > > > > wrote:
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Friday, October 23, 2015 11:10 AM
> > > > > > To: Zhao Qiang-B45475 
> > > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > > lau...@codeaurora.org; Xie Xiaobo-R63061 ;
> > > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472
> > > > > > ; pau...@samba.org
> > > > > > Subject: Re: [PATCH v12 4/6] QE/CPM: move muram management
> > > > functions
> > > > > > to qe_common
> > > > > > 
> > > > > > On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote:
> > > > > > > QE and CPM have the same muram, they use the same management
> > > > > > > functions. Now QE support both ARM and PowerPC, it is
> > > > > > > necessary to move QE to "driver/soc", so move the muram
> > > > > > > management functions from cpm_common to qe_common for
> > > > > > > preparing to move QE code to
> > > > "driver/soc"
> > > > > > > 
> > > > > > > Signed-off-by: Zhao Qiang 
> > > > > > > ---
> > > > > > > Changes for v2:
> > > > > > >   - no changes
> > > > > > > Changes for v3:
> > > > > > >   - no changes
> > > > > > > Changes for v4:
> > > > > > >   - no changes
> > > > > > > Changes for v5:
> > > > > > >   - no changes
> > > > > > > Changes for v6:
> > > > > > >   - using genalloc instead rheap to manage QE MURAM
> > > > > > >   - remove qe_reset from platform file, using
> > > > > > >   - subsys_initcall to call qe_init function.
> > > > > > > Changes for v7:
> > > > > > >   - move this patch from 3/3 to 2/3
> > > > > > >   - convert cpm with genalloc
> > > > > > >   - check for gen_pool allocation failure Changes for v8:
> > > > > > >   - rebase
> > > > > > >   - move BD_SC_* macro instead of copy Changes for v9:
> > > > > > >   - doesn't modify CPM, add a new patch to modify.
> > > > > > >   - rebase
> > > > > > > Changes for v10:
> > > > > > >   - rebase
> > > > > > > Changes for v11:
> > > > > > >   - remove renaming
> > > > > > >   - delete removing qe_reset and delete adding qe_init.
> > > > > > > Changes for v12:
> > > > > > >   - SPI_FSL_CPM depends on QE-MURAM, select QUICC_ENGINE for
> > it.
> > > > > > 
> > > > > > Why is the SPI change part of this patch?  Why is it even part
> > > > > > of this patchset, rather than an independent patch sent to the
> > > > > > SPI list and maintainer?  If it's tied to other changes you're
> > > > > > making, explain that.  As is, there is zero mention of the SPI
> > > > > > change in the part of the e-mail that will become the git 
> > > > > > changelog.
> > > > > > 
> > > > > This SPI_FSL_CPM is cpm-spi, it is part of CPM.
> > > > 
> > > > So then why are you selecting QUICC_ENGINE?  And again, what does it
> > > > have to do with this patch?
> > > 
> > > Cpm-spi is dependent on qe_muram, if not select it, Cpm-spi will
> > > failed to build.
> > 
> > Why QUICC_ENGINE and not CPM?
> 
> QE and CPM use the same muram, and it has been moved to qe_muram from 
> cpm_muram.

Fix the makefiles so that the muram code continues to be built for both 
QUICC_ENGINE and CPM.  It's not acceptable to have to bring in the entire QE 
code just for the muram.

-Scott

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

character driver - poll() timeout

[Muni Sekhar]

[ Please keep me in CC as I'm not subscribed to the list]

Hello,

Is it possible to print the timeout value in character driver poll() API?


User mode call: int poll(struct pollfd *fds, nfds_t nfds, int timeout)

Kernel mode call: unsigned int driver_poll(struct file *filp, poll_table *wait)


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

Re: [PATCH v4 3/7] usb: gadget: define free_ep_req as universal function

[Robert Baldyga]

On 10/26/2015 05:55 PM, Felipe F. Tonello wrote:
> This function is shared between gadget functions, so this avoid unnecessary
> duplicated code and potentially avoid memory leaks.
> 
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/function/f_midi.c   | 6 --
>  drivers/usb/gadget/function/f_sourcesink.c | 6 --
>  drivers/usb/gadget/function/g_zero.h   | 1 -
>  drivers/usb/gadget/u_f.c   | 8 
>  drivers/usb/gadget/u_f.h   | 3 +--
>  5 files changed, 9 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index c19f154..4c01c8a 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -202,12 +202,6 @@ static inline struct usb_request 
> *midi_alloc_ep_req(struct usb_ep *ep,
>   return alloc_ep_req(ep, length, length);
>  }
>  
> -static void free_ep_req(struct usb_ep *ep, struct usb_request *req)
> -{
> - kfree(req->buf);
> - usb_ep_free_request(ep, req);
> -}
> -
>  static const uint8_t f_midi_cin_length[] = {
>   0, 0, 2, 3, 3, 1, 2, 3, 3, 3, 3, 3, 2, 2, 3, 1
>  };
> diff --git a/drivers/usb/gadget/function/f_sourcesink.c 
> b/drivers/usb/gadget/function/f_sourcesink.c
> index 3a5ae99..eedea7f 100644
> --- a/drivers/usb/gadget/function/f_sourcesink.c
> +++ b/drivers/usb/gadget/function/f_sourcesink.c
> @@ -307,12 +307,6 @@ static inline struct usb_request *ss_alloc_ep_req(struct 
> usb_ep *ep, int len)
>   return alloc_ep_req(ep, len, buflen);
>  }
>  
> -void free_ep_req(struct usb_ep *ep, struct usb_request *req)
> -{
> - kfree(req->buf);
> - usb_ep_free_request(ep, req);
> -}
> -
>  static void disable_ep(struct usb_composite_dev *cdev, struct usb_ep *ep)
>  {
>   int value;
> diff --git a/drivers/usb/gadget/function/g_zero.h 
> b/drivers/usb/gadget/function/g_zero.h
> index 15f1809..5ed90b4 100644
> --- a/drivers/usb/gadget/function/g_zero.h
> +++ b/drivers/usb/gadget/function/g_zero.h
> @@ -59,7 +59,6 @@ void lb_modexit(void);
>  int lb_modinit(void);
>  
>  /* common utilities */
> -void free_ep_req(struct usb_ep *ep, struct usb_request *req);
>  void disable_endpoints(struct usb_composite_dev *cdev,
>   struct usb_ep *in, struct usb_ep *out,
>   struct usb_ep *iso_in, struct usb_ep *iso_out);
> diff --git a/drivers/usb/gadget/u_f.c b/drivers/usb/gadget/u_f.c
> index c6276f0..f78bd1f 100644
> --- a/drivers/usb/gadget/u_f.c
> +++ b/drivers/usb/gadget/u_f.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include "u_f.h"
>  
> +/* Requests allocated via alloc_ep_req() must be freed by free_ep_req(). */
>  struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len)
>  {
>   struct usb_request  *req;
> @@ -30,3 +31,10 @@ struct usb_request *alloc_ep_req(struct usb_ep *ep, int 
> len, int default_len)
>   return req;
>  }
>  EXPORT_SYMBOL_GPL(alloc_ep_req);
> +
> +void free_ep_req(struct usb_ep *ep, struct usb_request *req)
> +{
> + kfree(req->buf);
> + usb_ep_free_request(ep, req);
> +}
> +EXPORT_SYMBOL_GPL(free_ep_req);
> diff --git a/drivers/usb/gadget/u_f.h b/drivers/usb/gadget/u_f.h
> index 1d5f0eb..2a1a6fb 100644
> --- a/drivers/usb/gadget/u_f.h
> +++ b/drivers/usb/gadget/u_f.h
> @@ -46,7 +46,6 @@ struct usb_ep;
>  struct usb_request;
>  
>  struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int 
> default_len);
> +void free_ep_req(struct usb_ep *ep, struct usb_request *req);
>  
>  #endif /* __U_F_H__ */
> -
> -
> 

Isn't it simple enough to be static inline?

Best regards,
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/5] mm: simplify reclaim path for MADV_FREE

[Minchan Kim]

On Mon, Oct 26, 2015 at 07:09:15PM -0700, Hugh Dickins wrote:
> On Mon, 19 Oct 2015, Minchan Kim wrote:
> 
> > I made reclaim path mess to check and free MADV_FREEed page.
> > This patch simplify it with tweaking add_to_swap.
> > 
> > So far, we mark page as PG_dirty when we add the page into
> > swap cache(ie, add_to_swap) to page out to swap device but
> > this patch moves PG_dirty marking under try_to_unmap_one
> > when we decide to change pte from anon to swapent so if
> > any process's pte has swapent for the page, the page must
> > be swapped out. IOW, there should be no funcional behavior
> > change. It makes relcaim path really simple for MADV_FREE
> > because we just need to check PG_dirty of page to decide
> > discarding the page or not.
> > 
> > Other thing this patch does is to pass TTU_BATCH_FLUSH to
> > try_to_unmap when we handle freeable page because I don't
> > see any reason to prevent it.
> > 
> > Cc: Hugh Dickins 
> > Cc: Mel Gorman 
> > Signed-off-by: Minchan Kim 
> 
> Acked-by: Hugh Dickins 
> 
> This is sooo much nicer than the code it replaces!  Really good.

Thanks!

> Kudos also to Hannes for suggesting this approach originally, I think.

I should buy beer or soju if Hannes likes.

> 
> I hope this implementation satisfies a good proportion of the people
> who have been wanting MADV_FREE: I'm not among them, and have long
> lost touch with those discussions, so won't judge how usable it is.
> 
> I assume you'll refactor the series again before it goes to Linus,
> so the previous messier implementations vanish?  I notice Andrew

Actutally, I didn't think about that but once you mentioned it,
I realized that would be better. Thanks for the suggestion.

> has this "mm: simplify reclaim path for MADV_FREE" in mmotm as
> mm-dont-split-thp-page-when-syscall-is-called-fix-6.patch:
> I guess it all got much too messy to divide up in a hurry.

Yeb, I will rebase all series from the beginning based on recent mmtom
so I will vanish the mess in git-blame.

When I rebases it in mmotm, I will do it before reaching THP refcount
new design if Andrew and Kirill don't mind it because it makes to fail
my test as I reported. I don't know it's long time unknown bug or
something THP-ref new introduces. Anyway, I want to test smoothly.

> 
> I've noticed no problems in testing (unlike the first time you moved
> to working with pte_dirty); though of course I've not been using

Thanks for testing!

> MADV_FREE itself at all.
> 
> One aspect has worried me for a while, but I think I've reached the
> conclusion that it doesn't matter at all.  The swap that's allocated
> in add_to_swap() would normally get freed again (after try_to_unmap
> found it was a MADV_FREE !pte_dirty !PageDirty case) at the bottom
> of shrink_page_list(), in __remove_mapping(), yes?

Right.

> 
> The bit that worried me is that on rare occasions, something unknown
> might take a speculative reference to the page, and __remove_mapping()
> fail to freeze refs for that reason.  Much too rare to worry over not
> freeing that page immediately, but it leaves us with a PageUptodate
> PageSwapCache !PageDirty page, yet its contents are not the contents
> of that location on swap.
> 
> But since this can only happen when you have *not* inserted the
> corresponding swapent anywhere, I cannot think of anything that would
> have a legitimate interest in its contents matching that location on swap.
> So I don't think it's worth looking for somewhere to add a SetPageDirty
> (or a delete_from_swap_cache) just to regularize that case.


Exactly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] bindings for hisilicon hi6220 iommu driver

[Chen Feng]

docs: iommu: Documentation for iommu in hi6220 SoC.

Signed-off-by: Chen Feng 
Signed-off-by: Yu Dongbin 
---
 .../bindings/iommu/hisi,hi6220-iommu.txt   | 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt 
b/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
new file mode 100644
index 000..756e64f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
@@ -0,0 +1,56 @@
+Hi6220 SoC SMMU Device Driver devicetree document
+===
+The Architecture of SMMU on Hi6220 SoC:
+
+   +--+
+   |  |
+   | +-+  ++  +-+   +---+ |
+   | |   ADE   |  |  ISP   |  |  V/J codec  |   |  G3D  | |
+   | +|+  +---|+  +--|--+   +---|---| |
+   |  |   |  |  | |
+   | -v---v--v--v-|
+   |   Media Bus  |
+   | |---||
+   | |   ||
+   | +---v---v+   |
+   | |SMMU|   |
+   | +--|-|---+   |
+   || |   |
+   +|-|---+
+| |
+   +v-v---+
+   |  DDRC|
+   +--+
+
+Note:
+The media system shared the same smmu IP to access DDR memory. And all
+media IP used the same page table.
+
+Below binding describes the system mmu for media system in hi6220 platform
+
+Required properties:
+- compatible: should contain "hisilicon,hi6220-smmu".
+- reg: A tuple of base address and size of System MMU registers.
+- clocks: a list of phandle + clock-specifier pairs, one for each entry
+  in clock-names.
+- clock-names: should contain:
+  * "smmu"
+  * "media-sc"
+  * "smmu-peri"
+- interrupts: An interrupt specifier for interrupt signal of System MMU.
+- #iommu-cells: The iommu-cells should be 0. Because no additional information
+  needs to be encoded in the specifier.
+
+Examples:
+   iommu@f421 {
+   compatible = "hisilicon,hi6220-smmu";
+   reg = <0x0 0xf421 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_ctrl HI6220_MMU_CLK>,
+<_ctrl HI6220_MED_MMU>,
+<_ctrl HI6220_MEDIA_PLL_SRC>;
+   clock-names = "smmu",
+ "media-sc",
+ "smmu-peri";
+   #iommu-cells = <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/

Re: [PATCH 1/1] kthread: introduce kthread_get_run() to fix __nbd_ioctl()

[Markus Pargmann]

Hi,

On Mon, Oct 26, 2015 at 05:26:42PM -0700, Christoph Hellwig wrote:
> On Sun, Oct 25, 2015 at 03:27:13PM +0100, Oleg Nesterov wrote:
> > It is not safe to use the task_struct returned by kthread_run(threadfn)
> > if threadfn() can exit before the "owner" does kthread_stop(), nothing
> > protects this task_struct.
> > 
> > So __nbd_ioctl() looks buggy; a killed nbd_thread_send() can exit, free
> > its task_struct, and then kthread_stop() can use the freed/reused memory.
> > 
> > Add the new trivial helper, kthread_get_run(). Hopefully it will have more
> > users, this patch changes __nbd_ioctl() as an example.
> 
> This looks horrible.  I think the real problem is that nbd is totally
> abusing signals for kthreads and that needs to go away.

To avoid this kthread_get_run() we can change the NBD code as well to
guarantee that the thread does not exit until kthread_stop() was called.
I think that is independent of using signals.

Currently NBD uses signals for the timeout handling to get the threads
out of the TCP operations. Do you have an idea how to solve this
differently?

Best Regards,

Markus

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


signature.asc
Description: PGP signature

Re: [PATCH v3 7/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs

[Jiang Liu]

On 2015/10/27 7:15, ja...@microsoft.com wrote:
> From: Jake Oshins 
> 
> This patch introduces a new driver which exposes a root PCI bus whenever a PCI
> Express device is passed through to a guest VM under Hyper-V. The device can
> be single- or multi-function. The interrupts for the devices are managed by an
> IRQ domain, implemented within the driver.
> 
> Signed-off-by: Jake Oshins 
> ---

> +
> +/**
> + * hv_pcie_init_irq_domain() - Initialize IRQ domain
> + * @hbus:The root PCI bus
> + *
> + * Return: '0' on success and error value on failure
> + */
> +static int hv_pcie_init_irq_domain(struct hv_pcibus_device *hbus)
> +{
> + hbus->msi_info.chip = _msi_irq_chip;
> + hbus->msi_info.chip_data = hbus;
> + hbus->msi_info.ops = _msi_ops;
> + hbus->msi_info.flags = (MSI_FLAG_USE_DEF_DOM_OPS |
> + MSI_FLAG_USE_DEF_CHIP_OPS | MSI_FLAG_MULTI_PCI_MSI |
> + MSI_FLAG_PCI_MSIX);
When interrupt remapping is not supported, x86 vector allocator
can't support multiple MSI because it can't allocate continuous
vectors yet. So please confirm whether we could enable
MSI_FLAG_MULTI_PCI_MSI for HV.

> + hbus->msi_info.handler = handle_edge_irq;
> + hbus->msi_info.handler_name = "edge";
> + hbus->msi_info.data = hbus;
How about using following pattern so we could avoid exporting
too many interfaces?

struct irq_domain *parent_domain = NULL;
hbus->msi_info.chip = _msi_irq_chip;
hbus->msi_info.ops = _msi_ops;
// Let arch code to fill in default ops for chip and domain
x86_setup_default_msi_irqdomian_info(>msi_info, _domain);
// Override default ops if not applicable
hbus->irq_domain = pci_msi_create_irq_domain(hbus->fwnode,
 >msi_info,
 parent_domain);

> + hbus->irq_domain = pci_msi_create_irq_domain(hbus->fwnode,
> +  >msi_info,
> +  x86_vector_domain);
> + if (!hbus->irq_domain) {
> + pr_err("Failed to build an MSI IRQ domain\n");
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/19] staging/wilc1000 cleanups

[Tony Cho]

Hi Arnd,
I expect your opinion but I would like to make the patch to revert
the commit bcc43a4b5ed75285aeacf2cf8d9b96d6379fb429 if you don't mind
because the WILC1000 in staging still has compile errors.
Then, we had better make patch for your concerns.

I always appreciate your review and contribution.

Thanks,
Tony.

On 2015년 10월 23일 16:51, Tony Cho wrote:

Hi Arnd,
First of all, I would like to say "thank you" for your efforts and 
contributions.
We are updating the driver because new revision came up and making new 
patches
to make it stable and elegant as Linux driver. In these days, we are 
sending big changes

while testing such patches and also doing updates at once.

As you did, we are scheduled to provide the patches making device tree 
and delete all of platform
dependencies as you removed WILC_SDIO_IRQ_GPIO as well as other 
things. So, I would like to

discuss with you for your series of patch.

In this time, I think it's important to make the driver to be compiled 
even if the link problem
happens as you reported. So, how about deleting all of SPI related 
files from source tree and
even from Kconfig for the time being because new bus driver will come 
or revert

the Kconfig and then can we expect the best patch in the near feature?

I respect your efforts and patches, so your opinion is very important 
to me.


Thanks,
Tony.

On 2015년 10월 23일 10:37, glen lee wrote:


On 2015년 10월 22일 21:23, Arnd Bergmann wrote:

On Wednesday 21 October 2015 19:06:52 glen lee wrote:

Hi arnd,

Thanks for the all the patches.
About the patch ( use proper naming for global symbols ),
We are planning to use this driver not only for wilc1000 but also for
other atmel wireless driver. I'd appreciate if you could use wl 
instead of wilc1000.


And the global variable g_linux_wlan will be placed in netdevice 
private data
and finally it will be removed. I already posted some of those 
patches.

I couldn't find the patches anywhere, but I've updated my series now
to rename the symbols to wilc_* and to remove most but not all 
references to
g_linux_wlan (or wilc_dev after my rename). Do you want me to post 
those
so you can integrate them, or should I have a look at what you sent 
first

(please send me a copy then).


Hi arnd,

I have tested with all the patches you have posted but it does not 
works. firmware start timed out

in the function wilc1000_start_firmware.
I also have tested with all the patched without last one, [RFC] one, 
but it shows

Segmentation fault when insmod driver.
For now, I can't rebase the patches. I'd appreciate if you could help 
us.


The title of my first patch is,
[PATCH 01/13] staging: wilc1000: add wilc to netdev private data 
structure

and also refer to [PATCH 00/12] WILC1000 V2 for the g_linux_wlan
( The patches posted by tony@atmel.com )

By the way, deleting feature COMPLEMENT_BOOT patch already posted but 
not yet accepted.


Thank you.
Glen.


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 v3 5/7] PCI: irqdomain: Look up IRQ domain by fwnode_handle

[Jiang Liu]

On 2015/10/27 7:15, ja...@microsoft.com wrote:
> From: Jake Oshins 
> 
> The existing PCI code looks for an IRQ domain associated with a root PCI bus
> by looking in the Open Firmware tree.  This patch introduces a second way
> to identify the associated IRQ domain, if the lookup in the OF tree fails.
> The handle used for the IRQ domain lookup was introduced in the previous patch
> in the series.
> 
> Signed-off-by: Jake Oshins 
> ---
>  drivers/pci/probe.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index c0f2e44..62c9ac7 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -664,6 +664,7 @@ static void pci_set_bus_speed(struct pci_bus *bus)
>  static struct irq_domain *pci_host_bridge_msi_domain(struct pci_bus *bus)
>  {
>   struct irq_domain *d;
> + struct pci_host_bridge *host_bridge;
>  
>   /*
>* Any firmware interface that can resolve the msi_domain
> @@ -671,6 +672,18 @@ static struct irq_domain 
> *pci_host_bridge_msi_domain(struct pci_bus *bus)
>*/
>   d = pci_host_bridge_of_msi_domain(bus);
>  
> + /*
> +  * If no IRQ domain was found via the OF tree, try looking it up
> +  * directly through the fwnode_handle.
> +  */
> + if (!d) {
> + host_bridge = to_pci_host_bridge(bus->bridge);
> + if (host_bridge->fwnode) {
> + d = irq_find_matching_fwnode(host_bridge->fwnode,
> +  DOMAIN_BUS_ANY);
Should we use DOMAIN_BUS_PCI_MSI instead here?

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

Re: [PATCH 01/10] pwm: lpc18xx_pwm: use pwm_set_chip_data

[Olliver Schinagl]

Hey Ezequiel,

On October 26, 2015 10:58:18 PM CET, Ezequiel Garcia 
 wrote:
>(+ Ariel)
>
>Hi Oliver,
>
>Not sure why there's some many people in Cc for such a silly change.
>I guess you are using get_maintainers.pl on the entire patchset and get
>this rather long list.
>
I did indeed use the script and for v2 i'll split it up in several patches. The 
grouping that made sense to me was it was all pwm related. I'll do better next 
time. Sorry.

>IMO, the value of submitting patches as part of a larger series is to
>be able to
>push patches that need to be applied in some given order, or otherwise
>have some kind of logical relationship between them.
>
>However, this is not the case: it's just a very small change and has
>no relation to the rest of the patches in the series.
>I think a simple standalone patch would be better here.
>
>Also, get_maintainer.pl is just a hint, and not meant to be used as-is.
>In particular, you are missing the driver's author.
>
>On 26 October 2015 at 18:32, Olliver Schinagl
> wrote:
>> From: Olliver Schinagl 
>>
>> The lpc18xx driver currently manipulates the pwm_device struct
>directly
>> rather then using the pwm_set_chip_data. While the current method may
>> save a clock cycle or two, it is more obvious that data is set to the
>> chip pointer (especially since it is only a single int holding
>struct.
>>
>> Signed-off-by: Olliver Schinagl 
>> ---
>>  drivers/pwm/pwm-lpc18xx-sct.c | 11 +++
>>  drivers/pwm/pwm-sun4i.c   | 11 +++
>>  2 files changed, 18 insertions(+), 4 deletions(-)
>>
>
>...and this diffstat is obviously fishy.
It does.indeed, somehow i.must have accidentally merged two patches, stupid me. 
This.will also be addressed in the v2.

Olliver

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 0/3] mailbox: rockchip: Add mailbox driver for Rockchip platform

[Caesar Wang]

Mailbox is used by the Rockchip CPU cores to communicate
requests to MCU processor.

This driver is found on RK3368 SoCs.

The Mailbox module is a simple APB peripheral that allows both
the Cortex-A53 MCU system to communicate by writing operation to
generate interrupt.
The registers are accessible by both CPU via APB interface.

Tested on RK3368 SDK board.


Changes in v1:
- PATCH[1/3] doc:
- As the Rob Herring comments, s/share/shared/ and specify the value of 
#mbox-cells.
- Move the shared memory in mailbox, let's move the property the client
  driver in the future.
- PATCH[2/3] driver:
- The commit: %s/@/(num order).
- Add the module authors to instead of the notes.
- Add the COMPILE_TEST to auto compile test in Kconfig.
- Let the chan_to_idx() trys to instead of rockchip_mbox_chan.idx.
- Let's enable/disable the interrupt in startup/shutdown.
- Move the share memory and tx buf into the client drivers.
- PATCH[3/3] dts:
- fix "processormZ"--> "processor",the miss-fingerboard.
- Remove the shared memory in mailbox controller dtsi.

Caesar Wang (3):
  dt-bindings: rockchip-mailbox: Add mailbox controller document on
Rockchip SoCs
  mailbox: rockchip: Add Rockchip mailbox driver
  ARM64: dts: rk3368: Add mailbox device nodes

 .../bindings/mailbox/rockchip-mailbox.txt  |  32 +++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi   |  12 +
 drivers/mailbox/Kconfig|   9 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/rockchip-mailbox.c | 286 +
 5 files changed, 341 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
 create mode 100644 drivers/mailbox/rockchip-mailbox.c

-- 
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 v1 2/3] mailbox: rockchip: Add Rockchip mailbox driver

[Caesar Wang]

This driver is found on RK3368 SoCs.

The Mailbox module is a simple APB peripheral that allows both
the Cortex-A53 MCU system to communicate by writing operation to
generate interrupt.
The registers are accessible by both CPU via APB interface.

The Mailbox has the following main features:

1) Support dual-core system: Cortex-A53 and MCU.
2) Support APB interface.
3) Support four mailbox elements, each element includes one data word,
   one command word register and one flag bit that can represent
   one interrupt.
4) Four interrupts to Cortex-A53.
5) Four interrupts to MCU.
6) Provide 32 lock registers for software to use to indicate whether
   mailbox is occupied.

Signed-off-by: Caesar Wang 
---

Changes in v1:
- PATCH[2/3] driver:
- The commit: %s/@/(num order).
- Add the module authors to instead of the notes.
- Add the COMPILE_TEST to auto compile test in Kconfig.
- Let the chan_to_idx() trys to instead of rockchip_mbox_chan.idx.
- Let's enable/disable the interrupt in startup/shutdown.
- Move the share memory and tx buf into the client drivers.

 drivers/mailbox/Kconfig|   9 ++
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/rockchip-mailbox.c | 286 +
 3 files changed, 297 insertions(+)
 create mode 100644 drivers/mailbox/rockchip-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index bbec500..8b8d46e 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -43,6 +43,15 @@ config OMAP_MBOX_KFIFO_SIZE
  This can also be changed at runtime (via the mbox_kfifo_size
  module parameter).
 
+config ROCKCHIP_MBOX
+   bool "Rockchip Soc Intergrated Mailbox Support"
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
+   help
+ This driver provides support for inter-processor communication
+ between CPU cores and MCU processor on Some Rockchip SOCs.
+ Please check it that the Soc you use have Mailbox hardware.
+ Say Y here if you want to use the Rockchip Mailbox support.
+
 config PCC
bool "Platform Communication Channel Driver"
depends on ACPI
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 8e6d822..730cb5d 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -8,6 +8,8 @@ obj-$(CONFIG_PL320_MBOX)+= pl320-ipc.o
 
 obj-$(CONFIG_OMAP2PLUS_MBOX)   += omap-mailbox.o
 
+obj-$(CONFIG_ROCKCHIP_MBOX)+= rockchip-mailbox.o
+
 obj-$(CONFIG_PCC)  += pcc.o
 
 obj-$(CONFIG_ALTERA_MBOX)  += mailbox-altera.o
diff --git a/drivers/mailbox/rockchip-mailbox.c 
b/drivers/mailbox/rockchip-mailbox.c
new file mode 100644
index 000..5ccdc6b
--- /dev/null
+++ b/drivers/mailbox/rockchip-mailbox.c
@@ -0,0 +1,286 @@
+/*
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAILBOX_A2B_INTEN  0x00
+#define MAILBOX_A2B_STATUS 0x04
+#define MAILBOX_A2B_CMD(x) (0x08 + (x) * 8)
+#define MAILBOX_A2B_DAT(x) (0x0c + (x) * 8)
+
+#define MAILBOX_B2A_INTEN  0x28
+#define MAILBOX_B2A_STATUS 0x2C
+#define MAILBOX_B2A_CMD(x) (0x30 + (x) * 8)
+#define MAILBOX_B2A_DAT(x) (0x34 + (x) * 8)
+
+struct rockchip_mbox_msg {
+   u32 cmd;
+   int rx_size;
+};
+
+struct rockchip_mbox_data {
+   int num_chans;
+};
+
+struct rockchip_mbox_chan {
+   int idx;
+   int irq;
+   struct rockchip_mbox_msg *msg;
+   struct rockchip_mbox *mb;
+};
+
+struct rockchip_mbox {
+   struct mbox_controller mbox;
+   struct clk *pclk;
+   void __iomem *mbox_base;
+
+   /* The base address of share memory to transfer data */
+   void __iomem *buf_base;
+
+   /* The maximum size of buf for each channel */
+   u32 buf_size;
+
+   struct rockchip_mbox_chan *chans;
+};
+
+static int rockchip_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+   struct rockchip_mbox *mb = dev_get_drvdata(chan->mbox->dev);
+   struct rockchip_mbox_msg *msg = data;
+   struct rockchip_mbox_chan *chans = mb->chans;
+
+   if (!msg)
+   return -EINVAL;
+
+   if (msg->rx_size > mb->buf_size) {
+   dev_err(mb->mbox.dev, "Transmit size over buf size(%d)\n",
+   mb->buf_size);
+   return -EINVAL;
+   }
+
+   dev_dbg(mb->mbox.dev, "Chan[%d]: A2B 

[PATCH v1 3/3] ARM64: dts: rk3368: Add mailbox device nodes

[Caesar Wang]

This adds mailbox device nodes in dts.

Mailbox is used by the Rockchip CPU cores to communicate
requests to MCU processor.

Signed-off-by: Caesar Wang 
---

Changes in v1:
- PATCH[3/3] dts:
- fix "processormZ"--> "processor",the miss-fingerboard.
- Remove the shared memory in mailbox controller dtsi.

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index cc093a4..cefdad3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -484,6 +484,18 @@
status = "disabled";
};
 
+   mbox: mbox@ff6b {
+   compatible = "rockchip,rk3368-mailbox";
+   reg = <0x0 0xff6b 0x0 0x1000>,
+   interrupts = ,
+,
+,
+;
+   clocks = < PCLK_MAILBOX>;
+   clock-names = "pclk_mailbox";
+   #mbox-cells = <1>;
+   };
+
pmugrf: syscon@ff738000 {
compatible = "rockchip,rk3368-pmugrf", "syscon";
reg = <0x0 0xff738000 0x0 0x1000>;
-- 
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 v1 1/3] dt-bindings: rockchip-mailbox: Add mailbox controller document on Rockchip SoCs

[Caesar Wang]

This add the necessary binding documentation for mailbox
found on RK3368 SoC.

Signed-off-by: Caesar Wang 
---

Changes in v1:
- PATCH[1/3] doc:
- As the Rob Herring comments, s/share/shared/ and specify the value of 
#mbox-cells.
- Move the shared memory in mailbox, let's move the property the client
  driver in the future.

 .../bindings/mailbox/rockchip-mailbox.txt  | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
new file mode 100644
index 000..b6bb84a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
@@ -0,0 +1,32 @@
+Rockchip mailbox
+
+The Rockchip mailbox is used by the Rockchip CPU cores to communicate
+requests to MCU processor.
+
+Refer to ./mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+
+ - compatible: should be one of the following.
+   - "rockchip,rk3368-mbox" for rk3368
+ - 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.
+ - #mbox-cells: Common mailbox binding property to identify the number
+   of cells required for the mailbox specifier. Should be 1
+
+Example:
+
+
+/* RK3368 */
+mbox: mbox@ff6b {
+   compatible = "rockchip,rk3368-mailbox";
+   reg = <0x0 0xff6b 0x0 0x1000>,
+   interrupts = ,
+,
+,
+;
+   #mbox-cells = <1>;
+};
-- 
1.9.1

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

Re: [PATCH 4/5] mm: simplify reclaim path for MADV_FREE

[yalin wang]

> On Oct 27, 2015, at 15:09, Minchan Kim  wrote:
> 
> Hello Yalin,
> 
> Sorry for missing you in Cc list.
> IIRC, mails to send your previous mail address(yalin.w...@sonymobile.com)
> were returned.
> 
> You added comment bottom line so I'm not sure what PageDirty you meant.
> 
>> it is wrong here if you only check PageDirty() to decide if the page is 
>> freezable or not .
>> The Anon page are shared by multiple process, _mapcount > 1 ,
>> so you must check all pt_dirty bit during page_referenced() function,
>> see this mail thread:
>> http://ns1.ske-art.com/lists/kernel/msg1934021.html
> 
> If one of pte among process sharing the page was dirty, the dirtiness should
> be propagated from pte to PG_dirty by try_to_unmap_one.
> IOW, if the page doesn't have PG_dirty flag, it means all of process did
> MADV_FREE.
> 
> Am I missing something from you question?
> If so, could you show exact scenario I am missing?
> 
> Thanks for the interest.
oh, yeah , that is right , i miss that , pte_dirty will propagate to PG_dirty ,
so that is correct .
Generic to say this patch move set_page_dirty() from add_to_swap() to 
try_to_unmap(), i think can change a little about this patch:

@@ -1476,6 +1446,8 @@ static int try_to_unmap_one(struct page *page, struct 
vm_area_struct *vma,
ret = SWAP_FAIL;
goto out_unmap;
}
+   if (!PageDirty(page))
+   SetPageDirty(page);
if (list_empty(>mmlist)) {
spin_lock(_lock);
if (list_empty(>mmlist))

i think this 2 lines can be removed ,
since  pte_dirty have propagated to set_page_dirty() , we don’t need this line 
here ,
otherwise you will always dirty a AnonPage, even it is clean,
then we will page out this clean page to swap partition one more , this is not 
needed.
am i understanding correctly ?

By the way, please change my mail address to yalin.wang2...@gmail.com in CC 
list .
Thanks a lot. :) 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2] backlight: pm8941-wled: Add default-brightness property

[Rob Herring]

On Mon, Oct 26, 2015 at 12:45 PM, Bjorn Andersson
 wrote:
> Default the brightness to 2048 and add possibility to override this in
> device tree.
>
> Suggested-by: Rob Clark 
> Signed-off-by: Bjorn Andersson 
> ---
>
> Resend of v2, with updated backlight dt binding location.

Acked-by: Rob Herring 

>
>  Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt | 2 ++
>  drivers/video/backlight/pm8941-wled.c| 8 
>  2 files changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt 
> b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> index 424f8444a6cd..e5b294dafc58 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> @@ -5,6 +5,8 @@ Required properties:
>  - reg: slave address
>
>  Optional properties:
> +- default-brightness: brightness value on boot, value from: 0-4095
> +   default: 2048
>  - label: The name of the backlight device
>  - qcom,cs-out: bool; enable current sink output
>  - qcom,cabc: bool; enable content adaptive backlight control
> diff --git a/drivers/video/backlight/pm8941-wled.c 
> b/drivers/video/backlight/pm8941-wled.c
> index c704c3236034..e1298147bcbb 100644
> --- a/drivers/video/backlight/pm8941-wled.c
> +++ b/drivers/video/backlight/pm8941-wled.c
> @@ -17,6 +17,9 @@
>  #include 
>  #include 
>
> +/* From DT binding */
> +#define PM8941_WLED_DEFAULT_BRIGHTNESS 2048
> +
>  #define PM8941_WLED_REG_VAL_BASE   0x40
>  #define  PM8941_WLED_REG_VAL_MAX   0xFFF
>
> @@ -373,6 +376,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> struct backlight_device *bl;
> struct pm8941_wled *wled;
> struct regmap *regmap;
> +   u32 val;
> int rc;
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> @@ -395,8 +399,12 @@ static int pm8941_wled_probe(struct platform_device 
> *pdev)
> if (rc)
> return rc;
>
> +   val = PM8941_WLED_DEFAULT_BRIGHTNESS;
> +   of_property_read_u32(pdev->dev.of_node, "default-brightness", );
> +
> memset(, 0, sizeof(struct backlight_properties));
> props.type = BACKLIGHT_RAW;
> +   props.brightness = val;
> props.max_brightness = PM8941_WLED_REG_VAL_MAX;
> bl = devm_backlight_device_register(>dev, wled->name,
> >dev, wled,
> --
> 2.4.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] mtd: nand: drop unnecessary partition parser data

[Boris Brezillon]

On Mon, 26 Oct 2015 19:31:07 -0700
Brian Norris  wrote:

> All of these drivers set up a parser data struct just to communicate DT
> partition data. This field has been deprecated and is instead supported
> by telling nand_scan_ident() about the 'flash_node'.
> 
> This patch:
>  * sets chip->flash_node for those drivers that didn't already (but used
>OF partitioning)

As mentioned in patch 1, I think we should get rid of the ->flash_node
field and directly set mtd->dev.of_node instead. If we want to hide
MTD internals we could provide this kind of helper:

static inline void mtd_set_of_node(struct mtd_device *mtd,
   struct device_node *np)
{
mtd->dev.of_node = np;
}

>  * drops the parser data
>  * switches to the simpler mtd_device_register() where possible, now
>that we've eliminated one of the auxiliary parameters
> 
> Now that we've assigned chip->flash_node for these drivers, we can
> probably rely on nand_dt_init() to do more of the DT parsing for us, but
> for now, I don't want to fiddle with each of these drivers. The parsing
> is done in duplicate for now on some drivers. I don't think this should
> break things. (Famous last words.)
> 
> Signed-off-by: Brian Norris 

For the sunxi_nand driver

Acked-by: Boris Brezillon 

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: character driver - poll() timeout

[Clemens Ladisch]

Muni Sekhar wrote:
> Is it possible to print the timeout value in character driver poll() API?

No.  Your driver's poll callback never waits.

Why do you think you need this value?


Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] leds: leds-hp6xx: Use of devm_classdev_register

[Jacek Anaszewski]

Hi Fida,

Thanks for the patch. It doesn't apply smoothly, though.
Please rebase the patch on the top of LED git tree [1], for-next
branch.

[1] 
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git


Best Regards,
Jacek Anaszewski

On 10/26/2015 06:00 PM, Fida Mohammad wrote:

Use resource managed function devm_classdev_register to make
error path simpler. Also removed the redundant remove function.

Signed-off-by: Fida Mohammad 
---
  drivers/leds/leds-hp6xx.c | 15 ++-
  1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/leds/leds-hp6xx.c b/drivers/leds/leds-hp6xx.c
index 0b84c01..ffb6d5b 100644
--- a/drivers/leds/leds-hp6xx.c
+++ b/drivers/leds/leds-hp6xx.c
@@ -59,28 +59,17 @@ static int hp6xxled_probe(struct platform_device *pdev)
  {
int ret;

-   ret = led_classdev_register(>dev, _red_led);
+   ret = devm_led_classdev_register(>dev, _red_led);
if (ret < 0)
return ret;

-   ret = led_classdev_register(>dev, _green_led);
-   if (ret < 0)
-   led_classdev_unregister(_red_led);
+   return devm_led_classdev_register(>dev, _green_led);

-   return ret;
  }

-static int hp6xxled_remove(struct platform_device *pdev)
-{
-   led_classdev_unregister(_red_led);
-   led_classdev_unregister(_green_led);
-
-   return 0;
-}

  static struct platform_driver hp6xxled_driver = {
.probe  = hp6xxled_probe,
-   .remove = hp6xxled_remove,
.driver = {
.name   = "hp6xx-led",
},




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

[lkp] [of] db59ef4cdc:

[kernel test robot]

FYI, we noticed the below changes on

https://github.com/pantoniou/linux-beagle-track-mainline.git bbb-overlays
commit db59ef4cdc3261322ea61686e714b571ef709484 ("of: unittest: Unit-tests for 
target root overlays.")

We found some OF unittests errors in kernel log, while the line marked
with + is new after this commit.  This is intended? Or should be fixed?

[   10.536161] overlay_is_topmost: #5 clashes #6 
@/testcase-data/overlay-node/test-bus/test-unittest8
[   10.541601] overlay_removal_is_ok: overlay #5 is not topmost
[   10.542464] of_overlay_destroy: removal check failed for overlay #5
[   10.566327] find_target_node_direct: target 
"/testcase-data/overlay-node/test-bus/test-unittest18" not under target_root 
"/testcase-data/overlay-node/test-bus/test-unittest19"
[   10.570260] __of_overlay_create: of_build_overlay_info() failed for 
tree@/testcase-data/overlay19
[   10.609190] ### dt-test ### end of unittest - 152 passed, 0 failed

Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.3.0-rc6 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
CONFIG_TREE_RCU_TRACE=y
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_NOCB_CPU is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CGROUP_PERF is not set
# CONFIG_CGROUP_SCHED is not set
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
CONFIG_RD_LZMA=y
# CONFIG_RD_XZ is not set
CONFIG_RD_LZO=y
# CONFIG_RD_LZ4 is 

[PATCH 0/3] megaraid_sas: copule of fixes

[Weidong Wang]

Fix some checkpatch Warnings.
Fix a NULL pointer dereference.

As well kernel >=3.0.y will have the 'NULL pointer dereference'.

Weidong Wang (3):
  megaraid_sas: Convert dev_printk to dev_
  megaraid_sas: Convert printk to printk_
  megaraid_sas: return -ENOMEM when create DMA pool for cmd frames
failed

 drivers/scsi/megaraid/megaraid_sas_base.c | 83 ---
 1 file changed, 42 insertions(+), 41 deletions(-)

-- 
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 2/3] megaraid_sas: Convert printk to printk_

[Weidong Wang]

Reduce object size a little by using pr_
calls instead of printk(KERN_.

Signed-off-by: Weidong Wang 
---
 drivers/scsi/megaraid/megaraid_sas_base.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index ed9846d..2287aa1 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5889,7 +5889,7 @@ static int megasas_mgmt_fasync(int fd, struct file 
*filep, int mode)
return 0;
}
 
-   printk(KERN_DEBUG "megasas: fasync_helper failed [%d]\n", rc);
+   pr_debug("megasas: fasync_helper failed [%d]\n", rc);
 
return rc;
 }
@@ -6233,7 +6233,7 @@ static int megasas_mgmt_ioctl_aen(struct file *file, 
unsigned long arg)
u32 wait_time = MEGASAS_RESET_WAIT_TIME;
 
if (file->private_data != file) {
-   printk(KERN_DEBUG "megasas: fasync_helper was not "
+   pr_debug("megasas: fasync_helper was not "
   "called first\n");
return -EINVAL;
}
@@ -6355,7 +6355,7 @@ static int megasas_mgmt_compat_ioctl_fw(struct file 
*file, unsigned long arg)
 
if (copy_in_user(>frame.hdr.cmd_status,
 >frame.hdr.cmd_status, sizeof(u8))) {
-   printk(KERN_DEBUG "megasas: error copy_in_user cmd_status\n");
+   pr_debug("megasas: error copy_in_user cmd_status\n");
return -EFAULT;
}
return error;
@@ -6455,7 +6455,7 @@ megasas_sysfs_set_dbg_lvl(struct device_driver *dd, const 
char *buf, size_t coun
int retval = count;
 
if (sscanf(buf, "%u", _dbg_lvl) < 1) {
-   printk(KERN_ERR "megasas: could not set dbg_lvl\n");
+   pr_err("megasas: could not set dbg_lvl\n");
retval = -EINVAL;
}
return retval;
@@ -6480,7 +6480,7 @@ megasas_aen_polling(struct work_struct *work)
int error;
 
if (!instance) {
-   printk(KERN_ERR "invalid instance!\n");
+   pr_err("invalid instance!\n");
kfree(ev);
return;
}
@@ -6740,7 +6740,7 @@ static int __init megasas_init(void)
rval = register_chrdev(0, "megaraid_sas_ioctl", _mgmt_fops);
 
if (rval < 0) {
-   printk(KERN_DEBUG "megasas: failed to open device node\n");
+   pr_debug("megasas: failed to open device node\n");
return rval;
}
 
@@ -6752,7 +6752,7 @@ static int __init megasas_init(void)
rval = pci_register_driver(_pci_driver);
 
if (rval) {
-   printk(KERN_DEBUG "megasas: PCI hotplug registration failed 
\n");
+   pr_debug("megasas: PCI hotplug registration failed \n");
goto err_pcidrv;
}
 
-- 
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/

Re: [PATCH 0/8] mm: memcontrol: account socket memory in unified hierarchy

[Vladimir Davydov]

On Mon, Oct 26, 2015 at 01:22:16PM -0400, Johannes Weiner wrote:
> On Thu, Oct 22, 2015 at 09:45:10PM +0300, Vladimir Davydov wrote:
> > Hi Johannes,
> > 
> > On Thu, Oct 22, 2015 at 12:21:28AM -0400, Johannes Weiner wrote:
> > ...
> > > Patch #5 adds accounting and tracking of socket memory to the unified
> > > hierarchy memory controller, as described above. It uses the existing
> > > per-cpu charge caches and triggers high limit reclaim asynchroneously.
> > > 
> > > Patch #8 uses the vmpressure extension to equalize pressure between
> > > the pages tracked natively by the VM and socket buffer pages. As the
> > > pool is shared, it makes sense that while natively tracked pages are
> > > under duress the network transmit windows are also not increased.
> > 
> > First of all, I've no experience in networking, so I'm likely to be
> > mistaken. Nevertheless I beg to disagree that this patch set is a step
> > in the right direction. Here goes why.
> > 
> > I admit that your idea to get rid of explicit tcp window control knobs
> > and size it dynamically basing on memory pressure instead does sound
> > tempting, but I don't think it'd always work. The problem is that in
> > contrast to, say, dcache, we can't shrink tcp buffers AFAIU, we can only
> > stop growing them. Now suppose a system hasn't experienced memory
> > pressure for a while. If we don't have explicit tcp window limit, tcp
> > buffers on such a system might have eaten almost all available memory
> > (because of network load/problems). If a user workload that needs a
> > significant amount of memory is started suddenly then, the network code
> > will receive a notification and surely stop growing buffers, but all
> > those buffers accumulated won't disappear instantly. As a result, the
> > workload might be unable to find enough free memory and have no choice
> > but invoke OOM killer. This looks unexpected from the user POV.
> 
> I'm not getting rid of those knobs, I'm just reusing the old socket
> accounting infrastructure in an attempt to make the memory accounting
> feature useful to more people in cgroups v2 (unified hierarchy).
> 

My understanding is that in the meantime you effectively break the
existing per memcg tcp window control logic.

> We can always come back to think about per-cgroup tcp window limits in
> the unified hierarchy, my patches don't get in the way of this. I'm
> not removing the knobs in cgroups v1 and I'm not preventing them in v2.
> 
> But regardless of tcp window control, we need to account socket memory
> in the main memory accounting pool where pressure is shared (to the
> best of our abilities) between all accounted memory consumers.
> 

No objections to this point. However, I really don't like the idea to
charge tcp window size to memory.current instead of charging individual
pages consumed by the workload for storing socket buffers, because it is
inconsistent with what we have now. Can't we charge individual skb pages
as we do in case of other kmem allocations?

> From an interface standpoint alone, I don't think it's reasonable to
> ask users per default to limit different consumers on a case by case
> basis. I certainly have no problem with finetuning for scenarios you
> describe above, but with memory.current, memory.high, memory.max we
> are providing a generic interface to account and contain memory
> consumption of workloads. This has to include all major memory
> consumers to make semantical sense.

We can propose a reasonable default as we do in the global case.

> 
> But also, there are people right now for whom the socket buffers cause
> system OOM, but the existing memcg's hard tcp window limitq that
> exists absolutely wrecks network performance for them. It's not usable
> the way it is. It'd be much better to have the socket buffers exert
> pressure on the shared pool, and then propagate the overall pressure
> back to individual consumers with reclaim, shrinkers, vmpressure etc.
> 

This might or might not work. I'm not an expert to judge. But if you do
this only for memcg leaving the global case as it is, networking people
won't budge IMO. So could you please start such a major rework from the
global case? Could you please try to deprecate the tcp window limits not
only in the legacy memcg hierarchy, but also system-wide in order to
attract attention of networking experts?

Thanks,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/for-4.4] cgroup: fix race condition around termination check in css_task_iter_next()

[Tejun Heo]

css_task_iter_next() checked @it->cur_task before grabbing
css_set_lock and assumed that the result won't change afterwards;
however, tasks could leave the cgroup being iterated terminating the
iterator before css_task_lock is acquired.  If this happens,
css_task_iter_next() tries to calculate the current task from NULL
cg_list pointer leading to the following oops.

 BUG: unable to handle kernel paging request at f7d0
 IP: [] css_task_iter_next+0x42/0x80
 ...
 CPU: 4 PID: 6391 Comm: JobQDisp2 Not tainted 4.0.9-22_fbk4_rc3_81616_ge8d9cb6 
#1
 Hardware name: Quanta Freedom/Winterfell, BIOS F03_3B08 03/04/2014
 task: 880868e46400 ti: 88083404c000 task.ti: 88083404c000
 RIP: 0010:[]  [] 
css_task_iter_next+0x42/0x80
 RSP: 0018:88083404fd28  EFLAGS: 00010246
 RAX:  RBX: 88083404fd68 RCX: 8804697fb8b0
 RDX: f7c0 RSI: 8803b7dff800 RDI: 822c0278
 RBP: 88083404fd38 R08: 00017160 R09: 88046f4070c0
 R10: 810d61f7 R11: 0293 R12: 880863bf8400
 R13: 88046b87fd80 R14:  R15: 88083404fe58
 FS:  7fa0567e2700() GS:88046f90() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: f7d0 CR3: 000469568000 CR4: 001406e0
 Stack:
  0246  88083404fde8 810d6248
  88083404fd68  8803b7dff800 01ef01ee
    880863bf8568 
 Call Trace:
  [] cgroup_pidlist_start+0x258/0x550
  [] cgroup_seqfile_start+0x1d/0x20
  [] kernfs_seq_start+0x5f/0xa0
  [] seq_read+0x166/0x380
  [] kernfs_fop_read+0x11d/0x180
  [] __vfs_read+0x18/0x50
  [] vfs_read+0x8d/0x150
  [] SyS_read+0x4f/0xb0
  [] system_call_fastpath+0x12/0x17

Fix it by moving the termination condition check inside css_set_lock.
@it->cur_task is now cleared after being put and @it->task_pos is
tested for termination instead of @it->cset_pos as they indicate the
same condition and @it->task_pos is what's being dereferenced.

Signed-off-by: Tejun Heo 
Reported-by: Calvin Owens 
Fixes: ed27b9f7a17d ("cgroup: don't hold css_set_rwsem across css task 
iteration")
---
 kernel/cgroup.c |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3930,18 +3930,19 @@ void css_task_iter_start(struct cgroup_s
  */
 struct task_struct *css_task_iter_next(struct css_task_iter *it)
 {
-   if (!it->cset_pos)
-   return NULL;
-
-   if (it->cur_task)
+   if (it->cur_task) {
put_task_struct(it->cur_task);
+   it->cur_task = NULL;
+   }
 
spin_lock_bh(_set_lock);
 
-   it->cur_task = list_entry(it->task_pos, struct task_struct, cg_list);
-   get_task_struct(it->cur_task);
-
-   css_task_iter_advance(it);
+   if (it->task_pos) {
+   it->cur_task = list_entry(it->task_pos, struct task_struct,
+ cg_list);
+   get_task_struct(it->cur_task);
+   css_task_iter_advance(it);
+   }
 
spin_unlock_bh(_set_lock);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Roger Quadros]

Boris,

On 27/10/15 10:12, Boris Brezillon wrote:
> Hi Roger,
> 
> On Tue, 27 Oct 2015 10:03:02 +0200
> Roger Quadros  wrote:
> 
>> On 26/10/15 22:49, Brian Norris wrote:
>>>
>>> Others have been looking at using GPIOs for the ready/busy pin too. At a
>>> minimum, we need an updated DT binding doc for this, since I see you're
>>> adding this via device tree in a later patch (I don't see any DT binding
>>> patch for this; but I could just be overlooking it). It'd also be great
>>> if this support was moved to nand_dt_init() so other platforms can
>>> benefit, but I won't require that.
>>>
>>> Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio'
>>> (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't
>>> really care, but the name should be going into a doc, so we can choose
>>> the same one everywhere.
>>>
>>> EDIT: looks like the discussion was partly here [1] and it seems we're
>>> landing on "rb-gpios" in the latest version [2]. Can we stick with that?
>>
>> Why should it be "rb-gpios" and not "rb-gpio"?
>> I don't think there are multiple gpios for r/b# function.
> 
> Because it's supposed to be a generic binding, and some NAND chips
> embed several dies, thus exposing several CS and RB pins, hence the
> rb-gpios name.
> Also, as described here [1], the convention is to name your property
> -gpios even if you only need one gpio.

Makes sense now. Thanks for the explanation.
I'll update this patch to use rb-gpios and update the binding doc as well.

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

Re: [PATCH 07/10] pwm: gpio: Add a generic gpio based PWM driver

[Olliver Schinagl]

Hey Rob,

On October 27, 2015 8:42:48 AM CET, Rob Herring  wrote:
>On Mon, Oct 26, 2015 at 4:32 PM, Olliver Schinagl
> wrote:
>> From: Olliver Schinagl 
>>
>> This patch adds a bit-banging gpio PWM driver. It makes use of
>hrtimers,
>> to allow nano-second resolution, though it obviously strongly depends
>on
>> the switching speed of the gpio pins, hrtimer and system load.
>>
>> Each pwm node can have 1 or more "pwm-gpio" entries, which will be
>> treated as pwm's as part of a pwm chip.
>>
>> Signed-off-by: Olliver Schinagl 
>> ---
>>  Documentation/devicetree/bindings/pwm/pwm-gpio.txt |  18 ++
>>  MAINTAINERS|   5 +
>>  drivers/pwm/Kconfig|  15 ++
>>  drivers/pwm/Makefile   |   1 +
>>  drivers/pwm/pwm-gpio.c | 253
>+
>>  5 files changed, 292 insertions(+)
>>  create mode 100644
>Documentation/devicetree/bindings/pwm/pwm-gpio.txt
>>  create mode 100644 drivers/pwm/pwm-gpio.c
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/pwm-gpio.txt
>b/Documentation/devicetree/bindings/pwm/pwm-gpio.txt
>> new file mode 100644
>> index 000..336f61f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pwm/pwm-gpio.txt
>> @@ -0,0 +1,18 @@
>> +Generic GPIO bit-banged PWM driver
>> +
>> +Required properties:
>> +  - compatible: should be "pwm-gpio"
>> +  - #pwm-cells: should be 3, see pwm.txt in this directory for a
>general
>> +description of the cells format.
>> +  - pwm-gpios: one or more gpios describing the used gpio, see the
>gpio
>> +bindings for the used gpio driver.
>
>I'm not sure there is really much advantage to having multiple gpios
>per node. It would simplify the driver a bit not to, but I don't feel
>strongly either way.
I figured this way you have one (or more) gpio 'chips' and then per chip 1 or 
more outputs. I actually thing pne would use several gpios rather then several 
'chips'. Most hardware oprates the same way i thought.
>
>> +
>> +Example:
>> +#include 
>> +
>> +   pwm: pwm@0 {
>
>Unit address should be associated with a reg property, so drop it.
Done

>
>> +   compatible = "pwm-gpio";
>> +   #pwm-cells = 3;
>> +   pwm-gpios = < 7 1 GPIO_ACTIVE_LOW>;
>> +   pwm-gpios = < 7 2 GPIO_ACTIVE_LOW>;
>
>This would not actually compile. You can't have 2 properties of the
>same name.
A bad example is still a bug. Fixed.
>
>> +   };
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7ba7ab7..0ae7fbf 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -4555,6 +4555,11 @@ F:   drivers/i2c/muxes/i2c-mux-gpio.c
>>  F: include/linux/i2c-mux-gpio.h
>>  F: Documentation/i2c/muxes/i2c-mux-gpio
>>
>> +GENERIC GPIO PWM DRIVER
>> +M: Olliver Schinagl 
>> +S: Maintained
>> +F: drivers/pwm/pwm-gpio.c
>
>Can you add the binding doc too.
Sure, done.

>
>Rob

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] mm: simplify reclaim path for MADV_FREE

[yalin wang]

> On Oct 27, 2015, at 16:10, Minchan Kim  wrote:
> 
> On Tue, Oct 27, 2015 at 03:39:16PM +0800, yalin wang wrote:
>> 
>>> On Oct 27, 2015, at 15:09, Minchan Kim  wrote:
>>> 
>>> Hello Yalin,
>>> 
>>> Sorry for missing you in Cc list.
>>> IIRC, mails to send your previous mail address(yalin.w...@sonymobile.com)
>>> were returned.
>>> 
>>> You added comment bottom line so I'm not sure what PageDirty you meant.
>>> 
 it is wrong here if you only check PageDirty() to decide if the page is 
 freezable or not .
 The Anon page are shared by multiple process, _mapcount > 1 ,
 so you must check all pt_dirty bit during page_referenced() function,
 see this mail thread:
 http://ns1.ske-art.com/lists/kernel/msg1934021.html
>>> 
>>> If one of pte among process sharing the page was dirty, the dirtiness should
>>> be propagated from pte to PG_dirty by try_to_unmap_one.
>>> IOW, if the page doesn't have PG_dirty flag, it means all of process did
>>> MADV_FREE.
>>> 
>>> Am I missing something from you question?
>>> If so, could you show exact scenario I am missing?
>>> 
>>> Thanks for the interest.
>> oh, yeah , that is right , i miss that , pte_dirty will propagate to 
>> PG_dirty ,
>> so that is correct .
>> Generic to say this patch move set_page_dirty() from add_to_swap() to 
>> try_to_unmap(), i think can change a little about this patch:
>> 
>> @@ -1476,6 +1446,8 @@ static int try_to_unmap_one(struct page *page, struct 
>> vm_area_struct *vma,
>>  ret = SWAP_FAIL;
>>  goto out_unmap;
>>  }
>> +if (!PageDirty(page))
>> +SetPageDirty(page);
>>  if (list_empty(>mmlist)) {
>>  spin_lock(_lock);
>>  if (list_empty(>mmlist))
>> 
>> i think this 2 lines can be removed ,
>> since  pte_dirty have propagated to set_page_dirty() , we don’t need this 
>> line here ,
>> otherwise you will always dirty a AnonPage, even it is clean,
>> then we will page out this clean page to swap partition one more , this is 
>> not needed.
>> am i understanding correctly ?
> 
> Your understanding is correct.
> I will fix it in next spin.
> 
>> 
>> By the way, please change my mail address to yalin.wang2...@gmail.com in CC 
>> list .
>> Thanks a lot. :) 
> 
> Thanks for the review!

i have a look at the old mail list , i recall the scenario that multiple 
processes share a AnonPage 
special case :

for example Process A have a AnonPage map like this:
! pte_dirty() && PageDirty()==1   (this is possible after read fault 
happened on swap entry, and try_to_free_swap() succeed.)
Process A  do a fork() , New process is called B .
Then A  syscall(MADV_FREE) on the page .
At this time, page table like this:

A  ! pte_dirty() && PageDirty() == 0  && PageSwapCache() == 0

B ! pte_dirty() && PageDirty() == 0  && PageSwapCache() == 0

This means this page is freeable , and can be freed during page reclaim.
This is not fair for Process B . Since B don’t call syscall(MADV_FREE) ,
its page should not be discard .  Will cause some strange behaviour if happened 
.

This is discussed by 
http://www.serverphorums.com/read.php?12,1220840
but i don’t know why the patch is not merged .

Thanks 












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

[PATCH 0/2] Mediatek I2C driver fixup

[Liguo Zhang]

This series contain two patches, first is to optimize Mediatek I2C driver to 
use WRRD
if hardware support auto restart. Because auto restart will issue auto restart
interrupt, change to use WRRD can reduce interrupt latency. The second is to fix
multi transfer error in high speed mode. If hardware support auto restart, need 
driver
to send master code first.

Liguo Zhang (2):
  i2c: mediatek: add i2c first write then read optimization
  i2c: mediatek: fix i2c multi transfer issue in high speed mode

 drivers/i2c/busses/i2c-mt65xx.c | 77 +
 1 file changed, 71 insertions(+), 6 deletions(-)

--
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] input: Add keyreset driver.

[Dmitry Torokhov]

Hi Bálint,

On Tue, Oct 27, 2015 at 09:32:33AM +0100, Bálint Czobor wrote:
> From: Arve Hjønnevåg 
> 
> Add a platform device in the board file to specify a reset key-combo.
> The first time the key-combo is detected a work function that syncs
> the filesystems is scheduled. If all the keys are released and then
> pressed again, it calls panic. Reboot on panic should be set for
> this to work.

Mathieu Poirier integrated keyreset functionality into sysrq, see
3d289517dfd48f6487efda81543c3dda8b0e66f2 and
154b7a489a5b1d808323b933b04864958c2f1056

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regulator, dt: add dt support for tps6502x regulator

[Heiko Schocher]

Hello Mark,

Am 27.10.2015 um 03:12 schrieb Mark Brown:

On Mon, Oct 26, 2015 at 12:25:17PM +0100, Heiko Schocher wrote:

add DT support for the tps6502x regulators.


Please use subject lines matching the style for the subsystem.


Would be "regulator: tps6520x:" correct?


+   regulators = of_get_child_by_name(np, "regulators");
+   if (!regulators) {
+   dev_err(dev, "regulator node not found\n");
+   return NULL;
+   }


Please use the generic support for locating the DT information for
regulators using regulators_node and of_match in the regulator_desc
rather than open coding this.


Hmm.. could you point me to a correct example? Seems I overlook sth.

drivers/regulator/tps65090-regulator.c
drivers/regulator/tps65910-regulator.c
drivers/regulator/tps6507x-regulator.c
drivers/regulator/tps6586x-regulator.c

are doing it all the same way ...

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] mm: mark stable page dirty in KSM

[Minchan Kim]

On Mon, Oct 26, 2015 at 07:23:12PM -0700, Hugh Dickins wrote:
> On Mon, 19 Oct 2015, Minchan Kim wrote:
> 
> > Stable page could be shared by several processes and last process
> > could own the page among them after CoW or zapping for every process
> > except last process happens. Then, page table entry of the page
> > in last process can have no dirty bit and PG_dirty flag in page->flags.
> > In this case, MADV_FREE could discard the page wrongly.
> > For preventing it, we mark stable page dirty.
> 
> I agree with the change, but found that comment (repeated in the source)
> rather hard to follow.  And it doesn't really do justice to the changes
> you have made.
> 
> This is not now a MADV_FREE thing, it's more general than that, even
> if MADV_FREE is the only thing that takes advantage of it.  I like
> very much that you've made page reclaim sane, freeing non-dirty
> anonymous pages instead of swapping them out, without having to
> think of whether it's for MADV_FREE or not.
> 
> Would you mind if we replace your patch by a re-commented version?
> 
> [PATCH] mm: mark stable page dirty in KSM
> 
> The MADV_FREE patchset changes page reclaim to simply free a clean
> anonymous page with no dirty ptes, instead of swapping it out; but
> KSM uses clean write-protected ptes to reference the stable ksm page.
> So be sure to mark that page dirty, so it's never mistakenly discarded.
> 
> Signed-off-by: Minchan Kim 
> Signed-off-by: Hugh Dickins 

Looks better than mine.
I will include this in my patchset when I respin.

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

Re: [PATCH v3 4/7] PCI: Record an fwnode associated with root PCI buses, optionally

[Jiang Liu]

On 2015/10/27 7:15, ja...@microsoft.com wrote:
> From: Jake Oshins 
> 
> This patch allows a PCI front-end implementation to supply an fwnode_handle
> associated with a root PCI bus, optionally.  If supplied, the PCI driver
> records this.
> 
> This patch supports the next patch in the series, which looks up an IRQ domain
> through this handle.
Hi JaKeo,
Instead of changing the pci_create_root_bus() interface,
how about packing fwnode into sysdata, then we may
either 1) introduce a helper to retrieve fwnode from sysdata
or 2) set host_bridge->fwnode = sysdata in function
pcibios_root_bridge_prepare.

Thanks,
Gerry

> 
> Signed-off-by: Jake Oshins 
> ---
>  arch/sparc/kernel/pci.c   | 2 +-
>  drivers/acpi/pci_root.c   | 2 +-
>  drivers/parisc/lba_pci.c  | 2 +-
>  drivers/pci/host/pci-xgene.c  | 2 +-
>  drivers/pci/host/pcie-iproc.c | 3 ++-
>  drivers/pci/probe.c   | 8 +---
>  include/linux/pci.h   | 4 +++-
>  7 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
> index b91d7f1..3d4e9f9 100644
> --- a/arch/sparc/kernel/pci.c
> +++ b/arch/sparc/kernel/pci.c
> @@ -660,7 +660,7 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
>   pbm->busn.flags = IORESOURCE_BUS;
>   pci_add_resource(, >busn);
>   bus = pci_create_root_bus(parent, pbm->pci_first_busno, pbm->pci_ops,
> -   pbm, );
> +   pbm, , NULL);
>   if (!bus) {
>   printk(KERN_ERR "Failed to create bus for %s\n",
>  node->full_name);
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 850d7bf..eab95bc 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -840,7 +840,7 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root 
> *root,
>   pci_acpi_root_add_resources(info);
>   pci_add_resource(>resources, >secondary);
>   bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
> -   sysdata, >resources);
> +   sysdata, >resources, NULL);
>   if (!bus)
>   goto out_release_info;
>  
> diff --git a/drivers/parisc/lba_pci.c b/drivers/parisc/lba_pci.c
> index a32c1f6..a7b9d5c 100644
> --- a/drivers/parisc/lba_pci.c
> +++ b/drivers/parisc/lba_pci.c
> @@ -1567,7 +1567,7 @@ lba_driver_probe(struct parisc_device *dev)
>   dev->dev.platform_data = lba_dev;
>   lba_bus = lba_dev->hba.hba_bus =
>   pci_create_root_bus(>dev, lba_dev->hba.bus_num.start,
> - cfg_ops, NULL, );
> + cfg_ops, NULL, , NULL);
>   if (!lba_bus) {
>   pci_free_resource_list();
>   return 0;
> diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
> index ae00ce2..95c20c8 100644
> --- a/drivers/pci/host/pci-xgene.c
> +++ b/drivers/pci/host/pci-xgene.c
> @@ -545,7 +545,7 @@ static int xgene_pcie_probe_bridge(struct platform_device 
> *pdev)
>   return ret;
>  
>   bus = pci_create_root_bus(>dev, 0,
> - _pcie_ops, port, );
> + _pcie_ops, port, , NULL);
>   if (!bus)
>   return -ENOMEM;
>  
> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> index 9193951..bc999b7 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -357,7 +357,8 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct 
> list_head *res)
>   sysdata = pcie;
>  #endif
>  
> - bus = pci_create_root_bus(pcie->dev, 0, _pcie_ops, sysdata, res);
> + bus = pci_create_root_bus(pcie->dev, 0, _pcie_ops, sysdata, res,
> +   NULL);
>   if (!bus) {
>   dev_err(pcie->dev, "unable to create PCI root bus\n");
>   ret = -ENOMEM;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index f441d1b..c0f2e44 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2039,7 +2039,8 @@ void __weak pcibios_remove_bus(struct pci_bus *bus)
>  }
>  
>  struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> - struct pci_ops *ops, void *sysdata, struct list_head *resources)
> + struct pci_ops *ops, void *sysdata, struct list_head *resources,
> + struct fwnode_handle *fwnode)
>  {
>   int error;
>   struct pci_host_bridge *bridge;
> @@ -2069,6 +2070,7 @@ struct pci_bus *pci_create_root_bus(struct device 
> *parent, int bus,
>   if (!bridge)
>   goto err_out;
>  
> + bridge->fwnode = fwnode;
>   bridge->dev.parent = parent;
>   bridge->dev.release = pci_release_host_bridge_dev;
>   dev_set_name(>dev, "pci%04x:%02x", pci_domain_nr(b), bus);
> @@ -2223,7 +2225,7 @@ struct pci_bus *pci_scan_root_bus_msi(struct device 
> 

[PATCH V3 RESEND 1/3] bindings for hisilicon hi6220 iommu driver

[Chen Feng]

docs: iommu: Documentation for iommu in hi6220 SoC.

Signed-off-by: Chen Feng 
Signed-off-by: Yu Dongbin 
---
 .../bindings/iommu/hisi,hi6220-iommu.txt   | 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt 
b/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
new file mode 100644
index 000..756e64f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/hisi,hi6220-iommu.txt
@@ -0,0 +1,56 @@
+Hi6220 SoC SMMU Device Driver devicetree document
+===
+The Architecture of SMMU on Hi6220 SoC:
+
+   +--+
+   |  |
+   | +-+  ++  +-+   +---+ |
+   | |   ADE   |  |  ISP   |  |  V/J codec  |   |  G3D  | |
+   | +|+  +---|+  +--|--+   +---|---| |
+   |  |   |  |  | |
+   | -v---v--v--v-|
+   |   Media Bus  |
+   | |---||
+   | |   ||
+   | +---v---v+   |
+   | |SMMU|   |
+   | +--|-|---+   |
+   || |   |
+   +|-|---+
+| |
+   +v-v---+
+   |  DDRC|
+   +--+
+
+Note:
+The media system shared the same smmu IP to access DDR memory. And all
+media IP used the same page table.
+
+Below binding describes the system mmu for media system in hi6220 platform
+
+Required properties:
+- compatible: should contain "hisilicon,hi6220-smmu".
+- reg: A tuple of base address and size of System MMU registers.
+- clocks: a list of phandle + clock-specifier pairs, one for each entry
+  in clock-names.
+- clock-names: should contain:
+  * "smmu"
+  * "media-sc"
+  * "smmu-peri"
+- interrupts: An interrupt specifier for interrupt signal of System MMU.
+- #iommu-cells: The iommu-cells should be 0. Because no additional information
+  needs to be encoded in the specifier.
+
+Examples:
+   iommu@f421 {
+   compatible = "hisilicon,hi6220-smmu";
+   reg = <0x0 0xf421 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_ctrl HI6220_MMU_CLK>,
+<_ctrl HI6220_MED_MMU>,
+<_ctrl HI6220_MEDIA_PLL_SRC>;
+   clock-names = "smmu",
+ "media-sc",
+ "smmu-peri";
+   #iommu-cells = <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/

[ANNOUNCE] MDB Debugger Linux 4.2.4

[Jeffrey Merkey]

I changed the name to Modular Kernel Debugger from Merkey's Kernel
Debugger.  Very minimal changes considering the last release was four
years ago on 2.6.37.Will be backporting til it meets 2.6.37
versions.   Not fully tested on all x86_64 build options.  Please
email bugs are comments.

Is completely modular, loads as a kernel module, so can be loaded as
needed.   Submitted for consideration for inclusion.I have
maintained this for 15 years and its been on Linux for 8 years,  I
will continue to work it unless its taken over by LKML.

Thanks,

Jeff

http://www.jeffmerkey.com/mdb/mdb-4.2.4-x86_64-10-27-2015.patch

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

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

[PATCH V3 RESEND 3/3] Add iommu node for hi6220 SoC platform

[Chen Feng]

arm64: dts: Add dts node for hi6220 smmu driver

Signed-off-by: Chen Feng 
Signed-off-by: Yu Dongbin 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..7ae0984 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,18 @@
clocks = <_ctrl 36>, <_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+   iommu: iommu@f421 {
+   compatible = "hisilicon,hi6220-smmu";
+   reg = <0x0 0xf421 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_ctrl HI6220_MMU_CLK>,
+<_ctrl HI6220_MED_MMU>,
+<_ctrl HI6220_MEDIA_PLL_SRC>;
+   clock-names = "smmu",
+ "media-sc",
+ "smmu-peri";
+   #iommu-cells = <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/

Re: [PATCH 02/10] staging: fsl-mc: Added generic MSI support for FSL-MC devices

[Jiang Liu]

On 2015/10/26 23:49, J. German Rivera wrote:
> Created an MSI domain for the fsl-mc bus-- including functions
> to create a domain, find a domain, alloc/free domain irqs, and
> bus specific overrides for domain and irq_chip ops.
> 
> Signed-off-by: J. German Rivera 
> ---
>  drivers/staging/fsl-mc/bus/Kconfig  |   1 +
>  drivers/staging/fsl-mc/bus/Makefile |   1 +
>  drivers/staging/fsl-mc/bus/mc-msi.c | 278 
> 
>  drivers/staging/fsl-mc/include/mc-private.h |  17 ++
>  drivers/staging/fsl-mc/include/mc.h |  17 ++
>  5 files changed, 314 insertions(+)
>  create mode 100644 drivers/staging/fsl-mc/bus/mc-msi.c
> 


> +
> +static void fsl_mc_msi_free_descs(struct device *dev)
> +{
> + struct msi_desc *desc, *tmp;
> +
> + list_for_each_entry_safe(desc, tmp, dev_to_msi_list(dev), list) {
> + list_del(>list);
> + free_msi_entry(desc);
> + }
> +}
> +
> +static int fsl_mc_msi_alloc_descs(struct device *dev, unsigned int irq_count)
> +
> +{
> + unsigned int i;
> + int error;
> + struct msi_desc *msi_desc;
> +
> + for (i = 0; i < irq_count; i++) {
> + msi_desc = alloc_msi_entry(dev);
> + if (!msi_desc) {
> + dev_err(dev, "Failed to allocate msi entry\n");
> + error = -ENOMEM;
> + goto cleanup_msi_descs;
> + }
> +
> + msi_desc->msi_attrib.is_msix = 1;
> + msi_desc->msi_attrib.is_64 = 1;
> + msi_desc->msi_attrib.entry_nr = i;

Hi Rivera,
Field msi_desc->msi_attrib is for PCI MSI only, it would be better to
introduce a dedicated structure for FSL-MC, just like
struct platform_msi_desc.
Thanks,
Gerry

> + msi_desc->nvec_used = 1;
> + INIT_LIST_HEAD(_desc->list);
> + list_add_tail(_desc->list, dev_to_msi_list(dev));
> + }
> +
> + return 0;
> +
> +cleanup_msi_descs:
> + fsl_mc_msi_free_descs(dev);
> + return error;
> +}
> +
> +int fsl_mc_msi_domain_alloc_irqs(struct device *dev,
> +  unsigned int irq_count)
> +{
> + struct irq_domain *msi_domain;
> + int error;
> +
> + if (WARN_ON(!list_empty(dev_to_msi_list(dev
> + return -EINVAL;
> +
> + error = fsl_mc_msi_alloc_descs(dev, irq_count);
> + if (error < 0)
> + return error;
> +
> + msi_domain = dev_get_msi_domain(dev);
> + if (WARN_ON(!msi_domain)) {
> + error = -EINVAL;
> + goto cleanup_msi_descs;
> + }
> +
> + /*
> +  * NOTE: Calling this function will trigger the invocation of the
> +  * its_fsl_mc_msi_prepare() callback
> +  */
> + error = msi_domain_alloc_irqs(msi_domain, dev, irq_count);
> +
> + if (error) {
> + dev_err(dev, "Failed to allocate IRQs\n");
> + goto cleanup_msi_descs;
> + }
> +
> + return 0;
> +
> +cleanup_msi_descs:
> + fsl_mc_msi_free_descs(dev);
> + return error;
> +}
> +

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