Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver

[Jingoo Han]

On 2015. 8. 20., at PM 1:29, Archit Taneja  wrote:
> 
> Hi,
> 
>> On 08/19/2015 08:18 PM, Yakir Yang wrote:
>> 
>> Hi all,
>>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
>> share the same IP, so a lot of parts can be re-used. I split the common
>> code into bridge directory, then rk3288 and exynos only need to keep
>> some platform code. Cause I can't find the exact IP name of exynos dp
>> controller, so I decide to name dp core driver with "analogix" which I
>> find in rk3288 eDP TRM ;)
>> 
>> Beyond that, there are three light registers setting differents bewteen
>> exynos and rk3288.
>> 1. RK3288 have five special pll resigters which not indicata in exynos
>>dp controller.
>> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>>between rk3288 and exynos.
>> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>>register).
>> 
>> I have verified this series on two kinds of rockchip platform board, one
>> is rk3288 sdk board which connect with a 2K display port monitor, the other
>> is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
>> both of them works rightlly.
>> 
>> I haven't verified the dp function on samsung platform, cause I haven't got
>> exynos boards. I can only ensure that there are no build error on samsung
>> platform, wish some samsung guys help to test. ;)
>> 
>> Thanks,
>> - Yakir
>> 
>> Changes in v3:
>> - Take Thierry Reding suggest, move exynos's video_timing code
>>   to analogix_dp-exynos platform driver, add get_modes method
>>   to struct analogix_dp_plat_data.
>> - Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
>> - Take Thierry Reding suggest, dynamic parse video timing info from
>>   struct drm_display_mode and struct drm_display_info.
>> - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
>>   the DT property value directly, but we can take those as hardware limite.
>>   For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
>>   so DT property would like "link-rate = 0x0a" "lane-count = 4".
>> - Take Heiko suggest, add devicetree binding documents.
>> - Take Thierry Reding suggest, remove sync pol & colorimetry properies
>>   from the new analogix dp driver devicetree binding.
>> - Update the exist exynos dtsi file with the latest DP DT properies.
>> - Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
>>   dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
>>   core driver which name to "dp", and leave "pclk_edp" to rockchip dp 
>> platform
>>   driver which name to "pclk".
>> - Take Heiko suggest, add devicetree binding document.
>> - Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote
>>   point to get panel node.
>> - Add the new function point analogix_dp_platdata.get_modes init.
>> - Take Heiko suggest, add rockchip dp phy driver,
>>   collect the phy clocks and power control.
>> - Add "analogix,need-force-hpd" to indicate whether driver need foce
>>   hpd when hpd detect failed.
>> - move dp hpd detect to connector detect function.
>> - Add edid modes parse support
>> 
>> Changes in v2:
>> - Take Joe Preches advise, improved commit message more readable, and
>>   avoid using some uncommon style like bellow:
>>   -  retval = exynos_dp_read_bytes_from_i2c(...
>>...)
>>   +  retval =
>>   +  exynos_dp_read_bytes_from_i2c(..);
>> - Take Jingoo Han suggest, just remove my name from author list.
>> - Take Jingoo Han suggest, remove new copyright
>> - Fix compiled failed dut to analogix_dp_device misspell
>> - Take Heiko suggest, get panel node with remote-endpoint method,
>>   and create devicetree binding for driver.
>> - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
>>   leave those clock to rockchip dp phy driver.
>> - Add GNU license v2 declared and samsung copyright
>> - Fix compile failed dut to phy_pd_addr variable misspell error
>> 
>> Yakir Yang (14):
>>   drm: exynos/dp: fix code style
>>   drm: exynos/dp: convert to drm bridge mode
>>   drm: bridge: analogix_dp: split exynos dp driver to bridge dir
>>   drm: bridge/analogix_dp: dynamic parse sync_pol & interlace &
>> colorimetry
>>   drm: bridge/analogix_dp: fix link_rate & lane_count bug
>>   Documentation: drm/bridge: add document for analogix_dp
>>   drm: rockchip/dp: add rockchip platform dp driver
>>   phy: Add driver for rockchip Display Port PHY
>>   drm: bridge/analogix_dp: add platform device type support
>>   drm: bridge: analogix_dp: add some rk3288 special registers setting
>>   drm: bridge: analogix_dp: try force hpd after plug in lookup failed
>>   drm: bridge/analogix_dp: expand the delay time for hpd detect
>>   drm: bridge/analogix_dp: move hpd detect to connector detect function
>>   drm: bridge/analogix_dp: add edid modes parse in get_modes method
>> 
>>  .../devicetree/bindings/drm/bridge/analogix_dp.txt |   73 +

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

[Kishon Vijay Abraham I]

Hi Mark Brown,

On Wednesday 19 August 2015 11:41 PM, Mark Brown wrote:
> On Tue, Aug 18, 2015 at 11:23:54AM +0530, Kishon Vijay Abraham I wrote:
>> On Friday 14 August 2015 11:30 PM, Mark Brown wrote:
>>> On Mon, Jul 27, 2015 at 04:54:09PM +0530, Kishon Vijay Abraham I wrote:
> 
 is moved as a child node of syscon, vsel_reg and enable_reg has the
 absolute address because of the address translation that happens while
 creating device from device tree node.
 So avoid using platform_get_resource and use of_get_address in order to
 get only the offset (untranslated address) and populate these in
 vsel_reg and enable_reg.
> 
>>> This sounds like we're going in the wrong direction, we're moving from a
>>> more generic API to a firmware specific one.  Why is this a good fix?
> 
>> platform_get_resource can be used if we need the absolute address but here we
>> need only the offset.
> 
> So substract this address from the start of the resource to get the

That would mean from the offset (provided in dt) get the absolute address and
then again from the absolute address get the offset.
> offset?  Or provide a wrapper function in the resource code which does

Why not use 'of_get_address' which does the same thing? Moreover it's not a
resource we are dealing with here. It's a resource only for the syscon driver.
> that.  What you're saying above is pretty much "this happens to work"
> but my concern is that the solution that happens to work isn't really
> what we want to do.

Not just makes this work, this is also the most reasonable solution available 
IMHO.

The most ideal way would have been to use something like what Grygorii
mentioned to use syscon = <_conf 0xe00> and then use the phandle to get the
offset. But then with this we'll be breaking older dtbs.

Thanks
Kishon


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

Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation

[Vinod Koul]

On Thu, Aug 06, 2015 at 08:49:32AM +0530, Punnaiah Choudary Kalluri wrote:
> Device-tree binding documentation for Xilinx zynqmp dma engine used in
> Zynq UltraScale+ MPSoC.
> 
> Signed-off-by: Punnaiah Choudary Kalluri 
> ---
> Changes in v4:
> - None
> Changes in v3:
> - None
> Changes in v2:
> - None
> ---
>  .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt  |   61 
> 
>  1 files changed, 61 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> 
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt 
> b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> new file mode 100644
> index 000..e4f92b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> @@ -0,0 +1,61 @@
> +Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
> +memory to device and device to memory transfers. It also has flow
> +control and rate control support for slave/peripheral dma access.
> +
> +Required properties:
> +- compatible: Should be "xlnx,zynqmp-dma-1.0"
> +- #dma-cells: Should be <1>, a single cell holding a line request number
> +- reg: Memory map for module access
> +- interrupt-parent: Interrupt controller the interrupt is routed through
> +- interrupts: Should contain DMA channel interrupt
channel interrupt or interrupts, former says it is plural

-- 
~Vinod

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

Re: [PATCH v2 2/3] mailbox: Hi6220: add mailbox driver

[YiPing Xu]

On 2015/8/20 10:53, Leo Yan wrote:

Add driver for Hi6220 mailbox, the mailbox communicates with MCU; for
sending data, it can support two methods for low level implementation:
one is to use interrupt as acknowledge, another is automatic mode which
without any acknowledge. These two methods have been supported in the
driver. For receiving data, it will depend on the interrupt to notify
the channel has incoming message; enhance rx channel's message queue,
which is based on the code in drivers/mailbox/omap-mailbox.c.

Now mailbox driver is used to send message to MCU to control dynamic
voltage and frequency scaling for CPU, GPU and DDR.

Signed-off-by: Leo Yan 
---
  drivers/mailbox/Kconfig  |   8 +
  drivers/mailbox/Makefile |   2 +
  drivers/mailbox/hi6220-mailbox.c | 519 +++
  3 files changed, 529 insertions(+)
  create mode 100644 drivers/mailbox/hi6220-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index e269f08..21b71dd 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -70,4 +70,12 @@ config BCM2835_MBOX
  the services of the Videocore. Say Y here if you want to use the
  BCM2835 Mailbox.

+config HI6220_MBOX
+   tristate "Hi6220 Mailbox"
+   depends on ARCH_HISI
+   help
+ An implementation of the hi6220 mailbox. It is used to send message
+ between application processors and MCU. Say Y here if you want to 
build
+ the Hi6220 mailbox controller driver.
+
  endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 8e6d822..4ba9f5f 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -13,3 +13,5 @@ obj-$(CONFIG_PCC) += pcc.o
  obj-$(CONFIG_ALTERA_MBOX) += mailbox-altera.o

  obj-$(CONFIG_BCM2835_MBOX)+= bcm2835-mailbox.o
+
+obj-$(CONFIG_HI6220_MBOX)  += hi6220-mailbox.o
diff --git a/drivers/mailbox/hi6220-mailbox.c b/drivers/mailbox/hi6220-mailbox.c
new file mode 100644
index 000..8f63d0d
--- /dev/null
+++ b/drivers/mailbox/hi6220-mailbox.c
@@ -0,0 +1,519 @@
+/*
+ * Hisilicon's Hi6220 mailbox driver
+ *
+ * RX channel's message queue is based on the code written in
+ * drivers/mailbox/omap-mailbox.c.
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HI6220_MBOX_CHAN_MAX   32
+#define HI6220_MBOX_CHAN_NUM   2
+#define HI6220_MBOX_CHAN_SLOT_SIZE 64
+
+#define HI6220_MBOX_RX 0x0
+#define HI6220_MBOX_TX 0x1
+
+/* Mailbox message length: 32 bytes */
+#define HI6220_MBOX_MSG_LEN32
+
+/* Mailbox kfifo size */
+#define HI6220_MBOX_MSG_FIFO_SIZE  512
+
+/* Status & Mode Register */
+#define HI6220_MBOX_MODE_REG   0x0
+
+#define HI6220_MBOX_STATUS_MASK(0xF << 4)
+#define HI6220_MBOX_STATUS_IDLE(0x1 << 4)
+#define HI6220_MBOX_STATUS_TX  (0x2 << 4)
+#define HI6220_MBOX_STATUS_RX  (0x4 << 4)
+#define HI6220_MBOX_STATUS_ACK (0x8 << 4)
+#define HI6220_MBOX_ACK_CONFIG_MASK(0x1 << 0)
+#define HI6220_MBOX_ACK_AUTOMATIC  (0x1 << 0)
+#define HI6220_MBOX_ACK_IRQ(0x0 << 0)
+
+/* Data Registers */
+#define HI6220_MBOX_DATA_REG(i)(0x4 + (i << 2))
+
+/* ACPU Interrupt Register */
+#define HI6220_MBOX_ACPU_INT_RAW_REG   0x400
+#define HI6220_MBOX_ACPU_INT_MSK_REG   0x404
+#define HI6220_MBOX_ACPU_INT_STAT_REG  0x408
+#define HI6220_MBOX_ACPU_INT_CLR_REG   0x40c
+#define HI6220_MBOX_ACPU_INT_ENA_REG   0x500
+#define HI6220_MBOX_ACPU_INT_DIS_REG   0x504
+
+/* MCU Interrupt Register */
+#define HI6220_MBOX_MCU_INT_RAW_REG0x420
+
+/* Core Id */
+#define HI6220_CORE_ACPU   0x0
+#define HI6220_CORE_MCU0x2
+
+struct hi6220_mbox_queue {
+   struct kfifo fifo;
+   struct work_struct work;
+   struct mbox_chan *chan;
+   bool full;
+};
+
+struct hi6220_mbox_chan {
+
+   /*
+* Description for channel's hardware info:
+*  - direction;
+*  - peer core id for communication;
+*  - local irq vector or number;
+*  - remoted irq vector or number for peer core;
+*/
+   unsigned int dir;
+   unsigned int peer_core;
+   unsigned int remote_irq;
+   unsigned int local_irq;
+
+   /*
+* Slot 

Re: [PATCH v1 3/4] Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver

[Vinod Koul]

On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
> + nents = sg_nents(req->src);
> + sg_count = dma_map_sg(dev, req->src, nents, DMA_TO_DEVICE);
> + if (!sg_count) {
> + dev_err(dev, "Failed to map src sg");
> + return -ENOMEM;
mapping error shouldn't be no mem error

> + }
> +
> + if (sg_count > XGENE_DMA_MAX_FLYBY_SRC_CNT) {
> + dev_err(dev, "Unsupported src sg len\n");
would be worth printing length

> + goto err;
> + }
> +
> + flags = DMA_CTRL_ACK;
why ACK?

> +
> + tx = dchan->device->device_prep_dma_crc32c(dchan, req->src,
> +req->nbytes,
> +reqctx->seed,
> +req->result,
> +flags);
We should add helper for this

-- 
~Vinod

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

RE: [RESEND PATCH] dmaengine: Add Xilinx AXI Direct Memory Access Engine driver support

[Appana Durga Kedareswara Rao]

Hi Moritz Fischer,

Thanks for reviewing the patch.

> -Original Message-
> From: Moritz Fischer [mailto:moritz.fisc...@ettus.com]
> Sent: Thursday, August 20, 2015 3:21 AM
> To: Appana Durga Kedareswara Rao
> Cc: vinod.k...@intel.com; dan.j.willi...@intel.com; Michal Simek; Soren
> Brinkmann; Appana Durga Kedareswara Rao; aniru...@xilinx.com;
> dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel;
> Srikanth Thokala
> Subject: Re: [RESEND PATCH] dmaengine: Add Xilinx AXI Direct Memory Access
> Engine driver support
> 
> Hi there,
> 
> see comment below. I just did a quick compile test. Will take another look 
> once I
> synthesized an image.
> 
> On Mon, Aug 17, 2015 at 8:31 AM, Kedareswara rao Appana
>  wrote:
> > This is the driver for the AXI Direct Memory Access (AXI DMA) core,
> > which is a soft Xilinx IP core that provides high- bandwidth direct
> > memory access between memory and AXI4-Stream type target peripherals.
> >
> > Signed-off-by: Srikanth Thokala 
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > The deivce tree doc got applied in the slave-dmaengine.git.
> >
> > Forgot to include dmaeng...@vger.kernel.org in the cc list resending
> > the patch.
> >
> > Changes in v8:
> > - Updated the SG handling as suggested by Nicolae Rosia.
> > - Removed the unnecessary xilinx_dma_channel_set_config API the properties
> >   in this API is not being used by the driver.
> > Changes in v7:
> > - Updated license in the driver as suggested by Paul.
> > - Corrected return value in is_idle funtion.
> > Changes in v6:
> > - Fixed Odd indention in the Kconfig.
> > - used GFP_NOWAIT instead of GFP_KERNEL during the desc allocation
> > - Calculated residue in the tx_status instead of complete_descriptor.
> > - Update copy right to 2015.
> > - Modified spin_lock handling moved the spin_lock to the appropriate
> > functions (instead of xilinx_dma_start_transfer doing it
> xilinx_dma_issue_pending api).
> > - device_control and declare slave caps updated as per newer APi's.
> > Changes in v5:
> > - Modified the xilinx_dma.h header file location to the
> >   include/linux/dma/xilinx_dma.h
> > Changes in v4:
> > - Add direction field to DMA descriptor structure and removed from
> >   channel structure to avoid duplication.
> > - Check for DMA idle condition before changing the configuration.
> > - Residue is being calculated in complete_descriptor() and is reported
> >   to slave driver.
> > Changes in v3:
> > - Rebased on 3.16-rc7
> > Changes in v2:
> > - Simplified the logic to set SOP and APP words in prep_slave_sg().
> > - Corrected function description comments to match the return type.
> > - Fixed some minor comments as suggested by Andy.
> >
> >  drivers/dma/Kconfig |   13 +
> >  drivers/dma/xilinx/Makefile |1 +
> >  drivers/dma/xilinx/xilinx_dma.c | 1179
> > +++
> >  3 files changed, 1193 insertions(+)
> >  create mode 100644 drivers/dma/xilinx/xilinx_dma.c
> >
> > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index
> > 88d474b..5e95f07 100644
> > --- a/drivers/dma/Kconfig
> > +++ b/drivers/dma/Kconfig
> > @@ -507,4 +507,17 @@ config QCOM_BAM_DMA
> >   Enable support for the QCOM BAM DMA controller.  This controller
> >   provides DMA capabilities for a variety of on-chip devices.
> >
> > +config XILINX_DMA
> > +tristate "Xilinx AXI DMA Engine"
> > +depends on (ARCH_ZYNQ || MICROBLAZE)
> > +select DMA_ENGINE
> > +help
> > +  Enable support for Xilinx AXI DMA Soft IP.
> > +
> > +  This engine provides high-bandwidth direct memory access
> > +  between memory and AXI4-Stream type target peripherals.
> > +  It has two stream interfaces/channels, Memory Mapped to
> > +  Stream (MM2S) and Stream to Memory Mapped (S2MM) for the
> > +  data transfers.
> > +
> >  endif
> > diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile
> > index 3c4e9f2..6224a49 100644
> > --- a/drivers/dma/xilinx/Makefile
> > +++ b/drivers/dma/xilinx/Makefile
> > @@ -1 +1,2 @@
> >  obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o
> > +obj-$(CONFIG_XILINX_DMA) += xilinx_dma.o
> > diff --git a/drivers/dma/xilinx/xilinx_dma.c
> > b/drivers/dma/xilinx/xilinx_dma.c new file mode 100644 index
> > 000..a9be197
> > --- /dev/null
> > +++ b/drivers/dma/xilinx/xilinx_dma.c
> > @@ -0,0 +1,1179 @@
> > +/*
> > + * DMA driver for Xilinx DMA Engine
> > + *
> > + * Copyright (C) 2010 - 2015 Xilinx, Inc. All rights reserved.
> > + *
> > + * Based on the Freescale DMA driver.
> > + *
> > + * Description:
> > + *  The AXI DMA, is a soft IP, which provides high-bandwidth Direct
> > +Memory
> > + *  Access between memory and AXI4-Stream-type target peripherals. It
> > +can be
> > + *  configured to have one channel or two channels and if configured
> > +as two
> > + *  channels, one is to transmit data from memory to a device and
> > +another is
> 

Re: [PATCH v1 2/4] dmaengine: xgene-dma: Add support for CRC32C calculation via DMA engine

[Vinod Koul]

On Thu, Jul 30, 2015 at 05:41:06PM +0530, Rameshwar Prasad Sahu wrote:
> + /* Invalidate unused source address field */
> + for (; i < 4; i++)
> + xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
> +
> + /* Check whether requested buffer processed */
> + if (nbytes) {
> + chan_err(chan, "Src count crossed maximum limit\n");
> + return -EINVAL;
no cleanup ?

> +struct dma_async_tx_descriptor *xgene_dma_prep_flyby(
> + struct xgene_dma_chan *chan, struct scatterlist *src_sg,
> + size_t len, u32 seed, u8 *result, unsigned long flags, u8 opcode)
please fix style here

> +struct dma_async_tx_descriptor *xgene_dma_prep_crc32c(
> + struct dma_chan *dchan, struct scatterlist *src_sg,
> + size_t len, u32 seed, u8 *result, unsigned long flags)
here too

> @@ -1309,8 +1512,13 @@ static void xgene_dma_setup_ring(struct xgene_dma_ring 
> *ring)
> ring->pdma->csr_ring + XGENE_DMA_RING_ID);
> 
>   /* Set DMA ring buffer */
> - iowrite32(XGENE_DMA_RING_ID_BUF_SETUP(ring->num),
> -   ring->pdma->csr_ring + XGENE_DMA_RING_ID_BUF);
> + ring_id_buf = XGENE_DMA_RING_ID_BUF_SETUP(ring->num);
> +
> + if (ring->is_bufpool)
> + ring_id_buf |= XGENE_DMA_RING_IS_BUFPOOL;
> +
> + iowrite32(ring_id_buf, ring->pdma->csr_ring +
> +   XGENE_DMA_RING_ID_BUF);
pls fix style here

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

RE: [PATCH 3/8][v3]usb:fsl:otg: Add support to add/remove usb host driver

[Ramneek Mehresh]

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Friday, August 14, 2015 12:17 AM
> To: Mehresh Ramneek-B31383 
> Cc: linux-kernel@vger.kernel.org; ba...@ti.com;
> gre...@linuxfoundation.org; linux-...@vger.kernel.org; Li Yang-Leo-R58472
> 
> Subject: Re: [PATCH 3/8][v3]usb:fsl:otg: Add support to add/remove usb
> host driver
> 
> On Thu, 13 Aug 2015, Ramneek Mehresh wrote:
> 
> > Add workqueue to add/remove host driver (outside
> > interrupt context) upon each id change.
> >
> > Signed-off-by: Li Yang 
> > Signed-off-by: Ramneek Mehresh 
> > ---
> > Changes for v3:
> > - removed CONFIG_FSL_USB2_OTG and
> CONFIG_FSL_USB2_OTG_MODULE
> >   macros
> > - removed call to usb_hcd_resume_root_hub(hcd) from
> >   ehci_fsl_drv_resume()
> >
> >  drivers/usb/host/ehci-fsl.c | 71 -
> 
> >  drivers/usb/host/ehci-fsl.h | 18 
> >  2 files changed, 69 insertions(+), 20 deletions(-)
> 
> 
> >  static int ehci_fsl_drv_suspend(struct device *dev)
> >  {
> > struct usb_hcd *hcd = dev_get_drvdata(dev);
> > -   struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
> > void __iomem *non_ehci = hcd->regs;
> > +   struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
> > +   struct usb_bus host = hcd->self;
> 
> I just noticed this line.  It does not look right at all; it does a
> structure copy instead of copying a pointer.
my bad...will change to struct usb_bus *host = >self;
> 
> >
> > if (of_device_is_compatible(dev->parent->of_node,
> > "fsl,mpc5121-usb2-dr")) {
> > return ehci_fsl_mpc512x_drv_suspend(dev);
> > }
> >
> > +   if (host.is_otg) {
> > +   /* remove hcd */
> > +   ehci_fsl->hcd_add = 0;
> > +   schedule_work(_fsl->change_hcd_work);
> > +   host.is_otg = 0;
> 
> And here you turn off the flag in the local copy of the structure,
> which accomplishes nothing.
> 
agree...will change to host->is_otg = 0;
> > +   return 0;
> > +   }
> > +
> > ehci_prepare_ports_for_controller_suspend(hcd_to_ehci(hcd),
> > device_may_wakeup(dev));
> > if (!fsl_deep_sleep())
> > @@ -557,15 +579,24 @@ static int ehci_fsl_drv_suspend(struct device
> *dev)
> >  static int ehci_fsl_drv_resume(struct device *dev)
> >  {
> > struct usb_hcd *hcd = dev_get_drvdata(dev);
> > -   struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
> > struct ehci_hcd *ehci = hcd_to_ehci(hcd);
> > void __iomem *non_ehci = hcd->regs;
> > +   struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
> > +   struct usb_bus host = hcd->self;
> 
> Same here.
agree
> 
> > --- a/drivers/usb/host/ehci-fsl.h
> > +++ b/drivers/usb/host/ehci-fsl.h
> > @@ -63,4 +63,22 @@
> >  #define UTMI_PHY_EN (1<<9)
> >  #define ULPI_PHY_CLK_SEL(1<<10)
> >  #define PHY_CLK_VALID  (1<<17)
> > +
> > +struct ehci_fsl {
> > +#ifdef CONFIG_PM
> > +   /* Saved USB PHY settings, need to restore after deep sleep. */
> > +   u32 usb_ctrl;
> > +#endif
> 
> Do you need this #ifdef?
> 
Yes, this is required for deep-sleep support...we need to save/restore 
controller
registers during deep-sleep when usb controller power is shut-off. Don't need 
this
during normal usb operation...saving/restoring usb controller registers in non 
deep-sleep
scenario will add unnecessary delays
> Alan Stern

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

[lkp] [auxdisplay] 4edd70c133f: BUG: unable to handle kernel

[kernel test robot]

FYI, we noticed the below changes on

git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 4edd70c133f3921c594883d8f9da31a7261f8b4f ("auxdisplay: ks0108: use new 
parport device model")


+--+++
|  | c9efdbe634 | 4edd70c133 |
+--+++
| boot_successes   | 72 | 0  |
| boot_failures| 0  | 32 |
| BUG:unable_to_handle_kernel  | 0  | 32 |
| Oops | 0  | 32 |
| EIP_is_at_ks0108_writecontrol| 0  | 32 |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 32 |
| backtrace:cfag12864b_page| 0  | 32 |
| backtrace:cfag12864b_init| 0  | 32 |
| backtrace:kernel_init_freeable   | 0  | 32 |
+--+++


[1.646998] device id = 2670
[1.648297] slram: not enough parameters.
[1.648297] slram: not enough parameters.
[1.655191] BUG: unable to handle kernel 
[1.655191] BUG: unable to handle kernel NULL pointer dereferenceNULL 
pointer dereference at 0368
 at 0368
[1.656053] IP:
[1.656053] IP: [<41505410>] ks0108_writecontrol+0x20/0x30
 [<41505410>] ks0108_writecontrol+0x20/0x30
[1.656053] *pde =  
[1.656053] *pde =  

[1.656053] Oops:  [#1] 
[1.656053] Oops:  [#1] DEBUG_PAGEALLOC DEBUG_PAGEALLOC 

[1.656053] Modules linked in:
[1.656053] Modules linked in:

[1.656053] CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0-rc4-00102-g4edd70c 
#567
[1.656053] CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0-rc4-00102-g4edd70c 
#567
[1.656053] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[1.656053] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[1.656053] task: 40256040 ti: 40266000 task.ti: 40266000
[1.656053] task: 40256040 ti: 40266000 task.ti: 40266000
[1.656053] EIP: 0060:[<41505410>] EFLAGS: 00010247 CPU: 0
[1.656053] EIP: 0060:[<41505410>] EFLAGS: 00010247 CPU: 0
[1.656053] EIP is at ks0108_writecontrol+0x20/0x30
[1.656053] EIP is at ks0108_writecontrol+0x20/0x30
[1.656053] EAX:  EBX: 4197800a ECX:  EDX: 000a
[1.656053] EAX:  EBX: 4197800a ECX:  EDX: 000a
[1.656053] ESI:  EDI: 504fc120 EBP: 40267eec ESP: 40267ee8
[1.656053] ESI:  EDI: 504fc120 EBP: 40267eec ESP: 40267ee8
[1.656053]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[1.656053]  DS: 007b ES: 007b FS:  GS:  SS: 0068
[1.656053] CR0: 8005003b CR2: 0368 CR3: 01c2e000 CR4: 0690
[1.656053] CR0: 8005003b CR2: 0368 CR3: 01c2e000 CR4: 0690
[1.656053] Stack:
[1.656053] Stack:
[1.656053]  41978000
[1.656053]  41978000 40267ef4 40267ef4 415055f7 415055f7 40267f00 40267f00 
4150561c 4150561c 41978040 41978040 40267f10 40267f10 41bc9eb0 41bc9eb0

[1.656053]  419780c0
[1.656053]  419780c0 41bc9de7 41bc9de7 40267f84 40267f84 41000442 41000442 
00d0 00d0 418b5342 418b5342 41bc9de7 41bc9de7 0160 0160

[1.656053]  41971508
[1.656053]  41971508 40267f70 40267f70 410693af 410693af   
  40267f44 40267f44 4108940b 4108940b 0006 0006

[1.656053] Call Trace:
[1.656053] Call Trace:
[1.656053]  [<415055f7>] cfag12864b_e+0x37/0x40
[1.656053]  [<415055f7>] cfag12864b_e+0x37/0x40
[1.656053]  [<4150561c>] cfag12864b_page+0x1c/0x30
[1.656053]  [<4150561c>] cfag12864b_page+0x1c/0x30
[1.656053]  [<41bc9eb0>] cfag12864b_init+0xc9/0x127
[1.656053]  [<41bc9eb0>] cfag12864b_init+0xc9/0x127
[1.656053]  [<41bc9de7>] ? ks0108_init+0x16/0x16
[1.656053]  [<41bc9de7>] ? ks0108_init+0x16/0x16
[1.656053]  [<41000442>] do_one_initcall+0x82/0x1f0
[1.656053]  [<41000442>] do_one_initcall+0x82/0x1f0
[1.656053]  [<41bc9de7>] ? ks0108_init+0x16/0x16
[1.656053]  [<41bc9de7>] ? ks0108_init+0x16/0x16
[1.656053]  [<410693af>] ? parse_args+0x1df/0x410
[1.656053]  [<410693af>] ? parse_args+0x1df/0x410
[1.656053]  [<4108940b>] ? trace_hardirqs_on+0xb/0x10
[1.656053]  [<4108940b>] ? trace_hardirqs_on+0xb/0x10
[1.656053]  [<41b9ac44>] ? kernel_init_freeable+0x16c/0x209
[1.656053]  [<41b9ac44>] ? kernel_init_freeable+0x16c/0x209
[1.656053]  [<41b9ac64>] kernel_init_freeable+0x18c/0x209
[1.656053]  [<41b9ac64>] kernel_init_freeable+0x18c/0x209
[1.656053]  [<4168cbe0>] kernel_init+0x10/0xe0
[1.656053]  [<4168cbe0>] kernel_init+0x10/0xe0
[1.656053]  [<41073827>] ? 

Re: 0be964be0 "module: Sanitize RCU usage and locking" breaks symbol_put_addr?

[Rusty Russell]

Peter Zijlstra  writes:
> On Wed, Aug 19, 2015 at 06:19:43AM +0930, Rusty Russell wrote:
>> Indeed!  That comment is wrong, and your fix is good.
>> 
>> Care to S-O-B on it?
>
> Of course, here goes.

Thanks!  This is an ancient bug (2009) which your extra assertions
caught.  It's unlikely to have ever bitten anyone, but I've CC'd stable
for it anyway:

Fixes: a6e6abd575fc ("module: remove module_text_address()")
Cc: sta...@kernel.org

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

[lkp] [x86/entry/64] fa58aafc448: 10.8% aim7.jobs-per-min

[kernel test robot]

FYI, we noticed the below changes on

git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/entry
commit fa58aafc44805ac425d17c6a8082513b5442ce9d ("x86/entry/64: When returning 
via SYSRET, POP regs instead of using MOV")


=
tbox_group/testcase/rootfs/kconfig/compiler/load/test:
  lkp-a06/aim7/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/4000/new_raph

commit: 
  a4be9881623375fd126762af65ef18dc8175c68d
  fa58aafc44805ac425d17c6a8082513b5442ce9d

a4be9881623375fd fa58aafc44805ac425d17c6a80 
 -- 
 %stddev %change %stddev
 \  |\  
184099 ±  0% +10.8% 204000 ±  0%  aim7.jobs-per-min
131.89 ±  0%  -9.8% 119.00 ±  0%  aim7.time.elapsed_time
131.89 ±  0%  -9.8% 119.00 ±  0%  aim7.time.elapsed_time.max
   2215262 ±  0% -92.5% 165275 ±  0%  
aim7.time.involuntary_context_switches
 19.56 ±  1% -65.8%   6.70 ±  5%  aim7.time.system_time
435.63 ±  0%  -2.8% 423.34 ±  0%  aim7.time.user_time
 60385 ±  1% -17.3%  49927 ±  0%  
aim7.time.voluntary_context_switches
131.89 ±  0%  -9.8% 119.00 ±  0%  time.elapsed_time
131.89 ±  0%  -9.8% 119.00 ±  0%  time.elapsed_time.max
   2215262 ±  0% -92.5% 165275 ±  0%  time.involuntary_context_switches
 19.56 ±  1% -65.8%   6.70 ±  5%  time.system_time
 60385 ±  1% -17.3%  49927 ±  0%  time.voluntary_context_switches

=
tbox_group/testcase/rootfs/kconfig/compiler/load/test:
  lkp-a06/aim7/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/4000/pipe_cpy

commit: 
  a4be9881623375fd126762af65ef18dc8175c68d
  fa58aafc44805ac425d17c6a8082513b5442ce9d

a4be9881623375fd fa58aafc44805ac425d17c6a80 
 -- 
 %stddev %change %stddev
 \  |\  
247245 ±  1% +15.6% 285751 ±  1%  aim7.jobs-per-min
 98.61 ±  1% -13.4%  85.37 ±  1%  aim7.time.elapsed_time
 98.61 ±  1% -13.4%  85.37 ±  1%  aim7.time.elapsed_time.max
   2003598 ±  0% -93.3% 133967 ±  2%  
aim7.time.involuntary_context_switches
266.80 ±  1%  -7.1% 247.73 ±  1%  aim7.time.system_time
 51.41 ±  4% -11.8%  45.32 ±  7%  aim7.time.user_time
 53934 ±  1% -21.5%  42329 ±  1%  
aim7.time.voluntary_context_switches
 98.61 ±  1% -13.4%  85.37 ±  1%  time.elapsed_time
 98.61 ±  1% -13.4%  85.37 ±  1%  time.elapsed_time.max
   2003598 ±  0% -93.3% 133967 ±  2%  time.involuntary_context_switches
 51.41 ±  4% -11.8%  45.32 ±  7%  time.user_time
 53934 ±  1% -21.5%  42329 ±  1%  time.voluntary_context_switches

=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/nr_threads:
  
lkp-a06/dbench/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/100%

commit: 
  a4be9881623375fd126762af65ef18dc8175c68d
  fa58aafc44805ac425d17c6a8082513b5442ce9d

a4be9881623375fd fa58aafc44805ac425d17c6a80 
 -- 
 %stddev %change %stddev
 \  |\  
   2245160 ±  8% -76.6% 526406 ±  4%  
dbench.time.involuntary_context_switches
379.50 ±  0%  +1.3% 384.50 ±  0%  
dbench.time.percent_of_cpu_this_job_got
  1715 ±  0%  +1.7%   1745 ±  0%  dbench.time.system_time
   2245160 ±  8% -76.6% 526406 ±  4%  time.involuntary_context_switches
  2.69 ± 11% +81.5%   4.88 ± 37%  
perf-profile.cpu-cycles.__hrtimer_run_queues.hrtimer_interrupt.local_apic_timer_interrupt.smp_apic_timer_interrupt.apic_timer_interrupt
  1.43 ±  2% -10.1%   1.29 ±  2%  
perf-profile.cpu-cycles.entry_SYSCALL_64_after_swapgs
  1.51 ±  8% -26.2%   1.11 ± 10%  
perf-profile.cpu-cycles.rcu_nocb_kthread.kthread.ret_from_fork
  1.20 ± 15%+109.4%   2.51 ± 46%  
perf-profile.cpu-cycles.scheduler_tick.update_process_times.tick_sched_handle.tick_sched_timer.__hrtimer_run_queues
  0.68 ± 16%+110.7%   1.43 ± 47%  
perf-profile.cpu-cycles.task_tick_fair.scheduler_tick.update_process_times.tick_sched_handle.tick_sched_timer
  1.97 ± 11% +96.4%   3.87 ± 40%  
perf-profile.cpu-cycles.tick_sched_handle.isra.17.tick_sched_timer.__hrtimer_run_queues.hrtimer_interrupt.local_apic_timer_interrupt
  2.33 ± 10% +84.8%   4.30 ± 38%  
perf-profile.cpu-cycles.tick_sched_timer.__hrtimer_run_queues.hrtimer_interrupt.local_apic_timer_interrupt.smp_apic_timer_interrupt
  1.90 ± 11% +96.3%   3.72 ± 41%  

linux-next: manual merge of the tip tree with the s390 tree

[Stephen Rothwell]

Hi all,

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

  arch/s390/lib/uaccess.c

between commit:

  cabc4abe8e36 ("s390/uaccess: remove uaccess_primary kernel parameter")

from the s390 tree and commit:

  ed79e946732e ("s390/uaccess, locking/static_keys: employ 
static_branch_likely()")

from the tip tree.

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

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

diff --cc arch/s390/lib/uaccess.c
index 0d002a746bec,93cb1d09493d..
--- a/arch/s390/lib/uaccess.c
+++ b/arch/s390/lib/uaccess.c
@@@ -370,10 -370,23 +370,10 @@@ long __strncpy_from_user(char *dst, con
  }
  EXPORT_SYMBOL(__strncpy_from_user);
  
 -/*
 - * The "old" uaccess variant without mvcos can be enforced with the
 - * uaccess_primary kernel parameter. This is mainly for debugging purposes.
 - */
 -static int uaccess_primary __initdata;
 -
 -static int __init parse_uaccess_pt(char *__unused)
 -{
 -  uaccess_primary = 1;
 -  return 0;
 -}
 -early_param("uaccess_primary", parse_uaccess_pt);
 -
  static int __init uaccess_init(void)
  {
 -  if (!uaccess_primary && test_facility(27))
 +  if (test_facility(27))
-   static_key_slow_inc(_mvcos);
+   static_branch_enable(_mvcos);
return 0;
  }
  early_initcall(uaccess_init);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: un4i-ss-cipher.c warning

[Herbert Xu]

On Wed, Aug 19, 2015 at 04:35:36PM +0200, Michal Suchanek wrote:
> Hello,
> 
> when building a kernel with sunxi crypto driver as merged into the
> sinxi-wip branch I get a compiler warning.
> 
> I am not sure this is the latest version of the driver. It does not
> seem to be in mainline yet.

The warning appears to be spurious as the code always ends up
initialising todo before using it.

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

Re: [PATCH v3 0/5] sync a se with its cfs_rq when att(det)aching it

[Byungchul Park]

On Thu, Aug 20, 2015 at 03:17:21AM +0200, Peter Zijlstra wrote:
> 
> I did something like this on top.. please have a look at the XXX and
> integrate.

yes, i will do it.

> 
> ---
> 
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2664,8 +2664,8 @@ static inline u64 cfs_rq_clock_task(stru
>  /* Group cfs_rq's load_avg is used for task_h_load and update_cfs_share */
>  static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
>  {
> - int decayed;
>   struct sched_avg *sa = _rq->avg;
> + int decayed;
>  
>   if (atomic_long_read(_rq->removed_load_avg)) {
>   long r = atomic_long_xchg(_rq->removed_load_avg, 0);
> @@ -2695,15 +2695,16 @@ static inline int update_cfs_rq_load_avg
>  static inline void update_load_avg(struct sched_entity *se, int update_tg)
>  {
>   struct cfs_rq *cfs_rq = cfs_rq_of(se);
> - int cpu = cpu_of(rq_of(cfs_rq));
>   u64 now = cfs_rq_clock_task(cfs_rq);
> + int cpu = cpu_of(rq_of(cfs_rq));
>  
>   /*
>* Track task load average for carrying it to new CPU after migrated, 
> and
>* track group sched_entity load average for task_h_load calc in 
> migration
>*/
>   __update_load_avg(now, cpu, >avg,
> - se->on_rq * scale_load_down(se->load.weight), cfs_rq->curr == 
> se, NULL);
> +   se->on_rq * scale_load_down(se->load.weight),
> +   cfs_rq->curr == se, NULL);
>  
>   if (update_cfs_rq_load_avg(now, cfs_rq) && update_tg)
>   update_tg_load_avg(cfs_rq, 0);
> @@ -2718,9 +2719,10 @@ static void attach_entity_load_avg(struc
>* update here. we have to update it with prev cfs_rq just before 
> changing
>* se's cfs_rq, and get here soon.
>*/
> - if (se->avg.last_update_time)
> + if (se->avg.last_update_time) {
>   __update_load_avg(cfs_rq->avg.last_update_time, 
> cpu_of(rq_of(cfs_rq)),
> - >avg, 0, 0, NULL);
> +   >avg, 0, 0, NULL);
> + }
>  
>   se->avg.last_update_time = cfs_rq->avg.last_update_time;
>   cfs_rq->avg.load_avg += se->avg.load_avg;
> @@ -2732,17 +2734,13 @@ static void attach_entity_load_avg(struc
>  static void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
> sched_entity *se)
>  {
>   __update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq_of(cfs_rq)),
> - >avg, se->on_rq * scale_load_down(se->load.weight),
> - cfs_rq->curr == se, NULL);
> +   >avg, se->on_rq * 
> scale_load_down(se->load.weight),
> +   cfs_rq->curr == se, NULL);
>  
> - cfs_rq->avg.load_avg =
> - max_t(long, cfs_rq->avg.load_avg - se->avg.load_avg, 0);
> - cfs_rq->avg.load_sum =
> - max_t(s64, cfs_rq->avg.load_sum - se->avg.load_sum, 0);
> - cfs_rq->avg.util_avg =
> - max_t(long, cfs_rq->avg.util_avg - se->avg.util_avg, 0);
> - cfs_rq->avg.util_sum =
> - max_t(s32, cfs_rq->avg.util_sum - se->avg.util_sum, 0);
> + cfs_rq->avg.load_avg = max_t(long, cfs_rq->avg.load_avg - 
> se->avg.load_avg, 0);
> + cfs_rq->avg.load_sum = max_t(s64,  cfs_rq->avg.load_sum - 
> se->avg.load_sum, 0);
> + cfs_rq->avg.util_avg = max_t(long, cfs_rq->avg.util_avg - 
> se->avg.util_avg, 0);
> + cfs_rq->avg.util_sum = max_t(s32,  cfs_rq->avg.util_sum - 
> se->avg.util_sum, 0);
>  }
>  
>  /* Add the load generated by se into cfs_rq's load average */
> @@ -2751,14 +2749,14 @@ enqueue_entity_load_avg(struct cfs_rq *c
>  {
>   struct sched_avg *sa = >avg;
>   u64 now = cfs_rq_clock_task(cfs_rq);
> - int migrated = 0, decayed;
> + int migrated, decayed;
>  
> - if (sa->last_update_time == 0)
> - migrated = 1;
> - else
> + migrated = !sa->last_update_time;
> + if (!migrated) {
>   __update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa,
>   se->on_rq * scale_load_down(se->load.weight),
>   cfs_rq->curr == se, NULL);
> + }
>  
>   decayed = update_cfs_rq_load_avg(now, cfs_rq);
>  
> @@ -2781,7 +2779,7 @@ dequeue_entity_load_avg(struct cfs_rq *c
>   cfs_rq->runnable_load_avg =
>   max_t(long, cfs_rq->runnable_load_avg - se->avg.load_avg, 0);
>   cfs_rq->runnable_load_sum =
> - max_t(s64, cfs_rq->runnable_load_sum - se->avg.load_sum, 0);
> + max_t(s64,  cfs_rq->runnable_load_sum - se->avg.load_sum, 0);
>  }
>  
>  /*
> @@ -2849,6 +2847,11 @@ static inline void
>  dequeue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) {}
>  static inline void remove_entity_load_avg(struct sched_entity *se) {}
>  
> +static inline void
> +attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) {}
> +static inline void
> +detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) {}
> +
>  static inline int idle_balance(struct rq 

Re: [PATCH v3 4/5] sched: sync a se with its cfs_rq when switching sched class to fair class

[Byungchul Park]

On Wed, Aug 19, 2015 at 07:12:41PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 19, 2015 at 03:47:15PM +0900, byungchul.p...@lge.com wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 1be042a..3419f6c 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -2711,6 +2711,17 @@ static inline void update_load_avg(struct 
> > sched_entity *se, int update_tg)
> >  
> >  static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
> > sched_entity *se)
> >  {
> > +   /*
> > +* in case of migration and cgroup-change, more care should be taken
> > +* because se's cfs_rq was changed, that means calling __update_load_avg
> > +* with new cfs_rq->avg.last_update_time is meaningless. so we skip the
> > +* update here. we have to update it with prev cfs_rq just before 
> > changing
> > +* se's cfs_rq, and get here soon.
> > +*/
> > +   if (se->avg.last_update_time)
> > +   __update_load_avg(cfs_rq->avg.last_update_time, 
> > cpu_of(rq_of(cfs_rq)),
> > +   >avg, 0, 0, NULL);
> > +
> > se->avg.last_update_time = cfs_rq->avg.last_update_time;
> > cfs_rq->avg.load_avg += se->avg.load_avg;
> > cfs_rq->avg.load_sum += se->avg.load_sum;
> 
> you seem to have forgotten to remove the same logic from
> enqueue_entity_load_avg(), which will now call __update_load_avg()
> twice.

i am sorry for not catching what you want to say. enqueue_entity_load_avg()
calls __update_load_avg() in normal case, that is, not having changed its 
cfs_rq, while in case having changed its cfs_rq, we only need to attach the
average load assuming that __update_load_avg() was already called when its
cfs_rq was changed.

is there anything i missed? could you let me know if yes?

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

Re: [PATCH v1 1/4] dmaengine: Add support for new feature CRC32C

[Vinod Koul]

On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote:
> This patch adds support for new feature CRC32C calculation in
> dmaengine framework.

Looks okay can you please update Documentation also

-- 
~Vinod

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

Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device

[Ard Biesheuvel]

On 19 August 2015 at 22:49, Gabriel L. Somlo  wrote:
> Hi Ard,
>
> On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote:
>> (missed some cc's)
>>
>> On 19 August 2015 at 11:38, Ard Biesheuvel  wrote:
>> > From: "Gabriel L. Somlo" 
>> >> Several different architectures supported by QEMU are set up with a
>> >> "firmware configuration" (fw_cfg) device, used to pass configuration
>> >> "blobs" into the guest by the host running QEMU.
>> >>
>> >> Historically, these config blobs were mostly of interest to the guest
>> >> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via
>> >> the command line, which makes them potentially interesting to userspace
>> >> (e.g. for passing early boot environment variables, etc.).
>> >>
>> >
>> > Does 'potentially interesting' mean you have a use case? Could you 
>> > elaborate?
>
> My personal one would be something like:
>
> cat > guestinfo.txt << EOT
>   KEY1="val1"
>   KEY2="val2"
>   ...
> EOT
>
> qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
>
> Then, from inside the guest:
>
>   . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
>
>   do_something_with $KEY1 $KEY2
>   ...
>
> But I'm thinking this is only one of the many positive things one
> could do with the ability to access random host-supplied blobs from
> guest userspace :)
>

'random host-supplied blobs' sounds awfully like files in a file
system to me, and that is already supported by QEMU and works with any
guest OS unmodified. If you are in control of the command line, surely
you can add a -drive xxx,fat:path/to/blobs -device xxx pair that
simply turns up as a volume.

>> >>   1/3 - probes for the qemu fw_cfg device in locations known to work on
>> >>   the supported architectures, in decreasing order of "likelihood".
>> >>
>> >>   While it *may* be possible to detect the presence of fw_cfg via
>> >>   acpi or dtb (on x86 and arm, respectively), there's no way I know
>> >>   of attempting that on sun4 and ppc/mac, so I've stuck with simply
>> >>   probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() 
>> >> function)
>> >>   in fw_cfg.c. I could use some advice on how else that could be
>> >>   done more elegantly, if needed.
>> >>
>> >
>> > Sorry, but this is really out of the question, at least on ARM, but surely 
>> > on
>> > other architectures as well. You can't just go around and probe random 
>> > memory
>> > addresses. Perhaps QEMU tolerates it, but on anything that resembles a real
>> > system, this will immediately blow up. Also, what happens if the QEMU 
>> > memory
>> > map changes? Add more probes addresses?
>> >
>> > It is not /that/ difficult to simply wire it up to the DT and ACPI
>> > infrastructures, there are plenty of examples in the kernel tree how to
>> > accomplish that. As a bonus, it removes all the arch specific knowledge
>> > from your code, which means that if QEMU grows support for another DT or
>> > ACPI based architecture, it will just work.
>
> I was *hoping* a successful call to request_[mem_]region() will be
> enough in the way of asking for permission before probing for the
> fw_cfg registers, but I realize that might still not be polite enough :)
>

No, all request_mem_region() does is check whether the region in
question is not occupied yet by another driver. So your probing could
access unpopulated memory space, or MMIO space owned by a peripheral
whose driver is not loaded. Neither are allowable, I'm afraid.

> DT on ARM is fine, and I'm certainly happy to learn how to do it (even
> though my main focus is, for now, x86). The unfortunate thing though
> is that on x86, fw_cfg is *not* AFAICT in ACPI, so I'd have to detour into
> first adding it in on the host side, before I can rewrite the guest side
> driver to look it up in there :)
>
>> > I am not sure how relevant sun4 and ppc/mac are for what you are trying to
>> > accomplish, but perhaps it would be best to focus on x86 and ARM for now
>> > and do it correctly. If the probing is actually needed, you can always add
>> > it later.
>
> I guess that's the direction things seem to be headed, although it would
> make me a bit sad to leave out sun and ppc right from the very beginning :)
>

Sorry to be blunt, but I am not convinced there is a need for this
driver anyway.

> PS. If you have one .c file in the kernel which does any of the DT-on-arm
> boilerplate I'm supposed to immitate, I'd appreciate the shortcut :)
>

Check out drivers/tty/serial/amba-pl011.c

> PS2. Do you happen to be in Seattle right now ? :)

Nope :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 char-misc-next 11/19] dma: Add support to program MIC x100 status descriptiors

[Vinod Koul]

On Mon, Jul 27, 2015 at 04:58:17PM -0700, Ashutosh Dixit wrote:
> +/* Program a status descriptor with phys as address and value to be written 
> */
> +static int mic_dma_do_status_update(struct mic_dma_chan *ch, dma_addr_t phys,
> + u64 value)
> +{
> + int ret = mic_dma_avail_desc_ring_space(ch, 4);
> +
> + if (ret < 0)
> + return ret;
> + ret = 0;
?
> + mic_dma_prep_status_desc(>desc_ring[ch->head],
> +  value, phys, false);
> + mic_dma_hw_ring_inc_head(ch);
> + return ret;

return 0 then?

> +}
> +
>  static inline void mic_dma_issue_pending(struct dma_chan *ch)
>  {
>   struct mic_dma_chan *mic_ch = to_mic_dma_chan(ch);
> @@ -287,9 +310,28 @@ mic_dma_prep_memcpy_lock(struct dma_chan *ch, dma_addr_t 
> dma_dest,
>   return NULL;
>  
>   spin_lock(_ch->prep_lock);
> + if (len == 8) {
magic number?

> + /*
> +  * This is a hack to program status descriptor since
> +  * DMA engine API doesn't have support for this.
> +  */
what do you mean by programming status descriptor, what do you need to
program?

-- 
~Vinod

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

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell 
Date: Thu, 20 Aug 2015 12:57:34 +1000

> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> net/ipv4/fib_semantics.c: In function 'fib_encap_match':
> net/ipv4/fib_semantics.c:553:3: error: implicit declaration of function 
> 'lwtstate_free' [-Werror=implicit-function-declaration]
>lwtstate_free(lwtstate);
>^
> 
> Caused by commit
> 
>   df383e6240ef ("lwtunnel: fix memory leak")
> 
> CONFIG_LWTUNNEL is not set for this build.
> 
> I reverted that commit for today.

Ought to already be fixed by:


From 824e7383e92815cb591793c74cc836aa5165f7f8 Mon Sep 17 00:00:00 2001
From: Ying Xue 
Date: Wed, 19 Aug 2015 15:46:17 +0800
Subject: [PATCH 1/2] lwtunnel: Fix the sparse warnings in fib_encap_match
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When CONFIG_LWTUNNEL config is not enabled, the lwtstate_free() is not
declared in lwtunnel.h at all. However, even in this case, the function
is still referenced in fib_semantics.c so that there appears the
following sparse warnings:

net/ipv4/fib_semantics.c:553:17: error: undefined identifier 'lwtstate_free'
  CC  net/ipv4/fib_semantics.o
  net/ipv4/fib_semantics.c: In function ‘fib_encap_match’:
  net/ipv4/fib_semantics.c:553:3: error: implicit declaration of function 
‘lwtstate_free’ [-Werror=implicit-function-declaration]
  cc1: some warnings being treated as errors
  make[1]: *** [net/ipv4/fib_semantics.o] Error 1
  make: *** [net/ipv4/fib_semantics.o] Error 2

To eliminate the error, we define an empty function for lwtstate_free()
in lwtunnel.h when CONFIG_LWTUNNEL is disabled.

Fixes: df383e6240ef ("lwtunnel: fix memory leak")
Cc: Jiri Benc 
Reported-by: kbuild test robot 
Signed-off-by: Ying Xue 
Acked-by: Jiri Benc 
Signed-off-by: David S. Miller 
---
 include/net/lwtunnel.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/net/lwtunnel.h b/include/net/lwtunnel.h
index 34fd8f7..cfee539 100644
--- a/include/net/lwtunnel.h
+++ b/include/net/lwtunnel.h
@@ -93,6 +93,10 @@ int lwtunnel_input6(struct sk_buff *skb);
 
 #else
 
+static inline void lwtstate_free(struct lwtunnel_state *lws)
+{
+}
+
 static inline struct lwtunnel_state *
 lwtstate_get(struct lwtunnel_state *lws)
 {
-- 
2.1.0

Re: [PATCH v8] dma: sun4i: Add support for the DMA engine on sun[457]i SoCs

[Vinod Koul]

On Sun, Jul 26, 2015 at 10:50:55PM +0200, Maxime Ripard wrote:
> From: Emilio López 
> 
> This patch adds support for the DMA engine present on Allwinner A10,
> A13, A10S and A20 SoCs. This engine has two kinds of channels: normal
> and dedicated. The main difference is in the mode of operation;
> while a single normal channel may be operating at any given time,
> dedicated channels may operate simultaneously provided there is no
> overlap of source or destination.
> 
> Hardware documentation can be found on A10 User Manual (section 12), A13
> User Manual (section 14) and A20 User Manual (section 1.12)

Applied with subsystem name fixed

-- 
~Vinod

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

[v2 4/5] NET: nps_enet: TX done acknowledge.

[Noam Camus]

From: Noam Camus 

This is needed for when TX done interrupt is in
"level mode".
For example it is true for some simulators of this device.

Signed-off-by: Noam Camus 
---
 drivers/net/ethernet/ezchip/nps_enet.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/ezchip/nps_enet.c 
b/drivers/net/ethernet/ezchip/nps_enet.c
index e553e6a..69b9129 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -150,6 +150,9 @@ static void nps_enet_tx_handler(struct net_device *ndev)
if (!priv->tx_packet_sent || tx_ctrl.ct)
return;
 
+   /* Ack Tx ctrl register */
+   nps_enet_reg_set(priv, NPS_ENET_REG_TX_CTL, 0);
+
/* Check Tx transmit error */
if (unlikely(tx_ctrl.et)) {
ndev->stats.tx_errors++;
-- 
1.7.1

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

[v2 5/5] NET: nps_enet: minor namespace cleanup

[Noam Camus]

From: Noam Camus 

We define buf_int_enable in the minimal namespace it is used.
Signed-off-by: Noam Camus 
---
 drivers/net/ethernet/ezchip/nps_enet.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/ezchip/nps_enet.c 
b/drivers/net/ethernet/ezchip/nps_enet.c
index 69b9129..63c2bcf 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -179,15 +179,16 @@ static int nps_enet_poll(struct napi_struct *napi, int 
budget)
 {
struct net_device *ndev = napi->dev;
struct nps_enet_priv *priv = netdev_priv(ndev);
-   struct nps_enet_buf_int_enable buf_int_enable;
u32 work_done;
 
-   buf_int_enable.rx_rdy = NPS_ENET_ENABLE;
-   buf_int_enable.tx_done = NPS_ENET_ENABLE;
nps_enet_tx_handler(ndev);
work_done = nps_enet_rx_handler(ndev);
if (work_done < budget) {
+   struct nps_enet_buf_int_enable buf_int_enable;
+
napi_complete(napi);
+   buf_int_enable.rx_rdy = NPS_ENET_ENABLE;
+   buf_int_enable.tx_done = NPS_ENET_ENABLE;
nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE,
 buf_int_enable.value);
}
-- 
1.7.1

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

[v2 3/5] NET: nps_enet: drop control frames

[Noam Camus]

From: Noam Camus 

We set controller to drop control frames and not trying
to pass them on. This is only needed for debug reasons.

Signed-off-by: Noam Camus 
---
 drivers/net/ethernet/ezchip/nps_enet.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/ezchip/nps_enet.c 
b/drivers/net/ethernet/ezchip/nps_enet.c
index 8b25f24..e553e6a 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -304,11 +304,8 @@ static void nps_enet_hw_enable_control(struct net_device 
*ndev)
 
/* Discard Packets bigger than max frame length */
max_frame_length = ETH_HLEN + ndev->mtu + ETH_FCS_LEN;
-   if (max_frame_length <= NPS_ENET_MAX_FRAME_LENGTH) {
+   if (max_frame_length <= NPS_ENET_MAX_FRAME_LENGTH)
ge_mac_cfg_3->max_len = max_frame_length;
-   nps_enet_reg_set(priv, NPS_ENET_REG_GE_MAC_CFG_3,
-ge_mac_cfg_3->value);
-   }
 
/* Enable interrupts */
buf_int_enable.rx_rdy = NPS_ENET_ENABLE;
@@ -336,11 +333,14 @@ static void nps_enet_hw_enable_control(struct net_device 
*ndev)
ge_mac_cfg_0.tx_fc_en = NPS_ENET_ENABLE;
ge_mac_cfg_0.rx_fc_en = NPS_ENET_ENABLE;
ge_mac_cfg_0.tx_fc_retr = NPS_ENET_GE_MAC_CFG_0_TX_FC_RETR;
+   ge_mac_cfg_3->cf_drop = NPS_ENET_ENABLE;
 
/* Enable Rx and Tx */
ge_mac_cfg_0.rx_en = NPS_ENET_ENABLE;
ge_mac_cfg_0.tx_en = NPS_ENET_ENABLE;
 
+   nps_enet_reg_set(priv, NPS_ENET_REG_GE_MAC_CFG_3,
+ge_mac_cfg_3->value);
nps_enet_reg_set(priv, NPS_ENET_REG_GE_MAC_CFG_0,
 ge_mac_cfg_0.value);
 }
-- 
1.7.1

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

[v2 2/5] NET: nps_enet: TX done race condition

[Noam Camus]

From: Noam Camus 

We need to set tx_skb pointer before send frame.
If we receive interrupt before we set pointer we will try
to free SKB with wrong pointer.
Now we are sure that SKB pointer will never be NULL during
handling TX done and check is removed.

Signed-off-by: Noam Camus 
---
 drivers/net/ethernet/ezchip/nps_enet.c |   10 +++---
 1 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/ezchip/nps_enet.c 
b/drivers/net/ethernet/ezchip/nps_enet.c
index 0e652b4..8b25f24 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -158,11 +158,7 @@ static void nps_enet_tx_handler(struct net_device *ndev)
ndev->stats.tx_bytes += tx_ctrl.nt;
}
 
-   if (priv->tx_skb) {
-   dev_kfree_skb(priv->tx_skb);
-   priv->tx_skb = NULL;
-   }
-
+   dev_kfree_skb(priv->tx_skb);
priv->tx_packet_sent = false;
 
if (netif_queue_stopped(ndev))
@@ -528,10 +524,10 @@ static netdev_tx_t nps_enet_start_xmit(struct sk_buff 
*skb,
/* This driver handles one frame at a time  */
netif_stop_queue(ndev);
 
-   nps_enet_send_frame(ndev, skb);
-
priv->tx_skb = skb;
 
+   nps_enet_send_frame(ndev, skb);
+
return NETDEV_TX_OK;
 }
 
-- 
1.7.1

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

[v2 0/5] *** nps_enet fixups ***

[Noam Camus]

From: Noam Camus 

Change v2
TX done is handled back with NAPI poll.

Change v1
This patch set is a bunch of fixes to make nps_enet work correctly with
all platforms, i.e. real device, emulation system, and simulation system.
The main trigger for this patch set was that in our emulation system
the TX end interrupt is "edge-sensitive" and therefore we cannot use the
cause register since it is not sticky.
Also:
TX is handled during HW interrupt context and not NAPI job.
race with TX done was fixed.
added acknowledge for TX when device is "level sensitive".
enable drop of control frames which is not needed for regular usage.

So most of this patch set is about TX handling, which is now more complete.

Noam Camus (5):
  NET: nps_enet: replace use of cause register
  NET: nps_enet: TX done race condition
  NET: nps_enet: drop control frames
  NET: nps_enet: TX done acknowledge.
  NET: nps_enet: minor namespace cleanup

 drivers/net/ethernet/ezchip/nps_enet.c |   37 ---
 drivers/net/ethernet/ezchip/nps_enet.h |   20 -
 2 files changed, 19 insertions(+), 38 deletions(-)

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

[v2 1/5] NET: nps_enet: replace use of cause register

[Noam Camus]

From: Noam Camus 

When interrupt is received we read directly from control
register for RX/TX instead of reading cause register
since this register fails to indicate TX done when
TX interrupt is "edge mode".

Signed-off-by: Noam Camus 
---
 drivers/net/ethernet/ezchip/nps_enet.c |9 +
 drivers/net/ethernet/ezchip/nps_enet.h |   20 
 2 files changed, 5 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/ezchip/nps_enet.c 
b/drivers/net/ethernet/ezchip/nps_enet.c
index 24a85b2..0e652b4 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -211,12 +211,13 @@ static irqreturn_t nps_enet_irq_handler(s32 irq, void 
*dev_instance)
 {
struct net_device *ndev = dev_instance;
struct nps_enet_priv *priv = netdev_priv(ndev);
-   struct nps_enet_buf_int_cause buf_int_cause;
+   struct nps_enet_rx_ctl rx_ctrl;
+   struct nps_enet_tx_ctl tx_ctrl;
 
-   buf_int_cause.value =
-   nps_enet_reg_get(priv, NPS_ENET_REG_BUF_INT_CAUSE);
+   rx_ctrl.value = nps_enet_reg_get(priv, NPS_ENET_REG_RX_CTL);
+   tx_ctrl.value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
 
-   if (buf_int_cause.tx_done || buf_int_cause.rx_rdy)
+   if ((!tx_ctrl.ct && priv->tx_packet_sent) || rx_ctrl.cr)
if (likely(napi_schedule_prep(>napi))) {
nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE, 0);
__napi_schedule(>napi);
diff --git a/drivers/net/ethernet/ezchip/nps_enet.h 
b/drivers/net/ethernet/ezchip/nps_enet.h
index fc45c9d..6703674 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.h
+++ b/drivers/net/ethernet/ezchip/nps_enet.h
@@ -36,7 +36,6 @@
 #define NPS_ENET_REG_RX_CTL0x810
 #define NPS_ENET_REG_RX_BUF0x818
 #define NPS_ENET_REG_BUF_INT_ENABLE0x8C0
-#define NPS_ENET_REG_BUF_INT_CAUSE 0x8C4
 #define NPS_ENET_REG_GE_MAC_CFG_0  0x1000
 #define NPS_ENET_REG_GE_MAC_CFG_1  0x1004
 #define NPS_ENET_REG_GE_MAC_CFG_2  0x1008
@@ -108,25 +107,6 @@ struct nps_enet_buf_int_enable {
};
 };
 
-/* Interrupt cause for data buffer events register */
-struct nps_enet_buf_int_cause {
-   union {
-   /* tx_done: Interrupt in the case when current frame was
-*  read from TX buffer.
-* rx_rdy:  Interrupt in the case when new frame is ready
-*  in RX buffer.
-*/
-   struct {
-   u32
-   __reserved:30,
-   tx_done:1,
-   rx_rdy:1;
-   };
-
-   u32 value;
-   };
-};
-
 /* Gbps Eth MAC Configuration 0 register */
 struct nps_enet_ge_mac_cfg_0 {
union {
-- 
1.7.1

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

[PATCH] sched/idle/x86: add missing trace_cpu_idle to mwait_idle()

[Jisheng Zhang]

Commit b253149b843f ("sched/idle/x86: Restore mwait_idle() to fix boot
hangs, to improve power savings and to improve performance") restores
mwait_idle(), but the trace_cpu_idle related callings are missing,
this causes powertop on my old desktop powered by Intel Core2 E6550
reports zero wakeups and zero events.

After this patch, the powertop tool works again.

Signed-off-by: Jisheng Zhang 
Fixes: b253149b843f ("sched/idle/x86: Restore mwait_idle() to ...")
---
 arch/x86/kernel/process.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 397688b..c27cad7 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -408,6 +408,7 @@ static int prefer_mwait_c1_over_halt(const struct 
cpuinfo_x86 *c)
 static void mwait_idle(void)
 {
if (!current_set_polling_and_test()) {
+   trace_cpu_idle_rcuidle(1, smp_processor_id());
if (this_cpu_has(X86_BUG_CLFLUSH_MONITOR)) {
smp_mb(); /* quirk */
clflush((void *)_thread_info()->flags);
@@ -419,6 +420,7 @@ static void mwait_idle(void)
__sti_mwait(0, 0);
else
local_irq_enable();
+   trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
} else {
local_irq_enable();
}
-- 
2.5.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 v3 08/14] phy: Add driver for rockchip Display Port PHY

[Kishon Vijay Abraham I]

Hi,

On Wednesday 19 August 2015 08:21 PM, Yakir Yang wrote:
> Signed-off-by: Yakir Yang 

where's the commit message?
> ---
> Changes in v3:
> - Take Heiko suggest, add rockchip dp phy driver,
>   collect the phy clocks and power control.
> 
> Changes in v2: None
> 
>  .../devicetree/bindings/phy/rockchip-dp-phy.txt|  26 +++
>  drivers/phy/Kconfig|   7 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-rockchip-dp.c  | 185 
> +
>  4 files changed, 219 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>  create mode 100644 drivers/phy/phy-rockchip-dp.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> new file mode 100644
> index 000..5de1088
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> @@ -0,0 +1,26 @@
> +Rockchip Soc Seroes Display Port PHY
> +
> +
> +Required properties:
> +- compatible : should be one of the following supported values:
> +  - "rockchip.rk3288-dp-phy"
> +
> +- reg : a list of registers used by phy driver
> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +- clock-names: from common clock binding:
> + Required elements: "sclk_dp" "sclk_dp_24m"
> +
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> +- #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Example:
> +
> +edp_phy: phy@ff770274 {
> + compatilble = "rockchip,rk3288-dp-phy";
> + reg = <0xff770274 4>;
> + rockchip,grf = <>;
> + clocks = < SCLK_EDP_24M>;
> + clock-names = "24m";
> + #phy-cells = <0>;
> +}
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 6b8dd16..da00440 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -297,6 +297,13 @@ config PHY_ROCKCHIP_USB
>   help
> Enable this to support the Rockchip USB 2.0 PHY.
>  
> +config PHY_ROCKCHIP_DP
> + tristate "Rockchip Display Port PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY
> + help
> +   Enable this to support the Rockchip Display Port PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
>   tristate "ST SPEAR1310-MIPHY driver"
>   select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index f344e1b..35e3ce6 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -33,6 +33,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)  += 
> phy-s5pv210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)  += phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)  += phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..4759111
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,185 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GRF_SOC_CON12   0x0274
> +#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
> +
> +#define DP_PHY_SIDDQ_WRITE_EN   BIT(21)
> +#define DP_PHY_SIDDQ_ON 0
> +#define DP_PHY_SIDDQ_OFFBIT(5)
> +
> +struct rockchip_dp_phy {
> + struct device  *dev;
> + struct regmap  *grf;
> + void __iomem   *regs;
> + struct clk *phy_24m;
> +};
> +
> +static int rockchip_dp_phy_clk_enable(struct rockchip_dp_phy *dp)
> +{
> + int ret = 0;
> +
> + ret = clk_set_rate(dp->phy_24m, 2400);
> + if (ret < 0) {
> + dev_err(dp->dev, "cannot set clock phy_24m %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(dp->phy_24m);
> + if (ret < 0) {
> + dev_err(dp->dev, "cannot enable clock phy_24m %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int rockchip_dp_phy_clk_disable(struct rockchip_dp_phy *dp)
> +{
> + clk_disable_unprepare(dp->phy_24m);
> +
> + return 0;
> +}
> +
> +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> +{
> + struct rockchip_dp_phy *dp = 

Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver

[Archit Taneja]

Hi,

On 08/19/2015 08:18 PM, Yakir Yang wrote:


Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM ;)

Beyond that, there are three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).

I have verified this series on two kinds of rockchip platform board, one
is rk3288 sdk board which connect with a 2K display port monitor, the other
is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
both of them works rightlly.

I haven't verified the dp function on samsung platform, cause I haven't got
exynos boards. I can only ensure that there are no build error on samsung
platform, wish some samsung guys help to test. ;)

Thanks,
- Yakir

Changes in v3:
- Take Thierry Reding suggest, move exynos's video_timing code
   to analogix_dp-exynos platform driver, add get_modes method
   to struct analogix_dp_plat_data.
- Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
- Take Thierry Reding suggest, dynamic parse video timing info from
   struct drm_display_mode and struct drm_display_info.
- Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
   the DT property value directly, but we can take those as hardware limite.
   For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
   so DT property would like "link-rate = 0x0a" "lane-count = 4".
- Take Heiko suggest, add devicetree binding documents.
- Take Thierry Reding suggest, remove sync pol & colorimetry properies
   from the new analogix dp driver devicetree binding.
- Update the exist exynos dtsi file with the latest DP DT properies.
- Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
   dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
   core driver which name to "dp", and leave "pclk_edp" to rockchip dp platform
   driver which name to "pclk".
- Take Heiko suggest, add devicetree binding document.
- Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote
   point to get panel node.
- Add the new function point analogix_dp_platdata.get_modes init.
- Take Heiko suggest, add rockchip dp phy driver,
   collect the phy clocks and power control.
- Add "analogix,need-force-hpd" to indicate whether driver need foce
   hpd when hpd detect failed.
- move dp hpd detect to connector detect function.
- Add edid modes parse support

Changes in v2:
- Take Joe Preches advise, improved commit message more readable, and
   avoid using some uncommon style like bellow:
   -  retval = exynos_dp_read_bytes_from_i2c(...
...)
   +  retval =
   +  exynos_dp_read_bytes_from_i2c(..);
- Take Jingoo Han suggest, just remove my name from author list.
- Take Jingoo Han suggest, remove new copyright
- Fix compiled failed dut to analogix_dp_device misspell
- Take Heiko suggest, get panel node with remote-endpoint method,
   and create devicetree binding for driver.
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
   leave those clock to rockchip dp phy driver.
- Add GNU license v2 declared and samsung copyright
- Fix compile failed dut to phy_pd_addr variable misspell error

Yakir Yang (14):
   drm: exynos/dp: fix code style
   drm: exynos/dp: convert to drm bridge mode
   drm: bridge: analogix_dp: split exynos dp driver to bridge dir
   drm: bridge/analogix_dp: dynamic parse sync_pol & interlace &
 colorimetry
   drm: bridge/analogix_dp: fix link_rate & lane_count bug
   Documentation: drm/bridge: add document for analogix_dp
   drm: rockchip/dp: add rockchip platform dp driver
   phy: Add driver for rockchip Display Port PHY
   drm: bridge/analogix_dp: add platform device type support
   drm: bridge: analogix_dp: add some rk3288 special registers setting
   drm: bridge: analogix_dp: try force hpd after plug in lookup failed
   drm: bridge/analogix_dp: expand the delay time for hpd detect
   drm: bridge/analogix_dp: move hpd detect to connector detect function
   drm: bridge/analogix_dp: add edid modes parse in get_modes method

  .../devicetree/bindings/drm/bridge/analogix_dp.txt |   73 +
  .../devicetree/bindings/phy/rockchip-dp-phy.txt|   26 +
  .../bindings/video/analogix_dp-rockchip.txt|   83 ++
  .../devicetree/bindings/video/exynos_dp.txt|   51 +-
  arch/arm/boot/dts/exynos5250-arndale.dts   |   10 +-
  

[PATCH] perf probe: Try to use symbol table if searching debug info failed

[Wang Nan]

A problem can occure in statically linked perf when vmlinux can be found:

 # perf probe --add sys_epoll_pwait
 probe-definition(0): sys_epoll_pwait
 symbol:sys_epoll_pwait file:(null) line:0 offset:0 return:0 lazy:(null)
 0 arguments
 Looking at the vmlinux_path (7 entries long)
 Using /lib/modules/4.2.0-rc1+/build/vmlinux for symbols
 Open Debuginfo file: /lib/modules/4.2.0-rc1+/build/vmlinux
 Try to find probe point from debuginfo.
 Symbol sys_epoll_pwait address found : 8122bd40
 Matched function: SyS_epoll_pwait
 Failed to get call frame on 0x8122bd40
 An error occurred in debuginfo analysis (-2).
   Error: Failed to add events. Reason: No such file or directory (Code: -2)

The reason is caused by libdw that, if libdw is statically linked, it can't
load libebl_{arch}.so reliable.

In this case it is still possible to get the address from /proc/kalksyms.
However, perf tries that only when libdw returns -EBADF.

This patch gives it another chance to utilize symbol table, even if libdw
return error code other than -EBADF.

After applying this patch:

 # perf probe -nv --add sys_epoll_pwait
 probe-definition(0): sys_epoll_pwait
 symbol:sys_epoll_pwait file:(null) line:0 offset:0 return:0 lazy:(null)
 0 arguments
 Looking at the vmlinux_path (7 entries long)
 Using /lib/modules/4.2.0-rc1+/build/vmlinux for symbols
 Open Debuginfo file: /lib/modules/4.2.0-rc1+/build/vmlinux
 Try to find probe point from debuginfo.
 Symbol sys_epoll_pwait address found : 8122bd40
 Matched function: SyS_epoll_pwait
 Failed to get call frame on 0x8122bd40
 An error occurred in debuginfo analysis (-2).
 Trying to use symbols.
 Opening /sys/kernel/debug/tracing/kprobe_events write=1
 Added new event:
 Writing event: p:probe/sys_epoll_pwait _text+2276672
   probe:sys_epoll_pwait (on sys_epoll_pwait)

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

perf record -e probe:sys_epoll_pwait -aR sleep 1

Although libdw returns an error (Failed to get call frame),
perf tries symbol table and finally gets correct address.

Signed-off-by: Wang Nan 
---
 tools/perf/util/probe-event.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index fe4941a..f07374b 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -705,9 +705,10 @@ static int try_to_find_probe_trace_events(struct 
perf_probe_event *pev,
}
/* Error path : ntevs < 0 */
pr_debug("An error occurred in debuginfo analysis (%d).\n", ntevs);
-   if (ntevs == -EBADF) {
-   pr_warning("Warning: No dwarf info found in the vmlinux - "
-   "please rebuild kernel with CONFIG_DEBUG_INFO=y.\n");
+   if (ntevs < 0) {
+   if (ntevs == -EBADF)
+   pr_warning("Warning: No dwarf info found in the vmlinux 
- "
+   "please rebuild kernel with 
CONFIG_DEBUG_INFO=y.\n");
if (!need_dwarf) {
pr_debug("Trying to use symbols.\n");
return 0;
-- 
1.8.3.4

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

Re: [PATCH] powerpc/hvsi: Fix endianness issues in the HVSI driver

[Michael Ellerman]

On Thu, 2015-08-20 at 11:40 +1000, Michael Ellerman wrote:
> On Wed, 2015-08-19 at 23:53 +0200, Laurent Dufour wrote:
> > On 04/08/2015 02:51, Michael Ellerman wrote:
> > > On Fri, 2015-07-31 at 11:29 +0200, Laurent Dufour wrote:
> > >> This patch fixes several endianness issues detected when running the HVSI
> > >> driver in little endian mode.
> > >>
> > >> These issues are raised in little endian mode because the data exchanged 
> > >> in
> > >> memory between the kernel and the hypervisor has to be in big endian
> > >> format.

...
>
> So it seems you fixed all the issues, or at least all the issues we can detect
> with sparse. So I'll merge this as-is with an updated changelog.

Unless Greg wants to merge it? But I'll assume he's not bothered unless he says
otherwise as it's a powerpc only driver.

cheers



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

Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

[Archit Taneja]

Hi Thierry, Lucas,


On 08/19/2015 08:32 PM, Thierry Reding wrote:

On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:

Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:

On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:

Hi Thierry, Archit,


[...]

Perhaps a better way would be to invert this relationship. According to
your proposal we'd have to have DT like this:

i2c@... {
...

dsi-device@... {
...
dsi-bus = <>;
...
};

...
};

dsi@... {
...
};

Inversing the relationship would become something like this:

i2c@... {
...
};

dsi@... {
...

peripheral@... {
...
i2c-bus = <>;
...
};

...
};

Both of those aren't fundamentally different, and they both have the
disavantage of lacking ways to transport configuration data that the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI VC).

So how about we create two devices in the device tree and fuse them at
the driver level:

i2c@... {
...

i2cdsi: dsi-device@... {
...
};

...
};

dsi@... {
...

peripheral@... {
...
control = <>;
...
};

...
};

This way we'll get both an I2C device and a DSI device that we can fully
describe using the standard device tree bindings. At driver time we can
get the I2C device from the phandle in the control property of the DSI
device and use it to execute I2C transactions.


I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.

Devicetree is structured along the control buses, even if the devices
are connected to multiple buses, in the DT they are always children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is clearly
a child of the i2c master controller and only of that one.


I think that's a flawed interpretation of what's going on here. The
device in fact has two interfaces: one is I2C, the other is DSI. In my
opinion that's reason enough to represent it as two logical devices.


Does it really have 2 control interfaces that are used at the same time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?


The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.


If you need to model connections between devices that are not reflected
through the control bus hierarchy you should really consider using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)


The problem is that the original proposal would instantiate a dummy
device, so it wouldn't be represented in DT at all. So unless you do add
two logical devices to DT (one for each bus interface), you don't have
anything to glue together with an OF graph.


I see that the having dummy device is the least desirable solution. But
if there is only one control bus to the device I think it should be one
device sitting beneath the control bus.

You can then use of-graph to model the data path between the DSI encoder
and device.


But you will be needing a device below the DSI host controller to
represent that endpoint of the connection. The DSI host controller
itself is in no way connected to the I2C adapter. You would have to
add some sort of quirk to the DSI controller binding to allow it to


Thanks for the review.

I implemented this to support ADV7533 DSI to HDMI encoder chip, which
has a DSI video bus and an i2c control bus.

There weren't any quirks as such in the device tree when I tried to
implement this. The DT seems to manage fine without a node
corresponding to a mipi_dsi_device:

i2c_adap@.. {
adv7533@.. {

port {
adv_in: endpoint {
remote-endpoint = <_out>;
};
};
};
};

dsi_host@.. {
...
...

port {
dsi_out: endpoint {
remote-endpoint = <_in>;
}
};
};

It's the i2c driver's job to parse the graph and retrieve the
phandle to the dsi host. Using this, it can proceed with
registering itself to this host using the new dsi funcs. This
patch does the same for the adv7533 i2c 

Re: [PATCH] sha: Enable cpuid check for Intel SHA extensions implementations

[Borislav Petkov]

On Wed, Aug 19, 2015 at 09:49:58AM -0700, Tim Chen wrote:
> On Tue, 2015-08-18 at 18:46 +0200, Thomas Gleixner wrote:
> > On Mon, 17 Aug 2015, Tim Chen wrote:
> > > Signed-off-by: Chandramouli Narayanan 
> > > Signed-off-by: Tim Chen 
> > 
> > And now the question who authored this complex one liner 
> > 
> 
> Mouli did the patch originally but he left the company.  So
> I'm picking it up.

So the SOB chain should be:

From: you



Originally-by: Mouli
Signed-off-by: you

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(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 v2] dmaengine: fsl-edma: add PM suspend/resume support

[Vinod Koul]

On Mon, Aug 17, 2015 at 02:10:46PM -0500, Li Yang wrote:
> >> Think of it from the end user perspective. Would you like your laptop (or
> >> whatever) to refuse to suspend because of this condition? The user may well
> >> expect that closing the lid on their laptop will reliably lead to it 
> >> suspending to
> >> ram. Returning a failure here could result in a loss of data if the 
> >> condition is not
> >> detected and the machine subsequently runs out of power.
> >>
> >
> > Yes, the user may well expect that closing the lid on their laptop will 
> > reliably lead to it suspending to ram.
> > So the client(the user of the DMA) must  to PAUSE or terminate the DMA 
> > transmission.
> >
> > We need to rely on client doing the right thing here.
> > The DMA should not make a decision instead of client.
> > If the DMA is not idle in DMA suspend, it should be the client's issue.
> > We don't know what the client really want to do, so just return the 
> > non-success value.
> 
> The problem here is that neither the client nor the DMA controller
> driver should easily decide to stop the suspend entrance and rollback.
> I don't think the non-idle situation is serious enough to cause a
> rollback.  You should do whatever can be done with the DMA
> controller(such as stop the controller and leave whatever to be done
> to the wake up) and continue with the suspend.

Ideally yes client should suspend first and dmaengine driver then being idle
when suspend is invoked. But we know we are in idle world!
So, driver should ensure it suspends the active channels and then goes to
suspend and restores that on resume

-- 
~Vinod

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

Re: [PATCH RESEND 0/2] mtd: nand: pxa3xx-nand: fixes

[Brian Norris]

On Wed, Aug 19, 2015 at 06:18:57PM -0300, Ezequiel Garcia wrote:
> On 19 August 2015 at 15:30, Robert Jarzmik  wrote:
> > Hi Brian,
> >
> > As promised, here are the remaining fixes I have on pxa3xx-nand I'd like 
> > you to
> > queue up. The other changes I have submitted are under review and not of 
> > "fixes" type.
> >
> > Cheers.
> >
> > --
> > Robert
> >
> > Robert Jarzmik (2):
> >   mtd: nand: pxa3xx_nand: fix early spurious interrupt
> >   mtd: nand: pxa3xx-nand: fix random command timeouts
> >
> 
> For both patches:
> 
> Acked-by: Ezequiel Garcia 
> 
> I tested this on Armada 370:
> 
> Tested-by: Ezequiel Garcia 

Pushed both to l2-mtd.git, with Ezequiel's tags. Thanks for collecting
the patches, testing, and reviewing.

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

Re: [PATCH v10 03/20] x86/stackvalidate: Compile-time stack validation

[Josh Poimboeuf]

On Wed, Aug 19, 2015 at 12:01:38PM +0200, Ingo Molnar wrote:
> 
> * Josh Poimboeuf  wrote:
> 
> > On Sat, Aug 15, 2015 at 12:23:54AM -0700, Andrew Morton wrote:
> > > On Thu, 13 Aug 2015 22:10:24 -0500 Josh Poimboeuf  
> > > wrote:
> > > 
> > > > This adds a CONFIG_STACK_VALIDATION option which enables a host tool
> > > > named stackvalidate which runs at compile time.
> > > 
> > > It would be useful to
> > > 
> > > - show example output for a typical error site
> > > 
> > > - describe the consequences of that error (ie: why should we fix
> > >   these things?)
> > > 
> > > - describe what needs to be done to repair these sites.
> > > 
> > > 
> > > IOW, what do we gain from merging all this stuff?
> > 
> > I attempted to do all that in Documentation/stack-validation.txt which
> > is in patch 03/20.  Does it address your concerns?  Here it is:
> 
> I think it answers the first and third question, but not the second one:
> 
> - describe the consequences of that error (ie: why should we fix
>   these things?)
> 
> would be nice to document all that richly.

Ok.  I've tried to answer the "why" question from both a broad
perspective ("why do we need stackvalidate?") as well as for each of the
rules that it enforces.

---8<---

Subject: [PATCH] stackvalidate: Document why it's needed

Signed-off-by: Josh Poimboeuf 
---
 Documentation/stack-validation.txt | 122 +++--
 1 file changed, 118 insertions(+), 4 deletions(-)

diff --git a/Documentation/stack-validation.txt 
b/Documentation/stack-validation.txt
index c3d3d35..94dad40 100644
--- a/Documentation/stack-validation.txt
+++ b/Documentation/stack-validation.txt
@@ -24,6 +24,101 @@ instructions).  Similarly, it knows how to follow switch 
statements, for
 which gcc sometimes uses jump tables.
 
 
+Why do we need stack validation?
+
+
+Here are some of the benefits of validating stack metadata:
+
+a) More reliable stack traces for frame pointer enabled kernels
+
+   Frame pointers are used for debugging purposes.  They allow runtime
+   code and debug tools to be able to walk the stack to determine the
+   chain of function call sites that led to the currently executing
+   code.
+
+   For some architectures, frame pointers are enabled by
+   CONFIG_FRAME_POINTER.  For some other architectures they may be
+   required by the ABI (sometimes referred to as "backchain pointers").
+
+   For C code, gcc automatically generates instructions for setting up
+   frame pointers when the -fno-omit-frame-pointer option is used.
+
+   But for asm code, the frame setup instructions have to be written by
+   hand, which most people don't do.  So the end result is that
+   CONFIG_FRAME_POINTER is honored for C code but not for most asm code.
+
+   For stack traces based on frame pointers to be reliable, all
+   functions which call other functions must first create a stack frame
+   and update the frame pointer.  If a first function doesn't properly
+   create a stack frame before calling a second function, the *caller*
+   of the first function will be skipped on the stack trace.
+
+   The benefit of stackvalidate here is that it ensures that *all*
+   functions honor CONFIG_FRAME_POINTER.  As a result, no functions will
+   ever [*] be skipped on a stack trace.
+
+   [*] unless an interrupt or exception has occurred at the very
+   beginning of a function before the stack frame has been created,
+   or at the very end of the function after the stack frame has been
+   destroyed.  This is an inherent limitation of frame pointers.
+
+b) 100% reliable stack traces for DWARF enabled kernels
+
+   (NOTE: This is not yet implemented)
+
+   As an alternative to frame pointers, DWARF Call Frame Information
+   (CFI) metadata can be used to walk the stack.  Unlike frame pointers,
+   CFI metadata is out of band.  So it doesn't affect runtime
+   performance and it can be reliable even when interrupts or exceptions
+   are involved.
+
+   For C code, gcc automatically generates DWARF CFI metadata.  But for
+   asm code, generating CFI is a tedious manual approach which requires
+   manually placed .cfi assembler macros to be scattered throughout the
+   code.  It's clumsy and very easy to get wrong, and it makes the real
+   code harder to read.
+
+   Stackvalidate will improve this situation in several ways.  For code
+   which already has CFI annotations, it will validate them.  For code
+   which doesn't have CFI annotations, it will generate them.  So an
+   architecture can opt to strip out all the manual .cfi annotations
+   from their asm code and have stackvalidate generate them instead.
+
+   We might also add a runtime stack validation debug option where we
+   periodically walk the stack from schedule() and/or an NMI to ensure
+   that the stack metadata is sane and that we reach the bottom of the
+   stack.
+
+   So the benefit of stackvalidate here will be that external tooling
+   should 

Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Mike Galbraith]

On Wed, 2015-08-19 at 09:41 -0700, Tejun Heo wrote:

> Most problems can be solved in different ways and I'm doubtful that
> e.g. bouncing jobs to worker threads would be more expensive than
> migrating the worker back and forth in a lot of cases.  If migrating
> threads around floats somebody's boat, that's fine but that has never
> been and can't be the focus of design and optimization, not at the
> cost of the actual hot paths.

If create/attach/detach/destroy aren't hot paths, what is?  Those are
fork/exec/exit cgroup analogs.  If you have thousands upon thousands of
potentially active cgroups (aka customers), you wouldn't want to keep
them all around just in case when you can launch cgroup tasks the same
way we launch any other task.  You wouldn't contemplate slowing down
fork/exec/exit, but create/attach/detach/destroy are one and the same..
they need to be just as fast/light as they can be, as they are part and
parcel of the higher level process.

That's why my hack ended up in a large enterprise outfit's product, it
was _needed_ to fix up cgroups performance suckage.  That suckage was
fixed up properly quite a bit later.

Anyway, if what they or anybody like them can currently do with their
job launcher/manager gizmos is negatively impacted, they can gripe for
themselves.  All I'm saying is that there are definitely users out there
to whom create/attach/detach/destroy are highly important.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] sched: sync a se with its cfs_rq when switching sched class to fair class

[Yuyang Du]

On Wed, Aug 19, 2015 at 07:12:41PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 19, 2015 at 03:47:15PM +0900, byungchul.p...@lge.com wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 1be042a..3419f6c 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -2711,6 +2711,17 @@ static inline void update_load_avg(struct 
> > sched_entity *se, int update_tg)
> >  
> >  static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
> > sched_entity *se)
> >  {
> > +   /*
> > +* in case of migration and cgroup-change, more care should be taken
> > +* because se's cfs_rq was changed, that means calling __update_load_avg
> > +* with new cfs_rq->avg.last_update_time is meaningless. so we skip the
> > +* update here. we have to update it with prev cfs_rq just before 
> > changing
> > +* se's cfs_rq, and get here soon.
> > +*/
> > +   if (se->avg.last_update_time)
> > +   __update_load_avg(cfs_rq->avg.last_update_time, 
> > cpu_of(rq_of(cfs_rq)),
> > +   >avg, 0, 0, NULL);
> > +
> > se->avg.last_update_time = cfs_rq->avg.last_update_time;
> > cfs_rq->avg.load_avg += se->avg.load_avg;
> > cfs_rq->avg.load_sum += se->avg.load_sum;
> 
> you seem to have forgotten to remove the same logic from
> enqueue_entity_load_avg(), which will now call __update_load_avg()
> twice.

In case of enqueue_entity_load_avg(), that seems to be ok.

However, the problem is that he made it "entangled":

In enqueue_entity_load_avg():

if (migrated)
attach_entity_load_avg();

while in attach_entity_load_avg():

if (!migrated)
__update_load_avg();

so, if attach() is called from enqueue(), that if() is never true.

To Byungchul,

1) I suggest you not entangle the entire series by mixing problem
   sovling with code manipulating. That said, it is better you
   first solve the "move between task group" problem and the
   switch_to/from problem (if it is a problem, either way, comment
   with your explanation to how you deal with the lost record and why).
2) After that, make the code cleaner, without change to logic, especially
   avoid entangling the logic in order to do the code manipulation.
3) If you don't hate upper case letter, use it properly.

If it helps.

Thanks,
Yuyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/5] KVM: add KVM_REQ_EXIT request for userspace exit

[Wanpeng Li]

On 8/14/15 6:08 PM, Radim Krčmář wrote:

When userspace wants KVM to exit to userspace, it sends a signal.
This has a disadvantage of requiring a change to the signal mask because
the signal needs to be blocked in userspace to stay pending when sending
to self.

Using a request flag allows us to shave 200-300 cycles from every
userspace exit and the speedup grows with NUMA because unblocking
touches shared spinlock.

The disadvantage is that it adds an overhead of one bit check for all
kernel exits.  A quick tracing shows that the ratio of userspace exits
after boot is about 1/5 and in subsequent run of nmap and kernel compile
has about 1/60, so the check should not regress global performance.

All signal_pending() calls are userspace exit requests, so we add a
check for KVM_REQ_EXIT there.  There is one omitted call in kvm_vcpu_run
because KVM_REQ_EXIT is implied in earlier check for requests.


Actually I see more SIGUSR1 signals are intercepted by signal_pending() 
in vcpu_enter_guest() and vcpu_run() w/ win7 guest and kernel_irqchip=off.


Regards,
Wanpeng Li



Signed-off-by: Radim Krčmář 
---
  arch/x86/kvm/vmx.c   | 2 +-
  arch/x86/kvm/x86.c   | 6 ++
  include/linux/kvm_host.h | 8 +++-
  include/uapi/linux/kvm.h | 1 +
  virt/kvm/kvm_main.c  | 2 +-
  5 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 40c6180a0ecb..2b789a869ef5 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5833,7 +5833,7 @@ static int handle_invalid_guest_state(struct kvm_vcpu 
*vcpu)
goto out;
}
  
-		if (signal_pending(current))

+   if (kvm_need_exit(vcpu))
goto out;
if (need_resched())
schedule();
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e5850076bf7b..c3df7733af09 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6548,6 +6548,11 @@ static int vcpu_run(struct kvm_vcpu *vcpu)
++vcpu->stat.signal_exits;
break;
}
+   if (unlikely(kvm_has_request(KVM_REQ_EXIT, vcpu))) {
+   r = 0;
+   vcpu->run->exit_reason = KVM_EXIT_REQUEST;
+   break;
+   }
if (need_resched()) {
srcu_read_unlock(>srcu, vcpu->srcu_idx);
cond_resched();
@@ -6684,6 +6689,7 @@ out:
post_kvm_run_save(vcpu);
if (vcpu->sigset_active)
sigprocmask(SIG_SETMASK, , NULL);
+   clear_bit(KVM_REQ_EXIT, >requests);
  
  	return r;

  }
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 52e388367a26..dcc57171e3ec 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -121,7 +121,7 @@ static inline bool is_error_page(struct page *page)
  #define KVM_REQ_UNHALT 6
  #define KVM_REQ_MMU_SYNC   7
  #define KVM_REQ_CLOCK_UPDATE   8
-#define KVM_REQ_KICK   9
+#define KVM_REQ_EXIT   9
  #define KVM_REQ_DEACTIVATE_FPU10
  #define KVM_REQ_EVENT 11
  #define KVM_REQ_APF_HALT  12
@@ -1104,6 +1104,12 @@ static inline bool kvm_check_request(int req, struct 
kvm_vcpu *vcpu)
}
  }
  
+static inline bool kvm_need_exit(struct kvm_vcpu *vcpu)

+{
+   return signal_pending(current) ||
+  kvm_has_request(KVM_REQ_EXIT, vcpu);
+}
+
  extern bool kvm_rebooting;
  
  struct kvm_device {

diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 26daafbba9ec..d996a7cdb4d2 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -184,6 +184,7 @@ struct kvm_s390_skeys {
  #define KVM_EXIT_SYSTEM_EVENT 24
  #define KVM_EXIT_S390_STSI25
  #define KVM_EXIT_IOAPIC_EOI   26
+#define KVM_EXIT_REQUEST  27
  
  /* For KVM_EXIT_INTERNAL_ERROR */

  /* Emulate instruction failed. */
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d8db2f8fce9c..347899966178 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1914,7 +1914,7 @@ static int kvm_vcpu_check_block(struct kvm_vcpu *vcpu)
}
if (kvm_cpu_has_pending_timer(vcpu))
return -EINTR;
-   if (signal_pending(current))
+   if (kvm_need_exit(vcpu))
return -EINTR;
  
  	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 v2] pinctrl: mediatek: Fix multiple registration issue.

[Axel Lin]

2015-08-20 11:38 GMT+08:00 Hongzhou Yang :
> Since our common driver need support main chip and PMU
> at the same time, that means it will register two
> pinctrl device, and the pinctrl_desc structure should
> be used two times.
>
> But pinctrl_desc use global static definition, then
> the latest registered pinctrl device will overwrite
> the old one's, all members in pinctrl_desc will set to
> the new one's, such as name, pins and pins numbers, etc.
> This is a bug. Changing to use devm_kzalloc to fix it.
>
> Cc: sta...@vger.kernel.org # v4.1+
> Signed-off-by: Hongzhou Yang 
> ---
>  Use dynamic allocation to fix multiple registration issue.
>
>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |   26 
> ++---
>  drivers/pinctrl/mediatek/pinctrl-mtk-common.h |1 +
>  2 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> index ad1ea16..911c736 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> @@ -1202,12 +1202,6 @@ static int mtk_pctrl_build_state(struct 
> platform_device *pdev)
> return 0;
>  }
>
> -static struct pinctrl_desc mtk_pctrl_desc = {
> -   .confops= _pconf_ops,
> -   .pctlops= _pctrl_ops,
> -   .pmxops = _pmx_ops,
> -};
> -
>  int mtk_pctrl_init(struct platform_device *pdev,
> const struct mtk_pinctrl_devdata *data,
> struct regmap *regmap)
> @@ -1265,12 +1259,22 @@ int mtk_pctrl_init(struct platform_device *pdev,
>
> for (i = 0; i < pctl->devdata->npins; i++)
> pins[i] = pctl->devdata->pins[i].pin;
> -   mtk_pctrl_desc.name = dev_name(>dev);
> -   mtk_pctrl_desc.owner = THIS_MODULE;
> -   mtk_pctrl_desc.pins = pins;
> -   mtk_pctrl_desc.npins = pctl->devdata->npins;
> +
> +   pctl->pctl_desc = devm_kzalloc(>dev, sizeof(*pctl->pctl_desc),
> +   GFP_KERNEL);
> +   if (!pctl->pctl_desc)
> +   return -ENOMEM;
> +
> +   pctl->pctl_desc->name = dev_name(>dev);
> +   pctl->pctl_desc->owner = THIS_MODULE;
> +   pctl->pctl_desc->pins = pins;
> +   pctl->pctl_desc->npins = pctl->devdata->npins;
> +   pctl->pctl_desc->confops = _pconf_ops;
> +   pctl->pctl_desc->pctlops = _pctrl_ops;
> +   pctl->pctl_desc->pmxops = _pmx_ops;
> pctl->dev = >dev;
> -   pctl->pctl_dev = pinctrl_register(_pctrl_desc, >dev, pctl);
> +
> +   pctl->pctl_dev = pinctrl_register(pctl->pctl_desc, >dev, pctl);
> if (IS_ERR(pctl->pctl_dev)) {
> dev_err(>dev, "couldn't register pinctrl driver\n");
> return PTR_ERR(pctl->pctl_dev);
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.h 
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common.h
> index 30213e5..93d6f5b 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.h
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.h
> @@ -256,6 +256,7 @@ struct mtk_pinctrl_devdata {
>  struct mtk_pinctrl {
> struct regmap   *regmap1;
> struct regmap   *regmap2;
> +   struct pinctrl_desc *pctl_desc;
Use
struct pinctrl_desc pctl_desc;

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

[PATCH v2] pinctrl: mediatek: Fix multiple registration issue.

[Hongzhou Yang]

Since our common driver need support main chip and PMU
at the same time, that means it will register two
pinctrl device, and the pinctrl_desc structure should
be used two times.

But pinctrl_desc use global static definition, then
the latest registered pinctrl device will overwrite
the old one's, all members in pinctrl_desc will set to
the new one's, such as name, pins and pins numbers, etc.
This is a bug. Changing to use devm_kzalloc to fix it.

Cc: sta...@vger.kernel.org # v4.1+
Signed-off-by: Hongzhou Yang 
---
 Use dynamic allocation to fix multiple registration issue.

 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |   26 ++---
 drivers/pinctrl/mediatek/pinctrl-mtk-common.h |1 +
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index ad1ea16..911c736 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1202,12 +1202,6 @@ static int mtk_pctrl_build_state(struct platform_device 
*pdev)
return 0;
 }
 
-static struct pinctrl_desc mtk_pctrl_desc = {
-   .confops= _pconf_ops,
-   .pctlops= _pctrl_ops,
-   .pmxops = _pmx_ops,
-};
-
 int mtk_pctrl_init(struct platform_device *pdev,
const struct mtk_pinctrl_devdata *data,
struct regmap *regmap)
@@ -1265,12 +1259,22 @@ int mtk_pctrl_init(struct platform_device *pdev,
 
for (i = 0; i < pctl->devdata->npins; i++)
pins[i] = pctl->devdata->pins[i].pin;
-   mtk_pctrl_desc.name = dev_name(>dev);
-   mtk_pctrl_desc.owner = THIS_MODULE;
-   mtk_pctrl_desc.pins = pins;
-   mtk_pctrl_desc.npins = pctl->devdata->npins;
+
+   pctl->pctl_desc = devm_kzalloc(>dev, sizeof(*pctl->pctl_desc),
+   GFP_KERNEL);
+   if (!pctl->pctl_desc)
+   return -ENOMEM;
+
+   pctl->pctl_desc->name = dev_name(>dev);
+   pctl->pctl_desc->owner = THIS_MODULE;
+   pctl->pctl_desc->pins = pins;
+   pctl->pctl_desc->npins = pctl->devdata->npins;
+   pctl->pctl_desc->confops = _pconf_ops;
+   pctl->pctl_desc->pctlops = _pctrl_ops;
+   pctl->pctl_desc->pmxops = _pmx_ops;
pctl->dev = >dev;
-   pctl->pctl_dev = pinctrl_register(_pctrl_desc, >dev, pctl);
+
+   pctl->pctl_dev = pinctrl_register(pctl->pctl_desc, >dev, pctl);
if (IS_ERR(pctl->pctl_dev)) {
dev_err(>dev, "couldn't register pinctrl driver\n");
return PTR_ERR(pctl->pctl_dev);
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.h 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.h
index 30213e5..93d6f5b 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.h
@@ -256,6 +256,7 @@ struct mtk_pinctrl_devdata {
 struct mtk_pinctrl {
struct regmap   *regmap1;
struct regmap   *regmap2;
+   struct pinctrl_desc *pctl_desc;
struct device   *dev;
struct gpio_chip*chip;
struct mtk_pinctrl_group*groups;
-- 
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 V3] thermal: cpu_cooling: Add MAINTAINERS entry

[Viresh Kumar]

On 20-08-15, 05:01, Daniel Lezcano wrote:
> On 08/20/2015 04:40 AM, Viresh Kumar wrote:
> >None of the patches are reaching Viresh or Daniel directly as
> >get_maintainers doesn't report us as maintainers. Looks like file header
> >or history of commits isn't able to do that properly.
> >
> >Add a separate entry for cpu_cooling driver in MAINTAINERS.
> >
> >Acked-by: Eduardo Valentin 
> >Acked-by: Amit Daniel Kachhap 
> >Acked-by: Amit Daniel Kachhap 
> >Signed-off-by: Viresh Kumar 
> 
> Shouldn't be Javi Merino in Cc ?

Added him now, he wasn't there as get_maintainers missed his work :)

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ubifs: Allow O_DIRECT

[Dongsheng Yang]

On 08/20/2015 04:35 AM, Richard Weinberger wrote:

Currently UBIFS does not support direct IO, but some applications
blindly use the O_DIRECT flag.
Instead of failing upon open() we can do better and fall back
to buffered IO.


H, to be honest, I am not sure we have to do it as Dave
suggested. I think that's just a work-around for current fstests.

IMHO, perform a buffered IO when user request direct IO without
any warning sounds not a good idea. Maybe adding a warning would
make it better.

I think we need more discussion about AIO in ubifs, and actually
I have a plan for it. But I have not listed the all cons and pros of
it so far.

Artem, what's your opinion?

Yang


Cc: Dongsheng Yang 
Cc: dedeki...@gmail.com
Suggested-by: Dave Chinner 
Signed-off-by: Richard Weinberger 
---
  fs/ubifs/file.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c
index a3dfe2a..a61fe86 100644
--- a/fs/ubifs/file.c
+++ b/fs/ubifs/file.c
@@ -1540,6 +1540,15 @@ static int ubifs_file_mmap(struct file *file, struct 
vm_area_struct *vma)
return 0;
  }

+/*
+ * For now fall back to buffered IO.
+ */
+static ssize_t ubifs_direct_IO(struct kiocb *iocb, struct iov_iter *iter,
+  loff_t offset)
+{
+   return 0;
+}
+
  const struct address_space_operations ubifs_file_address_operations = {
.readpage   = ubifs_readpage,
.writepage  = ubifs_writepage,
@@ -1548,6 +1557,7 @@ const struct address_space_operations 
ubifs_file_address_operations = {
.invalidatepage = ubifs_invalidatepage,
.set_page_dirty = ubifs_set_page_dirty,
.releasepage= ubifs_releasepage,
+   .direct_IO  = ubifs_direct_IO,
  };

  const struct inode_operations ubifs_file_inode_operations = {



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: spi-nor: sf: Add clear flag status register support

[Hou Zhiqiang]

Hello Jagan,

> -Original Message-
> From: Jagan Teki [mailto:jt...@openedev.com]
> Sent: 2015年8月20日 1:49
> To: Hou Zhiqiang-B48286
> Cc: linux-...@lists.infradead.org; Hu Mingkai-B21284; Brian Norris; David
> Woodhouse; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 3/3] mtd: spi-nor: sf: Add clear flag status register
> support
> 
> Hi Zhiqiang,
> 
> On 19 August 2015 at 17:42, Hou Zhiqiang  wrote:
> > Hi Jagan,
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:jt...@openedev.com]
> >> Sent: 2015年8月19日 17:57
> >> To: linux-...@lists.infradead.org
> >> Cc: linux-kernel@vger.kernel.org; Jagan Teki; Hou Zhiqiang-B48286; Hu
> >> Mingkai-B21284; David Woodhouse; Brian Norris
> >> Subject: [PATCH 3/3] mtd: spi-nor: sf: Add clear flag status register
> >> support
> >>
> >> The clear flag status register operation was required by Micron
> >> SPI-NOR chips, which support FSR. And if an error bit of FSR have
> >> been set like protection, voltage, erase, and program, it must be
> >> cleared by the clear FSR operation.
> >>
> >> Signed-off-by: Jagan Teki 
> >> Cc: Hou Zhiqiang 
> >> Cc: Mingkai.Hu 
> >> Cc: David Woodhouse 
> >> Cc: Brian Norris 
> >> ---
> >>  drivers/mtd/spi-nor/spi-nor.c | 35 +++---
> -
> >>  include/linux/mtd/spi-nor.h   |  9 +
> >>  2 files changed, 40 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-
> >> nor.c index f954d03..c5c472d5 100644
> >> --- a/drivers/mtd/spi-nor/spi-nor.c
> >> +++ b/drivers/mtd/spi-nor/spi-nor.c
> >> @@ -100,6 +100,28 @@ static int read_fsr(struct spi_nor *nor)  }
> >>
> >>  /*
> >> + * Read the clear flag status register.
> >> + * The clear flag status register operation was required by Micron
> >> + * SPI-NOR chips, which support FSR. And if an error bit of FSR
> >> + * have been set like protection, voltage, erase, and program,
> >> + * it must be cleared by the clear FSR operation.
> >> + * Returns zero for FSR bits cleared and negative if error occurred.
> >> + */
> >> +static int read_cfsr(struct spi_nor *nor) {
> >> + int ret;
> >> + u8 val;
> >> +
> >> + ret = nor->read_reg(nor, SPINOR_OP_RDCFSR, , 1);
> >
> > There should be a write_reg instead of read_reg.
> > There isn’t a register named CFSR, and the command SPINOR_OP_RDCFSR is
> > used to clear the FSR, another words reset FSR to default value.
> 
> Yes, SPINOR_OP_RDCFSR is clear flag status register, for clearing errors
> bits on fsr we need to read cfsr once.
> 

Sorry, I'm not clear for this operation. Please correct me if I'm wrong.
As far as I understand, this command is used to reset the FSR. Does a value
Will be read back? And there is not the register CFSR, so I don't know which
register will be read by SPINOR_OP_RDCFSR?

> >
> >> + if (ret < 0) {
> >> + pr_err("error %d reading CFSR\n", ret);
> >> + return ret;
> >> + }
> >> +
> >> + return val;
> >> +}
> >> +
> >> +/*

Thanks,
Zhiqiang
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 V3] thermal: cpu_cooling: Add MAINTAINERS entry

[Daniel Lezcano]

On 08/20/2015 04:40 AM, Viresh Kumar wrote:

None of the patches are reaching Viresh or Daniel directly as
get_maintainers doesn't report us as maintainers. Looks like file header
or history of commits isn't able to do that properly.

Add a separate entry for cpu_cooling driver in MAINTAINERS.

Acked-by: Eduardo Valentin 
Acked-by: Amit Daniel Kachhap 
Acked-by: Amit Daniel Kachhap 
Signed-off-by: Viresh Kumar 


Shouldn't be Javi Merino in Cc ?


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

linux-next: build failure after merge of the net-next tree

[Stephen Rothwell]

Hi all,

After merging the net-next tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

net/ipv4/fib_semantics.c: In function 'fib_encap_match':
net/ipv4/fib_semantics.c:553:3: error: implicit declaration of function 
'lwtstate_free' [-Werror=implicit-function-declaration]
   lwtstate_free(lwtstate);
   ^

Caused by commit

  df383e6240ef ("lwtunnel: fix memory leak")

CONFIG_LWTUNNEL is not set for this build.

I reverted that commit for today.

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

[PATCH v2 3/3] arm64: dts: add Hi6220 mailbox node

[Leo Yan]

On Hi6220, below memory regions in DDR have specific purpose:

  0x05e0, - 0x05ef,: For MCU firmware using at runtime;
  0x0740,f000 - 0x0740,: For MCU firmware's section;
  0x06df,f000 - 0x06df,: For mailbox message data.

This patch reserves these memory regions and add device node for
mailbox in dts.

Signed-off-by: Leo Yan 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 20 +---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  8 
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index e36a539..d5470d3 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -7,9 +7,6 @@
 
 /dts-v1/;
 
-/*Reserved 1MB memory for MCU*/
-/memreserve/ 0x05e0 0x0010;
-
 #include "hi6220.dtsi"
 
 / {
@@ -28,4 +25,21 @@
device_type = "memory";
reg = <0x0 0x0 0x0 0x4000>;
};
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   mcu-buf@05e0 {
+   no-map;
+   reg = <0x0 0x05e0 0x0 0x0010>,  /* MCU firmware 
buffer */
+ <0x0 0x0740f000 0x0 0x1000>;  /* MCU firmware 
section */
+   };
+
+   mbox-buf@06dff000 {
+   no-map;
+   reg = <0x0 0x06dff000 0x0 0x1000>;  /* Mailbox 
message buf */
+   };
+   };
 };
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..9ff25bc 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,13 @@
clocks = <_ctrl 36>, <_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+   mailbox: mailbox@f751 {
+   #mbox-cells = <1>;
+   compatible = "hisilicon,hi6220-mbox";
+   reg = <0x0 0xf751 0x0 0x1000>, /* IPC_S */
+ <0x0 0x06dff800 0x0 0x0800>; /* Mailbox buffer */
+   interrupts = ;
+   };
};
 };
-- 
1.9.1

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

[PATCH v2 2/3] mailbox: Hi6220: add mailbox driver

[Leo Yan]

Add driver for Hi6220 mailbox, the mailbox communicates with MCU; for
sending data, it can support two methods for low level implementation:
one is to use interrupt as acknowledge, another is automatic mode which
without any acknowledge. These two methods have been supported in the
driver. For receiving data, it will depend on the interrupt to notify
the channel has incoming message; enhance rx channel's message queue,
which is based on the code in drivers/mailbox/omap-mailbox.c.

Now mailbox driver is used to send message to MCU to control dynamic
voltage and frequency scaling for CPU, GPU and DDR.

Signed-off-by: Leo Yan 
---
 drivers/mailbox/Kconfig  |   8 +
 drivers/mailbox/Makefile |   2 +
 drivers/mailbox/hi6220-mailbox.c | 519 +++
 3 files changed, 529 insertions(+)
 create mode 100644 drivers/mailbox/hi6220-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index e269f08..21b71dd 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -70,4 +70,12 @@ config BCM2835_MBOX
  the services of the Videocore. Say Y here if you want to use the
  BCM2835 Mailbox.
 
+config HI6220_MBOX
+   tristate "Hi6220 Mailbox"
+   depends on ARCH_HISI
+   help
+ An implementation of the hi6220 mailbox. It is used to send message
+ between application processors and MCU. Say Y here if you want to 
build
+ the Hi6220 mailbox controller driver.
+
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 8e6d822..4ba9f5f 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -13,3 +13,5 @@ obj-$(CONFIG_PCC) += pcc.o
 obj-$(CONFIG_ALTERA_MBOX)  += mailbox-altera.o
 
 obj-$(CONFIG_BCM2835_MBOX) += bcm2835-mailbox.o
+
+obj-$(CONFIG_HI6220_MBOX)  += hi6220-mailbox.o
diff --git a/drivers/mailbox/hi6220-mailbox.c b/drivers/mailbox/hi6220-mailbox.c
new file mode 100644
index 000..8f63d0d
--- /dev/null
+++ b/drivers/mailbox/hi6220-mailbox.c
@@ -0,0 +1,519 @@
+/*
+ * Hisilicon's Hi6220 mailbox driver
+ *
+ * RX channel's message queue is based on the code written in
+ * drivers/mailbox/omap-mailbox.c.
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HI6220_MBOX_CHAN_MAX   32
+#define HI6220_MBOX_CHAN_NUM   2
+#define HI6220_MBOX_CHAN_SLOT_SIZE 64
+
+#define HI6220_MBOX_RX 0x0
+#define HI6220_MBOX_TX 0x1
+
+/* Mailbox message length: 32 bytes */
+#define HI6220_MBOX_MSG_LEN32
+
+/* Mailbox kfifo size */
+#define HI6220_MBOX_MSG_FIFO_SIZE  512
+
+/* Status & Mode Register */
+#define HI6220_MBOX_MODE_REG   0x0
+
+#define HI6220_MBOX_STATUS_MASK(0xF << 4)
+#define HI6220_MBOX_STATUS_IDLE(0x1 << 4)
+#define HI6220_MBOX_STATUS_TX  (0x2 << 4)
+#define HI6220_MBOX_STATUS_RX  (0x4 << 4)
+#define HI6220_MBOX_STATUS_ACK (0x8 << 4)
+#define HI6220_MBOX_ACK_CONFIG_MASK(0x1 << 0)
+#define HI6220_MBOX_ACK_AUTOMATIC  (0x1 << 0)
+#define HI6220_MBOX_ACK_IRQ(0x0 << 0)
+
+/* Data Registers */
+#define HI6220_MBOX_DATA_REG(i)(0x4 + (i << 2))
+
+/* ACPU Interrupt Register */
+#define HI6220_MBOX_ACPU_INT_RAW_REG   0x400
+#define HI6220_MBOX_ACPU_INT_MSK_REG   0x404
+#define HI6220_MBOX_ACPU_INT_STAT_REG  0x408
+#define HI6220_MBOX_ACPU_INT_CLR_REG   0x40c
+#define HI6220_MBOX_ACPU_INT_ENA_REG   0x500
+#define HI6220_MBOX_ACPU_INT_DIS_REG   0x504
+
+/* MCU Interrupt Register */
+#define HI6220_MBOX_MCU_INT_RAW_REG0x420
+
+/* Core Id */
+#define HI6220_CORE_ACPU   0x0
+#define HI6220_CORE_MCU0x2
+
+struct hi6220_mbox_queue {
+   struct kfifo fifo;
+   struct work_struct work;
+   struct mbox_chan *chan;
+   bool full;
+};
+
+struct hi6220_mbox_chan {
+
+   /*
+* Description for channel's hardware info:
+*  - direction;
+*  - peer core id for communication;
+*  - local irq vector or number;
+*  - remoted irq vector or number for peer core;
+*/
+   unsigned int dir;
+   unsigned int peer_core;
+   unsigned int remote_irq;
+   unsigned int local_irq;
+
+   /*
+* Slot address is cached value derived from index
+  

[PATCH v2 0/3] mailbox: hisilicon: add Hi6220 mailbox driver

[Leo Yan]

Hi6220 mailbox supports up to 32 channels. Each channel is unidirectional
with a maximum message size of 8 words. I/O is performed using register
access (there is no DMA) and the cell raises an interrupt when messages
are received.

This patch series is to implement Hi6220 mailbox driver. It registers
two channels into framework for communication with MCU, one is tx channel
and another is rx channel. Now mailbox driver is used to send message to
MCU to control dynamic voltage and frequency scaling for CPU, GPU and DDR.

Changes from v1:
* Correct lock usage for SMP scenario

Changes from RFC:
* According to Jassi's review, totally remove the abstract common driver
  layer and only commit driver dedicated for Hi6220
* According to Paul Bolle's review, fix typo issue for Kconfig and remove
  unnecessary dependency with OF and fix minor for mailbox driver
* Refine a little for dts nodes


Leo Yan (3):
  dt-bindings: mailbox: Document Hi6220 mailbox driver
  mailbox: Hi6220: add mailbox driver
  arm64: dts: add Hi6220 mailbox node

 .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  |  57 +++
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |  20 +-
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |   8 +
 drivers/mailbox/Kconfig|   8 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/hi6220-mailbox.c   | 519 +
 6 files changed, 611 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
 create mode 100644 drivers/mailbox/hi6220-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/

Re: [PATCH 1/2] ubifs: Remove dead xattr code

[Dongsheng Yang]

On 08/20/2015 04:35 AM, Richard Weinberger wrote:

This is a partial revert of commit d7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53
("UBIFS: Add security.* XATTR support for the UBIFS").


Hi Richard,
What about a full reverting of this commit. In ubifs, we
*can* support any namespace of xattr including user, trusted, security
or other anyone prefixed by any words. But we have a check_namespace()
in xattr.c to limit what we want to support. That said, if we want to
"Add security.* XATTR support for the UBIFS", what we need to do is
just extending the check_namespace() to allow security namespace pass.
And yes, check_namespace() have been supporting security namespace.

So, IMHO, we do not depend on the generic mechanism at all, and we can
fully revert this commit.

But strange to me, why we picked this commit for ubifs? Artem, is there
something I am missing?

Yang


As UBIFS does not use generic inode xattr inode operations
the code behind sb->s_xattr is never called.
Remove that dead code for now.

Cc: Subodh Nijsure 
Cc: Marc Kleine-Budde 
Cc: Brad Mouring 
Cc: Gratian Crisan 
Cc: Artem Bityutskiy 
Reported-by: Andreas Grünbacher 
Signed-off-by: Richard Weinberger 
---
After the merge window (and my vacation) I'll have the time to
re-introduce/work security xattr support.

Thanks,
//richard
---
  fs/ubifs/super.c |  1 -
  fs/ubifs/ubifs.h |  1 -
  fs/ubifs/xattr.c | 40 
  3 files changed, 42 deletions(-)

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 9547a278..c71edca 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -2037,7 +2037,6 @@ static int ubifs_fill_super(struct super_block *sb, void 
*data, int silent)
if (c->max_inode_sz > MAX_LFS_FILESIZE)
sb->s_maxbytes = c->max_inode_sz = MAX_LFS_FILESIZE;
sb->s_op = _super_operations;
-   sb->s_xattr = ubifs_xattr_handlers;

mutex_lock(>umount_mutex);
err = mount_ubifs(c);
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index de75902..33b6ee7 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -1470,7 +1470,6 @@ extern spinlock_t ubifs_infos_lock;
  extern atomic_long_t ubifs_clean_zn_cnt;
  extern struct kmem_cache *ubifs_inode_slab;
  extern const struct super_operations ubifs_super_operations;
-extern const struct xattr_handler *ubifs_xattr_handlers[];
  extern const struct address_space_operations ubifs_file_address_operations;
  extern const struct file_operations ubifs_file_operations;
  extern const struct inode_operations ubifs_file_inode_operations;
diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
index 96f3448..b512b14 100644
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -582,46 +582,6 @@ out_free:
return err;
  }

-static size_t security_listxattr(struct dentry *d, char *list, size_t 
list_size,
-const char *name, size_t name_len, int flags)
-{
-   const int prefix_len = XATTR_SECURITY_PREFIX_LEN;
-   const size_t total_len = prefix_len + name_len + 1;
-
-   if (list && total_len <= list_size) {
-   memcpy(list, XATTR_SECURITY_PREFIX, prefix_len);
-   memcpy(list + prefix_len, name, name_len);
-   list[prefix_len + name_len] = '\0';
-   }
-
-   return total_len;
-}
-
-static int security_getxattr(struct dentry *d, const char *name, void *buffer,
- size_t size, int flags)
-{
-   return ubifs_getxattr(d, name, buffer, size);
-}
-
-static int security_setxattr(struct dentry *d, const char *name,
-const void *value, size_t size, int flags,
-int handler_flags)
-{
-   return ubifs_setxattr(d, name, value, size, flags);
-}
-
-static const struct xattr_handler ubifs_xattr_security_handler = {
-   .prefix = XATTR_SECURITY_PREFIX,
-   .list   = security_listxattr,
-   .get= security_getxattr,
-   .set= security_setxattr,
-};
-
-const struct xattr_handler *ubifs_xattr_handlers[] = {
-   _xattr_security_handler,
-   NULL,
-};
-
  static int init_xattrs(struct inode *inode, const struct xattr *xattr_array,
  void *fs_info)
  {



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

[PATCH v2 1/3] dt-bindings: mailbox: Document Hi6220 mailbox driver

[Leo Yan]

Document the new compatible for Hisilicon Hi6220 mailbox driver.

Signed-off-by: Leo Yan 
---
 .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  | 57 ++
 1 file changed, 57 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt

diff --git 
a/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
new file mode 100644
index 000..3dfb0b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
@@ -0,0 +1,57 @@
+Hisilicon Hi6220 Mailbox Driver
+===
+
+Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
+is unidirectional with a maximum message size of 8 words. I/O is
+performed using register access (there is no DMA) and the cell
+raises an interrupt when messages are received.
+
+Mailbox Device Node:
+
+
+Required properties:
+
+- compatible:  Shall be "hisilicon,hi6220-mbox"
+- reg: Contains the mailbox register address range (base
+   address and length); the first item is for IPC
+   registers, the second item is shared buffer for
+   slots.
+- #mbox-cells  Common mailbox binding property to identify the number
+   of cells required for the mailbox specifier. Should be 
1.
+- interrupts:  Contains the interrupt information for the mailbox
+   device. The format is dependent on which interrupt
+   controller the SoCs use.
+
+Example:
+
+
+   mailbox: mailbox@F751 {
+   #mbox-cells = <1>;
+   compatible = "hisilicon,hi6220-mbox";
+   reg = <0x0 0xF751 0x0 0x1000>, /* IPC_S */
+ <0x0 0x06DFF800 0x0 0x0800>; /* Mailbox */
+   interrupt-parent = <>;
+   interrupts = <0 94 4>;
+   };
+
+
+Mailbox client
+===
+
+"mboxes" and the optional "mbox-names" (please see
+Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each value
+of the mboxes property should contain a phandle to the mailbox controller
+device node and second argument is the channel index. It must be 0 (hardware
+support only one channel). The equivalent "mbox-names" property value can be
+used to give a name to the communication channel to be used by the client user.
+
+Example:
+
+
+   stub_clock: stub_clock {
+   compatible = "hisilicon,hi6220-stub-clk";
+   hisilicon,hi6220-clk-sram = <>;
+   #clock-cells = <1>;
+   mbox-names = "mbox-tx";
+   mboxes = < 1>;
+   };
-- 
1.9.1

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

[PATCH V3] thermal: cpu_cooling: Add MAINTAINERS entry

[Viresh Kumar]

None of the patches are reaching Viresh or Daniel directly as
get_maintainers doesn't report us as maintainers. Looks like file header
or history of commits isn't able to do that properly.

Add a separate entry for cpu_cooling driver in MAINTAINERS.

Acked-by: Eduardo Valentin 
Acked-by: Amit Daniel Kachhap 
Acked-by: Amit Daniel Kachhap 
Signed-off-by: Viresh Kumar 
---
V2->V3:
- Updated Amit's email address

 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d8ab5c06c4f..e733bd6272b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10298,6 +10298,15 @@ F: include/uapi/linux/thermal.h
 F: include/linux/cpu_cooling.h
 F: Documentation/devicetree/bindings/thermal/
 
+THERMAL/CPU_COOLING
+M: Amit Daniel Kachhap 
+M: Viresh Kumar 
+L: linux...@vger.kernel.org
+S: Supported
+F: Documentation/thermal/cpu-cooling-api.txt
+F: drivers/thermal/cpu_cooling.c
+F: include/linux/cpu_cooling.h
+
 THINGM BLINK(1) USB RGB LED DRIVER
 M: Vivien Didelot 
 S: Maintained
-- 
2.4.0

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

RE: [PATCH 0/4] printk: Softlockup avoidance

[KY Srinivasan]

> -Original Message-
> From: Jan Kara [mailto:j...@suse.com]
> Sent: Wednesday, August 19, 2015 8:38 AM
> To: Andrew Morton 
> Cc: LKML ; pmla...@suse.com;
> rost...@goodmis.org; Gavin Hu ; KY Srinivasan
> ; Jan Kara 
> Subject: [PATCH 0/4] printk: Softlockup avoidance
> 
> From: Jan Kara 
> 
> Hello,
> 
> since lately there were several attempts at dealing with softlockups due
> to heavy printk traffic [1] [2] and I've been also privately pinged by
> couple of people about the state of the patch set, I've decided to respin
> the patch set.
> 
> To remind the original problem:
> 
> Currently, console_unlock() prints messages from kernel printk buffer to
> console while the buffer is non-empty. When serial console is attached,
> printing is slow and thus other CPUs in the system have plenty of time
> to append new messages to the buffer while one CPU is printing. Thus the
> CPU can spend unbounded amount of time doing printing in
> console_unlock().
> This is especially serious when printk() gets called under some critical
> spinlock or with interrupts disabled.
> 
> In practice users have observed a CPU can spend tens of seconds printing
> in console_unlock() (usually during boot when hundreds of SCSI devices
> are discovered) resulting in RCU stalls (CPU doing printing doesn't
> reach quiescent state for a long time), softlockup reports (IPIs for the
> printing CPU don't get served and thus other CPUs are spinning waiting
> for the printing CPU to process IPIs), and eventually a machine death
> (as messages from stalls and lockups append to printk buffer faster than
> we are able to print). So these machines are unable to boot with serial
> console attached. Also during artificial stress testing SATA disk
> disappears from the system because its interrupts aren't served for too
> long.
> 
> This series addresses the problem in the following way: If CPU has printed
> more that printk_offload (defaults to 1000) characters, it wakes up one
> of dedicated printk kthreads (we don't use workqueue because that has
> deadlock potential if printk was called from workqueue code). Once we find
> out kthread is spinning on a lock, we stop printing, drop console_sem, and
> let kthread continue printing. Since there are two printing kthreads, they
> will pass printing between them and thus no CPU gets hogged by printing.
> 
> Changes since the last posting [3]:
> * I have replaced the state machine to pass printing and spinning on
>   console_sem with a simple spinlock which makes the code
>   somewhat easier to read and verify.
> * Some of the patches were merged so I dropped them.
> 
>   Honza

Thanks Jan. I would like to add that the problem described here is further 
aggravated
in virtual machines and the solution proposed here effectively solves the 
problem.

Regards,

K. Y
> 
> [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flkml.or
> g%2flkml%2f2015%2f7%2f8%2f215=01%7c01%7ckys%40microsoft.com
> %7c0be64449b7734417b58e08d2a8ac4215%7c72f988bf86f141af91ab2d7cd011
> db47%7c1=tIGC5%2bms890etIzVbaj3x3B3XUrgC54C79vaniZzRIY%3d
> [2]
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmarc.inf
> o%2f%3fl%3dlinux-
> kernel%26m%3d143929238407816%26w%3d2=01%7c01%7ckys%40micr
> osoft.com%7c0be64449b7734417b58e08d2a8ac4215%7c72f988bf86f141af91a
> b2d7cd011db47%7c1=DFEq8NILXnLGTo%2fscI5zjzWrX9%2buJlj9lmo8r
> ahuIt0%3d
> [3]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flkml.or
> g%2flkml%2f2014%2f3%2f17%2f68=01%7c01%7ckys%40microsoft.com
> %7c0be64449b7734417b58e08d2a8ac4215%7c72f988bf86f141af91ab2d7cd011
> db47%7c1=j9uJalk7Cup0q78gl8rgIIjySU0l7HIwk1AhYJ5cAd4%3d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] power: wm831x_power: Support USB charger current limit management

[Peter Chen]

 
> Integrate with the newly added USB charger interface to limit the current we
> draw from the USB input based on the input device configuration identified by
> the USB stack, allowing us to charge more quickly from high current inputs
> without drawing more current than specified from others.
> 
> Signed-off-by: Mark Brown 
> ---
> 
> Fix up the limit detection loop as identified by Peter Chen.
> 
>  drivers/power/wm831x_power.c | 69
> 
>  include/linux/mfd/wm831x/pdata.h |  3 ++
>  2 files changed, 72 insertions(+)
> 
> diff --git a/drivers/power/wm831x_power.c
> b/drivers/power/wm831x_power.c index c826c83..9493902 100644
> --- a/drivers/power/wm831x_power.c
> +++ b/drivers/power/wm831x_power.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -31,6 +32,8 @@ struct wm831x_power {
>   char usb_name[20];
>   char battery_name[20];
>   bool have_battery;
> + struct usb_charger *usb_charger;
> + struct notifier_block usb_notify;
>  };
> 
>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
> @@ -125,6 +128,43 @@ static enum power_supply_property
> wm831x_usb_props[] = {
>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>  };
> 
> +/* In miliamps */
> +static unsigned int wm831x_usb_limits[] = {
> + 0,
> + 2,
> + 100,
> + 500,
> + 900,
> + 1500,
> + 1800,
> + 550,
> +};
> +
> +static int wm831x_usb_limit_change(struct notifier_block *nb,
> +unsigned long limit, void *data) {
> + struct wm831x_power *wm831x_power = container_of(nb,
> +  struct wm831x_power,
> +  usb_notify);
> + int i, best;
> +
> + /* Find the highest supported limit */
> + best = 0;
> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
> + if (limit >= wm831x_usb_limits[i] &&
> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
> + best = i;
> + }
> +
> + dev_dbg(wm831x_power->wm831x->dev,
> + "Limiting USB current to %dmA", wm831x_usb_limits[best]);
> +
> + wm831x_set_bits(wm831x_power->wm831x,
> WM831X_POWER_STATE,
> + WM831X_USB_ILIM_MASK, best);
> +
> + return 0;
> +}
> +
> 
> /***
> **
>   *   Battery properties
> 
> 
> */
> @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct
> platform_device *pdev)
>   }
>   }
> 
> + if (wm831x_pdata && wm831x_pdata->usb_gadget) {
> + power->usb_charger =
> + usb_charger_find_by_name(wm831x_pdata-
> >usb_gadget);
> + if (IS_ERR(power->usb_charger)) {
> + ret = PTR_ERR(power->usb_charger);
> + dev_err(>dev,
> + "Failed to find USB gadget: %d\n", ret);
> + goto err_bat_irq;
> + }
> +
> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
> +
> + ret = usb_charger_register_notify(power->usb_charger,
> +   >usb_notify);
> + if (ret != 0) {
> + dev_err(>dev,
> + "Failed to register notifier: %d\n", ret);
> + goto err_usb_charger;
> + }
> + }
> +
>   return ret;
> 
> +err_usb_charger:
> + /* put_device on charger */
>  err_bat_irq:
>   --i;
>   for (; i >= 0; i--) {
> @@ -637,6 +700,12 @@ static int wm831x_power_remove(struct
> platform_device *pdev)
>   struct wm831x *wm831x = wm831x_power->wm831x;
>   int irq, i;
> 
> + if (wm831x_power->usb_charger) {
> + usb_charger_unregister_notify(wm831x_power->usb_charger,
> +   _power->usb_notify);
> + /* Free charger */
> + }
> +
>   for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
>   irq = wm831x_irq(wm831x,
>platform_get_irq_byname(pdev,
> diff --git a/include/linux/mfd/wm831x/pdata.h
> b/include/linux/mfd/wm831x/pdata.h
> index dcc9631..5af8399 100644
> --- a/include/linux/mfd/wm831x/pdata.h
> +++ b/include/linux/mfd/wm831x/pdata.h
> @@ -126,6 +126,9 @@ struct wm831x_pdata {
>   /** The driver should initiate a power off sequence during shutdown
> */
>   bool soft_shutdown;
> 
> + /** dev_name of USB charger gadget to integrate with */
> + const char *usb_gadget;
> +
>   int irq_base;
>   int gpio_base;
>   int gpio_defaults[WM831X_GPIO_NUM];
> --
> 2.5.0

Acked-by: Peter Chen 

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

Re: [PATCH v3 0/8] ARM: sunxi: Add Reduced Serial Bus support

[Chen-Yu Tsai]

On Thu, Aug 20, 2015 at 12:32 AM, Mark Brown  wrote:
> On Wed, Aug 19, 2015 at 12:20:01PM +0800, Chen-Yu Tsai wrote:
>> Hi everyone,
>>
>> This is my third attempt at adding support for Allwinner's Reduced
>> Serial Bus (RSB), which is used to communicate with PMICs and other
>> peripherals on their newer SoCs, such as the A23/A33/A80.
>
> This is flagged as something that is specific to the Allwinner SoCs.
> Why add generic regmap support rather than just implement the regmap
> reg_read() and reg_write() in a regmap in the controller driver?  Are
> there expected to be other controller drivers from other vendors?

I don't expect there to be any other controller drivers. And it seems
at least some of the devices are dual interface (I2C/RSB). Though I
don't see how its connected to the generic regmap support. Regmap
is for device drivers connected to the RSB bus, not the bus controller
itself.

That said, there are a few RSB mfd slave devices that need support,
those being the later AXP series PMICs, and AC100/AC200 audio-codec/RTC
chips. The current axp20x driver already uses i2c regmaps.

I could throw all the RSB-related stuff together, presumably under
drivers/soc/sunxi/rsb, though that doesn't help the fact that common
regmap code would be  better than scattering regmap_* in various mfd
drivers.


Regards
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers/base: fix typo

[Junesung Lee]

The word "filesystem" is being used without the space.

Signed-off-by: Junesung Lee 
---
 drivers/base/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 98504ec..9140666 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -42,7 +42,7 @@ config DEVTMPFS
  rescue systems, and reliably handles dynamic major/minor numbers.
 
  Notice: if CONFIG_TMPFS isn't enabled, the simpler ramfs
- file system will be used instead.
+ filesystem will be used instead.
 
 config DEVTMPFS_MOUNT
bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs"
@@ -100,7 +100,7 @@ config FIRMWARE_IN_KERNEL
  Enabling this option will build each required firmware blob
  into the kernel directly, where request_firmware() will find
  them without having to call out to userspace. This may be
- useful if your root file system requires a device that uses
+ useful if your root filesystem requires a device that uses
  such firmware and do not wish to use an initrd.
 
  This single option controls the inclusion of firmware for
-- 
2.1.4

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

Re: [PATCH v4 3/5] gadget: Support for the usb charger framework

[Baolin Wang]

On 19 August 2015 at 20:56, Sergei Shtylyov
 wrote:
> Hello.
>
> On 8/19/2015 12:13 PM, Baolin Wang wrote:
>
>> For supporting the usb charger, it adds the usb_charger_init() and
>> usb_charger_exit() functions for usb charger initialization and exit.
>>
>> Introduce a callback 'get_charger_type' which will implemented by
>> user for usb gadget operations to get the usb charger type.
>>
>> Signed-off-by: Baolin Wang 
>
> [...]
>
>> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> index 755e8bc..44d82f5 100644
>> --- a/include/linux/usb/gadget.h
>> +++ b/include/linux/usb/gadget.h
>> @@ -537,6 +537,7 @@ struct usb_gadget_ops {
>> struct usb_ep *(*match_ep)(struct usb_gadget *,
>> struct usb_endpoint_descriptor *,
>> struct usb_ss_ep_comp_descriptor *);
>> +   enum usb_charger_type   (*get_charger_type)(struct usb_gadget *);
>
>  ^^^ please use space, not tab here

OK.

>
>>   };
>>
>>   /**
>> @@ -611,6 +612,7 @@ struct usb_gadget {
>> struct usb_otg_caps *otg_caps;
>> struct raw_notifier_headnh;
>> struct mutexlock;
>> +   struct usb_charger  *uchger;
>
>
>Why not simply call the field 'charger'? :-)

I think 'uchger' is the abbreviation of 'usb charger' which is maybe a
little verbous, I'll change it. Thanks for your comments.

>
> [...]
>
> WBR, Sergei
>



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] powerpc/hvsi: Fix endianness issues in the HVSI driver

[Michael Ellerman]

On Wed, 2015-08-19 at 23:53 +0200, Laurent Dufour wrote:
> On 04/08/2015 02:51, Michael Ellerman wrote:
> > On Fri, 2015-07-31 at 11:29 +0200, Laurent Dufour wrote:
> >> This patch fixes several endianness issues detected when running the HVSI
> >> driver in little endian mode.
> >>
> >> These issues are raised in little endian mode because the data exchanged in
> >> memory between the kernel and the hypervisor has to be in big endian
> >> format.
> > 
> > Can you include the sparse output before and after?
> 
> Hi Michael,
> 
> Here is the output message displayed on the console when the bug occurred:
> 
> [0.000517] irq: (null) didn't like hwirq-0x1000a00 to VIRQ16 mapping 
> (rc=-22)
> [0.000578] hvsi_console_init: couldn't create irq mapping for 0x1000a00
> 
> With the patch is applied, the hvsi driver is initializing correctly and
> no message is displayed, except the one saying the number of device the
> hvsi driver has configured. For instance:

> [1.535783] HVSI: registered 1 devices


OK that's also good.

I was talking about the output from sparse endian checking, as the driver seems
to already be endian annotated.

ie, before:

$ make C=2 CF=-D__CHECK_ENDIAN__
...
drivers/tty/hvc/hvsi.c:245:36: warning: restricted __be32 degrades to integer
drivers/tty/hvc/hvsi.c:243:23: warning: restricted __be16 degrades to integer
drivers/tty/hvc/hvsi.c:243:23: warning: restricted __be16 degrades to integer
drivers/tty/hvc/hvsi.c:277:36: warning: restricted __be32 degrades to integer
drivers/tty/hvc/hvsi.c:279:36: warning: restricted __be32 degrades to integer
drivers/tty/hvc/hvsi.c:298:26: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:298:26:expected restricted __be16 [assigned] 
[usertype] seqno
drivers/tty/hvc/hvsi.c:298:26:got int
drivers/tty/hvc/hvsi.c:299:21: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:299:21:expected restricted __be16 [assigned] 
[usertype] verb
drivers/tty/hvc/hvsi.c:299:21:got int
drivers/tty/hvc/hvsi.c:301:28: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:301:28:expected restricted __be16 [assigned] 
[usertype] query_seqno
drivers/tty/hvc/hvsi.c:301:28:got int
drivers/tty/hvc/hvsi.c:322:60: warning: incorrect type in argument 2 (different 
base types)
drivers/tty/hvc/hvsi.c:322:60:expected unsigned short [unsigned] [usertype] 
query_seqno
drivers/tty/hvc/hvsi.c:322:60:got restricted __be16 [usertype] seqno
drivers/tty/hvc/hvsi.c:558:26: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:558:26:expected restricted __be16 [assigned] 
[usertype] seqno
drivers/tty/hvc/hvsi.c:558:26:got int
drivers/tty/hvc/hvsi.c:559:21: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:559:21:expected restricted __be16 [assigned] 
[usertype] verb
drivers/tty/hvc/hvsi.c:559:21:got unsigned short [unsigned] [usertype] verb
drivers/tty/hvc/hvsi.c:600:26: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:600:26:expected restricted __be16 [assigned] 
[usertype] seqno
drivers/tty/hvc/hvsi.c:600:26:got int
drivers/tty/hvc/hvsi.c:602:21: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:602:21:expected restricted __be16 [assigned] 
[usertype] verb
drivers/tty/hvc/hvsi.c:602:21:got int
drivers/tty/hvc/hvsi.c:603:21: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:603:21:expected restricted __be32 [assigned] 
[usertype] mask
drivers/tty/hvc/hvsi.c:603:21:got int
drivers/tty/hvc/hvsi.c:606:29: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:606:29:expected restricted __be32 [assigned] 
[usertype] word
drivers/tty/hvc/hvsi.c:606:29:got int
drivers/tty/hvc/hvsi.c:683:26: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:683:26:expected restricted __be16 [assigned] 
[usertype] seqno
drivers/tty/hvc/hvsi.c:683:26:got int
drivers/tty/hvc/hvsi.c:700:26: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:700:26:expected restricted __be16 [assigned] 
[usertype] seqno
drivers/tty/hvc/hvsi.c:700:26:got int
drivers/tty/hvc/hvsi.c:702:21: warning: incorrect type in assignment (different 
base types)
drivers/tty/hvc/hvsi.c:702:21:expected restricted __be16 [assigned] 
[usertype] verb
drivers/tty/hvc/hvsi.c:702:21:got int
...

And with your patch applied there are no warnings from hvsi.c!

So it seems you fixed all the issues, or at least all the issues we can detect
with sparse. So I'll merge this as-is with an updated changelog.

cheers


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

Re: [PATCH] mm: mmap: Simplify the failure return working flow

[gchen gchen]

On Tue, 18 Aug 2015 15:57:08 -0700 a...@linux-foundation.org 
wrote: On Wed, 19 Aug 2015 06:27:58 +0800 Chen Gang 
xili_gchen_5...@hotmail.com wrote: From: Chen Gang 
xili_gchen_5...@hotmail.com As sent, this patch is 
From:you@hotmail and Signed-off-by:you@gmail. This is peculiar. 
 I'm assuming that it should have been From:you@gmail and I have made 
that change to my copy of the patch. You can do this yourself 
by putting an explicit From: line at the start of the 
changelog.Yes, it is really peculiar, the reason is gmail is 
not stable in China.I have to send mail in my hotmail address.But I 
still want to use my gmail as Signed-off-by, since I have alreadyused it, 
and also its name is a little formal than my hotmail.Welcome any ideas, 
suggestions and completions for it (e.g. if it isnecessary to let send mail 
and Signed-off-by mail be the same, I shalltry).[...] 
So, --- 
a/mm/mmap.c~mm-mmap-simplify-the-failure-return-working-flow-fix +++ 
a/mm/mmap.c @@ -2952,7 +2952,7 @@ struct vm_area_struct 
*copy_vma(struct v } else { new_vma = 
kmem_cache_alloc(vm_area_cachep, GFP_KERNEL); if 
(!new_vma) -   return NULL; +   
goto out; *new_vma = *vma;  
   new_vma-vm_start = addr; new_vma-vm_end = 
addr + len; @@ -2971,10 +2971,11 @@ struct vm_area_struct 
*copy_vma(struct v } return 
new_vma; - out_free_mempol: +out_free_mempol:   
  mpol_put(vma_policy(new_vma)); - out_free_vma: 
+out_free_vma: kmem_cache_free(vm_area_cachep, 
new_vma); +out: return NULL;  
}It is OK to me, thanks.During these days (2-4 months), 
I shall try to make some patches forLinux mm: - I am learning Linux 
kernel mmu, so I can re-use part of code to user   mode (add softmmu to 
qemu linux user in my working time). Then I can   try some mm patches when 
I am reading related code. - At present, cross-building various archs 
with allmodconfig looks OK   (have no many issues), so for me, I can stop 
and start another parts   (e.g. mmu, loongson machine of mips arch, 
...).Welcome any ideas, suggestions and completions for it: - 
Assume I am not quite familiar with mmu -- in honest, I feel I am   really 
not. - Is it possible to build the related 'softmmu' as a module which 
can   be used by both kernel mode and user mode (if really it is, I 
shall   try to perform it -- I can do it in my working time). - 
...Thanks.--Chen GangOpen, share, and attitude like 
air, water, and life which God blessed  

Re: [PATCH] mm: mmap: Simplify the failure return working flow

[gchen gchen]

On Tue, 18 Aug 2015 15:57:08 -0700 a...@linux-foundation.org wrote:
>
> On Wed, 19 Aug 2015 06:27:58 +0800 Chen Gang
>  wrote:
>
>> From: Chen Gang 
>
> As sent, this patch is From:you@hotmail and Signed-off-by:you@gmail.
>
> This is peculiar.  I'm assuming that it should have been From:you@gmail and
> I have made that change to my copy of the patch.
>
> You can do this yourself by putting an explicit From: line at the start
> of the changelog.
>

Yes, it is really peculiar, the reason is gmail is not stable in China.
I have to send mail in my hotmail address.

But I still want to use my gmail as Signed-off-by, since I have already
used it, and also its name is a little formal than my hotmail.

Welcome any ideas, suggestions and completions for it (e.g. if it is
necessary to let send mail and Signed-off-by mail be the same, I shall
try).

[...]

> So,
>
> --- a/mm/mmap.c~mm-mmap-simplify-the-failure-return-working-flow-fix
> +++ a/mm/mmap.c
> @@ -2952,7 +2952,7 @@ struct vm_area_struct *copy_vma(struct v
> } else {
> new_vma = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
> if (!new_vma)
> -   return NULL;
> +   goto out;
> *new_vma = *vma;
> new_vma->vm_start = addr;
> new_vma->vm_end = addr + len;
> @@ -2971,10 +2971,11 @@ struct vm_area_struct *copy_vma(struct v
> }
> return new_vma;
>
> - out_free_mempol:
> +out_free_mempol:
> mpol_put(vma_policy(new_vma));
> - out_free_vma:
> +out_free_vma:
> kmem_cache_free(vm_area_cachep, new_vma);
> +out:
> return NULL;
>  }
>

It is OK to me, thanks.

During these days (2-4 months), I shall try to make some patches for
Linux mm:

 - I am learning Linux kernel mmu, so I can re-use part of code to user
   mode (add softmmu to qemu linux user in my working time). Then I can
   try some mm patches when I am reading related code.

 - At present, cross-building various archs with allmodconfig looks OK
   (have no many issues), so for me, I can stop and start another parts
   (e.g. mmu, loongson machine of mips arch, ...).

Welcome any ideas, suggestions and completions for it:

 - Assume I am not quite familiar with mmu -- in honest, I feel I am
   really not.

 - Is it possible to build the related 'softmmu' as a module which can
   be used by both kernel mode and user mode (if really it is, I shall
   try to perform it -- I can do it in my working time).

 - ...

Thanks.
--
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
  

Re: [PATCH v4 5/5] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

On 20 August 2015 at 00:24, Mark Brown  wrote:
> On Wed, Aug 19, 2015 at 05:13:48PM +0800, Baolin Wang wrote:
>> Integrate with the newly added USB charger interface to limit the current
>> we draw from the USB input based on the input device configuration
>> identified by the USB stack, allowing us to charge more quickly from high
>> current inputs without drawing more current than specified from others.
>>
>> Signed-off-by: Mark Brown 
>> Signed-off-by: Baolin Wang 
>
> When people (like Charles and Lee have) have reviewed a change you
> should add any tags they gave when you resend the change so they don't
> have to duplicate their work and other people know that the review has
> happened.

Make sense. Thanks.


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

Re: [PATCH v3 0/5] sync a se with its cfs_rq when att(det)aching it

[Peter Zijlstra]

I did something like this on top.. please have a look at the XXX and
integrate.

---

--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2664,8 +2664,8 @@ static inline u64 cfs_rq_clock_task(stru
 /* Group cfs_rq's load_avg is used for task_h_load and update_cfs_share */
 static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
 {
-   int decayed;
struct sched_avg *sa = _rq->avg;
+   int decayed;
 
if (atomic_long_read(_rq->removed_load_avg)) {
long r = atomic_long_xchg(_rq->removed_load_avg, 0);
@@ -2695,15 +2695,16 @@ static inline int update_cfs_rq_load_avg
 static inline void update_load_avg(struct sched_entity *se, int update_tg)
 {
struct cfs_rq *cfs_rq = cfs_rq_of(se);
-   int cpu = cpu_of(rq_of(cfs_rq));
u64 now = cfs_rq_clock_task(cfs_rq);
+   int cpu = cpu_of(rq_of(cfs_rq));
 
/*
 * Track task load average for carrying it to new CPU after migrated, 
and
 * track group sched_entity load average for task_h_load calc in 
migration
 */
__update_load_avg(now, cpu, >avg,
-   se->on_rq * scale_load_down(se->load.weight), cfs_rq->curr == 
se, NULL);
+ se->on_rq * scale_load_down(se->load.weight),
+ cfs_rq->curr == se, NULL);
 
if (update_cfs_rq_load_avg(now, cfs_rq) && update_tg)
update_tg_load_avg(cfs_rq, 0);
@@ -2718,9 +2719,10 @@ static void attach_entity_load_avg(struc
 * update here. we have to update it with prev cfs_rq just before 
changing
 * se's cfs_rq, and get here soon.
 */
-   if (se->avg.last_update_time)
+   if (se->avg.last_update_time) {
__update_load_avg(cfs_rq->avg.last_update_time, 
cpu_of(rq_of(cfs_rq)),
-   >avg, 0, 0, NULL);
+ >avg, 0, 0, NULL);
+   }
 
se->avg.last_update_time = cfs_rq->avg.last_update_time;
cfs_rq->avg.load_avg += se->avg.load_avg;
@@ -2732,17 +2734,13 @@ static void attach_entity_load_avg(struc
 static void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
 {
__update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq_of(cfs_rq)),
-   >avg, se->on_rq * scale_load_down(se->load.weight),
-   cfs_rq->curr == se, NULL);
+ >avg, se->on_rq * 
scale_load_down(se->load.weight),
+ cfs_rq->curr == se, NULL);
 
-   cfs_rq->avg.load_avg =
-   max_t(long, cfs_rq->avg.load_avg - se->avg.load_avg, 0);
-   cfs_rq->avg.load_sum =
-   max_t(s64, cfs_rq->avg.load_sum - se->avg.load_sum, 0);
-   cfs_rq->avg.util_avg =
-   max_t(long, cfs_rq->avg.util_avg - se->avg.util_avg, 0);
-   cfs_rq->avg.util_sum =
-   max_t(s32, cfs_rq->avg.util_sum - se->avg.util_sum, 0);
+   cfs_rq->avg.load_avg = max_t(long, cfs_rq->avg.load_avg - 
se->avg.load_avg, 0);
+   cfs_rq->avg.load_sum = max_t(s64,  cfs_rq->avg.load_sum - 
se->avg.load_sum, 0);
+   cfs_rq->avg.util_avg = max_t(long, cfs_rq->avg.util_avg - 
se->avg.util_avg, 0);
+   cfs_rq->avg.util_sum = max_t(s32,  cfs_rq->avg.util_sum - 
se->avg.util_sum, 0);
 }
 
 /* Add the load generated by se into cfs_rq's load average */
@@ -2751,14 +2749,14 @@ enqueue_entity_load_avg(struct cfs_rq *c
 {
struct sched_avg *sa = >avg;
u64 now = cfs_rq_clock_task(cfs_rq);
-   int migrated = 0, decayed;
+   int migrated, decayed;
 
-   if (sa->last_update_time == 0)
-   migrated = 1;
-   else
+   migrated = !sa->last_update_time;
+   if (!migrated) {
__update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa,
se->on_rq * scale_load_down(se->load.weight),
cfs_rq->curr == se, NULL);
+   }
 
decayed = update_cfs_rq_load_avg(now, cfs_rq);
 
@@ -2781,7 +2779,7 @@ dequeue_entity_load_avg(struct cfs_rq *c
cfs_rq->runnable_load_avg =
max_t(long, cfs_rq->runnable_load_avg - se->avg.load_avg, 0);
cfs_rq->runnable_load_sum =
-   max_t(s64, cfs_rq->runnable_load_sum - se->avg.load_sum, 0);
+   max_t(s64,  cfs_rq->runnable_load_sum - se->avg.load_sum, 0);
 }
 
 /*
@@ -2849,6 +2847,11 @@ static inline void
 dequeue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) {}
 static inline void remove_entity_load_avg(struct sched_entity *se) {}
 
+static inline void
+attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) {}
+static inline void
+detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) {}
+
 static inline int idle_balance(struct rq *rq)
 {
return 0;
@@ -7915,29 +7918,50 @@ prio_changed_fair(struct rq *rq, struct
check_preempt_curr(rq, p, 0);
 }
 
-static void detach_task_cfs_rq(struct task_struct *p, int 

Re: provide more common DMA API functions V2

[Michael Ellerman]

On Thu, 2015-08-20 at 09:52 +1000, Stephen Rothwell wrote:
> Hi Andrew (sorry, I can't tell who made the incorrect statement below
> that I am replying to),
> 
> On Wed, 19 Aug 2015 14:36:56 -0700 Andrew Morton  
> wrote:
> >
> > On Wed, 19 Aug 2015 10:08:14 +0200 Christoph Hellwig  wrote:
> > 
> > > On Tue, Aug 18, 2015 at 09:51:07AM +0200, Ingo Molnar wrote:
> > > > I.e. shouldn't this be:
> > > > 
> > > > > I'll merge these 5 patches for 4.4.  That means I'll release them 
> > > > > into 
> > > > > linux-next after 4.2 is released.
> > > > >
> > > > > [...]
> > > > > 
> > > > > Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next 
> > > > > is supposed 
> > > > > to contain only 4.3 material.  Once 4.2 is released and the 4.3 merge 
> > > > > window 
> > > > > opens, linux-next is open for 4.4 material.
> 
> Just to be clear: the above should read "Once 4.2 is released and the
> 4.3 merge window *closes* (i.e. v4.3-rc1 is released), linux-next is
> open for 4.4 material".

/me registers www.whatdamnkernelversionareweuptoagain.com

cheers


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

Re: [PATCH] x86_64/efi: Mapping Boot and Runtime EFI memory regions to different starting virtual address

[joeyli]

On Wed, Aug 19, 2015 at 05:31:45PM +0100, Matt Fleming wrote:
> On Thu, 30 Jul, at 10:16:01PM, joeyli wrote:
> > 
> > Thanks for your explanation.
> > 
> > For my issue, I will check if rewriting the VA of runtime services can fix 
> > issue.
> > If not, then I think need find a way to sync the mapping in EFI page table 
> > between
> > boot kernel and image kernel.
> 
> Hey Joey, did you make any progress with this issue?
> 
> -- 
> Matt Fleming, Intel Open Source Technology Center

I am sticky on other issue and hope back to trace this problem in this week.
Sorry for my delay!


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

Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Dave,

On 08/19/2015 06:54 PM, Dave Airlie wrote:

On 20 August 2015 at 00:48, Yakir Yang  wrote:

Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM ;)

Beyond that, there are three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).

I have verified this series on two kinds of rockchip platform board, one
is rk3288 sdk board which connect with a 2K display port monitor, the other
is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
both of them works rightlly.

I haven't verified the dp function on samsung platform, cause I haven't got
exynos boards. I can only ensure that there are no build error on samsung
platform, wish some samsung guys help to test. ;)

I'd like to pull this in, but it probably needs an ack from Samsung,

Inki can you guys find some time to test this?

Dave.


Wow, thanks a lots  :-)

Still waiting for some reviews and acks.

Best regards,
- Yakir






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

linux-next: manual merge of the tile tree with the microblaze tree

[Stephen Rothwell]

Hi Chris,

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

  include/uapi/linux/elf-em.h

between commit:

  bb88ba0946dd ("elf-em.h: move EM_MICROBLAZE to the common header")

from the microblaze tree and commit:

  a0ddef81f4ae ("tile: enable full SECCOMP support")

from the tile tree.

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

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

diff --cc include/uapi/linux/elf-em.h
index 8c90a7972a2f,3429a3ba382b..
--- a/include/uapi/linux/elf-em.h
+++ b/include/uapi/linux/elf-em.h
@@@ -38,7 -38,8 +38,9 @@@
  #define EM_ALTERA_NIOS2   113 /* Altera Nios II soft-core processor */
  #define EM_TI_C6000   140 /* TI C6X DSPs */
  #define EM_AARCH64183 /* ARM 64 bit */
+ #define EM_TILEPRO188 /* Tilera TILEPro */
 +#define EM_MICROBLAZE 189 /* Xilinx MicroBlaze */
+ #define EM_TILEGX 191 /* Tilera TILE-Gx */
  #define EM_FRV0x5441  /* Fujitsu FR-V */
  #define EM_AVR32  0x18ad  /* Atmel AVR32 */
  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] dmaengine: pl330: do not emit loop for 1 byte transfer.

[Vinod Koul]

On Thu, Aug 20, 2015 at 08:58:49AM +0900, Krzysztof Kozłowski wrote:
> 2015-08-20 1:42 GMT+09:00 Vinod Koul :
> >
> > On Thu, Jul 23, 2015 at 06:04:49PM +0200, Michal Suchanek wrote:
> > > When there is only one burst required do not emit loop instructions to
> > > loop exactly once. Emit just the body of the loop.
> >
> > Applied, thanks
> 
> Where is the patch? I can't find it on my subscribed mailing lists
> (like dmaengine, LKML). It seems it is not present also in Google. The
> same applies to 2/2. I see only replies (Vinod's and Michal's) but not
> original email.

Now that you mentioned I did notice that too. Somehow the vger lists have
rejected this patch, althpugh it is addressed to both dmaengine and lkml
list

-- 
~Vinod

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

Re: [RFC PATCH 1/7] x86, mm: ZONE_DEVICE for "device memory"

[Dan Williams]

On Tue, Aug 18, 2015 at 12:06 PM, Jerome Glisse  wrote:
> On Tue, Aug 18, 2015 at 10:23:38AM -0700, Dan Williams wrote:
> Thought maybe you don't need a new ZONE_DEV and all you need is valid
> struct page for this device memory, and you don't want this page to be
> useable by the general memory allocator. There is surely other ways to
> achieve that like marking all as reserved when you hotplug them.
>

Yes, there are other ways that can achieve the same thing, but I do
like the ability to do reverse page to zone lookups for debug if
anything.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Exporting obscene amounts of data in rtnl_link_ops->fill_info()

[Jason A. Donenfeld]

Hi guys,

I have a new link driver that registers a rtnl_link_ops. For many
things, the rtnl interfaces are perfectly suited: I can use netlink in
userspace to check out packet counts, adjust interface parameters, and
all sorts of things. There is even the "fill_info" function exporting
interface-specific types of data to userspace through the standard
netlink interfaces. I'm glad this is here, because it's exactly what I
want.

Problem: sometimes I want to export a *lot* of data to userspace. When
this happens, even if I make the netlink socket receive buffer really
huge, this code path is still reached in rtnetlink.c:

err = rtnl_fill_ifinfo(skb, dev, RTM_NEWLINK,
   NETLINK_CB(cb->skb).portid,
   cb->nlh->nlmsg_seq, 0,
   NLM_F_MULTI,
   ext_filter_mask);
/* If we ran out of room on the first message,
 * we're in trouble
 */
WARN_ON((err == -EMSGSIZE) && (skb->len == 0));

That is -- it tries to fill the skb (for sending it back to
userspace), but doesn't have enough room, so it returns -EMSGSIZE.
That seems like reasonable behavior, but it doesn't really help me
obtain my goal. I'd like to send quite a bit of data back to userspace
for a network interface, and I'd like to do it using the standard
netlink APIs. Is this possible?

Thanks,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [PATCH v3 00/20] xen/arm64: Add support for 64KB page

[Julien Grall]

Hi,

Ping? I'm missing some reviews on block and netfront code.

We'd like to see this series going in Linux 4.3. Some distributions 
plans to use this version for aarch64 support. If we miss it, we won't 
have any Xen guests support, even it's minimal, for Linux using 64KB 
page granularity.


Regards,

On 07/08/2015 09:46, Julien Grall wrote:

Hi all,

ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
hypercall interface and PV protocol are always based on 4KB page granularity.

Any attempt to boot a Linux guest with 64KB pages enabled will result to a
guest crash.

This series is a first attempt to allow those Linux running with the current
hypercall interface and PV protocol.

This solution has been chosen because we want to run Linux 64KB in released
Xen ARM version or/and platform using an old version of Linux DOM0.

There is room for improvement, such as support of 64KB grant, modification
of PV protocol to support different page size... They will be explored in a
separate patch series later.

TODO list:
 - Convert swiotlb to 64KB
 - Convert xenfb to 64KB
 - Check if backend in QEMU works with DOM0 64KB
 - It may be possible to move some common define between
 netback/netfront and blkfront/blkback in an header

All patches has been built tested for ARM32, ARM64, x86. But I haven't tested
to run it on x86 as I don't have a box with Xen x86 running. I would be
happy if someone give a try and see possible regression for x86.

A branch based on the latest linux/master can be found here:

git://xenbits.xen.org/people/julieng/linux-arm.git branch xen-64k-v3

Comments, suggestions are welcomed.

Sincerely yours,

Cc: david.vra...@citrix.com
Cc: konrad.w...@oracle.com
Cc: boris.ostrov...@oracle.com
Cc: wei.l...@citrix.com
Cc: roger@citrix.com

Julien Grall (20):
   net/xen-netback: xenvif_gop_frag_copy: move GSO check out of the loop
   arm/xen: Drop pte_mfn and mfn_pte
   xen: Add Xen specific page definition
   xen/grant: Introduce helpers to split a page into grant
   xen/grant: Add helper gnttab_page_grant_foreign_access_ref_one
   block/xen-blkfront: Split blkif_queue_request in 2
   block/xen-blkfront: Store a page rather a pfn in the grant structure
   block/xen-blkfront: split get_grant in 2
   xen/biomerge: Don't allow biovec to be merge when Linux is not using
 4KB page
   xen/xenbus: Use Xen page definition
   tty/hvc: xen: Use xen page definition
   xen/balloon: Don't rely on the page granularity is the same for Xen
 and Linux
   xen/events: fifo: Make it running on 64KB granularity
   xen/grant-table: Make it running on 64KB granularity
   block/xen-blkfront: Make it running on 64KB page granularity
   block/xen-blkback: Make it running on 64KB page granularity
   net/xen-netfront: Make it running on 64KB page granularity
   net/xen-netback: Make it running on 64KB page granularity
   xen/privcmd: Add support for Linux 64KB page granularity
   arm/xen: Add support for 64KB page granularity

  arch/arm/include/asm/xen/page.h |  18 +-
  arch/arm/xen/enlighten.c|   6 +-
  arch/arm/xen/p2m.c  |   6 +-
  arch/x86/include/asm/xen/page.h |   2 +-
  drivers/block/xen-blkback/blkback.c |   5 +-
  drivers/block/xen-blkback/common.h  |  17 +-
  drivers/block/xen-blkback/xenbus.c  |   9 +-
  drivers/block/xen-blkfront.c| 552 +++-
  drivers/net/xen-netback/common.h|  15 +-
  drivers/net/xen-netback/netback.c   | 163 +++
  drivers/net/xen-netfront.c  | 122 +---
  drivers/tty/hvc/hvc_xen.c   |   4 +-
  drivers/xen/balloon.c   |  47 ++-
  drivers/xen/biomerge.c  |   8 +
  drivers/xen/events/events_base.c|   2 +-
  drivers/xen/events/events_fifo.c|   2 +-
  drivers/xen/grant-table.c   |  32 ++-
  drivers/xen/privcmd.c   |   8 +-
  drivers/xen/xenbus/xenbus_client.c  |   6 +-
  drivers/xen/xenbus/xenbus_probe.c   |   3 +-
  drivers/xen/xlate_mmu.c | 124 +---
  include/xen/grant_table.h   |  51 
  include/xen/page.h  |  27 +-
  23 files changed, 844 insertions(+), 385 deletions(-)



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

DEBUG_LOCKS_WARN_ON(in_interrupt()) triggering in socket code

[Jason A. Donenfeld]

Hi folks,

In setting up a socket, there are two functions I make use of that in
turn wind up calling static_key_slow_inc: setup_udp_tunnel_sock and
sk_set_memalloc. These both make use of static_key_slow_inc because
they selectively enable certain important code paths.

This is all fine, except it poses some problems when calling these
functions inside of .ndo_open. In that case, I get ugly (debug)
warnings like this:

WARNING: CPU: 1 PID: 2002 at kernel/locking/mutex.c:526
mutex_lock_nested+0x39b/0x3b0()
DEBUG_LOCKS_WARN_ON(in_interrupt())
 [] dump_stack+0x45/0x57
 [] warn_slowpath_common+0x8a/0xc0
 [] warn_slowpath_fmt+0x55/0x70
 [] mutex_lock_nested+0x39b/0x3b0
 [] static_key_slow_inc+0x59/0xc0
 [] udp_encap_enable+0x20/0x30
 [] setup_udp_tunnel_sock+0x55/0x70
 [] socket_init+0x1cc/0x3a0
 [] open+0x21/0x1b0
 [] __dev_open+0xb0/0x110
 [] __dev_change_flags+0xa1/0x160
 [] dev_change_flags+0x29/0x70
 [] do_setlink+0x5da/0xa80
 [] rtnl_newlink+0x50d/0x8a0
 [] rtnetlink_rcv_msg+0xa1/0x240
 [] netlink_rcv_skb+0x9b/0xc0
 [] rtnetlink_rcv+0x2e/0x40
 [] netlink_unicast+0x16f/0x200
 [] netlink_sendmsg+0x339/0x380
 [] ___sys_sendmsg+0x2f9/0x310
 [] __sys_sendmsg+0x57/0xa0
 [] SyS_sendmsg+0x12/0x20
 [] entry_SYSCALL_64_fastpath+0x16/0x7a

The reason is that the static key code makes use of mutexes. And the
mutex debug code ensures that in_interrupt() is zero; otherwise it
prints that warning. In this case, in_interrupt() has a value of 512.

So, questions:

1. Is the best thing to do just move my socket creation routine into a
workqueue, and avoid this issue all together?
2. Is it, in fact, incorrect to check for in_interrupt(), and the
debug assertion is actually wrong?
3. Is it a bug that in_interrupt() is returning non-zero in relation
to a syscall?

Thanks,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xen/tmem: Pass page instead of pfn to xen_tmem_get_page()

[Julien Grall]

Hi,

On 19/08/2015 06:25, Murilo Opsfelder Araujo wrote:

The commit 091208a676dfdabb2b8fe86ee155c6fc80081b69 "xen/tmem: Use
xen_page_to_gfn rather than pfn_to_gfn" left behind a call to
xen_tmem_get_page() receiving pfn instead of page.

This change also fixes the following build warning:

drivers/xen/tmem.c: In function ‘tmem_cleancache_get_page’:
drivers/xen/tmem.c:194:47: warning: passing argument 4 of ‘xen_tmem_get_page’ 
makes pointer from integer without a cast
   ret = xen_tmem_get_page((u32)pool, oid, ind, pfn);
^
drivers/xen/tmem.c:138:12: note: expected ‘struct page *’ but argument is of 
type ‘long unsigned int’
  static int xen_tmem_get_page(u32 pool_id, struct tmem_oid oid,
 ^

Signed-off-by: Murilo Opsfelder Araujo 


Sorry for the breakage, I haven't spot it because CONFIG_CLEANCACHE is 
not enabled on my config.


Reviewed-by: Julien Grall 

Regards,

--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: temperature: add max6675 thermocouple converter driver

[Matt Porter]

On Sat, Aug 08, 2015 at 12:39:40PM +0100, Jonathan Cameron wrote:
> On 06/08/15 18:38, Matt Porter wrote:
> > On Mon, Aug 03, 2015 at 11:26:12PM +0200, Peter Meerwald wrote:
> >> On Mon, 3 Aug 2015, Matt Porter wrote:
> > 
> > ...
> > 
> >>> +static int max6675_read(struct max6675_state *st, int *val)
> >>> +{
> >>> + int ret;
> >>> +
> >>> + ret = spi_read(st->spi, val, 2);
> >>> + if (ret < 0)
> >>> + return ret;
> >>> +
> >>> + /* Temperature is bits 14..3 */
> >>> + *val = (*val >> 3) & 0xfff;
> >>
> >> what about endianness conversion?
> >> use be16_to_cpu()
> > 
> > Apologies, I spoke before engaging the brain on my first reply to this
> > As specified by the SPI subsystem docs, SPI buffers are always stored
> > in native endian order. There is no need for endianness conversion here.
> First of all, which doc say this?
> Secondly how does SPI know the endianness of the sensor which is what
> actually matters here?  I2C can in theory make these guarantees as there
> is an expected byte order on the wire (even if quite a few drivers don't
> conform to the spec anyway). No such guarantee can exist for SPI.

include/linux/spi/spi.h:

 * In-memory data values are always in native CPU byte order, translated
 * from the wire byte order (big-endian except with SPI_LSB_FIRST).  So
 * for example when bits_per_word is sixteen, buffers are 2N bytes long
 * (@len = 2N) and hold N sixteen bit words in CPU byte order.

So, as you mention, there's no standardized byte order but it's
controlled with the per transfer flag and big endian by default.

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

[GIT] Networking

[David Miller]

1) Out of bounds array access in 802.11 minstrel code, from Adrien
   Schildknecht.

2) Don't use skb_get() in IGMP/MLD code paths, as this makes
   pskb_may_pull() BUG.  From Linus Luessing.

3) Fix off by one in ipv4 route dumping code, from Andy Whitcroft.

4) Fix deadlock in reqsk_queue_unlink(), from Eric Dumazet.

5) Fix ppp device deregistration wrt. netns deletion, from
   Guillaume Nault.

6) Fix deadlock when creating per-cpu ipv6 routes, from Martin KaFai
   Lau.

7) Fix memory leak in batman-adv code, from Sven Eckelmann.

Please pull, thanks a lot!

The following changes since commit 5b3e2e14eaa2a98232a4f292341fb88438685734:

  Merge tag 'dm-4.2-fixes-5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm 
(2015-08-13 13:52:46 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master

for you to fetch changes up to fd7dec25a18f495e50d2040398fd263836ff3b28:

  batman-adv: Fix memory leak on tt add with invalid vlan (2015-08-18 19:08:23 
-0700)


Adrien Schildknecht (1):
  mac80211: fix invalid read in minstrel_sort_best_tp_rates()

Andy Whitcroft (1):
  ipv4: off-by-one in continuation handling in /proc/net/route

Calvin Owens (1):
  Revert "net: limit tcp/udp rmem/wmem to SOCK_{RCV,SND}BUF_MIN"

Claudiu Manoil (1):
  gianfar: Restore link state settings after MAC reset

Dan Carpenter (1):
  net: ethernet: micrel: fix an error code

David S. Miller (2):
  Merge tag 'mac80211-for-davem-2015-08-14' of 
git://git.kernel.org/.../jberg/mac80211
  Merge branch 'ipv6_percpu_rt_deadlock'

David Ward (1):
  net: qmi_wwan: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module

Eric Dumazet (1):
  inet: fix potential deadlock in reqsk_queue_unlink()

Guillaume Nault (1):
  ppp: fix device unregistration upon netns deletion

Igor Plyatov (1):
  net: phy: workaround for buggy cable detection by LAN8700 after cable 
plugging

Ivan Vecera (1):
  be2net: avoid vxlan offloading on multichannel configs

Linus Lüssing (1):
  net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code

Martin KaFai Lau (3):
  ipv6: Remove un-used argument from ip6_dst_alloc()
  ipv6: Add rt6_make_pcpu_route()
  ipv6: Fix a potential deadlock when creating pcpu rt

Shaohui Xie (1):
  net: phy: fix PHY_RUNNING in phy_state_machine

Sven Eckelmann (1):
  batman-adv: Fix memory leak on tt add with invalid vlan

kbuild test robot (1):
  net: phy: fix semicolon.cocci warnings

 drivers/net/ethernet/emulex/benet/be_main.c |4 ++--
 drivers/net/ethernet/freescale/gianfar.c|5 +
 drivers/net/ethernet/micrel/ks8842.c|5 ++---
 drivers/net/phy/phy.c   |   16 
 drivers/net/phy/smsc.c  |   31 
+++
 drivers/net/ppp/ppp_generic.c   |   78 
++
 drivers/net/usb/qmi_wwan.c  |1 +
 net/batman-adv/translation-table.c  |5 -
 net/bridge/br_multicast.c   |4 ++--
 net/core/skbuff.c   |   37 
++---
 net/ipv4/fib_trie.c |2 +-
 net/ipv4/igmp.c |   33 
++---
 net/ipv4/inet_connection_sock.c |2 +-
 net/ipv4/sysctl_net_ipv4.c  |   10 --
 net/ipv6/ip6_fib.c  |2 ++
 net/ipv6/mcast_snoop.c  |   33 
++---
 net/ipv6/route.c|   79 
+++
 net/mac80211/rc80211_minstrel.c |   11 ++-
 18 files changed, 212 insertions(+), 146 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node

[David Rientjes]

On Wed, 19 Aug 2015, Patil, Kiran wrote:

> Acked-by: Kiran Patil 

Where's the call to preempt_disable() to prevent kernels with preemption 
from making numa_node_id() invalid during this iteration?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 4.2-rc7: mutex-related crash on boot (radeon?)

[Dave Airlie]

On 19 August 2015 at 00:28, Meelis Roos  wrote:
> Hi, I tried 4.2-rc7 and todays 4.2-rc7+git on a P4 PC with Intel 850
> chipset and old Radeon graphics. The machine crashes during boot and
> starts spamming dmesg as fast as it scrolls. Netconsole caught the
> dmesg. 4.1.0 worked fine.
>
> The first crash seems to be related to radeon_hotplug_work_func during
> radeon initialization.

Looks like a race at startup, I've sent a fix to dri-devel that should work.

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

Re: [PATCH] regulator: Add lockdep asserts to help detecting locking misuse

[Krzysztof Kozlowski]

On 19.08.2015 22:08, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> On Wed, Jun 10, 2015 at 8:23 AM, Krzysztof Kozlowski
>  wrote:
>> Add lockdep_assert_held_once() to functions explicitly mentioning that
>> rdev or regulator_list mutex must be held. Using WARN_ONCE shouldn't
>> pollute the dmesg to much.
>>
>> The patch (if CONFIG_LOCKDEP enabled) will show warnings in certain
>> regulators calling regulator_notifier_call_chain() without rdev->mutex
>> held.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>>
>> ---
>>
>> Warnings for missing locks when calling regulator_notifier_call_chain()
>> should appear on many regulators except wm8350-regulator.c, e.g.:
>> da9055-regulator.c, da9062-regulator.c, da9063-regulator.c,
>> da9211-regulator.c, wm831x-dcdc.c and few more.
>>
>> The question is whether the lock during that call should be held?
> 
> That was a (so far, not counting the "Applied, thanks!") unanswered question?
> 
> For the first time ever, I got:
> 
> drivers/regulator/core.c:3480 
> regulator_notifier_call_chain+0x54/0x80()
> 
> due to da9210_irq_handler() not taking the mutex.
> 
> Drivers calling regulator_notifier_call_chain() from a threaded interrupt
> handler should be OK calling mutex_lock().
> 
> Does anyone have plans to fix all affected drivers?

Question is still unanswered. I don't have plans to fix the drivers
because I don't have necessary hardware. Blindly fixing such minor issue
could do more harm than good. I just polluted the dmesg with WARN hoping
that this will wake up someone :) .

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

Re: [Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node

[David Rientjes]

On Wed, 19 Aug 2015, Jiang Liu wrote:

> > Why not simply fix build_zonelists_node() so that the __GFP_THISNODE 
> > zonelists are set up to reference the zones of cpu_to_mem() for memoryless 
> > nodes?
> > 
> > It seems much better than checking and maintaining every __GFP_THISNODE 
> > user to determine if they are using a memoryless node or not.  I don't 
> > feel that this solution is maintainable in the longterm.
> Hi David,
>   There are some usage cases, such as memory migration,
> expect the page allocator rejecting memory allocation requests
> if there is no memory on local node. So we have:
> 1) alloc_pages_node(cpu_to_node(), __GFP_THISNODE) to only allocate
> memory from local node.
> 2) alloc_pages_node(cpu_to_mem(), __GFP_THISNODE) to allocate memory
> from local node or from nearest node if local node is memoryless.
> 

Right, so do you think it would be better to make the default zonelists be 
setup so that cpu_to_node()->zonelists == cpu_to_mem()->zonelists and then 
individual callers that want to fail for memoryless nodes check 
populated_zone() themselves?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/9] kernel/profile.c: Replace cpu_to_mem() with cpu_to_node()

[David Rientjes]

On Wed, 19 Aug 2015, Jiang Liu wrote:

> On 2015/8/18 8:31, David Rientjes wrote:
> > On Mon, 17 Aug 2015, Jiang Liu wrote:
> > 
> >> Function profile_cpu_callback() allocates memory without specifying
> >> __GFP_THISNODE flag, so replace cpu_to_mem() with cpu_to_node()
> >> because cpu_to_mem() may cause suboptimal memory allocation if
> >> there's no free memory on the node returned by cpu_to_mem().
> >>
> > 
> > Why is cpu_to_node() better with regard to free memory and NUMA locality?
> Hi David,
>   Thanks for review. This is a special case pointed out by Tejun.
> For the imagined topology, A<->B<->X<->C<->D, where A, B, C, D has
> memory and X is memoryless.
> Possible fallback lists are:
> B: [ B, A, C, D]
> X: [ B, C, A, D]
> C: [ C, D, B, A]
> 
> cpu_to_mem(X) will either return B or C. Let's assume it returns B.
> Then we will use "B: [ B, A, C, D]" to allocate memory for X, which
> is not the optimal fallback list for X. And cpu_to_node(X) returns
> X, and "X: [ B, C, A, D]" is the optimal fallback list for X.

Ok, that makes sense, but I would prefer that this 
alloc_pages_exact_node() change to alloc_pages_node() since, as you 
mention in your commit message, __GFP_THISNODE is not set.

In the longterm, if we setup both zonelists correctly (no __GFP_THISNODE 
and with __GFP_THISNODE), then I'm not sure there's any reason to ever use 
cpu_to_mem() for alloc_pages().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] dmaengine: pl330: do not emit loop for 1 byte transfer.

[Krzysztof Kozłowski]

2015-08-20 1:42 GMT+09:00 Vinod Koul :
>
> On Thu, Jul 23, 2015 at 06:04:49PM +0200, Michal Suchanek wrote:
> > When there is only one burst required do not emit loop instructions to
> > loop exactly once. Emit just the body of the loop.
>
> Applied, thanks

Where is the patch? I can't find it on my subscribed mailing lists
(like dmaengine, LKML). It seems it is not present also in Google. The
same applies to 2/2. I see only replies (Vinod's and Michal's) but not
original email.

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

Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver

[Dave Airlie]

On 20 August 2015 at 00:48, Yakir Yang  wrote:
>
> Hi all,
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM ;)
>
> Beyond that, there are three light registers setting differents bewteen
> exynos and rk3288.
> 1. RK3288 have five special pll resigters which not indicata in exynos
>dp controller.
> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>between rk3288 and exynos.
> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>register).
>
> I have verified this series on two kinds of rockchip platform board, one
> is rk3288 sdk board which connect with a 2K display port monitor, the other
> is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
> both of them works rightlly.
>
> I haven't verified the dp function on samsung platform, cause I haven't got
> exynos boards. I can only ensure that there are no build error on samsung
> platform, wish some samsung guys help to test. ;)

I'd like to pull this in, but it probably needs an ack from Samsung,

Inki can you guys find some time to test this?

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

Re: provide more common DMA API functions V2

[Stephen Rothwell]

Hi Andrew (sorry, I can't tell who made the incorrect statement below
that I am replying to),

On Wed, 19 Aug 2015 14:36:56 -0700 Andrew Morton  
wrote:
>
> On Wed, 19 Aug 2015 10:08:14 +0200 Christoph Hellwig  wrote:
> 
> > On Tue, Aug 18, 2015 at 09:51:07AM +0200, Ingo Molnar wrote:
> > > I.e. shouldn't this be:
> > > 
> > > > I'll merge these 5 patches for 4.4.  That means I'll release them into 
> > > > linux-next after 4.2 is released.
> > > >
> > > > [...]
> > > > 
> > > > Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next is 
> > > > supposed 
> > > > to contain only 4.3 material.  Once 4.2 is released and the 4.3 merge 
> > > > window 
> > > > opens, linux-next is open for 4.4 material.

Just to be clear: the above should read "Once 4.2 is released and the
4.3 merge window *closes* (i.e. v4.3-rc1 is released), linux-next is
open for 4.4 material".

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

Re: [PATCH] Memory hot added,The memory can not been added to movable zone

[Andrew Morton]

On Wed, 19 Aug 2015 04:18:26 -0400 Changsheng Liu  
wrote:

> From: Changsheng Liu 
> 
> When memory hot added, the function should_add_memory_movable
> always return 0,because the movable zone is empty,
> so the memory that hot added will add to normal zone even if
> we want to remove the memory.
> So we change the function should_add_memory_movable,if the user
> config CONFIG_MOVABLE_NODE it will return 1 when
> movable zone is empty

I cleaned this up a bit:

: Subject: mm: memory hot-add: memory can not been added to movable zone
: 
: When memory is hot added, should_add_memory_movable() always returns 0
: because the movable zone is empty, so the memory that was hot added will
: add to the normal zone even if we want to remove the memory.
: 
: So we change should_add_memory_movable(): if the user config
: CONFIG_MOVABLE_NODE it will return 1 when the movable zone is empty.

But I don't understand the "even if we want to remove the memory". 
This is hot-add, not hot-remove.  What do you mean here?

> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1198,9 +1198,13 @@ static int should_add_memory_movable(int nid, u64 
> start, u64 size)
>   pg_data_t *pgdat = NODE_DATA(nid);
>   struct zone *movable_zone = pgdat->node_zones + ZONE_MOVABLE;
>  
> - if (zone_is_empty(movable_zone))
> + if (zone_is_empty(movable_zone)) {
> + #ifdef CONFIG_MOVABLE_NODE
> + return 1;
> + #else
>   return 0;
> -
> + #endif
> + }
>   if (movable_zone->zone_start_pfn <= start_pfn)
>   return 1;

Cleaner:

--- 
a/mm/memory_hotplug.c~memory-hot-addedthe-memory-can-not-been-added-to-movable-zone-fix
+++ a/mm/memory_hotplug.c
@@ -1181,13 +1181,9 @@ static int should_add_memory_movable(int
pg_data_t *pgdat = NODE_DATA(nid);
struct zone *movable_zone = pgdat->node_zones + ZONE_MOVABLE;
 
-   if (zone_is_empty(movable_zone)) {
-   #ifdef CONFIG_MOVABLE_NODE
-   return 1;
-   #else
-   return 0;
-   #endif
-   }
+   if (zone_is_empty(movable_zone))
+   return IS_ENABLED(CONFIG_MOVABLE_NODE);
+
if (movable_zone->zone_start_pfn <= start_pfn)
return 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 v1 4/4] perf script: enable printing of branch stack

[Andi Kleen]

> > Also it would be good to resolve the addresses to symbol + offset
> 
> But then, that becomes harder to post-process or even read with long
> C++ signatures.

Ok. Maybe make it optional? 

For many usages resolved addresses will be much more useful than raw.
Normall call stacks also do that.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: android: fix typo

[Junesung Lee]

Fix typo.

Signed-off-by: Junesung Lee 
---
 drivers/staging/android/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 24d657b..0a9a7b3 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -53,7 +53,7 @@ config SW_SYNC
depends on SYNC
---help---
  A sync object driver that uses a 32bit counter to coordinate
- syncrhronization.  Useful when there is no hardware primitive backing
+ synchronization.  Useful when there is no hardware primitive backing
  the synchronization.
 
 config SW_SYNC_USER
-- 
2.1.4

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

Re: Ping Re: [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp

[Michael Ellerman]

On Wed, 2015-08-19 at 14:39 +, Joseph Myers wrote:
> I'd like to ping this patch series, not having seen any comments on it.
> 
> [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp
> https://lkml.org/lkml/2015/7/2/394
> 
> [PATCH 1/8] math-emu: Move math-emu to math-emu-old
> https://lkml.org/lkml/2015/7/2/395
> 
> [PATCH 2/8] math-emu: Import current glibc soft-fp as include/math-emu
> https://lkml.org/lkml/2015/7/2/398
> 
> [PATCH 3/8] alpha/math-emu: Move alpha from math-emu-old to math-emu
> https://lkml.org/lkml/2015/7/2/399
> 
> [PATCH 4/8] powerpc/math-emu: Move powerpc from math-emu-old to math-emu
> https://lkml.org/lkml/2015/7/2/400
> 
> [PATCH 5/8] s390/math-emu: Move s390 from math-emu-old to math-emu
> https://lkml.org/lkml/2015/7/2/401
> 
> [PATCH 6/8] sh/math-emu: Move sh from math-emu-old to math-emu
> https://lkml.org/lkml/2015/7/2/402
> 
> [PATCH 7/8] sparc/math-emu: Move sparc from math-emu-old to math-emu
> https://lkml.org/lkml/2015/7/2/404
> 
> [PATCH 8/8] math-emu: Remove math-emu-old
> https://lkml.org/lkml/2015/7/2/405
> 
> As noted in patch 0, the dependencies are as follows: patch 2 depends on 
> patch 1, patches 3-7 depend on patches 1 and 2 but are independent of each 
> other, patch 8 depends on all the other patches.

Hi Joseph,

I have done some testing on powerpc, and it seems good.

I'm reluctant to proceed with merging them though until we've heard at least
*something* from the other maintainers.

We don't want to end up with math-emu-old hanging around for ever.

cheers


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

Re: __sb_start_write() && force_trylock hack

[Dave Chinner]

On Wed, Aug 19, 2015 at 05:00:26PM +0200, Oleg Nesterov wrote:
> On 08/19, Dave Chinner wrote:
> >
> > On Tue, Aug 18, 2015 at 04:49:00PM +0200, Oleg Nesterov wrote:
> > > Jan, Dave, perhaps you can take a look...
> > >
> > > On 08/14, Oleg Nesterov wrote:
> > > >
> > > > Plus another patch which removes the "trylock"
> > > > hack in __sb_start_write().
> > >
> > > I meant the patch we already discussed (attached at the end). And yes,
> > > previously I reported it passed the tests. However, I only ran the same
> > > 'grep -il freeze tests/*/???' tests. When I tried to run all tests, I
> > > got the new reports from lockdep.
> > >
> > >   [ 2098.281171]  May be due to missing lock nesting notation
> >
> > 
> >
> > >   [ 2098.288744] 4 locks held by fsstress/50971:
> > >   [ 2098.293408]  #0:  (sb_writers#13){++}, at: [] 
> > > __sb_start_write+0x32/0x40
> > >   [ 2098.303085]  #1:  (>i_mutex_dir_key#4/1){+.+.+.}, at: 
> > > [] filename_create+0x7f/0x170
> > >   [ 2098.314038]  #2:  (sb_internal#2){++}, at: [] 
> > > __sb_start_write+0x32/0x40
> > >   [ 2098.323711]  #3:  (>s_umount_key#54){++}, at: 
> > > [] xfs_flush_inodes+0x1c/0x40 [xfs]
> > >   [ 2098.334898]
> > >  stack backtrace:
> > >   [ 2098.339762] CPU: 3 PID: 50971 Comm: fsstress Not tainted 4.2.0-rc6+ 
> > > #27
> > >   [ 2098.347143] Hardware name: Intel Corporation S2600CP/S2600CP, BIOS 
> > > RMLSDP.86I.R3.27.D685.1305151734 05/15/2013
> > >   [ 2098.358303]   e70ee864 880c05a2b9c8 
> > > 817ee692
> > >   [ 2098.366603]   826f8030 880c05a2bab8 
> > > 810f45be
> > >   [ 2098.374900]   880c05a2bb20  
> > > 
> > >   [ 2098.383197] Call Trace:
> > >   [ 2098.385930]  [] dump_stack+0x45/0x57
> > >   [ 2098.391667]  [] __lock_acquire+0x1e9e/0x2040
> > >   [ 2098.398177]  [] ? __lock_acquire+0x9ed/0x2040
> > >   [ 2098.404787]  [] ? pagevec_lookup_entries+0x22/0x30
> > >   [ 2098.411879]  [] ? 
> > > truncate_inode_pages_range+0x2b2/0x7e0
> > >   [ 2098.419551]  [] lock_acquire+0xbe/0x150
> > >   [ 2098.425566]  [] ? __sb_start_write+0x32/0x40
> > >   [ 2098.432079]  [] percpu_down_read+0x51/0xa0
> > >   [ 2098.438396]  [] ? __sb_start_write+0x32/0x40
> > >   [ 2098.444905]  [] __sb_start_write+0x32/0x40
> > >   [ 2098.451244]  [] xfs_trans_alloc+0x24/0x40 [xfs]
> > >   [ 2098.458076]  [] xfs_inactive_truncate+0x32/0x110 
> > > [xfs]
> > >   [ 2098.465580]  [] xfs_inactive+0x102/0x120 [xfs]
> > >   [ 2098.472308]  [] xfs_fs_evict_inode+0x7b/0xc0 [xfs]
> > >   [ 2098.479401]  [] evict+0xab/0x170
> > >   [ 2098.484748]  [] iput+0x1a8/0x230
> > >   [ 2098.490100]  [] sync_inodes_sb+0x14c/0x1d0
> > >   [ 2098.496439]  [] xfs_flush_inodes+0x28/0x40 [xfs]
> > >   [ 2098.503361]  [] xfs_create+0x5c3/0x6d0 [xfs]
> >
> > Another false positive.
> 
> Confused...
> 
> Dave, I removed your explanation which I can't understand anyway, let
> me remind that I know absolutely nothing about filesystems.
> 
> > But there is no deadlock here
> 
> Yes, we hold SB_FREEZE_WRITE lock, so recursive SB_FREEZE_FS is safe.
> 
> But, this means that the comment in __sb_start_write() is still correct,
> "XFS for example gets freeze protection on internal level twice" is true,
> and we can not remove this force_trylock hack.

You've hit a very rare corner case of a rare corner case. Please
forgive me if I forget such paths - stuff that just works because it
was required to be deadlock free is easy to forget because, well, it
doesn't deadlock.

Cheers,

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

[tip:irq/urgent] irqchip/crossbar: Restore set_wake functionality

[tip-bot for Grygorii Strashko]

Commit-ID:  8200fe4347870d4ad6475048bcdf3e7c106c5268
Gitweb: http://git.kernel.org/tip/8200fe4347870d4ad6475048bcdf3e7c106c5268
Author: Grygorii Strashko 
AuthorDate: Fri, 14 Aug 2015 15:20:30 +0300
Committer:  Thomas Gleixner 
CommitDate: Thu, 20 Aug 2015 00:25:26 +0200

irqchip/crossbar: Restore set_wake functionality

The TI crossbar irqchip doesn't provides any facility to configure the
wakeup sources, but the conversion to hierarchical irqdomains set the
irq_set_wake callback to irq_chip_set_wake_parent. The parent chip
(OMAP wakeupgen) has no irq_set_wake function either so the call will
fail with -ENOSYS. As a result the irq_set_wake() call in the resume
path will trigger an 'Unbalanced wake disable' warning.

Before the conversion the GIC irqchip was the top level irqchip and
correctly flagged with IRQCHIP_SKIP_SET_WAKE.

Restore the correct behaviour by removing the irq_set_type callback
from the crossbar irqchip and set the IRQCHIP_SKIP_SET_WAKE flag which
lets the irq_set_irq_wake() call from the driver succeed.

[ tglx: Massaged changelog ]

Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: Grygorii Strashko 
Cc: Sudeep Holla 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: sta...@vger.kernel.org # 4.1
Link: 
http://lkml.kernel.org/r/1439554830-19502-7-git-send-email-grygorii.stras...@ti.com
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-crossbar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index f5a72cc..c12bb93 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -68,9 +68,9 @@ static struct irq_chip crossbar_chip = {
.irq_mask   = irq_chip_mask_parent,
.irq_unmask = irq_chip_unmask_parent,
.irq_retrigger  = irq_chip_retrigger_hierarchy,
-   .irq_set_wake   = irq_chip_set_wake_parent,
.irq_set_type   = irq_chip_set_type_parent,
-   .flags  = IRQCHIP_MASK_ON_SUSPEND,
+   .flags  = IRQCHIP_MASK_ON_SUSPEND |
+ IRQCHIP_SKIP_SET_WAKE,
 #ifdef CONFIG_SMP
.irq_set_affinity   = irq_chip_set_affinity_parent,
 #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:irq/urgent] ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanism

[tip-bot for Grygorii Strashko]

Commit-ID:  63059a272398ef5dc1bd7065a036e8b6e82d1af7
Gitweb: http://git.kernel.org/tip/63059a272398ef5dc1bd7065a036e8b6e82d1af7
Author: Grygorii Strashko 
AuthorDate: Fri, 14 Aug 2015 15:20:28 +0300
Committer:  Thomas Gleixner 
CommitDate: Thu, 20 Aug 2015 00:25:25 +0200

ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanism

The conversion of the wakeupgen irqchip to hierarchical irq domains
failed to provide a mechanism to properly set the trigger type of an
interrupt.

The wakeupgen irq chip itself has no mechanism and therefor no
irq_set_type() callback. The code before the conversion relayed the
trigger configuration directly to the underlying GIC.

Restore the correct behaviour by setting the wakeupgen irq_set_type
callback to irq_chip_set_type_parent(). This propagates the
set_trigger() call to the underlying GIC irqchip.

[ tglx: Massaged changelog ]

Fixes: 7136d457f365 ('ARM: omap: convert wakeupgen to stacked domains')
Signed-off-by: Grygorii Strashko 
Acked-by: Tony Lindgren 
Cc: Sudeep Holla 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: sta...@vger.kernel.org # 4.1
Link: 
http://lkml.kernel.org/r/1439554830-19502-5-git-send-email-grygorii.stras...@ti.com
Signed-off-by: Thomas Gleixner 
---
 arch/arm/mach-omap2/omap-wakeupgen.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c 
b/arch/arm/mach-omap2/omap-wakeupgen.c
index 8e52621..e1d2e99 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -392,6 +392,7 @@ static struct irq_chip wakeupgen_chip = {
.irq_mask   = wakeupgen_mask,
.irq_unmask = wakeupgen_unmask,
.irq_retrigger  = irq_chip_retrigger_hierarchy,
+   .irq_set_type   = irq_chip_set_type_parent,
.flags  = IRQCHIP_SKIP_SET_WAKE | 
IRQCHIP_MASK_ON_SUSPEND,
 #ifdef CONFIG_SMP
.irq_set_affinity   = irq_chip_set_affinity_parent,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:irq/urgent] irqchip/crossbar: Restore the mask on suspend behaviour

[tip-bot for Grygorii Strashko]

Commit-ID:  4fd8f47e7e5b64a74b60f23c2e08ba8234d659d1
Gitweb: http://git.kernel.org/tip/4fd8f47e7e5b64a74b60f23c2e08ba8234d659d1
Author: Grygorii Strashko 
AuthorDate: Fri, 14 Aug 2015 15:20:29 +0300
Committer:  Thomas Gleixner 
CommitDate: Thu, 20 Aug 2015 00:25:25 +0200

irqchip/crossbar: Restore the mask on suspend behaviour

The ARM GIC requires that all interrupts which are not used as a
wakeup source have to be masked during suspend.

The conversion of the crossbar irqchip to hierarchical irq domains
failed to mark the crossbar irqchip with the IRQCHIP_MASK_ON_SUSPEND
flag and therefor broke the suspend requirement of the GIC.

Before the conversion the flags were visible because the GIC was the
top level irqchip. After the conversion the crossbar irqchip is the
top level irq chip whose flags are evaluated in suspend_device_irq().
As the flag is not set the masking of the non-wakeup irqs is not
invoked which breaks suspend.

Add the IRQCHIP_MASK_ON_SUSPEND flag to the crossbar irqchip, so the
GIC interrupts get masked properly.

[ tglx: Massaged changelog ]

Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: Grygorii Strashko 
Cc: Sudeep Holla 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: sta...@vger.kernel.org # 4.1
Link: 
http://lkml.kernel.org/r/1439554830-19502-6-git-send-email-grygorii.stras...@ti.com
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-crossbar.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 3ba58e7..f5a72cc 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -70,6 +70,7 @@ static struct irq_chip crossbar_chip = {
.irq_retrigger  = irq_chip_retrigger_hierarchy,
.irq_set_wake   = irq_chip_set_wake_parent,
.irq_set_type   = irq_chip_set_type_parent,
+   .flags  = IRQCHIP_MASK_ON_SUSPEND,
 #ifdef CONFIG_SMP
.irq_set_affinity   = irq_chip_set_affinity_parent,
 #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:irq/urgent] irqchip/crossbar: Restore the irq_set_type() mechanism

[tip-bot for Grygorii Strashko]

Commit-ID:  e269ec42328783e51be08c191aa935dba56141fc
Gitweb: http://git.kernel.org/tip/e269ec42328783e51be08c191aa935dba56141fc
Author: Grygorii Strashko 
AuthorDate: Fri, 14 Aug 2015 15:20:27 +0300
Committer:  Thomas Gleixner 
CommitDate: Thu, 20 Aug 2015 00:25:25 +0200

irqchip/crossbar: Restore the irq_set_type() mechanism

The conversion of the crossbar irqchip to hierarchical irq domains
failed to provide a mechanism to properly set the trigger type of an
interrupt.

The crossbar irq chip itself has no mechanism and therefor no
irq_set_type() callback. The code before the conversion relayed the
trigger configuration directly to the underlying GIC.

Restore the correct behaviour by setting the crossbar irq_set_type
callback to irq_chip_set_type_parent(). This propagates the
set_trigger() call to the underlying GIC irqchip.

[ tglx: Massaged changelog ]

Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar...')
Signed-off-by: Grygorii Strashko 
Cc: Sudeep Holla 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: sta...@vger.kernel.org # 4.1
Link: 
http://lkml.kernel.org/r/1439554830-19502-4-git-send-email-grygorii.stras...@ti.com
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-crossbar.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 692fe2b..3ba58e7 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -69,6 +69,7 @@ static struct irq_chip crossbar_chip = {
.irq_unmask = irq_chip_unmask_parent,
.irq_retrigger  = irq_chip_retrigger_hierarchy,
.irq_set_wake   = irq_chip_set_wake_parent,
+   .irq_set_type   = irq_chip_set_type_parent,
 #ifdef CONFIG_SMP
.irq_set_affinity   = irq_chip_set_affinity_parent,
 #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:irq/urgent] genirq: Don' t return ENOSYS in irq_chip_retrigger_hierarchy

[tip-bot for Grygorii Strashko]

Commit-ID:  6d4affea7d5aa5ca5ff4c3e5fbf3ee16801cc527
Gitweb: http://git.kernel.org/tip/6d4affea7d5aa5ca5ff4c3e5fbf3ee16801cc527
Author: Grygorii Strashko 
AuthorDate: Fri, 14 Aug 2015 15:20:25 +0300
Committer:  Thomas Gleixner 
CommitDate: Thu, 20 Aug 2015 00:25:25 +0200

genirq: Don't return ENOSYS in irq_chip_retrigger_hierarchy

irq_chip_retrigger_hierarchy() returns -ENOSYS if it was not able to
find at least one .irq_retrigger() callback implemented in the IRQ
domain hierarchy.

That's wrong, because check_irq_resend() expects a 0 return value from
the callback in case that the hardware assisted resend was not
possible. If the return value is non zero the core code assumes
hardware resend success and the software resend is not invoked.

This results in lost interrupts on platforms where none of the parent
irq chips in the hierarchy implements the retrigger callback.

This is observable on TI OMAP, where the hierarchy is:

 ARM GIC <- OMAP wakeupgen <- TI Crossbar

Return 0 instead so the software resend mechanism gets invoked.

[ tglx: Massaged changelog ]

Fixes: 85f08c17de26 ('genirq: Introduce helper functions...')
Signed-off-by: Grygorii Strashko 
Reviewed-by: Marc Zyngier 
Reviewed-by: Jiang Liu 
Cc: Sudeep Holla 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: sta...@vger.kernel.org # 4.1
Link: 
http://lkml.kernel.org/r/1439554830-19502-2-git-send-email-grygorii.stras...@ti.com
Signed-off-by: Thomas Gleixner 
---
 kernel/irq/chip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 27f4332..6de638b 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -997,7 +997,7 @@ int irq_chip_retrigger_hierarchy(struct irq_data *data)
if (data->chip && data->chip->irq_retrigger)
return data->chip->irq_retrigger(data);
 
-   return -ENOSYS;
+   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/

[tip:irq/urgent] genirq: Introduce irq_chip_set_type_parent() helper

[tip-bot for Grygorii Strashko]

Commit-ID:  b7560de198222994374c1340a389f12d5efb244a
Gitweb: http://git.kernel.org/tip/b7560de198222994374c1340a389f12d5efb244a
Author: Grygorii Strashko 
AuthorDate: Fri, 14 Aug 2015 15:20:26 +0300
Committer:  Thomas Gleixner 
CommitDate: Thu, 20 Aug 2015 00:25:25 +0200

genirq: Introduce irq_chip_set_type_parent() helper

This helper is required for irq chips which do not implement a
irq_set_type callback and need to call down the irq domain hierarchy
for the actual trigger type change.

This helper is required to fix further wreckage caused by the
conversion of TI OMAP to hierarchical irq domains and therefor tagged
for stable.

[ tglx: Massaged changelog ]

Signed-off-by: Grygorii Strashko 
Cc: Sudeep Holla 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: 
Cc: sta...@vger.kernel.org # 4.1
Link: 
http://lkml.kernel.org/r/1439554830-19502-3-git-send-email-grygorii.stras...@ti.com
Signed-off-by: Thomas Gleixner 
---
 include/linux/irq.h |  1 +
 kernel/irq/chip.c   | 17 +
 2 files changed, 18 insertions(+)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index 92188b0..51744bc 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -484,6 +484,7 @@ extern int irq_chip_set_affinity_parent(struct irq_data 
*data,
 extern int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on);
 extern int irq_chip_set_vcpu_affinity_parent(struct irq_data *data,
 void *vcpu_info);
+extern int irq_chip_set_type_parent(struct irq_data *data, unsigned int type);
 #endif
 
 /* Handling of unhandled and spurious interrupts: */
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6de638b..ae21682 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -985,6 +985,23 @@ int irq_chip_set_affinity_parent(struct irq_data *data,
 }
 
 /**
+ * irq_chip_set_type_parent - Set IRQ type on the parent interrupt
+ * @data:  Pointer to interrupt specific data
+ * @type:  IRQ_TYPE_{LEVEL,EDGE}_* value - see include/linux/irq.h
+ *
+ * Conditional, as the underlying parent chip might not implement it.
+ */
+int irq_chip_set_type_parent(struct irq_data *data, unsigned int type)
+{
+   data = data->parent_data;
+
+   if (data->chip->irq_set_type)
+   return data->chip->irq_set_type(data, type);
+
+   return -ENOSYS;
+}
+
+/**
  * irq_chip_retrigger_hierarchy - Retrigger an interrupt in hardware
  * @data:  Pointer to interrupt specific data
  *
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Next round: revised futex(2) man page for review

[Thomas Gleixner]

On Sat, 8 Aug 2015, Michael Kerrisk (man-pages) wrote:
> >>FUTEX_CMP_REQUEUE (since Linux 2.6.7)
> >>   This  operation  first  checks  whether the location uaddr
> >>   still contains the value  val3.   If  not,  the  operation
> >>   fails  with  the  error  EAGAIN.  Otherwise, the operation
> >>   wakes up a maximum of val waiters that are waiting on  the
> >>   futex  at uaddr.  If there are more than val waiters, then
> >>   the remaining waiters are removed from the wait  queue  of
> >>   the  source  futex at uaddr and added to the wait queue of
> >>   the target futex at uaddr2.  The val2  argument  specifies
> >>   an  upper limit on the number of waiters that are requeued
> >>   to the futex at uaddr2.
> >>
> >> .\" FIXME(Torvald) Is the following correct?  Or is just the decision
> >> .\" which threads to wake or requeue part of the atomic operation?
> >>
> >>   The load from uaddr is  an  atomic  memory  access  (i.e.,
> >>   using atomic machine instructions of the respective archi‐
> >>   tecture).  This load, the comparison with  val3,  and  the
> >>   requeueing  of  any  waiters  are performed atomically and
> >>   totally ordered with respect to other  operations  on  the
> >>   same futex word.
> > 
> > It's atomic as the other atomic operations on the futex word. It's
> > always performed with the proper lock(s) held in the kernel. That
> > means any concurrent operation will serialize on that lock(s). User
> > space has to make sure, that depending on the observed value no
> > concurrent operations happen, but that's something the kernel cannot
> > control.
> 
> ???
> Sorry, I'm not clear here. Is the current text correct then? Or is some
> change needed.

I think we need some change here because the meaning of atomic is
unclear. The basic rules of futexes are:

 - All modifying operations on the futex value have to be done with
   atomic instructions, usually cmpxchg. That applies to both kernel
   and user space.

   That's the atomicity at the futex value level.

 - In the kernel we have to create/modify/destroy state in order to
   provide the blocking/requeueing etc.

   This state needs protection as well. So all operations related to
   the kernel internal state are serialized on the hash bucket
   locks. The hash buckets are a scalability mechanism to avoid
   contention on a single lock protecting all kernel internal
   state. For simplicity reasons you can just think of a global lock
   protecting all kernel internal state.

   If the kernel creates/modifies state then it can be necessary to
   either reread the futex value or modify it. That happens under the
   locks as well.

   So in the case of requeue, we take the proper locks and perform the
   comparison with val3 and the requeueing with the locks held.
   
   So that lock protection makes these operations 'atomic'. The
   correct expression is 'serialized'.
 
> >> .\" FIXME We need some explanation in the following paragraph of *why*
> >> .\"   it is important to note that "the kernel will update the
> >> .\"   futex word's value prior
> >>It is important to note to returning to user space" . Can someone
> >>explain?   that  the  kernel  will  update the futex word's value
> >>prior to returning to user space.  Unlike the other futex  opera‐
> >>tions  described  above, the PI futex operations are designed for
> >>the implementation of very specific IPC mechanisms.
> > 
> > If there are multiple waiters on a pi futex then a wake pi operation
> > will wake the first waiter and hand over the lock to this waiter. This
> > includes handing over the rtmutex which represents the futex in the
> > kernel. The strict requirement is that the futex owner and the rtmutex
> > owner must be the same, except for the update period which is
> > serialized by the futex internal locking. That means the kernel must
> > update the user space value prior to returning to user space.

And as noted above: It must update while holding the proper locks.

> >> .\" FIXME XXX In discussing errors for FUTEX_CMP_REQUEUE_PI, Darren Hart
> >> .\"   made the observation that "EINVAL is returned if the non-pi 
> >> .\"   to pi or op pairing semantics are violated."
> >> .\"   Probably there needs to be a general statement about this
> >> .\"   requirement, probably located at about this point in the page.
> >> .\"   Darren (or someone else), care to take a shot at this?
> > 
> > Well, that's hard to describe because the kernel only has a limited
> > way of detecting such mismatches. It only can detect it when there are
> > non PI waiters on a futex and a PI function is called or vice versa.
> 
> Hmmm. Okay, I filed your comments away for reference, but
> hopefully someone can help with 

Re: cxl: Add alternate MMIO error handling

[Michael Ellerman]

On Thu, 2015-23-07 at 06:43:56 UTC, Ian Munsie wrote:
> From: Ian Munsie 
> 
> userspace programs using cxl currently have to use two strategies for
> dealing with MMIO errors simultaneously. They have to check every read
> for a return of all Fs in case the adapter has gone away and the kernel
> has not yet noticed, and they have to deal with SIGBUS in case the
> kernel has already noticed, invalidated the mapping and marked the
> context as failed.
> 
> In order to simplify things, this patch adds an alternative approach
> where the kernel will return a page filled with Fs instead of delivering
> a SIGBUS. This allows userspace to only need to deal with one of these
> two error paths, and is intended for use in libraries that use cxl
> transparently and may not be able to safely install a signal handler.
> 
> This approach will only work if certain constraints are met. Namely, if
> the application is both reading and writing to an address in the problem
> state area it cannot assume that a non-FF read is OK, as it may just be
> reading out a value it has previously written. Further - since only one
> page is used per context a write to a given offset would be visible when
> reading the same offset from a different page in the mapping (this only
> applies within a single context, not between contexts).
> 
> An application could deal with this by e.g. making sure it also reads
> from a read-only offset after any reads to a read/write offset.
> 
> Due to these constraints, this functionality must be explicitly
> requested by userspace when starting the context by passing in the
> CXL_START_WORK_ERR_FF flag.
> 
> Signed-off-by: Ian Munsie 
> Acked-by: Michael Neuling 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/d9232a3da8683cd9c985

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

Re: [06/31] arch/powerpc/pseries: use kmemdup rather than duplicating its implementation

[Michael Ellerman]

On Fri, 2015-07-08 at 07:59:12 UTC, Andrzej Hajda wrote:
> The patch was generated using fixed coccinelle semantic patch
> scripts/coccinelle/api/memdup.cocci [1].
> 
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320
> 
> Signed-off-by: Andrzej Hajda 
> Reviewed-by: Nathan Fontenot 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/2e16acc5ee3626bcd32e

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

Re: [RESEND] powerpc/numa: initialize distance lookup table from drconf path

[Michael Ellerman]

On Thu, 2015-02-07 at 05:39:01 UTC, Nikunj A Dadhania wrote:
> In some situations, a NUMA guest that supports
> ibm,dynamic-memory-reconfiguration node will end up having flat NUMA
> distances between nodes. This is because of two problems in the
> current code.
> 
> 1) Different representations of associativity lists.
> 
>There is an assumption about the associativity list in
>initialize_distance_lookup_table(). Associativity list has two forms:
> 
>a) [cpu,memory]@x/ibm,associativity has following
>   format:
> 
> 
>b) ibm,dynamic-reconfiguration-memory/ibm,associativity-lookup-arrays
> 
>  
>M = the number of associativity lists
>N = the number of entries per associativity list
> 
>Fix initialize_distance_lookup_table() so that it does not assume
>"case a". And update the caller to skip the length field before
>sending the associativity list.
> 
> 2) Distance table not getting updated from drconf path.
> 
>Node distance table will not get initialized in certain cases as
>ibm,dynamic-reconfiguration-memory path does not initialize the
>lookup table.
> 
>Call initialize_distance_lookup_table() from drconf path with
>appropriate associativity list.
> 
> Reported-by: Bharata B Rao 
> Signed-off-by: Nikunj A Dadhania 
> Acked-by: Anton Blanchard 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/1d805440a364b4a68562

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

Re: [05/31] arch/powerpc/nvram: use kmemdup rather than duplicating its implementation

[Michael Ellerman]

On Fri, 2015-07-08 at 07:59:11 UTC, Andrzej Hajda wrote:
> The patch was generated using fixed coccinelle semantic patch
> scripts/coccinelle/api/memdup.cocci [1].
> 
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320
> 
> Signed-off-by: Andrzej Hajda 
> Reviewed-by: Nathan Fontenot 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/fc9e9cbf4e48f28525ed

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

Re: [PATCH] bluetooth:Make the function sco_conn_del have a return type of void

[Marcel Holtmann]

Hi Nicholas,

> This makes the function sco_conn_del have a return type of void now
> due to this function always running successfully and thus never
> needing to signal its caller when a non recoverable internal failure
> occurs by returning a error code to its respective caller.
> 
> Signed-off-by: Nicholas Krause 
> ---
> net/bluetooth/sco.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] nd_blk: add support for "read flush" DSM flag

[Dan Williams]

On Wed, Aug 19, 2015 at 3:48 PM, Ross Zwisler
 wrote:
> Add support for the "read flush" _DSM flag, as outlined in the DSM spec:
>
> http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
>
> This flag tells the ND BLK driver that it needs to flush the cache lines
> associated with the aperture after the aperture is moved but before any
> new data is read.  This ensures that any stale cache lines from the
> previous contents of the aperture will be discarded from the processor
> cache, and the new data will be read properly from the DIMM.  We know
> that the cache lines are clean and will be discarded without any
> writeback because either a) the previous aperture operation was a read,
> and we never modified the contents of the aperture, or b) the previous
> aperture operation was a write and we must have written back the dirtied
> contents of the aperture to the DIMM before the I/O was completed.
>
> By supporting the "read flush" flag we can also change the ND BLK
> aperture mapping from write-combining to write-back via memremap().
>
> In order to add support for the "read flush" flag I needed to add a
> generic routine to invalidate cache lines, mmio_flush_range().  This is
> protected by the ARCH_HAS_MMIO_FLUSH Kconfig variable, and is currently
> only supported on x86.
>
> Signed-off-by: Ross Zwisler 
> Cc: Dan Williams 
[..]
> diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
> index 7c2638f..56fff01 100644
> --- a/drivers/acpi/nfit.c
> +++ b/drivers/acpi/nfit.c
[..]
>  static int acpi_nfit_blk_single_io(struct nfit_blk *nfit_blk,
> @@ -1078,11 +1078,16 @@ static int acpi_nfit_blk_single_io(struct nfit_blk 
> *nfit_blk,
> }
>
> if (rw)
> -   memcpy_to_pmem(mmio->aperture + offset,
> +   memcpy_to_pmem(mmio->addr.aperture + offset,
> iobuf + copied, c);
> -   else
> +   else {
> +   if (nfit_blk->dimm_flags & ND_BLK_READ_FLUSH)
> +   mmio_flush_range((void __force *)
> +   mmio->addr.aperture + offset, c);
> +
> memcpy_from_pmem(iobuf + copied,
> -   mmio->aperture + offset, c);
> +   mmio->addr.aperture + offset, c);
> +   }

Why is the flush inside the "while (len)" loop?  I think it should be
done immediately after the call to write_blk_ctl() since that is the
point at which the aperture becomes invalidated, and not prior to each
read within a given aperture position.  Taking it a bit further, we
may be writing the same address into the control register as was there
previously so we wouldn't need to flush in that case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/