[PATCH v3 0/5] iio: common: ssp_sensors: Add sensorhub driver

[Karol Wrona]

This patchset adds support for sensorhub. It is an external mcu which
manages and collects data from several sensors i.e. on Galaxy Gear 2 watch.

It contains:
- spi driver for sensorhub device
- DT binding for the device
- IIO common utils for ssp sensors (iio kfifo setup helpers, pre/post callbacks)
- IIO accelerometer driver
- IIO gyroscope driver

For now the driver supports "traditional" sensors but new ones types are
intended to be used.

>From v1:
  - Adopted to new stm32fwu v5
  - Fixed sensors' data process callbacks
  - Fixed comments style

>From v2:
  - Fixes after Hartmut Knaack review
  - Sensorhub driver was moved from misc to iio after the discussion with Arnd
and Jonathan
  - Firmware upgrade is not supported in this patchset. I hope it will be
applied when it will find its own place in the tree.



Karol Wrona (5):
  iio: common: ssp_sensors: Add sensorhub driver
  iio: sensorhub: Add sensorhub bindings
  iio: common: ssp_sensors: Add sensorhub iio commons
  iio: common: ssp_sensors: Add sensorhub accelerometer sensor
  iio: common: ssp_sensors: Add sensorhub gyroscope sensor

 .../devicetree/bindings/iio/sensorhub.txt  |   46 ++
 drivers/iio/accel/Makefile |1 +
 drivers/iio/accel/ssp_accel_sensor.c   |  203 ++
 drivers/iio/common/Kconfig |1 +
 drivers/iio/common/Makefile|1 +
 drivers/iio/common/ssp_sensors/Kconfig |   24 +
 drivers/iio/common/ssp_sensors/Makefile|6 +
 drivers/iio/common/ssp_sensors/ssp.h   |  254 +++
 drivers/iio/common/ssp_sensors/ssp_dev.c   |  693 
 drivers/iio/common/ssp_sensors/ssp_iio.c   |   82 +++
 drivers/iio/common/ssp_sensors/ssp_iio_sensor.h|   56 ++
 drivers/iio/common/ssp_sensors/ssp_spi.c   |  644 ++
 drivers/iio/gyro/Makefile  |2 +
 drivers/iio/gyro/ssp_gyro_sensor.c |  202 ++
 include/linux/iio/common/ssp_sensors.h |   80 +++
 15 files changed, 2295 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/sensorhub.txt
 create mode 100644 drivers/iio/accel/ssp_accel_sensor.c
 create mode 100644 drivers/iio/common/ssp_sensors/Kconfig
 create mode 100644 drivers/iio/common/ssp_sensors/Makefile
 create mode 100644 drivers/iio/common/ssp_sensors/ssp.h
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_dev.c
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio.c
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio_sensor.h
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_spi.c
 create mode 100644 drivers/iio/gyro/ssp_gyro_sensor.c
 create mode 100644 include/linux/iio/common/ssp_sensors.h

-- 
1.7.9.5

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

[PATCH v3 4/5] iio: common: ssp_sensors: Add sensorhub accelerometer sensor

[Karol Wrona]

This patch adds accelerometer iio driver which uses sensorhub as data
provider.

Change-Id: I4686741b7401ec5cbf4b5d0f2a5cc146fbe24d53
Signed-off-by: Karol Wrona 
Acked-by: Kyungmin Park 
---
 drivers/iio/accel/Makefile   |1 +
 drivers/iio/accel/ssp_accel_sensor.c |  203 ++
 2 files changed, 204 insertions(+)
 create mode 100644 drivers/iio/accel/ssp_accel_sensor.c

diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index a593996..df6a0b2 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
 obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
 obj-$(CONFIG_KXSD9)+= kxsd9.o
 obj-$(CONFIG_MMA8452)  += mma8452.o
+obj-$(CONFIG_IIO_SSP_SENSOR) += ssp_accel_sensor.o
 
 obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
 st_accel-y := st_accel_core.o
diff --git a/drivers/iio/accel/ssp_accel_sensor.c 
b/drivers/iio/accel/ssp_accel_sensor.c
new file mode 100644
index 000..0a47c29
--- /dev/null
+++ b/drivers/iio/accel/ssp_accel_sensor.c
@@ -0,0 +1,203 @@
+/*
+ *  Copyright (C) 2014, Samsung Electronics Co. Ltd. All Rights Reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../common/ssp_sensors/ssp_iio_sensor.h"
+
+#define SSP_CHANNEL_COUNT 3
+
+#define SSP_ACCEL_NAME "ssp-accelerometer"
+static const char ssp_accel_device_name[] = SSP_ACCEL_NAME;
+
+enum ssp_accel_3d_channel {
+   SSP_CHANNEL_SCAN_INDEX_X,
+   SSP_CHANNEL_SCAN_INDEX_Y,
+   SSP_CHANNEL_SCAN_INDEX_Z,
+   SSP_CHANNEL_SCAN_INDEX_TIME,
+   SSP_ACCEL_3D_CHANNEL_MAX,
+};
+
+static int ssp_accel_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,  int *val,
+ int *val2, long mask)
+{
+   u32 t;
+   struct ssp_data *data = dev_get_drvdata(indio_dev->dev.parent->parent);
+
+   switch (mask) {
+   case IIO_CHAN_INFO_SAMP_FREQ:
+   t = ssp_get_sensor_delay(data, SSP_ACCELEROMETER_SENSOR);
+   ssp_convert_to_freq(t, val, val2);
+   return IIO_VAL_INT_PLUS_MICRO;
+   default:
+   break;
+   }
+
+   return -EINVAL;
+}
+
+static int ssp_accel_write_raw(struct iio_dev *indio_dev,
+  struct iio_chan_spec const *chan, int val,
+  int val2, long mask)
+{
+   int ret;
+   struct ssp_data *data = dev_get_drvdata(indio_dev->dev.parent->parent);
+
+   switch (mask) {
+   case IIO_CHAN_INFO_SAMP_FREQ:
+   ret = ssp_convert_to_time(val, val2);
+   ret = ssp_change_delay(data, SSP_ACCELEROMETER_SENSOR, ret);
+   if (ret < 0)
+   dev_err(_dev->dev, "accel sensor enable fail\n");
+
+   return ret;
+   default:
+   break;
+   }
+
+   return -EINVAL;
+}
+
+static struct iio_info ssp_accel_iio_info = {
+   .read_raw = _accel_read_raw,
+   .write_raw = _accel_write_raw,
+};
+
+static const struct iio_chan_spec ssp_acc_channels[] = {
+   SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_X, SSP_CHANNEL_SCAN_INDEX_X),
+   SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_Y, SSP_CHANNEL_SCAN_INDEX_Y),
+   SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_Z, SSP_CHANNEL_SCAN_INDEX_Z),
+   IIO_CHAN_SOFT_TIMESTAMP(SSP_CHANNEL_SCAN_INDEX_TIME),
+};
+
+static int ssp_process_accel_data(struct iio_dev *indio_dev, void *buf,
+ int64_t timestamp)
+{
+   __le32 time;
+   const int len = SSP_ACCELEROMETER_SIZE;
+   int64_t calculated_time;
+   char *data;
+   int ret;
+
+   if (indio_dev->scan_bytes == 0)
+   return 0;
+
+   data = kmalloc(indio_dev->scan_bytes, GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
+
+   memcpy(data, buf, len);
+
+   if (indio_dev->scan_timestamp) {
+   memcpy(, &((char *)buf)[len], SSP_TIME_SIZE);
+   calculated_time =
+   timestamp + (int64_t)le32_to_cpu(time) * 100;
+   }
+
+   ret = iio_push_to_buffers_with_timestamp(indio_dev, data,
+calculated_time);
+
+   kfree(data);
+
+   return ret;
+}
+
+static const struct iio_buffer_setup_ops ssp_accel_buffer_ops = {
+   .postenable = _common_buffer_postenable,
+   .predisable = 

[PATCH v3 2/5] iio: sensorhub: Add sensorhub bindings

[Karol Wrona]

Add sensorhub bindings for sensorhub on Galaxy Gear 2.

Change-Id: I4ee25aef33c21a4662de230841de9a8684f2c26b
Signed-off-by: Karol Wrona 
Acked-by: Kyungmin Park 
---
 .../devicetree/bindings/iio/sensorhub.txt  |   46 
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/sensorhub.txt

diff --git a/Documentation/devicetree/bindings/iio/sensorhub.txt 
b/Documentation/devicetree/bindings/iio/sensorhub.txt
new file mode 100644
index 000..2aca0c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/sensorhub.txt
@@ -0,0 +1,46 @@
+Samsung Sensorhub driver
+
+Sensorhub is a MCU which manages several sensors and also plays the role
+of a virtual sensor device.
+
+Required properties:
+- compatible: "samsung,sensorhub-rinato" or "samsung,sensorhub-thermostat"
+- spi-max-frequency: max SPI clock frequency
+- interrupt-parent: interrupt parent
+- interrupts: communication interrupt
+- ap-mcu-gpio: [out] ap to sensorhub line - used during communication
+- mcu-ap-gpio: [in] sensorhub to ap - used during communication
+- mcu-reset: [out] sensorhub reset
+
+Optional properties:
+- sensor's nodes:
+  compatible = "samsung,mpu6500-accel"
+  compatible = "samsung,mpu6500-gyro"
+  compatible = "samsung,adpd142"
+
+Sensor compatibles are used to match proper sensor driver to real sensor on
+the board. The firmware does not give such information, so it helps to specify
+some sensors properties. Sensors have "samsung" prefixes because frequently
+they will not have much in common with sensors used without sensorhub because
+it can do some data processing.
+
+Example:
+
+   shub_spi: shub {
+   compatible = "samsung,sensorhub-rinato";
+   spi-max-frequency = <500>;
+   interrupt-parent = <>;
+   interrupts = <2 0>;
+   ap-mcu-gpio = < 0 0>;
+   mcu-ap-gpio = < 4 0>;
+   mcu-reset = < 5 0>;
+   sensor@0 {
+   compatible = "samsung,mpu6500-accel";
+   };
+   sensor@1 {
+   compatible = "samsung,mpu6500-gyro";
+   };
+   sensor@2 {
+   compatible = "samsung,adpd142";
+   };
+   };
-- 
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 linux-next] Documentation: Build mic/mpssd only for x86_64

[Dan Streetman]

On Fri, Dec 5, 2014 at 1:18 PM, Ashutosh Dixit  wrote:
> On Thu, Dec 04 2014 at 07:27:06 PM, Dan Streetman  wrote:
>> On Thu, Dec 4, 2014 at 4:27 PM, Ashutosh Dixit  
>> wrote:
>>> mic/mpssd along with MIC drivers are currently only usable on
>>> x86_64. So build mic/mpssd only for x86_64 to avoid build breaks on
>>> big-endian systems.
>>
>> Only building for x86_64 is fine, but in that case what's the point of
>> leaving the htole16() et. al. functions in mpssd.c?  Shouldn't they be
>> removed?
>
> I am hoping that once glibc is fixed we can remove this limitation on
> building only for x86_64, so I'd rather htole16() et. al. stayed.

FYI, the bug I opened with glibc:
https://sourceware.org/bugzilla/show_bug.cgi?id=17679

was rejected because Andreas states "C does not allow function calls
in file scope."  The suggestion was made to try to fix gcc, but
honestly I don't have the time (or energy) to push for a gcc change
just for this. :-)

I do think it's too bad that glibc hto* functions don't work in file
scope (i.e. with static/global var initialization) for constant values
(using them with variables is different, which is why
__bswap_constant_* works in file scope but __bswap_* doesn't), since
it's simply a 2-step process that's entirely doable by the
preprocessor and/or compiler; just check if target endianness matches
desired endianness, and if not the compiler does a simple byte swap of
the constant value.

Anyway, I doubt glibc and/or gcc will be updated anytime soon to allow this.

>  As I
> said earlier, I'm fine with your patch too, but restricting the build
> for x86_64 seems to be the smallest patch which provides an acceptable
> solution.

Fine with me too.  It'll get big-endian building again.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller

[Graham Moore]

This patchset provides a driver for the Cadence Quad SPI Flash Controller.
This controller is used on SOCFPGA systems.

The driver was tested on Altera's Cyclone5 and Arria5 dev kits, with
Micron n25q00 and n25q512 flash parts.

Comments from Ezequiel Garcia were incorporated.

Graham Moore (2):
  mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
  mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

 .../devicetree/bindings/mtd/cadence_quadspi.txt|   50 +
 drivers/mtd/spi-nor/Kconfig|6 +
 drivers/mtd/spi-nor/Makefile   |1 +
 drivers/mtd/spi-nor/cadence-quadspi.c  | 1281 
 4 files changed, 1338 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
 create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c

-- 
1.7.9.5

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

[PATCH 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.

[Graham Moore]

Signed-off-by: Graham Moore 
---
 .../devicetree/bindings/mtd/cadence_quadspi.txt|   50 
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/cadence_quadspi.txt

diff --git a/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt 
b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
new file mode 100644
index 000..3a8ea1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
@@ -0,0 +1,50 @@
+* Cadence Quad SPI controller
+
+Required properties:
+- compatible : Should be "cdns,qspi-nor".
+- reg : Contains two entries, each of which is a tuple consisting of a
+   physical address and length.  The first entry is the address and
+   length of the controller register set.  The second entry is the
+   address and length of the QSPI Controller data area.
+- interrupts : Unit interrupt specifier for the controller interrupt.
+- clocks : phandle to the Quad SPI clock.
+- ext-decoder : Value of 0 means no external chipselect decoder is
+   connected, 1 means there is an external chipselect decoder connected.
+- fifo-depth : Size of the data FIFO in words.
+- bus-num : Number of the SPI bus to which the controller is connected.
+
+Optional subnodes:
+Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
+custom properties:
+- cdns,page-size : Size, in bytes, of the device's write page
+- cdns,block-size : Size of the device's erase block
+- cdns,read-delay : Selay for read capture logic, in clock cycles
+- cdns,tshsl-ns : Delay in master reference clocks for the length that the 
master mode chip select outputs are de-asserted between transactions.
+- cdns,tsd2d-ns : Delay in master reference clocks between one chip select 
being de-activated and the activation of another.
+- cdns,tchsh-ns : Delay in master reference clocks between last bit of current 
transaction and deasserting the device chip select (qspi_n_ss_out).
+- cdns,tslch-ns : Delay in master reference clocks between setting 
qspi_n_ss_out low and first bit transfer.
+
+Example:
+
+   qspi: spi@ff705000 {
+   compatible = "cdns,qspi-nor";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0xff705000 0x1000>,
+   <0xffa0 0x1000>;
+   interrupts = <0 151 4>;
+   clocks = <_clk>;
+   ext-decoder = <0>;
+   fifo-depth = <128>;
+
+   flash0: n25q00@0 {
+   ...
+   cdns,page-size = <256>;
+   cdns,block-size = <16>;
+   cdns,read-delay = <4>;
+   cdns,tshsl-ns = <50>;
+   cdns,tsd2d-ns = <50>;
+   cdns,tchsh-ns = <4>;
+   cdns,tslch-ns = <4>;
+   }
+   }
-- 
1.7.9.5

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

[PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

[Graham Moore]

Signed-off-by: Graham Moore 
---
 drivers/mtd/spi-nor/Kconfig   |6 +
 drivers/mtd/spi-nor/Makefile  |1 +
 drivers/mtd/spi-nor/cadence-quadspi.c | 1281 +
 3 files changed, 1288 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 64a4f0e..9485481 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -28,4 +28,10 @@ config SPI_FSL_QUADSPI
  This enables support for the Quad SPI controller in master mode.
  We only connect the NOR to this controller now.
 
+config SPI_CADENCE_QUADSPI
+   tristate "Cadence Quad SPI controller"
+   depends on ARCH_SOCFPGA
+   help
+ This enables support for the Cadence Quad SPI controller and NOR 
flash.
+
 endif # MTD_SPI_NOR
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 6a7ce14..372628c 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_MTD_SPI_NOR)  += spi-nor.o
+obj-$(CONFIG_SPI_CADENCE_QUADSPI)  += cadence-quadspi.o
 obj-$(CONFIG_SPI_FSL_QUADSPI)  += fsl-quadspi.o
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
new file mode 100644
index 000..60e8660
--- /dev/null
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -0,0 +1,1281 @@
+/*
+ * Driver for Cadence QSPI Controller
+ *
+ * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CQSPI_NAME "cadence-qspi"
+#define CQSPI_MAX_CHIPSELECT   16
+
+struct cqspi_flash_pdata {
+   struct mtd_info mtd;
+   struct spi_nor nor;
+   u32 clk_rate;
+   unsigned int page_size;
+   unsigned int block_size;
+   unsigned int read_delay;
+   unsigned int tshsl_ns;
+   unsigned int tsd2d_ns;
+   unsigned int tchsh_ns;
+   unsigned int tslch_ns;
+};
+
+struct cqspi_st {
+   struct platform_device *pdev;
+
+   struct clk *clk;
+   unsigned int sclk;
+
+   void __iomem *iobase;
+   void __iomem *ahb_base;
+   struct completion transfer_complete;
+   unsigned int irq_mask;
+   int current_cs;
+   unsigned int ahb_phy_addr;
+   unsigned int master_ref_clk_hz;
+   unsigned int ext_decoder;
+   unsigned int fifo_depth;
+   struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
+};
+
+/* Operation timeout value */
+#define CQSPI_TIMEOUT_MS   500
+#define CQSPI_READ_TIMEOUT_MS  10
+#define CQSPI_POLL_IDLE_RETRY  3
+
+#define CQSPI_FIFO_WIDTH   4
+
+#define CQSPI_REG_SRAM_THRESHOLD_BYTES 50
+
+/* Instruction type */
+#define CQSPI_INST_TYPE_SINGLE 0
+#define CQSPI_INST_TYPE_DUAL   1
+#define CQSPI_INST_TYPE_QUAD   2
+
+#define CQSPI_DUMMY_CLKS_PER_BYTE  8
+#define CQSPI_DUMMY_BYTES_MAX  4
+
+#define CQSPI_STIG_DATA_LEN_MAX8
+
+#define CQSPI_INDIRECTTRIGGER_ADDR_MASK0xF
+
+/* Register map */
+#define CQSPI_REG_CONFIG   0x00
+#define CQSPI_REG_CONFIG_ENABLE_MASK   BIT(0)
+#define CQSPI_REG_CONFIG_DECODE_MASK   BIT(9)
+#define CQSPI_REG_CONFIG_CHIPSELECT_LSB10
+#define CQSPI_REG_CONFIG_DMA_MASK  BIT(15)
+#define CQSPI_REG_CONFIG_BAUD_LSB  19
+#define CQSPI_REG_CONFIG_IDLE_LSB  31
+#define CQSPI_REG_CONFIG_CHIPSELECT_MASK   0xF
+#define CQSPI_REG_CONFIG_BAUD_MASK 0xF
+
+#define CQSPI_REG_RD_INSTR 0x04
+#define CQSPI_REG_RD_INSTR_OPCODE_LSB  0
+#define CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB  8
+#define CQSPI_REG_RD_INSTR_TYPE_ADDR_LSB   12
+#define CQSPI_REG_RD_INSTR_TYPE_DATA_LSB   16
+#define CQSPI_REG_RD_INSTR_MODE_EN_LSB 20
+#define CQSPI_REG_RD_INSTR_DUMMY_LSB   24
+#define CQSPI_REG_RD_INSTR_TYPE_INSTR_MASK 0x3
+#define CQSPI_REG_RD_INSTR_TYPE_ADDR_MASK  0x3
+#define 

Re: using DMA-API on ARM

[Arend van Spriel]

On 12/05/14 19:53, Catalin Marinas wrote:

On Fri, Dec 05, 2014 at 06:39:45PM +, Catalin Marinas wrote:

On Fri, Dec 05, 2014 at 09:22:22AM +, Arend van Spriel wrote:

For our brcm80211 development we are working on getting brcmfmac driver
up and running on a Broadcom ARM-based platform. The wireless device is
a PCIe device, which is hooked up to the system behind a PCIe host
bridge, and we transfer information between host and device using a
descriptor ring buffer allocated using dma_alloc_coherent(). We mostly
tested on x86 and seen no issue. However, on this ARM platform
(single-core A9) we detect occasionally that the descriptor content is
invalid. When this occurs we do a dma_sync_single_for_cpu() and this is
retried a number of times if the problem persists. Actually, found out
that someone made a mistake by using virt_to_dma(va) to get the
dma_handle parameter. So probably we only provided a delay in the retry
loop. After fixing that a single call to dma_sync_single_for_cpu() is
sufficient. The DMA-API-HOWTO clearly states that:


Does your system have an L2 cache? What's the SoC topology, can PCIe see
such L2 cache (or snoop the L1 caches)?


BTW, if you really have a PL310-like L2 cache, have a look at some
patches (I've seen similar symptoms) and make sure your configuration is
correct:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6395/1

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6529/1

The first one is vexpress specific. The second one was eventually
discarded by Russell (I don't remember the reason, I guess it's because
SoC code is supposed to set the right bits in there anyway). In your
case, such bits may be set up by firmware, so Linux cannot fix anything
up.


I guess by firmware you mean to bootloader. This one boots with CFE 
bootloader which Broadcom maintains itself so could look into that.


Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/RFC v8 03/14] Documentation: leds: Add description of v4l2-flash sub-device

[Bryan Wu]

On Fri, Nov 28, 2014 at 1:17 AM, Jacek Anaszewski
 wrote:
> This patch extends LED Flash class documention by
> the description of interactions with v4l2-flash sub-device.
>
> Signed-off-by: Jacek Anaszewski 
> Acked-by: Kyungmin Park 
> Cc: Bryan Wu 
> Cc: Richard Purdie 
> ---

This patch looks good to me. I will take it with other patches!

Thanks,
-Bryan

>  Documentation/leds/leds-class-flash.txt |   13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/leds/leds-class-flash.txt 
> b/Documentation/leds/leds-class-flash.txt
> index d68565c..1a611ec 100644
> --- a/Documentation/leds/leds-class-flash.txt
> +++ b/Documentation/leds/leds-class-flash.txt
> @@ -46,3 +46,16 @@ Following sysfs attributes are exposed for controlling 
> flash led devices:
>  until this flag is no longer set
> * 0x100 - the temperature of the LED has exceeded its allowed
>   upper limit
> +
> +A LED subsystem driver can be controlled also from the level of 
> VideoForLinux2
> +subsystem. In order to enable this CONFIG_V4L2_FLASH_LED_CLASS symbol has to
> +be defined in the kernel config. The driver must call the v4l2_flash_init
> +function to get registered in the V4L2 subsystem. On remove the
> +v4l2_flash_release function has to be called (see ).
> +
> +After proper initialization a V4L2 Flash sub-device is created. The 
> sub-device
> +exposes a number of V4L2 controls, which allow for controlling a LED Flash 
> class
> +device with use of its internal kernel API.
> +Opening the V4L2 Flash sub-device makes the LED subsystem sysfs interface
> +unavailable. The interface is re-enabled after the V4L2 Flash sub-device
> +is closed.
> --
> 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: [PATCHv5 2/3] kernel: add support for live patching

[Josh Poimboeuf]

On Fri, Dec 05, 2014 at 06:55:04PM +0100, Jiri Slaby wrote:
> On 12/04/2014, 04:53 PM, Seth Jennings wrote:
> ...
> > --- /dev/null
> > +++ b/kernel/livepatch/core.c
> > @@ -0,0 +1,902 @@
> ...
> > +static struct kobj_type klp_ktype_patch = {
> > +   .sysfs_ops = _sysfs_ops,
> > +   .default_attrs = klp_patch_attrs
> > +};
> 
> Hi, I seem to have only a single comment here. If I am looking
> correctly, the last put on this kobject will cause kobject_cleanup to
> generate a warning:
>"kobject: '%s' (%p): does not have a release() "
>"function, it is broken and must be fixed.\n",
> 
> There should be some .release. IMO, this is a place where we will
> release the module with the patch. So the .release hook should contain
> something like a commented out module_put() with a pointer to
> klp_register_patch. (Or be empty at worst.)

Ok, thanks.

BTW, Seth will be out for at least the next week.  I'll take over the
patch set until he returns.

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

[3.13.y-ckt stable] Linux 3.13.11-ckt12

[Kamal Mostafa]

I am announcing the release of the Linux 3.13.11-ckt12 kernel.

The updated 3.13.y-ckt tree can be found at: 
  git://kernel.ubuntu.com/ubuntu/linux.git linux-3.13.y
and can be browsed at:
  
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.13.y;a=shortlog

The diff from v3.13.11.11 is posted as a follow-up to this email.

The 3.13.y-ckt extended stable tree is maintained by the Canonical Kernel Team.
For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

 -Kamal

-- 
 .../bindings/interrupt-controller/interrupts.txt   |   4 -
 Makefile   |   2 +-
 arch/arm/Kconfig.debug |   2 +-
 arch/arm/boot/compressed/head.S|  20 ++-
 arch/arm/mach-pxa/include/mach/addr-map.h  |   5 +
 arch/arm/mm/Kconfig|   1 +
 arch/arm64/lib/clear_user.S|   2 +-
 arch/mips/oprofile/backtrace.c |   2 +-
 arch/parisc/include/uapi/asm/shmbuf.h  |  25 ++-
 arch/parisc/kernel/syscall_table.S |   8 +-
 arch/powerpc/kernel/entry_64.S |   6 +
 arch/x86/include/asm/cpufeature.h  |   1 +
 arch/x86/include/asm/kvm_para.h|  10 +-
 arch/x86/include/asm/page_32_types.h   |   1 -
 arch/x86/include/asm/page_64_types.h   |  11 +-
 arch/x86/include/asm/traps.h   |   1 +
 arch/x86/kernel/cpu/amd.c  |   7 +
 arch/x86/kernel/cpu/common.c   |   2 +
 arch/x86/kernel/dumpstack_64.c |   1 -
 arch/x86/kernel/entry_64.S |   2 +-
 arch/x86/kernel/traps.c|  18 +--
 arch/x86/kvm/emulate.c |   8 +
 arch/x86/kvm/x86.c |   2 +-
 arch/x86/mm/init_64.c  |  11 +-
 arch/xtensa/include/uapi/asm/unistd.h  |   3 +-
 drivers/acpi/device_pm.c   |   2 +-
 drivers/ata/ahci.c |  19 ++-
 drivers/base/core.c|   4 +-
 drivers/base/regmap/regmap.c   |   6 +-
 drivers/block/rbd.c|   2 +-
 drivers/char/hw_random/pseries-rng.c   |  11 +-
 drivers/clocksource/sun4i_timer.c  |  10 +-
 drivers/crypto/caam/key_gen.c  |  29 ++--
 drivers/firewire/core-cdev.c   |   3 +-
 drivers/gpu/drm/i915/intel_pm.c|  39 +++--
 drivers/gpu/drm/radeon/cik.c   |   7 +-
 drivers/gpu/drm/radeon/cik_sdma.c  |  21 +--
 drivers/gpu/drm/radeon/evergreen.c |   4 +
 drivers/gpu/drm/radeon/r100.c  |   3 +
 drivers/gpu/drm/radeon/r600_dma.c  |  20 +--
 drivers/gpu/drm/radeon/r600_dpm.c  |   2 +-
 drivers/gpu/drm/radeon/rs600.c |   3 +
 drivers/gpu/drm/radeon/rs690.c |   3 +
 drivers/gpu/drm/radeon/rv515.c |   3 +
 drivers/gpu/drm/radeon/si.c|   3 +
 drivers/i2c/busses/i2c-at91.c  |   2 +-
 drivers/infiniband/ulp/isert/ib_isert.c|  44 --
 drivers/infiniband/ulp/srpt/ib_srpt.c  |   8 +
 drivers/input/mouse/alps.c |  28 +++-
 drivers/md/dm-bufio.c  |  12 +-
 drivers/md/dm-raid.c   |  11 +-
 drivers/md/dm-thin.c   |  16 +-
 drivers/md/md.c|   4 +
 drivers/md/persistent-data/dm-btree-internal.h |   6 +
 drivers/md/persistent-data/dm-btree-spine.c|   2 +-
 drivers/md/persistent-data/dm-btree.c  |  24 ++-
 drivers/media/dvb-frontends/ds3000.c   |   7 +
 drivers/media/usb/ttusb-dec/ttusbdecfe.c   |   3 +
 drivers/net/can/dev.c  |   2 +-
 drivers/net/can/usb/esd_usb2.c |   1 +
 drivers/net/macvtap.c  |   2 +
 drivers/net/tun.c  |  16 +-
 drivers/net/wireless/ath/ath9k/ar9003_phy.c|  13 ++
 drivers/net/wireless/ath/ath9k/hw.c|  13 --
 drivers/net/wireless/ath/ath9k/reg.h   |  13 +-
 drivers/net/wireless/rt2x00/rt2x00queue.c  |  50 ++
 drivers/of/address.c   |  19 ++-
 drivers/of/base.c  |  88 +++
 drivers/of/selftest.c  |  66 +++-
 drivers/platform/x86/acer-wmi.c|  19 +++
 drivers/platform/x86/samsung-laptop.c  |  10 ++
 drivers/power/charger-manager.c|  65 +---
 drivers/regulator/max77693.c   |   2 +-
 

[PATCH v2 2/4] pinctrl: cygnus: add initial pinctrl support

[Ray Jui]

This adds the initial driver support for the Broadcom Cygnus pinctrl
controller. The Cygnus pinctrl controller supports group based
alternate function configuration

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Fengguang Wu 
---
 drivers/pinctrl/Kconfig  |7 +
 drivers/pinctrl/Makefile |1 +
 drivers/pinctrl/pinctrl-bcm-cygnus.c |  753 ++
 3 files changed, 761 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-bcm-cygnus.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index d014f22..4549e9f 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -85,6 +85,13 @@ config PINCTRL_BCM281XX
  BCM28145, and BCM28155 SoCs.  This driver requires the pinctrl
  framework.  GPIO is provided by a separate GPIO driver.
 
+config PINCTRL_BCM_CYGNUS
+   bool "Broadcom Cygnus pinctrl driver"
+   depends on (ARCH_BCM_CYGNUS || COMPILE_TEST)
+   select PINMUX
+   select PINCONF
+   select GENERIC_PINCONF
+
 config PINCTRL_LANTIQ
bool
depends on LANTIQ
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index c030b3d..4ed8e8a 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_PINCTRL_BF60x)   += pinctrl-adi2-bf60x.o
 obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o
 obj-$(CONFIG_PINCTRL_BCM2835)  += pinctrl-bcm2835.o
 obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o
+obj-$(CONFIG_PINCTRL_BCM_CYGNUS)   += pinctrl-bcm-cygnus.o
 obj-$(CONFIG_PINCTRL_FALCON)   += pinctrl-falcon.o
 obj-$(CONFIG_PINCTRL_PALMAS)   += pinctrl-palmas.o
 obj-$(CONFIG_PINCTRL_ROCKCHIP) += pinctrl-rockchip.o
diff --git a/drivers/pinctrl/pinctrl-bcm-cygnus.c 
b/drivers/pinctrl/pinctrl-bcm-cygnus.c
new file mode 100644
index 000..eb6e27a
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-bcm-cygnus.c
@@ -0,0 +1,753 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+#include "pinctrl-utils.h"
+
+/*
+ * Alternate function configuration
+ *
+ * @name: name of the alternate function
+ * @group_names: array of strings of group names that can be supported by this
+ * alternate function
+ * @num_groups: total number of groups that can be supported by this alternate
+ * function
+ * @mux: mux setting for this alternate function to be programed
+ */
+struct cygnus_pin_function {
+   const char *name;
+   const char * const *group_names;
+   const unsigned num_groups;
+   unsigned int mux;
+};
+
+/*
+ * Cygnus allows group based pinmux configuration
+ *
+ * @name: name of the group
+ * @pins: array of pins used by this group
+ * @num_pins: total number of pins used by this group
+ * @offset: register offset for pinmux configuration of this group
+ * @shift: bit shift for pinmux configuration of this group
+ */
+struct cygnus_pin_group {
+   const char *name;
+   const unsigned *pins;
+   const unsigned num_pins;
+   const unsigned int offset;
+   const unsigned int shift;
+};
+
+/*
+ * Cygnus pinctrl core
+ *
+ * @pctl: pointer to pinctrl_dev
+ * @dev: pointer to the device
+ * @base: I/O register base for Cygnus pinctrl configuration
+ *
+ */
+struct cygnus_pinctrl {
+   struct pinctrl_dev *pctl;
+   struct device *dev;
+   void __iomem *base;
+
+   const struct pinctrl_pin_desc *pins;
+   unsigned num_pins;
+
+   const struct cygnus_pin_group *groups;
+   unsigned num_groups;
+
+   const struct cygnus_pin_function *functions;
+   unsigned num_functions;
+};
+
+#define CYGNUS_PIN_GROUP(group_name, off, sh)  \
+{  \
+   .name = #group_name,\
+   .pins = group_name##_pins,  \
+   .num_pins = ARRAY_SIZE(group_name##_pins),  \
+   .offset = off,  \
+   .shift = sh,\
+}
+
+/*
+ * The following pin description is based on Cygnus I/O MUX spreadsheet
+ */
+static const struct pinctrl_pin_desc cygnus_pinctrl_pins[] = {
+   PINCTRL_PIN(0, "ext_device_reset_n"),
+   PINCTRL_PIN(1, "chip_mode0"),
+   PINCTRL_PIN(2, "chip_mode1"),
+   PINCTRL_PIN(3, "chip_mode2"),
+   PINCTRL_PIN(4, "chip_mode3"),
+   PINCTRL_PIN(5, "chip_mode4"),
+   PINCTRL_PIN(6, "bsc0_scl"),

[PATCH v2 3/4] ARM: mach-bcm: enable pinctrl support for Cygnus

[Ray Jui]

This enables the pinctrl driver for Broadcom Cygnus SoC

Signed-off-by: Ray Jui 
---
 arch/arm/mach-bcm/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index aaeec78..b4efff2 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -29,6 +29,7 @@ config ARCH_BCM_IPROC
 config ARCH_BCM_CYGNUS
bool "Broadcom Cygnus Support" if ARCH_MULTI_V7
select ARCH_BCM_IPROC
+   select PINCTRL_BCM_CYGNUS
help
  Enable support for the Cygnus family,
  which includes the following variants:
-- 
1.7.9.5

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

[PATCH v2 4/4] ARM: dts: enable pinctrl for Broadcom Cygnus

[Ray Jui]

This enables the pinctrl support for Broadcom Cygnus SoC

Signed-off-by: Ray Jui 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 5126f9e..4c6bf4d 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -54,6 +54,11 @@
 
/include/ "bcm-cygnus-clock.dtsi"
 
+   pinctrl: pinctrl@0x0301d0c8 {
+   compatible = "brcm,cygnus-pinctrl";
+   reg = <0x0301d0c8 0x2c>;
+   };
+
amba {
#address-cells = <1>;
#size-cells = <1>;
-- 
1.7.9.5

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

[PATCH v2 0/4] Add pinctrl support to Broadcom Cygnus SoC

[Ray Jui]

This patchset contains the initial pinctrl support for the Broadcom Cygnus SoC.
The Cygnus pinctrl controller supports group based alternate function 
configuration

Changes from v1:
 - Fix a typo in device tree binding document

Ray Jui (4):
  pinctrl: Broadcom Cygnus pinctrl device tree binding
  pinctrl: cygnus: add initial pinctrl support
  ARM: mach-bcm: enable pinctrl support for Cygnus
  ARM: dts: enable pinctrl for Broadcom Cygnus

 .../bindings/pinctrl/brcm,cygnus-pinctrl.txt   |   92 +++
 arch/arm/boot/dts/bcm-cygnus.dtsi  |5 +
 arch/arm/mach-bcm/Kconfig  |1 +
 drivers/pinctrl/Kconfig|7 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-bcm-cygnus.c   |  753 
 6 files changed, 859 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-bcm-cygnus.c

-- 
1.7.9.5

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

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

[Ray Jui]

Device tree binding documentation for Broadcom Cygnus pinctrl driver

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../bindings/pinctrl/brcm,cygnus-pinctrl.txt   |   92 
 1 file changed, 92 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinctrl.txt
new file mode 100644
index 000..4461aaf
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinctrl.txt
@@ -0,0 +1,92 @@
+Broadcom Cygnus Pin Controller
+
+The Cygnus pin controller supports setting the alternate functions of groups
+of pins. Pinmux configuration on individual pins is not supported by the
+Cygnus A0 SoC.
+
+Required properties:
+
+- compatible:
+Must be "brcm,cygnus-pinctrl"
+
+- reg:
+Define the base and range of the I/O address space that contain the Cygnus
+pin control registers
+
+- brcm,groups:
+This can be strings of one or more group names. This defines the group(s)
+that one wants to configure
+
+- brcm,function:
+This is the alternate function that one wants to configure to. Valid
+alternate functions are "alt1", "alt2", "alt3", "alt4"
+
+Each child node represents a configuration. Client devices reference the the
+child node to enable the mux configuration.
+
+For example:
+
+   pinctrl: pinctrl@0x0301d0c8 {
+   compatible = "brcm,cygnus-pinctrl";
+   reg = <0x0301d0c8 0x2c>;
+
+   i2s_0: i2s_0 {
+   brcm,groups = "smart_card0", "smart_card0_fcb";
+   brcm,function = "alt2";
+   };
+
+   i2s_1: i2s_1 {
+   brcm,groups = "smart_card1", "smart_card1_fcb";
+   brcm,function = "alt2";
+   };
+
+   spi_0: spi_0 {
+   brcm,groups = "spi0";
+   brcm,function = "alt1";
+   };
+   }
+
+   spi0@18028000 {
+   compatible = "arm,pl022", "arm,primecell";
+   reg = <0x18028000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   pinctrl-0 = <_0>;
+   clocks = <_clk>;
+   clock-names = "apb_pclk";
+   };
+
+Consider the following snapshot of Cygnus pinmux table:
+
+numberpingroup  alt1 alt2alt3  
  alt4
+-----      
  
+42sc0_clksmart_card0SMART CARD0  I2S_0   N/A   
  chip_gpio24
+43sc0_cmdvcc_l   smart_card0SMART CARD0  I2S_0   N/A   
  STRAP
+44sc0_detect smart_card0SMART CARD0  I2S_0   N/A   
  chip_gpio25
+45sc0_fcbsmart_card0_fcbSMART CARD0_FCB  I2S_0   N/A   
  chip_gpio26
+46sc0_io smart_card0SMART CARD0  I2S_0   N/A   
  chip_gpio27
+47sc0_rst_l  smart_card0SMART CARD0  SPDIF   N/A   
  STRAP
+
+Note due to limitation of the Cygnus hardware, pinmux configuration can only
+be group based. To enable I2S_0 function, one needs the following child node
+configuration:
+
+   i2s_0: i2s_0 {
+   brcm,groups = "smart_card0", "smart_card0_fcb";
+   brcm,function = "alt2";
+   };
+
+This tells the Cygnus pin controller to configure groups "smart_card0" and
+"smart_card0_fcb" to I2S_0. With this configuration, pins 42, 43, 44, 45, 46
+become I2S_0, and pin 47 becomes SPDIF
+
+Consider another example, that one wants to configure the above pins as GPIO:
+
+   gpio_24_27: gpio_24_27 {
+   brcm,groups = "smart_card0", "smart_card0_fcb";
+   brcm,function = "alt4";
+   };
+
+With the above configuration, pins 42, 44, 45, 46 become GPIO, and 43 and 47
+become reserved for STRAP
-- 
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/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension

[Bryan Wu]

On Mon, Dec 1, 2014 at 5:58 AM, Jacek Anaszewski
 wrote:
> Hi Pavel,
>
> On 12/01/2014 02:04 PM, Pavel Machek wrote:
>>
>> Hi!
>>
 How are faults cleared? Should it be list of strings, instead of
 bitmask? We may want to add new fault modes in future...
>>>
>>>
>>> Faults are cleared by reading the attribute. I will add this note.
>>> There can be more than one fault at a time. I think that the bitmask
>>> is a flexible solution. I don't see any troubles related to adding
>>> new fault modes in the future, do you?
>>
>>
>> I do not think that "read attribute to clear" is good idea. Normally,
>> you'd want the error attribute world-readable, but you don't want
>> non-root users to clear the errors.
>
>
> This is also V4L2_CID_FLASH_FAULT control semantics.
> Moreover many devices clear the errors upon reading register.
> I don't see anything wrong in the fact that an user can clear
> an error. If the user has a permission to use a device then
> it also should be allowed to clear the errors.
>
>> I am not sure if bitmask is good solution. I'd return space-separated
>> strings like "overtemp". That way, there's good chance that other LED
>> drivers would be able to use similar interface...
>
>
> The format of a sysfs attribute should be concise.
> The error codes are generic and map directly to the V4L2 Flash
> error codes.
>

Actually I'd like to see those flash fault code defined in LED
subsystem. And V4L2 will just include LED flash header file to use it.
Because flash fault code is not for V4L2 specific but it's a feature
of LED flash devices.

For clearing error code of flash devices, I think it depends on the
hardware. If most of our LED flash is using reading to clear error
code, we probably can make it simple as this now. But what if some
other LED flash devices are using writing to clear error code? we
should provide a API to that?

-Bryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] MIPS: set stack/data protection as non-executable

[Christoph Lameter]

On Fri, 5 Dec 2014, David Daney wrote:

> The problem is not with "modern" executables that are properly annotated with
> PT_GNU_STACK.
>
> My objection is to the intentional breaking of old executables that have no
> PT_GNU_STACK annotation, but require an executable stack.  Since we usually
> try not to break userspace, we cannot merge a patch like this one.

How old are these and how many are still around? Can the annotation be
added with a tool?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] MIPS: set stack/data protection as non-executable

[Leonid Yegoshin]

On 12/05/2014 11:06 AM, David Daney wrote:

On 12/05/2014 10:51 AM, Kees Cook wrote:
On Fri, Dec 5, 2014 at 9:28 AM, David Daney  
wrote:


Some programs require an executable stack, this patch will break them.


Have you tested this?


Do you require empirical evidence that the patch is incorrect, or is 
it enough to just to trust me when I say that it is incorrect? 
Typically the burden of proof is with those proposing the patches.





You can only select a non-executable stack in response to PT_GNU_STACK
program headers in the ELF file of the executable program.


This is already handled by fs/binfmt_elf.c. It does the parsing of the
PT_GNU_STACK needs, and sets up the stack flags appropriately. All the
change to VM_DATA_DEFAULT_FLAGS does is make sure that EXSTACK_DEFAULT
now means no VM_EXEC by default. If PT_GNU_STACK requires it, it gets
added back in.



The problem is not with "modern" executables that are properly 
annotated with PT_GNU_STACK.


My objection is to the intentional breaking of old executables that 
have no PT_GNU_STACK annotation, but require an executable stack.  
Since we usually try not to break userspace, we cannot merge a patch 
like this one.




I ran Debian, buildroot etc and I had only one problem - ssh_keygen is 
built with PT_GNU_STACK annotation stack executable protection. And 
debug output shows a spectacular discarding this setup from kernel by 
GLIBC loader a couple of milliseconds later, at first library load. You 
can test it yourself - run ssh_keygen and look into it's 
/proc//maps, stack would have +X.


The rest of Debian distribution, buildroot and Android runs fine with 
this patch series.


Without any step forward the stack protection would be never solved. 
GLIBC team looked into problem and they agree to fix a default 
cancellation of no-X but they need a platform for that.



But of course, we can delay this specific non-X setup for stack until 
GLIBC fixes loader and do this patch optional or via boot flag.


Note: I push this series not because of default non-X stack but because 
an explicit PT_GNU_STACK no-X is ignored.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] MIPS: set stack/data protection as non-executable

[Kees Cook]

On Fri, Dec 5, 2014 at 11:06 AM, David Daney  wrote:
> On 12/05/2014 10:51 AM, Kees Cook wrote:
>>
>> On Fri, Dec 5, 2014 at 9:28 AM, David Daney  wrote:
>>>
>>> On 12/02/2014 05:58 PM, Leonid Yegoshin wrote:


 This is a last step of 3 patches which shift FPU emulation out of
 stack into protected area. So, it disables a default executable stack.

 Additionally, it sets a default data area non-executable protection.

 Signed-off-by: Leonid Yegoshin 
>>>
>>>
>>>
>>> NAK!
>>>
>>> Some programs require an executable stack, this patch will break them.
>>
>> Have you tested this?
>
> Do you require empirical evidence that the patch is incorrect, or is it
> enough to just to trust me when I say that it is incorrect?  Typically the
> burden of proof is with those proposing the patches.

My fault, I misunderstood. (See below.)

>>> You can only select a non-executable stack in response to PT_GNU_STACK
>>> program headers in the ELF file of the executable program.
>>
>>
>> This is already handled by fs/binfmt_elf.c. It does the parsing of the
>> PT_GNU_STACK needs, and sets up the stack flags appropriately. All the
>> change to VM_DATA_DEFAULT_FLAGS does is make sure that EXSTACK_DEFAULT
>> now means no VM_EXEC by default. If PT_GNU_STACK requires it, it gets
>> added back in.
>>
>
> The problem is not with "modern" executables that are properly annotated
> with PT_GNU_STACK.
>
> My objection is to the intentional breaking of old executables that have no
> PT_GNU_STACK annotation, but require an executable stack.  Since we usually
> try not to break userspace, we cannot merge a patch like this one.

Ah! Okay. If legacy executables expected an executable stack for more
reasons than FPU emulation, then yes, absolutely I agree with you.

-Kees

>
> David Daney.
>
>
>
>> -Kees
>>
>>>
>>> David Daney
>>>
>>>
>>>
 ---
arch/mips/include/asm/page.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
 index 3be81803595d..d49ba81cb4ed 100644
 --- a/arch/mips/include/asm/page.h
 +++ b/arch/mips/include/asm/page.h
 @@ -230,7 +230,7 @@ extern int __virt_addr_valid(const volatile void
 *kaddr);
#define virt_addr_valid(kaddr)
 \
  __virt_addr_valid((const volatile void *) (kaddr))

 -#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | VM_EXEC | \
 +#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | \
   VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)

#define UNCAC_ADDR(addr)  ((addr) - PAGE_OFFSET + UNCAC_BASE)




>>>
>>
>>
>>
>



-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] compiler: use compiler to detect integer overflows

[Dan Carpenter]

On Fri, Dec 05, 2014 at 10:50:19AM -0800, Linus Torvalds wrote:
> On Fri, Dec 5, 2014 at 1:54 AM, Dan Carpenter  
> wrote:
> >
> > There are some false positives which do:
> >
> > if ((u16)(u16_foo + u16_bar) < u16_foo) {
> 
> Actually, the worse false positive is the ones that are pointer comparisons.
> 
> A compiler that does those as signed is just broken. It's happened,
> but it's *still* completely broken.
> 

Oh.  Wow...  That's embarrassing.  I thought they were signed for some
reason, and I thought it was weird, but I didn't think about it hard
enough...

I'll redo this.

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: frequent lockups in 3.18rc4

[Dave Jones]

On Fri, Dec 05, 2014 at 11:31:11AM -0800, Linus Torvalds wrote:
 > On Fri, Dec 5, 2014 at 10:48 AM, Dave Jones  wrote:
 > >
 > > In the meantime, I rebooted into the same kernel, and ran trinity
 > > solely doing the lsetxattr syscalls.
 > 
 > Any particular reason for the lsetxattr guess? Just the last call
 > chain? I don't recognize it from the other traces, but maybe I just
 > didn't notice.

yeah just a wild guess, just that that trace looked so.. clean.

 > >   The load was a bit lower, so I
 > > cranked up the number of child processes to 512, and then this
 > > happened..
 >
 > Ugh. "dump_trace()" being broken and looping forever? I don't actually
 > believe it, because this isn't even on the exception stack (well, the
 > NMI dumper is, but that one worked fine - this is the "nested" dumping
 > of just the allocation call chain)
 >
 > Smells like more random callchains to me. Unless this one is repeatable.
 >
 > Limiting trinity to just lsetxattr is interesting. Did it make things
 > fail faster?

It sure failed quickly, but not in the "machine is totally locked up"
sense, just "shit is all corrupted" sense. So it might be a completely different
thing, or it could be a different manifestation of a corruptor.

I guess we'll see how things go now that I marked it 'bad'.

I'll give it a quick run with just lsetxattr again just to see what
happens, but before I leave this one run over the weekend, I'll switch
it back to "do everything", and pick it up again on Monday.

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/

[PATCH net] bnx2x: Implement ndo_gso_check()

[Joe Stringer]

Use vxlan_gso_check() to advertise offload support for this NIC.

Signed-off-by: Joe Stringer 
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 74fbf9e..893cdb6 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -12550,6 +12551,11 @@ static int bnx2x_get_phys_port_id(struct net_device 
*netdev,
return 0;
 }
 
+static bool bnx2x_gso_check(struct sk_buff *skb, struct net_device *dev)
+{
+   return vxlan_gso_check(skb);
+}
+
 static const struct net_device_ops bnx2x_netdev_ops = {
.ndo_open   = bnx2x_open,
.ndo_stop   = bnx2x_close,
@@ -12581,6 +12587,7 @@ static const struct net_device_ops bnx2x_netdev_ops = {
 #endif
.ndo_get_phys_port_id   = bnx2x_get_phys_port_id,
.ndo_set_vf_link_state  = bnx2x_set_vf_link_state,
+   .ndo_gso_check  = bnx2x_gso_check,
 };
 
 static int bnx2x_set_coherency_mask(struct bnx2x *bp)
-- 
1.7.10.4

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

Re: [PATCH v2] i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C spec

[Doug Anderson]

Hi,

On Thu, Dec 4, 2014 at 11:03 AM, Wolfram Sang  wrote:
>
>> > New binding should have the "-ns" suffix, right? So, I'd vote to add the
>> > suffix to the new bindings and deprecate the ones used in the designware
>> > driver: "i2c-scl-rising-time-ns" and "i2c-scl-falling-time-ns"
>> >
>> > It might be a little more work now, but it will help us in the future,
>> > because it is the correct way to do it.
>>
>> OK, that sounds fair.  You're OK with my proposal otherwise?
>
> Yes.

OK, for simplicity I put my requested changes in



>> Are you looking for Addy or me to submit a patch supporting the "-ns"
>> suffix on the Designware i2c driver, or should we just use the "-ns"
>> suffix in the Rockchip driver and assume someone will later add
>> support for the new binding in the Designware i2c driver?
>
> I'd be really happy if you can do it. I'd love to have consistency right
> away.

Well that was easy.  https://patchwork.kernel.org/patch/5445231/

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

Re: frequent lockups in 3.18rc4

[Linus Torvalds]

On Fri, Dec 5, 2014 at 10:48 AM, Dave Jones  wrote:
>
> In the meantime, I rebooted into the same kernel, and ran trinity
> solely doing the lsetxattr syscalls.

Any particular reason for the lsetxattr guess? Just the last call
chain? I don't recognize it from the other traces, but maybe I just
didn't notice.

>   The load was a bit lower, so I
> cranked up the number of child processes to 512, and then this
> happened..

Ugh. "dump_trace()" being broken and looping forever? I don't actually
believe it, because this isn't even on the exception stack (well, the
NMI dumper is, but that one worked fine - this is the "nested" dumping
of just the allocation call chain)

Smells like more random callchains to me. Unless this one is repeatable.

Limiting trinity to just lsetxattr is interesting. Did it make things
fail faster?

 Linus

> [ 1611.747053] WARNING: CPU: 0 PID: 14810 at kernel/watchdog.c:265 
> watchdog_overflow_callback+0xd5/0x120()
> [ 1611.747083] Watchdog detected hard LOCKUP on cpu 0
> [ 1611.747389] CPU: 0 PID: 14810 Comm: trinity-c304 Not tainted 3.16.0+ #114
> [ 1611.747544] Call Trace:
>[ remnoved NMI perf event stack trace ]
> [ 1611.753861]  [] is_module_text_address+0x17/0x50
> [ 1611.754734]  [] __kernel_text_address+0x58/0x80
> [ 1611.755575]  [] print_context_stack+0x8f/0x100
> [ 1611.756410]  [] dump_trace+0x140/0x370
> [ 1611.758895]  [] save_stack_trace+0x2b/0x50
> [ 1611.759720]  [] set_track+0x70/0x140
> [ 1611.760541]  [] alloc_debug_processing+0x92/0x118
> [ 1611.761366]  [] __slab_alloc+0x45f/0x56f
> [ 1611.765539]  [] kmem_cache_alloc+0x1f6/0x270
> [ 1611.767183]  [] getname_flags+0x4f/0x1a0
> [ 1611.768004]  [] user_path_at_empty+0x45/0xc0
> [ 1611.772129]  [] user_path_at+0x11/0x20
> [ 1611.772959]  [] SyS_lsetxattr+0x4b/0xf0
> [ 1611.773783]  [] system_call_fastpath+0x16/0x1b
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: frequent lockups in 3.18rc4

[Linus Torvalds]

On Fri, Dec 5, 2014 at 11:04 AM, Chris Mason  wrote:
>
> So one idea is that our allocation/freeing of pages is dramatically more
> expensive and we're hitting a strange edge condition.  Maybe we're even
> faulting on a readonly page from a horrible place?

Well, various allocators have definitely shown up a lot.
DEBUG_PAGEALLOC does horrible things to performance, though, and the
kernel will just spend a *lot* of time in memory allocators when it is
on. So it might just be "yeah, the traces show allocations a lot, but
that might just be because allocation is slow". The last one showed
slub debugging - getting a call trace for the allocation.

> [83246.925234] end_request: I/O error, dev sda, sector 0
>
> Ext3/4 shouldn't be doing IO to sector zero.  Something is stomping on ram?

I'd buy memory corruption through wild pointers as the reason, but
quite frankly, that tends to have completely different failure modes.
Not NMI watchdogs.

So it must be some very particular corruption. I still vote for "let's
see if Dave can narrow it down with bisection".

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

Re: using DMA-API on ARM

[Russell King - ARM Linux]

On Fri, Dec 05, 2014 at 08:22:05PM +0100, Arend van Spriel wrote:
> On 12/05/14 19:28, Catalin Marinas wrote:
> >This is solved by using a pre-allocated, pre-mapped atomic_pool which
> >avoids any further mapping. __dma_alloc() calls __alloc_from_pool() when
> >!__GFP_WAIT.
> 
> So we are actually calling dma_alloc_coherent() with GFP_KERNEL during
> device probe. That last paragraph Russell pointed out seems to suggest this
> is not allowed.

device probe is a schedulable, sleepable context, so dma_alloc_coherent()
is fine there.  As Catalin points out, and as I realised after sending
them ail, it does check for __GFP_WAIT and uses a smaller atomic pool
for those allocations.  This explains why no one has hit any warnings in
map_vm_area.

So, it's safe from atomic contexts after all.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: using DMA-API on ARM

[Arend van Spriel]

On 12/05/14 19:28, Catalin Marinas wrote:

On Fri, Dec 05, 2014 at 03:06:48PM +, Russell King - ARM Linux wrote:

I've been doing more digging into the current DMA code, and I'm dismayed
to see that there's new bugs in it...

commit 513510ddba9650fc7da456eefeb0ead7632324f6
Author: Laura Abbott
Date:   Thu Oct 9 15:26:40 2014 -0700

 common: dma-mapping: introduce common remapping functions

This uses map_vm_area() to achieve the remapping of pages allocated inside
dma_alloc_coherent().  dma_alloc_coherent() is documented in a rather
round-about way in Documentation/DMA-API.txt:

| Part Ia - Using large DMA-coherent buffers
| --
|
| void *
| dma_alloc_coherent(struct device *dev, size_t size,
|  dma_addr_t *dma_handle, gfp_t flag)
|
| void
| dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
|dma_addr_t dma_handle)
|
| Free a region of consistent memory you previously allocated.  dev,
| size and dma_handle must all be the same as those passed into
| dma_alloc_coherent().  cpu_addr must be the virtual address returned by
| the dma_alloc_coherent().
|
| Note that unlike their sibling allocation calls, these routines
| may only be called with IRQs enabled.

Note that very last paragraph.  What this says is that it is explicitly
permitted to call dma_alloc_coherent() with IRQs disabled.


This is solved by using a pre-allocated, pre-mapped atomic_pool which
avoids any further mapping. __dma_alloc() calls __alloc_from_pool() when
!__GFP_WAIT.


So we are actually calling dma_alloc_coherent() with GFP_KERNEL during 
device probe. That last paragraph Russell pointed out seems to suggest 
this is not allowed.



This code got pretty complex and we may find bugs. It can be simplified
by a pre-allocated non-cacheable region that is safe in atomic context
(how big you allocate this is hard to say).


If the problem which you (Broadcom) are suffering from is down to the
issue I suspect (that being having mappings with different cache
attributes) then I'm not sure that there's anything we can realistically
do about that.  There's a number of issues which make it hard to see a
way forward.


I'm still puzzled by this problem, so I don't have any suggestion yet. I
wouldn't blame the mismatched attributes yet as I haven't seen such
problem in practice (but you never know).

How does the DT describe this device? Could it have some dma-coherent
property in there that causes dma_alloc_coherent() to create a cacheable
memory?


Ok. Will add it to our todo list: check DTS files for dma-coherent property.

Thanks,
Arend


The reverse could also cause problems: the device is coherent but the
CPU creates a non-cacheable mapping.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: pull request: bluetooth-next 2014-12-05

[John W. Linville]

On Fri, Dec 05, 2014 at 06:41:49PM +0200, Johan Hedberg wrote:
> Hi John,
> 
> Marcel had a couple more patches that were supposed to be in the pull
> request, so here's a new one that supersedes the one I made earlier
> today.
> 
> In addition to the previous one this contains two more cleanups to
> mac802154 as well as support for some new HCI features from the
> Bluetooth 4.2 specification.
> 
> From the original request:
> 
> "Here's what should be the last bluetooth-next pull request for 3.19.
> It's rather large but the majority of it is the Low Energy Secure
> Connections feature that's part of the Bluetooth 4.2 specification. The
> specification went public only this week so we couldn't publish the
> corresponding code before that. The code itself can nevertheless be
> considered fairly mature as it's been in development for over 6 months
> and gone through several interoperability test events.
> 
> Besides LE SC the pull request contains an important fix for command
> complete events for mgmt sockets which also fixes some leaks of hci_conn
> objects when powering off or unplugging Bluetooth adapters.
> 
> A smaller feature that's part of the pull request is service discovery
> support. This is like normal device discovery except that devices not
> matching specific UUIDs or strong enough RSSI are filtered out.
> 
> Other changes that the pull request contains are firmware dump support
> to the btmrvl driver, firmware download support for Broadcom BCM20702A0
> variants, as well as some coding style cleanups in 6lowpan &
> ieee802154/mac802154 code."
> 
> Please let me know if there are any issues pulling. Thanks.
> 
> Johan
> 
> ---
> The following changes since commit f6af675ef5489c69fc3d4faf8c6f477df3cbf8b9:
> 
>   Bluetooth: Automatically flushable packets aren't allowed on LE links 
> (2014-11-27 12:12:27 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git 
> for-upstream
> 
> for you to fetch changes up to 5a34bd5f5d8119def4feb1d2b4e3906b71059416:
> 
>   Bluetooth: Enable events for P-256 Public Key and DHKey commands 
> (2014-12-05 18:17:49 +0200)

Pulling now...

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-nics] [PATCHv4 net] i40e: Implement ndo_gso_check()

[Jeff Kirsher]

On Fri, 2014-12-05 at 10:41 -0800, Joe Stringer wrote:
> ndo_gso_check() was recently introduced to allow NICs to report the
> offloading support that they have on a per-skb basis. Add an
> implementation for this driver which checks for IPIP, GRE, UDP
> tunnels.
> 
> Signed-off-by: Joe Stringer 
> ---
> v4: Simplify the check to just do tunnel header length.
> Fix #define style issue.
> v3: Drop IPIP and GRE (no driver support even though hw supports it).
> Check for UDP outer protocol for UDP tunnels.
> v2: Expand to include IP in IP and IPv4/IPv6 inside GRE/UDP tunnels.
> Add MAX_INNER_LENGTH (as 80).
> ---
>  drivers/net/ethernet/intel/i40e/i40e_main.c |   12 
>  1 file changed, 12 insertions(+)

Thanks Joe, I will update the patch in my queue with your latest
version.


signature.asc
Description: This is a digitally signed message part

[PATCH net-next] macvlan: allow setting LRO independently of lower device

[Michal Kubecek]

Since commit fbe168ba91f7 ("net: generic dev_disable_lro() stacked
device handling"), dev_disable_lro() zeroes NETIF_F_LRO feature flag
first for a macvlan device and then for its lower device. As an attempt
to set NETIF_F_LRO to zero is ignored, dev_disable_lro() issues a
warning and taints kernel.

Allowing NETIF_F_LRO to be set independently of the lower device
consists of three parts:

  - add the flag to hw_features to allow toggling it
  - allow setting it to 0 even if lower device has the flag set
  - add the flag to MACVLAN_FEATURES to restore copying from lower
device on macvlan creation

Signed-off-by: Michal Kubecek 
---
 drivers/net/macvlan.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 9538674..10604db 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -747,7 +747,7 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
 
 #define MACVLAN_FEATURES \
(NETIF_F_SG | NETIF_F_ALL_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
-NETIF_F_GSO | NETIF_F_TSO | NETIF_F_UFO | \
+NETIF_F_GSO | NETIF_F_TSO | NETIF_F_UFO | NETIF_F_LRO | \
 NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
 NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
 
@@ -784,6 +784,7 @@ static int macvlan_init(struct net_device *dev)
  (lowerdev->state & MACVLAN_STATE_MASK);
dev->features   = lowerdev->features & MACVLAN_FEATURES;
dev->features   |= ALWAYS_ON_FEATURES;
+   dev->hw_features|= NETIF_F_LRO;
dev->vlan_features  = lowerdev->vlan_features & MACVLAN_FEATURES;
dev->gso_max_size   = lowerdev->gso_max_size;
dev->iflink = lowerdev->ifindex;
@@ -936,15 +937,15 @@ static netdev_features_t macvlan_fix_features(struct 
net_device *dev,
  netdev_features_t features)
 {
struct macvlan_dev *vlan = netdev_priv(dev);
+   netdev_features_t lowerdev_features = vlan->lowerdev->features;
netdev_features_t mask;
 
features |= NETIF_F_ALL_FOR_ALL;
features &= (vlan->set_features | ~MACVLAN_FEATURES);
mask = features;
 
-   features = netdev_increment_features(vlan->lowerdev->features,
-features,
-mask);
+   lowerdev_features &= (features | ~NETIF_F_LRO);
+   features = netdev_increment_features(lowerdev_features, features, mask);
features |= ALWAYS_ON_FEATURES;
features &= ~NETIF_F_NETNS_LOCAL;
 
-- 
1.8.4.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/

[RFC PATCH v6 3/9] tools lib traceevent: Add support for __print_u{8,16,32,64}_array()

[Javi Merino]

Trace can now generate traces with u8, u16, u32 and u64 dynamic
arrays.  Add support to parse them.

Cc: Arnaldo Carvalho de Melo 
Cc: Steven Rostedt 
Cc: Jiri Olsa 
Signed-off-by: Javi Merino 
---
 tools/lib/traceevent/event-parse.c | 62 +++---
 tools/lib/traceevent/event-parse.h |  4 +++
 2 files changed, 61 insertions(+), 5 deletions(-)

diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index f12ea53cc83b..f67260bddd65 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -753,6 +753,10 @@ static void free_arg(struct print_arg *arg)
free_arg(arg->symbol.field);
free_flag_sym(arg->symbol.symbols);
break;
+   case PRINT_U8:
+   case PRINT_U16:
+   case PRINT_U32:
+   case PRINT_U64:
case PRINT_HEX:
free_arg(arg->num.field);
free_arg(arg->num.size);
@@ -2827,6 +2831,22 @@ process_function(struct event_format *event, struct 
print_arg *arg,
free_token(token);
return process_hex(event, arg, tok);
}
+   if (strcmp(token, "__print_u8_array") == 0) {
+   free_token(token);
+   return process_num(event, arg, tok, PRINT_U8);
+   }
+   if (strcmp(token, "__print_u16_array") == 0) {
+   free_token(token);
+   return process_num(event, arg, tok, PRINT_U16);
+   }
+   if (strcmp(token, "__print_u32_array") == 0) {
+   free_token(token);
+   return process_num(event, arg, tok, PRINT_U32);
+   }
+   if (strcmp(token, "__print_u64_array") == 0) {
+   free_token(token);
+   return process_num(event, arg, tok, PRINT_U64);
+   }
if (strcmp(token, "__get_str") == 0) {
free_token(token);
return process_str(event, arg, tok);
@@ -3355,6 +3375,10 @@ eval_num_arg(void *data, int size, struct event_format 
*event, struct print_arg
break;
case PRINT_FLAGS:
case PRINT_SYMBOL:
+   case PRINT_U8:
+   case PRINT_U16:
+   case PRINT_U32:
+   case PRINT_U64:
case PRINT_HEX:
break;
case PRINT_TYPE:
@@ -3660,7 +3684,7 @@ static void print_str_arg(struct trace_seq *s, void 
*data, int size,
unsigned long long val, fval;
unsigned long addr;
char *str;
-   unsigned char *hex;
+   void *num;
int print;
int i, len;
 
@@ -3739,13 +3763,17 @@ static void print_str_arg(struct trace_seq *s, void 
*data, int size,
}
}
break;
+   case PRINT_U8:
+   case PRINT_U16:
+   case PRINT_U32:
+   case PRINT_U64:
case PRINT_HEX:
if (arg->num.field->type == PRINT_DYNAMIC_ARRAY) {
unsigned long offset;
offset = pevent_read_number(pevent,
data + arg->num.field->dynarray.field->offset,
arg->num.field->dynarray.field->size);
-   hex = data + (offset & 0x);
+   num = data + (offset & 0x);
} else {
field = arg->num.field->field.field;
if (!field) {
@@ -3755,13 +3783,24 @@ static void print_str_arg(struct trace_seq *s, void 
*data, int size,
goto out_warning_field;
arg->num.field->field.field = field;
}
-   hex = data + field->offset;
+   num = data + field->offset;
}
len = eval_num_arg(data, size, event, arg->num.size);
for (i = 0; i < len; i++) {
if (i)
trace_seq_putc(s, ' ');
-   trace_seq_printf(s, "%02x", hex[i]);
+   if (arg->type == PRINT_HEX)
+   trace_seq_printf(s, "%02x",
+   ((uint8_t *)num)[i]);
+   else if (arg->type == PRINT_U8)
+   trace_seq_printf(s, "%u", ((uint8_t *)num)[i]);
+   else if (arg->type == PRINT_U16)
+   trace_seq_printf(s, "%u", ((uint16_t *)num)[i]);
+   else if (arg->type == PRINT_U32)
+   trace_seq_printf(s, "%u", ((uint32_t *)num)[i]);
+   else/* PRINT_U64 */
+   trace_seq_printf(s, "%lu",
+   ((uint64_t *)num)[i]);
}
break;
 
@@ -4922,7 +4961,20 @@ static void print_args(struct print_arg *args)
printf(")");
break;
case PRINT_HEX:

[RFC PATCH v6 2/9] tools lib traceevent: Generalize numeric argument

[Javi Merino]

Numeric arguments can be in different bases, so rename it to num so
that they can be used for formats other than PRINT_HEX

Cc: Steven Rostedt 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Signed-off-by: Javi Merino 
---
 tools/lib/traceevent/event-parse.c | 26 +-
 tools/lib/traceevent/event-parse.h |  4 ++--
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index cf3a44bf1ec3..f12ea53cc83b 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -754,8 +754,8 @@ static void free_arg(struct print_arg *arg)
free_flag_sym(arg->symbol.symbols);
break;
case PRINT_HEX:
-   free_arg(arg->hex.field);
-   free_arg(arg->hex.size);
+   free_arg(arg->num.field);
+   free_arg(arg->num.size);
break;
case PRINT_TYPE:
free(arg->typecast.type);
@@ -2503,7 +2503,7 @@ process_hex(struct event_format *event, struct print_arg 
*arg, char **tok)
if (test_type_token(type, token, EVENT_DELIM, ","))
goto out_free;
 
-   arg->hex.field = field;
+   arg->num.field = field;
 
free_token(token);
 
@@ -2519,7 +2519,7 @@ process_hex(struct event_format *event, struct print_arg 
*arg, char **tok)
if (test_type_token(type, token, EVENT_DELIM, ")"))
goto out_free;
 
-   arg->hex.size = field;
+   arg->num.size = field;
 
free_token(token);
type = read_token_item(tok);
@@ -3740,24 +3740,24 @@ static void print_str_arg(struct trace_seq *s, void 
*data, int size,
}
break;
case PRINT_HEX:
-   if (arg->hex.field->type == PRINT_DYNAMIC_ARRAY) {
+   if (arg->num.field->type == PRINT_DYNAMIC_ARRAY) {
unsigned long offset;
offset = pevent_read_number(pevent,
-   data + arg->hex.field->dynarray.field->offset,
-   arg->hex.field->dynarray.field->size);
+   data + arg->num.field->dynarray.field->offset,
+   arg->num.field->dynarray.field->size);
hex = data + (offset & 0x);
} else {
-   field = arg->hex.field->field.field;
+   field = arg->num.field->field.field;
if (!field) {
-   str = arg->hex.field->field.name;
+   str = arg->num.field->field.name;
field = pevent_find_any_field(event, str);
if (!field)
goto out_warning_field;
-   arg->hex.field->field.field = field;
+   arg->num.field->field.field = field;
}
hex = data + field->offset;
}
-   len = eval_num_arg(data, size, event, arg->hex.size);
+   len = eval_num_arg(data, size, event, arg->num.size);
for (i = 0; i < len; i++) {
if (i)
trace_seq_putc(s, ' ');
@@ -4923,9 +4923,9 @@ static void print_args(struct print_arg *args)
break;
case PRINT_HEX:
printf("__print_hex(");
-   print_args(args->hex.field);
+   print_args(args->num.field);
printf(", ");
-   print_args(args->hex.size);
+   print_args(args->num.size);
printf(")");
break;
case PRINT_STRING:
diff --git a/tools/lib/traceevent/event-parse.h 
b/tools/lib/traceevent/event-parse.h
index 7a3873ff9a4f..2bf72e908a74 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -240,7 +240,7 @@ struct print_arg_symbol {
struct print_flag_sym   *symbols;
 };
 
-struct print_arg_hex {
+struct print_arg_num {
struct print_arg*field;
struct print_arg*size;
 };
@@ -291,7 +291,7 @@ struct print_arg {
struct print_arg_typecast   typecast;
struct print_arg_flags  flags;
struct print_arg_symbol symbol;
-   struct print_arg_hexhex;
+   struct print_arg_numnum;
struct print_arg_func   func;
struct print_arg_string string;
struct print_arg_bitmaskbitmask;
-- 
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: frequent lockups in 3.18rc4

[Chris Mason]

On Fri, Dec 5, 2014 at 1:38 PM, Linus Torvalds 
 wrote:

On Fri, Dec 5, 2014 at 9:15 AM, Dave Jones  wrote:


 A bisect later, and I landed on a kernel that ran for a day, before
 spewing NMI messages, recovering, and then..

 
https://urldefense.proofpoint.com/v1/url?u=http://codemonkey.org.uk/junk/log.txt=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A=6%2FL0lzzDhu0Y1hL9xm%2BQyA%3D%3D%0A=APfD8%2BRkGVsO9UHnH6Oo05Zuoh90VyaaF71AycsnLbQ%3D%0A=de71b34f3a7da1c7b8f12dcd760c271657f9f7e2a93b4d2e296b2c687cee5157


I have to admit I'm seeing absolutely nothing sensible in there.

Call it bad, and see if bisection ends up slowly -oh so slowly -
pointing to some direction. Because I don't think it's the hardware,
considering that apparently 3.16 is solid. And the spews themselves
are so incomprehensible that I'm not seeing any pattern what-so-ever.


I went back through all of the traces Dave has posted in this thread.  
This one looks like vm debugging is on:


http://marc.info/?l=linux-kernel=141632237304726=2

Another had a function call from CONFIG_DEBUG_PAGEALLOC:

http://marc.info/?l=linux-kernel=141701248210949=2

So one idea is that our allocation/freeing of pages is dramatically 
more expensive and we're hitting a strange edge condition.  Maybe we're 
even faulting on a readonly page from a horrible place?


[83246.925234] end_request: I/O error, dev sda, sector 0

Ext3/4 shouldn't be doing IO to sector zero.  Something is stomping on 
ram?


-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] MIPS: set stack/data protection as non-executable

[David Daney]

On 12/05/2014 10:51 AM, Kees Cook wrote:

On Fri, Dec 5, 2014 at 9:28 AM, David Daney  wrote:

On 12/02/2014 05:58 PM, Leonid Yegoshin wrote:


This is a last step of 3 patches which shift FPU emulation out of
stack into protected area. So, it disables a default executable stack.

Additionally, it sets a default data area non-executable protection.

Signed-off-by: Leonid Yegoshin 



NAK!

Some programs require an executable stack, this patch will break them.


Have you tested this?


Do you require empirical evidence that the patch is incorrect, or is it 
enough to just to trust me when I say that it is incorrect?  Typically 
the burden of proof is with those proposing the patches.





You can only select a non-executable stack in response to PT_GNU_STACK
program headers in the ELF file of the executable program.


This is already handled by fs/binfmt_elf.c. It does the parsing of the
PT_GNU_STACK needs, and sets up the stack flags appropriately. All the
change to VM_DATA_DEFAULT_FLAGS does is make sure that EXSTACK_DEFAULT
now means no VM_EXEC by default. If PT_GNU_STACK requires it, it gets
added back in.



The problem is not with "modern" executables that are properly annotated 
with PT_GNU_STACK.


My objection is to the intentional breaking of old executables that have 
no PT_GNU_STACK annotation, but require an executable stack.  Since we 
usually try not to break userspace, we cannot merge a patch like this one.


David Daney.



-Kees



David Daney




---
   arch/mips/include/asm/page.h |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
index 3be81803595d..d49ba81cb4ed 100644
--- a/arch/mips/include/asm/page.h
+++ b/arch/mips/include/asm/page.h
@@ -230,7 +230,7 @@ extern int __virt_addr_valid(const volatile void
*kaddr);
   #define virt_addr_valid(kaddr)
\
 __virt_addr_valid((const volatile void *) (kaddr))

-#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | VM_EXEC | \
+#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | \
  VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)

   #define UNCAC_ADDR(addr)  ((addr) - PAGE_OFFSET + UNCAC_BASE)












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

[RFC PATCH v6 9/9] of: thermal: Introduce sustainable power for a thermal zone

[Javi Merino]

From: Punit Agrawal 

Introduce an optional property called, sustainable-power, which
represents the power (in mW) which the thermal zone can safely
dissipate.

If provided the property is parsed and associated with the thermal
zone via the thermal zone parameters.

Cc: Zhang Rui 
Cc: Eduardo Valentin 
Signed-off-by: Punit Agrawal 
---
 Documentation/devicetree/bindings/thermal/thermal.txt | 4 
 drivers/thermal/of-thermal.c  | 4 
 2 files changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
b/Documentation/devicetree/bindings/thermal/thermal.txt
index f5db6b72a36f..c6eb9a8d2aed 100644
--- a/Documentation/devicetree/bindings/thermal/thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -167,6 +167,10 @@ Optional property:
by means of sensor ID. Additional coefficients are
interpreted as constant offset.
 
+- sustainable-power:   An estimate of the sustainable power (in mW) that the
+  Type: unsigned   thermal zone can dissipate.
+  Size: one cell
+
 Note: The delay properties are bound to the maximum dT/dt (temperature
 derivative over time) in two situations for a thermal zone:
 (i)  - when passive cooling is activated (polling-delay-passive); and
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 62143ba31001..e032b9bf4085 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -794,6 +794,7 @@ int __init of_parse_thermal_zones(void)
for_each_child_of_node(np, child) {
struct thermal_zone_device *zone;
struct thermal_zone_params *tzp;
+   u32 prop;
 
/* Check whether child is enabled or not */
if (!of_device_is_available(child))
@@ -820,6 +821,9 @@ int __init of_parse_thermal_zones(void)
/* No hwmon because there might be hwmon drivers registering */
tzp->no_hwmon = true;
 
+   if (!of_property_read_u32(child, "sustainable-power", ))
+   tzp->sustainable_power = prop;
+
zone = thermal_zone_device_register(child->name, tz->ntrips,
0, tz,
ops, tzp,
-- 
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/

[RFC PATCH v6 6/9] thermal: cpu_cooling: implement the power cooling device API

[Javi Merino]

Add a basic power model to the cpu cooling device to implement the
power cooling device API.  The power model uses the current frequency,
current load and OPPs for the power calculations.  The cpus must have
registered their OPPs using the OPP library.

Cc: Zhang Rui 
Cc: Eduardo Valentin 
Signed-off-by: Punit Agrawal 
Signed-off-by: Javi Merino 
---
 Documentation/thermal/cpu-cooling-api.txt | 144 +-
 drivers/thermal/cpu_cooling.c | 431 +-
 include/linux/cpu_cooling.h   |  49 +++-
 3 files changed, 611 insertions(+), 13 deletions(-)

diff --git a/Documentation/thermal/cpu-cooling-api.txt 
b/Documentation/thermal/cpu-cooling-api.txt
index fca24c931ec8..d438a900e374 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -25,8 +25,150 @@ the user. The registration APIs returns the cooling device 
pointer.
 
clip_cpus: cpumask of cpus where the frequency constraints will happen.
 
-1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
+1.1.2 struct thermal_cooling_device *cpufreq_power_cooling_register(
+const struct cpumask *clip_cpus, u32 capacitance,
+get_static_t plat_static_func)
+
+Similar to cpufreq_cooling_register, this function registers a cpufreq
+cooling device.  Using this function, the cooling device will
+implement the power extensions by using a simple cpu power model.  The
+cpus must have registered their OPPs using the OPP library.
+
+The additional parameters are needed for the power model (See 2. Power
+models).  "capacitance" is the dynamic power coefficient (See 2.1
+Dynamic power).  "plat_static_func" is a function to calculate the
+static power consumed by these cpus (See 2.2 Static power).
+
+1.1.3 struct thermal_cooling_device *of_cpufreq_power_cooling_register(
+struct device_node *np, const struct cpumask *clip_cpus, u32 capacitance,
+get_static_t plat_static_func)
+
+Similar to cpufreq_power_cooling_register, this function register a
+cpufreq cooling device with power extensions using the device tree
+information supplied by the np parameter.
+
+1.1.4 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 
 This interface function unregisters the "thermal-cpufreq-%x" cooling 
device.
 
 cdev: Cooling device pointer which has to be unregistered.
+
+2. Power models
+
+The power API registration functions provide a simple power model for
+CPUs.  The current power is calculated as dynamic + (optionally)
+static power.  This power model requires that the operating-points of
+the CPUs are registered using the kernel's opp library and the
+`cpufreq_frequency_table` is assigned to the `struct device` of the
+cpu.  If you are using the `cpufreq-cpu0.c` driver then the
+`cpufreq_frequency_table` should already be assigned to the cpu
+device.
+
+The `plat_static_func` parameter of `cpufreq_power_cooling_register()`
+and `of_cpufreq_power_cooling_register()` is optional.  If you don't
+provide it, only dynamic power will be considered.
+
+2.1 Dynamic power
+
+The dynamic power consumption of a processor depends on many factors.
+For a given processor implementation the primary factors are:
+
+- The time the processor spends running, consuming dynamic power, as
+  compared to the time in idle states where dynamic consumption is
+  negligible.  Herein we refer to this as 'utilisation'.
+- The voltage and frequency levels as a result of DVFS.  The DVFS
+  level is a dominant factor governing power consumption.
+- In running time the 'execution' behaviour (instruction types, memory
+  access patterns and so forth) causes, in most cases, a second order
+  variation.  In pathological cases this variation can be significant,
+  but typically it is of a much lesser impact than the factors above.
+
+A high level dynamic power consumption model may then be represented as:
+
+Pdyn = f(run) * Voltage^2 * Frequency * Utilisation
+
+f(run) here represents the described execution behaviour and its
+result has a units of Watts/Hz/Volt^2 (this often expressed in
+mW/MHz/uVolt^2)
+
+The detailed behaviour for f(run) could be modelled on-line.  However,
+in practice, such an on-line model has dependencies on a number of
+implementation specific processor support and characterisation
+factors.  Therefore, in initial implementation that contribution is
+represented as a constant coefficient.  This is a simplification
+consistent with the relative contribution to overall power variation.
+
+In this simplified representation our model becomes:
+
+Pdyn = Kd * Voltage^2 * Frequency * Utilisation
+
+Where Kd (capacitance) represents an indicative running time dynamic
+power coefficient in fundamental units of mW/MHz/uVolt^2
+
+2.2 Static power
+
+Static leakage power consumption depends on a number of factors.  For a
+given circuit implementation the primary factors are:
+
+- Time the circuit spends in each 'power state'
+- Temperature
+- 

[RFC PATCH v6 7/9] thermal: introduce the Power Allocator governor

[Javi Merino]

The power allocator governor is a thermal governor that controls system
and device power allocation to control temperature.  Conceptually, the
implementation divides the sustainable power of a thermal zone among
all the heat sources in that zone.

This governor relies on "power actors", entities that represent heat
sources.  They can report current and maximum power consumption and
can set a given maximum power consumption, usually via a cooling
device.

The governor uses a Proportional Integral Derivative (PID) controller
driven by the temperature of the thermal zone.  The output of the
controller is a power budget that is then allocated to each power
actor that can have bearing on the temperature we are trying to
control.  It decides how much power to give each cooling device based
on the performance they are requesting.  The PID controller ensures
that the total power budget does not exceed the control temperature.

Cc: Zhang Rui 
Cc: Eduardo Valentin 
Signed-off-by: Punit Agrawal 
Signed-off-by: Javi Merino 
---
 Documentation/thermal/power_allocator.txt | 196 
 drivers/thermal/Kconfig   |  15 +
 drivers/thermal/Makefile  |   1 +
 drivers/thermal/power_allocator.c | 511 ++
 drivers/thermal/thermal_core.c|   7 +-
 drivers/thermal/thermal_core.h|   8 +
 include/linux/thermal.h   |  40 ++-
 7 files changed, 774 insertions(+), 4 deletions(-)
 create mode 100644 drivers/thermal/power_allocator.c

diff --git a/Documentation/thermal/power_allocator.txt 
b/Documentation/thermal/power_allocator.txt
index d3bb79050c27..23b684afdc75 100644
--- a/Documentation/thermal/power_allocator.txt
+++ b/Documentation/thermal/power_allocator.txt
@@ -1,3 +1,172 @@
+Power allocator governor tunables
+=
+
+Trip points
+---
+
+The governor requires the following two passive trip points:
+
+1.  "switch on" trip point: temperature above which the governor
+control loop starts operating.
+2.  "desired temperature" trip point: it should be higher than the
+"switch on" trip point. It is the target temperature the governor
+is controlling for.
+
+PID Controller
+--
+
+The power allocator governor implements a
+Proportional-Integral-Derivative controller (PID controller) with
+temperature as the control input and power as the controlled output:
+
+P_max = k_p * e + k_i * err_integral + k_d * diff_err + sustainable_power
+
+where
+e = desired_temperature - current_temperature
+err_integral is the sum of previous errors
+diff_err = e - previous_error
+
+It is similar to the one depicted below:
+
+  k_d
+   |
+current_temp   |
+ | v
+ |+--+   +---+
+ | +->| diff_err |-->| X |--+
+ | |  +--+   +---+  |
+ | ||  tdpactor
+ | |  k_i   |   |get_actual_power()
+ | |   ||   || |
+ | |   ||   || | ...
+ v |   vv   vv v
+   +---+   |  +---+  +---++---+   +---+   +--+
+   | S |---+->| sum e |->| X |--->| S |-->| S |-->|power |
+   +---+   |  +---+  +---++---+   +---+   |allocation|
+ ^ |^ +--+
+ | ||| |
+ | |+---+   || |
+ | +--->| X |---+v v
+ |  +---+   granted performance
+desired_temperature   ^
+  |
+  |
+  k_po/k_pu
+
+Sustainable power
+-
+
+An estimate of the sustainable dissipatable power (in mW) should be
+provided while registering the thermal zone.  This estimates the
+sustained power that can be dissipated at the desired control
+temperature.  This is the maximum sustained power for allocation at
+the desired maximum temperature.  The actual sustained power can vary
+for a number of reasons.  The closed loop controller will take care of
+variations such as environmental conditions, and some factors related
+to the speed-grade of the silicon.  `sustainable_power` is therefore
+simply an estimate, and may be tuned to affect the aggressiveness of
+the thermal ramp.  For reference, this is 2000mW - 4500mW depending on
+screen size (4" phone - 10" tablet).
+
+If you are using device tree, do add it as a property of the
+thermal-zone.  For example:
+

[RFC PATCH v6 8/9] thermal: add trace events to the power allocator governor

[Javi Merino]

Add trace events for the power allocator governor and the power actor
interface of the cpu cooling device.

Cc: Zhang Rui 
Cc: Eduardo Valentin 
Cc: Steven Rostedt 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Signed-off-by: Javi Merino 
---
 drivers/thermal/cpu_cooling.c  |  26 -
 drivers/thermal/power_allocator.c  |  21 +++-
 include/trace/events/thermal_power_allocator.h | 138 +
 3 files changed, 182 insertions(+), 3 deletions(-)
 create mode 100644 include/trace/events/thermal_power_allocator.h

diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 335d95dd7e5a..f4d453429742 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 
+#include 
+
 /**
  * struct power_table - frequency to power conversion
  * @frequency: frequency in KHz
@@ -644,12 +646,20 @@ static int cpufreq_set_cur_state(struct 
thermal_cooling_device *cdev,
 static u32 cpufreq_get_actual_power(struct thermal_cooling_device *cdev)
 {
unsigned long freq;
-   int cpu;
+   int i = 0, cpu;
u32 static_power, dynamic_power, total_load = 0;
struct cpufreq_cooling_device *cpufreq_device = cdev->devdata;
+   u32 *load_cpu = NULL;
 
freq = cpufreq_quick_get(cpumask_any(_device->allowed_cpus));
 
+   if (trace_thermal_power_cpu_get_power_enabled()) {
+   u32 ncpus = cpumask_weight(_device->allowed_cpus);
+
+   load_cpu = devm_kcalloc(>device, ncpus, sizeof(*load_cpu),
+   GFP_KERNEL);
+   }
+
for_each_cpu(cpu, _device->allowed_cpus) {
u32 load;
 
@@ -659,6 +669,10 @@ static u32 cpufreq_get_actual_power(struct 
thermal_cooling_device *cdev)
load = 0;
 
total_load += load;
+   if (trace_thermal_power_cpu_limit_enabled() && load_cpu)
+   load_cpu[i] = load;
+
+   i++;
}
 
cpufreq_device->last_load = total_load;
@@ -666,6 +680,14 @@ static u32 cpufreq_get_actual_power(struct 
thermal_cooling_device *cdev)
static_power = get_static_power(cpufreq_device, freq);
dynamic_power = get_dynamic_power(cpufreq_device, freq);
 
+   if (trace_thermal_power_cpu_limit_enabled() && load_cpu) {
+   trace_thermal_power_cpu_get_power(
+   _device->allowed_cpus,
+   freq, load_cpu, i, dynamic_power, static_power);
+
+   devm_kfree(>device, load_cpu);
+   }
+
return static_power + dynamic_power;
 }
 
@@ -730,6 +752,8 @@ static unsigned long cpufreq_power2state(struct 
thermal_cooling_device *cdev,
return 0;
}
 
+   trace_thermal_power_cpu_limit(_device->allowed_cpus,
+   target_freq, cdev_state, power);
return cdev_state;
 }
 
diff --git a/drivers/thermal/power_allocator.c 
b/drivers/thermal/power_allocator.c
index 09e98991efbb..fa725a36872e 100644
--- a/drivers/thermal/power_allocator.c
+++ b/drivers/thermal/power_allocator.c
@@ -19,6 +19,9 @@
 #include 
 #include 
 
+#define CREATE_TRACE_POINTS
+#include 
+
 #include "thermal_core.h"
 
 #define FRAC_BITS 10
@@ -157,7 +160,14 @@ static u32 pid_controller(struct thermal_zone_device *tz,
/* feed-forward the known sustainable dissipatable power */
power_range = tz->tzp->sustainable_power + frac_to_int(power_range);
 
-   return clamp(power_range, (s64)0, (s64)max_allocatable_power);
+   power_range = clamp(power_range, (s64)0, (s64)max_allocatable_power);
+
+   trace_thermal_power_allocator_pid(frac_to_int(err),
+   frac_to_int(params->err_integral),
+   frac_to_int(p), frac_to_int(i),
+   frac_to_int(d), power_range);
+
+   return power_range;
 }
 
 /**
@@ -238,7 +248,7 @@ static int allocate_power(struct thermal_zone_device *tz,
struct thermal_instance *instance;
u32 *req_power, *max_power, *granted_power;
u32 total_req_power, max_allocatable_power;
-   u32 power_range;
+   u32 total_granted_power, power_range;
int i, num_actors, ret = 0;
 
mutex_lock(>lock);
@@ -301,6 +311,7 @@ static int allocate_power(struct thermal_zone_device *tz,
divvy_up_power(req_power, max_power, num_actors, total_req_power,
power_range, granted_power);
 
+   total_granted_power = 0;
i = 0;
list_for_each_entry(instance, >thermal_instances, tz_node) {
if (instance->trip != TRIP_MAX_DESIRED_TEMPERATURE)
@@ -310,10 +321,16 @@ static int allocate_power(struct thermal_zone_device *tz,
continue;
 
power_actor_set_power(instance->cdev, granted_power[i]);
+   total_granted_power += granted_power[i];
 

[RFC PATCH v6 5/9] thermal: extend the cooling device API to include power information

[Javi Merino]

Add three optional callbacks to the cooling device interface to allow
them to express power.  In addition to the callbacks, add helpers to
identify cooling devices that implement the power cooling device API.

Cc: Zhang Rui 
Cc: Eduardo Valentin 
Signed-off-by: Javi Merino 
---
 Documentation/thermal/power_allocator.txt | 27 ++
 drivers/thermal/thermal_core.c| 38 +++
 include/linux/thermal.h   | 12 ++
 3 files changed, 77 insertions(+)
 create mode 100644 Documentation/thermal/power_allocator.txt

diff --git a/Documentation/thermal/power_allocator.txt 
b/Documentation/thermal/power_allocator.txt
new file mode 100644
index ..d3bb79050c27
--- /dev/null
+++ b/Documentation/thermal/power_allocator.txt
@@ -0,0 +1,27 @@
+Cooling device power API
+
+
+Cooling devices controlled by this governor must supply the additional
+"power" API in their `cooling_device_ops`.  It consists on three ops:
+
+1. u32 get_actual_power(struct thermal_cooling_device *cdev);
+@cdev: The `struct thermal_cooling_device` pointer
+
+`get_actual_power()` returns the power currently consumed by the
+device in milliwatts.
+
+2. u32 state2power(struct thermal_cooling_device *cdev, unsigned long
+state);
+@cdev: The `struct thermal_cooling_device` pointer
+@state: A cooling device state
+
+Convert cooling device state @state into power consumption in
+milliwatts.
+
+3. unsigned long power2state(struct thermal_cooling_device *cdev,
+u32 power);
+@cdev: The `struct thermal_cooling_device` pointer
+@power: power in milliwatts
+
+Calculate a cooling device state that would make the device consume at
+most @power mW.
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 9021cb72a13a..c490f262ea7f 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -866,6 +866,44 @@ emul_temp_store(struct device *dev, struct 
device_attribute *attr,
 static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
 #endif/*CONFIG_THERMAL_EMULATION*/
 
+/**
+ * power_actor_get_max_power() - get the maximum power that a cdev can consume
+ * @cdev:  pointer to _cooling_device
+ *
+ * Calculate the maximum power consumption in milliwats that the
+ * cooling device can currently consume.  If @cdev doesn't support the
+ * power_actor API, this function returns 0.
+ */
+u32 power_actor_get_max_power(struct thermal_cooling_device *cdev)
+{
+   if (!cdev_is_power_actor(cdev))
+   return 0;
+
+   return cdev->ops->state2power(cdev, 0);
+}
+
+/**
+ * power_actor_set_power() - limit the maximum power that a cooling device can 
consume
+ * @cdev:  pointer to _cooling_device
+ * @power: the power in milliwatts
+ *
+ * Set the cooling device to consume at most @power milliwatts.
+ *
+ * Returns: 0 on success, -EINVAL if the cooling device does not
+ * implement the power actor API or -E* for other failures.
+ */
+int power_actor_set_power(struct thermal_cooling_device *cdev, u32 power)
+{
+   unsigned long state;
+
+   if (!cdev_is_power_actor(cdev))
+   return -EINVAL;
+
+   state = cdev->ops->power2state(cdev, power);
+
+   return cdev->ops->set_cur_state(cdev, state);
+}
+
 static DEVICE_ATTR(type, 0444, type_show, NULL);
 static DEVICE_ATTR(temp, 0444, temp_show, NULL);
 static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 2c14ab1f5c0d..1155457caf52 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -142,6 +142,9 @@ struct thermal_cooling_device_ops {
int (*get_max_state) (struct thermal_cooling_device *, unsigned long *);
int (*get_cur_state) (struct thermal_cooling_device *, unsigned long *);
int (*set_cur_state) (struct thermal_cooling_device *, unsigned long);
+   u32 (*get_actual_power) (struct thermal_cooling_device *);
+   u32 (*state2power) (struct thermal_cooling_device *, unsigned long);
+   unsigned long (*power2state) (struct thermal_cooling_device *, u32);
 };
 
 struct thermal_cooling_device {
@@ -322,6 +325,15 @@ void thermal_zone_of_sensor_unregister(struct device *dev,
 }
 
 #endif
+
+static inline bool cdev_is_power_actor(struct thermal_cooling_device *cdev)
+{
+   return cdev->ops->get_actual_power && cdev->ops->state2power &&
+   cdev->ops->power2state;
+}
+
+u32 power_actor_get_max_power(struct thermal_cooling_device *);
+int power_actor_set_power(struct thermal_cooling_device *, u32);
 struct thermal_zone_device *thermal_zone_device_register(const char *, int, 
int,
void *, struct thermal_zone_device_ops *,
const struct thermal_zone_params *, int, int);
-- 
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  

[RFC PATCH v6 1/9] tracing: Add array printing helpers

[Javi Merino]

From: Dave Martin 

If a trace event contains an array, there is currently no standard
way to format this for text output.  Drivers are currently hacking
around this by a) local hacks that use the trace_seq functionailty
directly, or b) just not printing that information.  For fixed size
arrays, formatting of the elements can be open-coded, but this gets
cumbersome for arrays of non-trivial size.

These approaches result in non-standard content of the event format
description delivered to userspace, so userland tools needs to be
taught to understand and parse each array printing method
individually.

This patch implements common __print__array() helpers that
tracepoint implementations can use instead of reinventing them.  A
simple C-style syntax is used to delimit the array and its elements
{like,this}.

So that the helpers can be used with large static arrays as well as
dynamic arrays, they take a pointer and element count: they can be
used with __get_dynamic_array() for use with dynamic arrays.

Cc: Steven Rostedt 
Cc: Ingo Molnar 
Signed-off-by: Dave Martin 
---
 include/linux/ftrace_event.h |  9 
 include/trace/ftrace.h   | 17 +++
 kernel/trace/trace_output.c  | 51 
 3 files changed, 77 insertions(+)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 28672e87e910..415afc53fa51 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -44,6 +44,15 @@ const char *ftrace_print_bitmask_seq(struct trace_seq *p, 
void *bitmask_ptr,
 const char *ftrace_print_hex_seq(struct trace_seq *p,
 const unsigned char *buf, int len);
 
+const char *ftrace_print_u8_array_seq(struct trace_seq *p,
+ const u8 *buf, int count);
+const char *ftrace_print_u16_array_seq(struct trace_seq *p,
+  const u16 *buf, int count);
+const char *ftrace_print_u32_array_seq(struct trace_seq *p,
+  const u32 *buf, int count);
+const char *ftrace_print_u64_array_seq(struct trace_seq *p,
+  const u64 *buf, int count);
+
 struct trace_iterator;
 struct trace_event;
 
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 26b4f2e13275..15bc5d417aea 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -263,6 +263,19 @@
 #undef __print_hex
 #define __print_hex(buf, buf_len) ftrace_print_hex_seq(p, buf, buf_len)
 
+#undef __print_u8_array
+#define __print_u8_array(array, count) \
+   ftrace_print_u8_array_seq(p, array, count)
+#undef __print_u16_array
+#define __print_u16_array(array, count)\
+   ftrace_print_u16_array_seq(p, array, count)
+#undef __print_u32_array
+#define __print_u32_array(array, count)\
+   ftrace_print_u32_array_seq(p, array, count)
+#undef __print_u64_array
+#define __print_u64_array(array, count)\
+   ftrace_print_u64_array_seq(p, array, count)
+
 #undef DECLARE_EVENT_CLASS
 #define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print) \
 static notrace enum print_line_t   \
@@ -676,6 +689,10 @@ static inline void ftrace_test_probe_##call(void)  
\
 #undef __get_dynamic_array_len
 #undef __get_str
 #undef __get_bitmask
+#undef __print_u8_array
+#undef __print_u16_array
+#undef __print_u32_array
+#undef __print_u64_array
 
 #undef TP_printk
 #define TP_printk(fmt, args...) "\"" fmt "\", "  __stringify(args)
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index c6977d5a9b12..4a6ee61f30b3 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -186,6 +186,57 @@ ftrace_print_hex_seq(struct trace_seq *p, const unsigned 
char *buf, int buf_len)
 }
 EXPORT_SYMBOL(ftrace_print_hex_seq);
 
+static const char *
+ftrace_print_array_seq(struct trace_seq *p, const void *buf, int buf_len,
+  bool (*iterator)(struct trace_seq *p, const char *prefix,
+   const void **buf, int *buf_len))
+{
+   const char *ret = trace_seq_buffer_ptr(p);
+   const char *prefix = "";
+
+   trace_seq_putc(p, '{');
+
+   while (iterator(p, prefix, , _len))
+   prefix = ",";
+
+   trace_seq_putc(p, '}');
+   trace_seq_putc(p, 0);
+
+   return ret;
+}
+
+#define DEFINE_PRINT_ARRAY(type, printk_type, format)  \
+static bool\
+ftrace_print_array_iterator_##type(struct trace_seq *p, const char *prefix, \
+  const void **buf, int *buf_len)  \
+{  \
+   const type *__src = *buf;   \
+

[RFC PATCH v6 4/9] thermal: let governors have private data for each thermal zone

[Javi Merino]

A governor may need to store its current state between calls to
throttle().  That state depends on the thermal zone, so store it as
private data in struct thermal_zone_device.

The governors may have two new ops: bind_to_tz() and unbind_from_tz().
When provided, these functions let governors do some initialization
and teardown when they are bound/unbound to a tz and possibly store that
information in the governor_data field of the struct
thermal_zone_device.

Cc: Zhang Rui 
Cc: Eduardo Valentin 
Signed-off-by: Javi Merino 
---
 drivers/thermal/thermal_core.c | 83 ++
 include/linux/thermal.h|  9 +
 2 files changed, 84 insertions(+), 8 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 43b90709585f..9021cb72a13a 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -75,6 +75,58 @@ static struct thermal_governor *__find_governor(const char 
*name)
return NULL;
 }
 
+/**
+ * bind_previous_governor() - bind the previous governor of the thermal zone
+ * @tz:a valid pointer to a struct thermal_zone_device
+ * @failed_gov_name:   the name of the governor that failed to register
+ *
+ * Register the previous governor of the thermal zone after a new
+ * governor has failed to be bound.
+ */
+static void bind_previous_governor(struct thermal_zone_device *tz,
+   const char *failed_gov_name)
+{
+   if (tz->governor && tz->governor->bind_to_tz) {
+   if (tz->governor->bind_to_tz(tz)) {
+   dev_err(>device,
+   "governor %s failed to bind and the previous 
one (%s) failed to bind again, thermal zone %s has no governor\n",
+   failed_gov_name, tz->governor->name, tz->type);
+   tz->governor = NULL;
+   }
+   }
+}
+
+/**
+ * thermal_set_governor() - Switch to another governor
+ * @tz:a valid pointer to a struct thermal_zone_device
+ * @new_gov:   pointer to the new governor
+ *
+ * Change the governor of thermal zone @tz.
+ *
+ * Return: 0 on success, an error if the new governor's bind_to_tz() failed.
+ */
+static int thermal_set_governor(struct thermal_zone_device *tz,
+   struct thermal_governor *new_gov)
+{
+   int ret = 0;
+
+   if (tz->governor && tz->governor->unbind_from_tz)
+   tz->governor->unbind_from_tz(tz);
+
+   if (new_gov && new_gov->bind_to_tz) {
+   ret = new_gov->bind_to_tz(tz);
+   if (ret) {
+   bind_previous_governor(tz, new_gov->name);
+
+   return ret;
+   }
+   }
+
+   tz->governor = new_gov;
+
+   return ret;
+}
+
 int thermal_register_governor(struct thermal_governor *governor)
 {
int err;
@@ -107,8 +159,15 @@ int thermal_register_governor(struct thermal_governor 
*governor)
 
name = pos->tzp->governor_name;
 
-   if (!strncasecmp(name, governor->name, THERMAL_NAME_LENGTH))
-   pos->governor = governor;
+   if (!strncasecmp(name, governor->name, THERMAL_NAME_LENGTH)) {
+   int ret;
+
+   ret = thermal_set_governor(pos, governor);
+   if (ret)
+   dev_err(>device,
+   "Failed to set governor %s for thermal 
zone %s: %d\n",
+   governor->name, pos->type, ret);
+   }
}
 
mutex_unlock(_list_lock);
@@ -134,7 +193,7 @@ void thermal_unregister_governor(struct thermal_governor 
*governor)
list_for_each_entry(pos, _tz_list, node) {
if (!strncasecmp(pos->governor->name, governor->name,
THERMAL_NAME_LENGTH))
-   pos->governor = NULL;
+   thermal_set_governor(pos, NULL);
}
 
mutex_unlock(_list_lock);
@@ -762,8 +821,9 @@ policy_store(struct device *dev, struct device_attribute 
*attr,
if (!gov)
goto exit;
 
-   tz->governor = gov;
-   ret = count;
+   ret = thermal_set_governor(tz, gov);
+   if (!ret)
+   ret = count;
 
 exit:
mutex_unlock(_governor_lock);
@@ -1459,6 +1519,7 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
int result;
int count;
int passive = 0;
+   struct thermal_governor *governor;
 
if (type && strlen(type) >= THERMAL_NAME_LENGTH)
return ERR_PTR(-EINVAL);
@@ -1549,9 +1610,15 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
mutex_lock(_governor_lock);
 
if (tz->tzp)
-   tz->governor = __find_governor(tz->tzp->governor_name);
+   governor = 

RE: [PATCH v2 3/5] usb: dwc2: Add generic PHY framework support for dwc2 usb controler platform driver.

[Paul Zimmerman]

> From: Yunzhi Li [mailto:l...@rock-chips.com]
> Sent: Friday, December 05, 2014 4:52 AM
> 
> Get PHY parameters from devicetree and power off usb PHY during
> system suspend.
> 
> Signed-off-by: Yunzhi Li 
> ---
> 
>  drivers/usb/dwc2/gadget.c   | 33 -
>  drivers/usb/dwc2/platform.c | 34 ++
>  2 files changed, 46 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 200168e..2601c61 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -3410,8 +3410,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
>  {
>   struct device *dev = hsotg->dev;
>   struct s3c_hsotg_plat *plat = dev->platform_data;
> - struct phy *phy;
> - struct usb_phy *uphy;
>   struct s3c_hsotg_ep *eps;
>   int epnum;
>   int ret;
> @@ -3421,30 +3419,23 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int 
> irq)
>   hsotg->phyif = GUSBCFG_PHYIF16;
> 
>   /*
> -  * Attempt to find a generic PHY, then look for an old style
> -  * USB PHY, finally fall back to pdata
> +  * If platform probe couldn't find a generic PHY or an old style
> +  * USB PHY, fall back to pdata
>*/
> - phy = devm_phy_get(dev, "usb2-phy");
> - if (IS_ERR(phy)) {
> - uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> - if (IS_ERR(uphy)) {
> - /* Fallback for pdata */
> - plat = dev_get_platdata(dev);
> - if (!plat) {
> - dev_err(dev,
> - "no platform data or transceiver defined\n");
> - return -EPROBE_DEFER;
> - }
> - hsotg->plat = plat;
> - } else
> - hsotg->uphy = uphy;
> - } else {
> - hsotg->phy = phy;
> + if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
> + plat = dev_get_platdata(dev);
> + if (!plat) {
> + dev_err(dev,
> + "no platform data or transceiver defined\n");
> + return -EPROBE_DEFER;
> + }
> + hsotg->plat = plat;
> + } else if (hsotg->phy) {

You have changed the behavior here. Previously, the driver would work
even if there were no phys or pdata defined. Now it will return
-EPROBE_DEFER instead. Are you sure that won't break any existing
platforms?

>   /*
>* If using the generic PHY framework, check if the PHY bus
>* width is 8-bit and set the phyif appropriately.
>*/
> - if (phy_get_bus_width(phy) == 8)
> + if (phy_get_bus_width(hsotg->phy) == 8)
>   hsotg->phyif = GUSBCFG_PHYIF8;
>   }
> 
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 6a795aa..739d14f 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -155,6 +155,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
>   struct dwc2_core_params defparams;
>   struct dwc2_hsotg *hsotg;
>   struct resource *res;
> + struct phy *phy;
> + struct usb_phy *uphy;
>   int retval;
>   int irq;
> 
> @@ -212,6 +214,24 @@ static int dwc2_driver_probe(struct platform_device *dev)
> 
>   hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
> 
> + /*
> +  * Attempt to find a generic PHY, then look for an old style
> +  * USB PHY
> +  */
> + phy = devm_phy_get(>dev, "usb2-phy");
> + if (IS_ERR(phy)) {
> + hsotg->phy = NULL;
> + uphy = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
> + if (IS_ERR(uphy))
> + hsotg->uphy = NULL;
> + else
> + hsotg->uphy = uphy;
> + } else {
> + hsotg->phy = phy;
> + phy_power_on(hsotg->phy);
> + phy_init(hsotg->phy);
> + }
> +
>   spin_lock_init(>lock);
>   mutex_init(>init_mutex);
>   retval = dwc2_gadget_init(hsotg, irq);
> @@ -233,6 +253,14 @@ static int __maybe_unused dwc2_suspend(struct device 
> *dev)
> 
>   if (dwc2_is_device_mode(dwc2))
>   ret = s3c_hsotg_suspend(dwc2);
> + else {

Kernel style says that both branches of the if() should have braces
here.

> + if (dwc2->lx_state == DWC2_L0)
> + return 0;
> + if (dwc2->phy) {
> + phy_exit(dwc2->phy);
> + phy_power_off(dwc2->phy);
> + }

Minor nit: no need to test dwc2->phy for NULL here, the phy functions
handle a NULL pointer just fine.

> + }
>   return ret;
>  }
> 
> @@ -243,6 +271,12 @@ static int __maybe_unused dwc2_resume(struct device *dev)
> 
>   if (dwc2_is_device_mode(dwc2))
>   ret = 

[RFC PATCH v6 0/9] The power allocator thermal governor

[Javi Merino]

Hi linux-pm,

The power allocator governor allocates device power to control
temperature.  This requires transforming performance requests into
requested power, which we do with an extended cooling device API
introduced in patch 5 (thermal: extend the cooling device API to
include power information).  Patch 6 (thermal: cpu_cooling: implement
the power cooling device API) extends the cpu cooling device using a
simple power model.  The division of power between the cooling devices
ensures that power is allocated where it is needed the most, based on
the current workload.

Patches 1-3 adds array printing helpers to ftrace, which we then use
in patch 8.

Changes since v5:
  - Addressed Stephen's review of the trace patches.
  - Removed power actors and extended the cooling device interface
instead.
  - Let platforms override the power allocator governor parameters in
their thermal zone parameters

Changes since v4:
  - Add more tracing
  - Document some of the limitations of the power allocator governor
  - Export the power_actor API and move power_actor.h to include/linux

Changes since v3:
  - Use tz->passive to poll faster when the first trip point is hit.
  - Don't make a special directory for power_actors
  - Add a DT property for sustainable-power
  - Simplify the static power interface and pass the current thermal
zone in every power_actor_ops to remove the controversial
enum power_actor_types
  - Use locks with the actor_list list
  - Use cpufreq_get() to get the frequency of the cpu instead of
using the notifiers.
  - Remove the prompt for THERMAL_POWER_ACTOR_CPU when configuring
the kernel

Changes since v2:
  - Changed the PI controller into a PID controller
  - Added static power to the cpu power model
  - tz parameter max_dissipatable_power renamed to sustainable_power
  - Register the cpufreq cooling device as part of the
power_cpu_actor registration.

Changes since v1:
  - Fixed finding cpufreq cooling devices in cpufreq_frequency_change()
  - Replaced the cooling device interface with a separate power actor
API
  - Addressed most of Eduardo's comments
  - Incorporated ftrace support for bitmask to trace cpumasks

Todo:
  - Expose thermal zone parameters in sysfs
  - Expose new governor parameters in device tree
  - Expose cooling device weights in device tree

Cheers,
Javi & Punit

Dave Martin (1):
  tracing: Add array printing helpers

Javi Merino (7):
  tools lib traceevent: Generalize numeric argument
  tools lib traceevent: Add support for __print_u{8,16,32,64}_array()
  thermal: let governors have private data for each thermal zone
  thermal: extend the cooling device API to include power information
  thermal: cpu_cooling: implement the power cooling device API
  thermal: introduce the Power Allocator governor
  thermal: add trace events to the power allocator governor

Punit Agrawal (1):
  of: thermal: Introduce sustainable power for a thermal zone

 .../devicetree/bindings/thermal/thermal.txt|   4 +
 Documentation/thermal/cpu-cooling-api.txt  | 144 +-
 Documentation/thermal/power_allocator.txt  | 223 +
 drivers/thermal/Kconfig|  15 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/cpu_cooling.c  | 455 +-
 drivers/thermal/of-thermal.c   |   4 +
 drivers/thermal/power_allocator.c  | 528 +
 drivers/thermal/thermal_core.c | 128 -
 drivers/thermal/thermal_core.h |   8 +
 include/linux/cpu_cooling.h|  49 +-
 include/linux/ftrace_event.h   |   9 +
 include/linux/thermal.h|  61 ++-
 include/trace/events/thermal_power_allocator.h | 138 ++
 include/trace/ftrace.h |  17 +
 kernel/trace/trace_output.c|  51 ++
 tools/lib/traceevent/event-parse.c |  88 +++-
 tools/lib/traceevent/event-parse.h |   8 +-
 18 files changed, 1886 insertions(+), 45 deletions(-)
 create mode 100644 Documentation/thermal/power_allocator.txt
 create mode 100644 drivers/thermal/power_allocator.c
 create mode 100644 include/trace/events/thermal_power_allocator.h

-- 
1.9.1


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

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

[Peter Maydell]

On 5 December 2014 at 18:44, Catalin Marinas  wrote:
> On Fri, Dec 05, 2014 at 05:27:02PM +, Russell King - ARM Linux wrote:
>> which makes the summary line rather misleading, and I really don't think
>> we need to do this on ARM for the simple reason that we've been doing it
>> for soo long that it can't be an issue.
>
> I started this as a revert and then realised that it doesn't solve
> anything for arm32 without changing the poisoning.
>
> Anyway, if you are happy with how it is, I'll drop the arm32 part. As I
> said yesterday, the issue is worse for arm64 with 64K pages.

If you do want to retain the arm32 "mustn't be in the 4K page of
the initrd tail" behaviour then it would probably be a good idea
to document this in the Booting spec.

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Bisected] linux-next 20141205 fails to mount ext4 fs on arm64 with CONFIG_ARM64_64K_PAGES=y

[Dmitry Monakhov]

Liviu Dudau  writes:

Yes. This is my crap.
- sbi->s_group_desc[group_desc]
+ gd_bh = *rcu_dereference(sbi->s_group_desc) + group_desc;

Ted I have to admit that I'm an idiot.
I already have fix where I've fixed the typo and complain from sparse
which was reported by kbuild01. In order to prevent similar shame in future 
I've wrote several
tests for resize2fs and unfortunately they are failed even w/o my
patches. It is appeared that resize2fs is broken for big disks.
So feel free to drop the patch, and give me some tome to investigate the
issues. I'll back with the patch-set in 24hrs.


> Hi Dmitry,
>
> I was testing linux-next for 20141205 today with CONFIG_ARM64_64K_PAGES=y
> when I've got the following in my kernel log when trying to mount the ext4
> filesystem that I'm using:
>
> hub 1-1:1.0: USB hub found
> hub 1-1:1.0: 4 ports detected
> usb 1-1.2: new high-speed USB device number 3 using ehci-platform
> usb-storage 1-1.2:1.0: USB Mass Storage device detected
> scsi host0: usb-storage 1-1.2:1.0
> atkbd serio0: keyboard reset failed on 1c06.kmi
> Waiting for root device /dev/sda3...
> usb 1-1.1: new low-speed USB device number 4 using ehci-platform
> input: USB Keyboard as 
> /devices/platform/7ffc.ehci/usb1/1-1/1-1.1/1-1.1:1.0/0003:0DC6:3910.0001/input/input2
> hid-generic 0003:0DC6:3910.0001: input: USB HID v1.00 Keyboard [USB Keyboard] 
> on usb-7ffc.ehci-1.1/input0
> input: USB Keyboard as 
> /devices/platform/7ffc.ehci/usb1/1-1/1-1.1/1-1.1:1.1/0003:0DC6:3910.0002/input/input3
> hid-generic 0003:0DC6:3910.0002: input: USB HID v1.00 Mouse [USB Keyboard] on 
> usb-7ffc.ehci-1.1/input1
> atkbd serio1: keyboard reset failed on 1c07.kmi
> scsi 0:0:0:0: Direct-Access Toshiba  StorE HDD PQ: 0 ANSI: 4
> sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 38 00 00 00
> sd 0:0:0:0: [sda] No Caching mode page found
> sd 0:0:0:0: [sda] Assuming drive cache: write through
>  sda: sda1 sda2 sda3
> sd 0:0:0:0: [sda] Attached SCSI disk
> EXT3-fs (sda3): error: couldn't mount because of unsupported optional 
> features (240)
> EXT2-fs (sda3): error: couldn't mount because of unsupported optional 
> features (240)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 128 failed 
> (15930!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 129 failed 
> (54075!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 130 failed 
> (42043!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 131 failed 
> (18746!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 132 failed 
> (19003!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 133 failed 
> (42810!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 134 failed 
> (53306!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 135 failed 
> (15675!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 136 failed 
> (54840!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 137 failed 
> (15161!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 138 failed 
> (19513!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 139 failed 
> (41272!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 140 failed 
> (41529!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 141 failed 
> (20280!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 142 failed 
> (14392!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 143 failed 
> (54585!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 144 failed 
> (44605!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 145 failed 
> (17212!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 146 failed 
> (13372!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 147 failed 
> (55613!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 148 failed 
> (55868!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 149 failed 
> (14141!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 150 failed 
> (16445!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 151 failed 
> (44348!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 152 failed 
> (17983!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 153 failed 
> (43838!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 154 failed 
> (56382!=0)
> EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 155 failed 
> (12607!=0)
> EXT4-fs (sda3): ext4_che

Re: using DMA-API on ARM

[Catalin Marinas]

On Fri, Dec 05, 2014 at 06:39:45PM +, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 09:22:22AM +, Arend van Spriel wrote:
> > For our brcm80211 development we are working on getting brcmfmac driver
> > up and running on a Broadcom ARM-based platform. The wireless device is
> > a PCIe device, which is hooked up to the system behind a PCIe host
> > bridge, and we transfer information between host and device using a
> > descriptor ring buffer allocated using dma_alloc_coherent(). We mostly
> > tested on x86 and seen no issue. However, on this ARM platform
> > (single-core A9) we detect occasionally that the descriptor content is
> > invalid. When this occurs we do a dma_sync_single_for_cpu() and this is
> > retried a number of times if the problem persists. Actually, found out
> > that someone made a mistake by using virt_to_dma(va) to get the
> > dma_handle parameter. So probably we only provided a delay in the retry
> > loop. After fixing that a single call to dma_sync_single_for_cpu() is
> > sufficient. The DMA-API-HOWTO clearly states that:
> 
> Does your system have an L2 cache? What's the SoC topology, can PCIe see
> such L2 cache (or snoop the L1 caches)?

BTW, if you really have a PL310-like L2 cache, have a look at some
patches (I've seen similar symptoms) and make sure your configuration is
correct:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6395/1

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6529/1

The first one is vexpress specific. The second one was eventually
discarded by Russell (I don't remember the reason, I guess it's because
SoC code is supposed to set the right bits in there anyway). In your
case, such bits may be set up by firmware, so Linux cannot fix anything
up.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] MIPS: set stack/data protection as non-executable

[Kees Cook]

On Fri, Dec 5, 2014 at 9:28 AM, David Daney  wrote:
> On 12/02/2014 05:58 PM, Leonid Yegoshin wrote:
>>
>> This is a last step of 3 patches which shift FPU emulation out of
>> stack into protected area. So, it disables a default executable stack.
>>
>> Additionally, it sets a default data area non-executable protection.
>>
>> Signed-off-by: Leonid Yegoshin 
>
>
> NAK!
>
> Some programs require an executable stack, this patch will break them.

Have you tested this?

> You can only select a non-executable stack in response to PT_GNU_STACK
> program headers in the ELF file of the executable program.

This is already handled by fs/binfmt_elf.c. It does the parsing of the
PT_GNU_STACK needs, and sets up the stack flags appropriately. All the
change to VM_DATA_DEFAULT_FLAGS does is make sure that EXSTACK_DEFAULT
now means no VM_EXEC by default. If PT_GNU_STACK requires it, it gets
added back in.

-Kees

>
> David Daney
>
>
>
>> ---
>>   arch/mips/include/asm/page.h |2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
>> index 3be81803595d..d49ba81cb4ed 100644
>> --- a/arch/mips/include/asm/page.h
>> +++ b/arch/mips/include/asm/page.h
>> @@ -230,7 +230,7 @@ extern int __virt_addr_valid(const volatile void
>> *kaddr);
>>   #define virt_addr_valid(kaddr)
>> \
>> __virt_addr_valid((const volatile void *) (kaddr))
>>
>> -#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | VM_EXEC | \
>> +#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | \
>>  VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
>>
>>   #define UNCAC_ADDR(addr)  ((addr) - PAGE_OFFSET + UNCAC_BASE)
>>
>>
>>
>>
>



-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] compiler: use compiler to detect integer overflows

[Linus Torvalds]

On Fri, Dec 5, 2014 at 1:54 AM, Dan Carpenter  wrote:
>
> There are some false positives which do:
>
> if ((u16)(u16_foo + u16_bar) < u16_foo) {

Actually, the worse false positive is the ones that are pointer comparisons.

A compiler that does those as signed is just broken. It's happened,
but it's *still* completely broken.

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

Re: frequent lockups in 3.18rc4

[Dave Jones]

On Fri, Dec 05, 2014 at 10:38:55AM -0800, Linus Torvalds wrote:
 > On Fri, Dec 5, 2014 at 9:15 AM, Dave Jones  wrote:
 > >
 > > A bisect later, and I landed on a kernel that ran for a day, before
 > > spewing NMI messages, recovering, and then..
 > >
 > > http://codemonkey.org.uk/junk/log.txt
 > 
 > I have to admit I'm seeing absolutely nothing sensible in there.
 > 
 > Call it bad, and see if bisection ends up slowly -oh so slowly -
 > pointing to some direction. Because I don't think it's the hardware,
 > considering that apparently 3.16 is solid. And the spews themselves
 > are so incomprehensible that I'm not seeing any pattern what-so-ever.

Will do.
In the meantime, I rebooted into the same kernel, and ran trinity
solely doing the lsetxattr syscalls. The load was a bit lower, so I
cranked up the number of child processes to 512, and then this
happened..

[ 1611.746960] [ cut here ]
[ 1611.747053] WARNING: CPU: 0 PID: 14810 at kernel/watchdog.c:265 
watchdog_overflow_callback+0xd5/0x120()
[ 1611.747083] Watchdog detected hard LOCKUP on cpu 0
[ 1611.747097] Modules linked in:
[ 1611.747112]  rfcomm hidp bnep scsi_transport_iscsi can_bcm nfnetlink can_raw 
nfc caif_socket caif af_802154 ieee802154 phonet af_rxrpc bluetooth can pppoe 
pppox ppp_generic slhc irda crc_ccitt rds rose x25 atm netrom appletalk ipx 
p8023 psnap p8022 llc ax25 cfg80211 rfkill coretemp hwmon x86_pkg_temp_thermal 
kvm_intel kvm e1000e crct10dif_pclmul crc32c_intel ghash_clmulni_intel 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
snd_hda_controller snd_hda_codec microcode serio_raw pcspkr snd_hwdep snd_seq 
snd_seq_device nfsd usb_debug snd_pcm ptp shpchp pps_core snd_timer snd 
soundcore auth_rpcgss oid_registry nfs_acl lockd sunrpc
[ 1611.747389] CPU: 0 PID: 14810 Comm: trinity-c304 Not tainted 3.16.0+ #114
[ 1611.747449]   7964733e 880244006be0 
8178fccb
[ 1611.747481]  880244006c28 880244006c18 81073ecd 

[ 1611.747512]   880244006d58 880244006ef8 

[ 1611.747544] Call Trace:
[ 1611.747555][] dump_stack+0x4e/0x7a
[ 1611.747582]  [] warn_slowpath_common+0x7d/0xa0
[ 1611.747604]  [] warn_slowpath_fmt+0x5c/0x80
[ 1611.747625]  [] ? restart_watchdog_hrtimer+0x50/0x50
[ 1611.747648]  [] watchdog_overflow_callback+0xd5/0x120
[ 1611.747673]  [] __perf_event_overflow+0xac/0x2a0
[ 1611.747696]  [] ? x86_perf_event_set_period+0xde/0x150
[ 1611.747720]  [] perf_event_overflow+0x14/0x20
[ 1611.747742]  [] intel_pmu_handle_irq+0x206/0x410
[ 1611.747764]  [] perf_event_nmi_handler+0x2b/0x50
[ 1611.747787]  [] nmi_handle+0xa3/0x1b0
[ 1611.747807]  [] ? nmi_handle+0x5/0x1b0
[ 1611.747827]  [] ? preempt_count_add+0x18/0xb0
[ 1611.748699]  [] default_do_nmi+0x72/0x1c0
[ 1611.749570]  [] do_nmi+0xb8/0xf0
[ 1611.750438]  [] end_repeat_nmi+0x1e/0x2e
[ 1611.751312]  [] ? preempt_count_add+0x18/0xb0
[ 1611.752177]  [] ? preempt_count_add+0x18/0xb0
[ 1611.753025]  [] ? preempt_count_add+0x18/0xb0
[ 1611.753861]  <>  [] is_module_text_address+0x17/0x50
[ 1611.754734]  [] __kernel_text_address+0x58/0x80
[ 1611.755575]  [] print_context_stack+0x8f/0x100
[ 1611.756410]  [] dump_trace+0x140/0x370
[ 1611.757242]  [] ? getname_flags+0x4f/0x1a0
[ 1611.758072]  [] ? getname_flags+0x4f/0x1a0
[ 1611.758895]  [] save_stack_trace+0x2b/0x50
[ 1611.759720]  [] set_track+0x70/0x140
[ 1611.760541]  [] alloc_debug_processing+0x92/0x118
[ 1611.761366]  [] __slab_alloc+0x45f/0x56f
[ 1611.762195]  [] ? getname_flags+0x4f/0x1a0
[ 1611.763024]  [] ? __slab_free+0x114/0x309
[ 1611.763853]  [] ? debug_check_no_obj_freed+0x17e/0x270
[ 1611.764712]  [] ? getname_flags+0x4f/0x1a0
[ 1611.765539]  [] kmem_cache_alloc+0x1f6/0x270
[ 1611.766364]  [] ? local_clock+0x25/0x30
[ 1611.767183]  [] getname_flags+0x4f/0x1a0
[ 1611.768004]  [] user_path_at_empty+0x45/0xc0
[ 1611.768827]  [] ? preempt_count_sub+0x6b/0xf0
[ 1611.769649]  [] ? put_lock_stats.isra.23+0xe/0x30
[ 1611.770470]  [] ? lock_release_holdtime.part.24+0x9d/0x160
[ 1611.771297]  [] ? mntput_no_expire+0x6d/0x160
[ 1611.772129]  [] user_path_at+0x11/0x20
[ 1611.772959]  [] SyS_lsetxattr+0x4b/0xf0
[ 1611.773783]  [] system_call_fastpath+0x16/0x1b
[ 1611.774631] ---[ end trace 5beef170ba6002cc ]---
[ 1611.775514] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 
28.493 msecs
[ 1611.776368] perf interrupt took too long (223592 > 2500), lowering 
kernel.perf_event_max_sample_rate to 5


I don't really know if that's indicative of anything useful, but it
at least might have been how we triggered the NMI in the previous run.

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/

[PATCH] i2c: designware: Fix falling time bindings doc

[Doug Anderson]

In (6468276 i2c: designware: make SCL and SDA falling time
configurable) new device tree properties were added for setting the
falling time of SDA and SCL.  The device tree bindings doc had a typo
in it: it forgot the "-ns" suffix for both properies in the prose of
the bindings.

I assume this is a typo because:
* The source code includes the "-ns"
* The example in the bindings includes the "-ns".

Fix the typo.

Signed-off-by: Doug Anderson 
Fixes: 6468276b2206 ("i2c: designware: make SCL and SDA falling time 
configurable")
---
 Documentation/devicetree/bindings/i2c/i2c-designware.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt 
b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
index 5199b0c..fee26dc 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
@@ -14,10 +14,10 @@ Optional properties :
  - i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds.
This option is only supported in hardware blocks version 1.11a or newer.
 
- - i2c-scl-falling-time : should contain the SCL falling time in nanoseconds.
+ - i2c-scl-falling-time-ns : should contain the SCL falling time in 
nanoseconds.
This value which is by default 300ns is used to compute the tLOW period.
 
- - i2c-sda-falling-time : should contain the SDA falling time in nanoseconds.
+ - i2c-sda-falling-time-ns : should contain the SDA falling time in 
nanoseconds.
This value which is by default 300ns is used to compute the tHIGH period.
 
 Example :
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2] arm:extend the reserved mrmory for initrd to be page aligned

[Catalin Marinas]

On Fri, Dec 05, 2014 at 05:27:02PM +, Russell King - ARM Linux wrote:
> On Fri, Dec 05, 2014 at 05:07:45PM +, Catalin Marinas wrote:
> > From 8e317c6be00abe280de4dcdd598d2e92009174b6 Mon Sep 17 00:00:00 2001
> > From: Catalin Marinas 
> > Date: Fri, 5 Dec 2014 16:41:52 +
> > Subject: [PATCH] Revert "ARM: 8167/1: extend the reserved memory for initrd 
> > to
> >  be page aligned"
> > 
> > This reverts commit 421520ba98290a73b35b7644e877a48f18e06004. There is
> > no guarantee that the boot-loader places other images like dtb in a
> > different page than initrd start/end. When this happens, such pages must
> > not be freed. The free_reserved_area() already takes care of rounding up
> > "start" and rounding down "end" to avoid freeing partially used pages.
> > 
> > In addition to the revert, this patch also removes the arm32
> > PAGE_ALIGN(end) when calculating the size of the memory to be poisoned.
> 
> which makes the summary line rather misleading, and I really don't think
> we need to do this on ARM for the simple reason that we've been doing it
> for soo long that it can't be an issue.

I started this as a revert and then realised that it doesn't solve
anything for arm32 without changing the poisoning.

Anyway, if you are happy with how it is, I'll drop the arm32 part. As I
said yesterday, the issue is worse for arm64 with 64K pages.

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

[PATCHv4 net] i40e: Implement ndo_gso_check()

[Joe Stringer]

ndo_gso_check() was recently introduced to allow NICs to report the
offloading support that they have on a per-skb basis. Add an
implementation for this driver which checks for IPIP, GRE, UDP tunnels.

Signed-off-by: Joe Stringer 
---
v4: Simplify the check to just do tunnel header length.
Fix #define style issue.
v3: Drop IPIP and GRE (no driver support even though hw supports it).
Check for UDP outer protocol for UDP tunnels.
v2: Expand to include IP in IP and IPv4/IPv6 inside GRE/UDP tunnels.
Add MAX_INNER_LENGTH (as 80).
---
 drivers/net/ethernet/intel/i40e/i40e_main.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c 
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index c3a7f4a..9eedfd15 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7447,6 +7447,17 @@ static int i40e_ndo_fdb_dump(struct sk_buff *skb,
 
 #endif /* USE_DEFAULT_FDB_DEL_DUMP */
 #endif /* HAVE_FDB_OPS */
+#define I40E_MAX_TUNNEL_HDR_LEN80
+static bool i40e_gso_check(struct sk_buff *skb, struct net_device *dev)
+{
+   if (skb->encapsulation &&
+   (skb_inner_mac_header(skb) - skb_transport_header(skb) >
+I40E_MAX_TUNNEL_HDR_LEN))
+   return false;
+
+   return true;
+}
+
 static const struct net_device_ops i40e_netdev_ops = {
.ndo_open   = i40e_open,
.ndo_stop   = i40e_close,
@@ -7487,6 +7498,7 @@ static const struct net_device_ops i40e_netdev_ops = {
.ndo_fdb_dump   = i40e_ndo_fdb_dump,
 #endif
 #endif
+   .ndo_gso_check  = i40e_gso_check,
 };
 
 /**
-- 
1.7.10.4

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

Re: using DMA-API on ARM

[Catalin Marinas]

On Fri, Dec 05, 2014 at 09:22:22AM +, Arend van Spriel wrote:
> For our brcm80211 development we are working on getting brcmfmac driver
> up and running on a Broadcom ARM-based platform. The wireless device is
> a PCIe device, which is hooked up to the system behind a PCIe host
> bridge, and we transfer information between host and device using a
> descriptor ring buffer allocated using dma_alloc_coherent(). We mostly
> tested on x86 and seen no issue. However, on this ARM platform
> (single-core A9) we detect occasionally that the descriptor content is
> invalid. When this occurs we do a dma_sync_single_for_cpu() and this is
> retried a number of times if the problem persists. Actually, found out
> that someone made a mistake by using virt_to_dma(va) to get the
> dma_handle parameter. So probably we only provided a delay in the retry
> loop. After fixing that a single call to dma_sync_single_for_cpu() is
> sufficient. The DMA-API-HOWTO clearly states that:

Does your system have an L2 cache? What's the SoC topology, can PCIe see
such L2 cache (or snoop the L1 caches)?

Also, are you certain that dma_alloc_coherent() ends up creating a
non-cacheable mapping in Linux (this call translates to a function
pointer call which may or may not create non-cacheable memory, depending
on the "dma-coherent" property passed via DT).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: frequent lockups in 3.18rc4

[Linus Torvalds]

On Fri, Dec 5, 2014 at 9:15 AM, Dave Jones  wrote:
>
> A bisect later, and I landed on a kernel that ran for a day, before
> spewing NMI messages, recovering, and then..
>
> http://codemonkey.org.uk/junk/log.txt

I have to admit I'm seeing absolutely nothing sensible in there.

Call it bad, and see if bisection ends up slowly -oh so slowly -
pointing to some direction. Because I don't think it's the hardware,
considering that apparently 3.16 is solid. And the spews themselves
are so incomprehensible that I'm not seeing any pattern what-so-ever.

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

Re: [PATCH] spi/pxa2xx: Clear cur_chip pointer before starting next message

[Robert Jarzmik]

Mika Westerberg  writes:

> On Thu, Dec 04, 2014 at 10:01:06PM +0100, Robert Jarzmik wrote:
>> So with your change, we have :
>>  drv_data->cur_chip = NULL;
>>  spi_finalize_current_message(drv_data->master);
>> 
>> In that case, if spi_finalize_current_message() queues another message, upon
>> this next message completion, won't giveback() be called, and dereference
>> cur_chip as well ?
>
> When the next message is started pxa2xx_spi_transfer_one_message() gets
> called and that will set cur_chip again.

Acked-by: Robert Jarzmik 

Cheers.

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

Re: [PATCH v7 1/2] spi: add support for DLN-2 USB-SPI adapter

[Mark Brown]

On Fri, Nov 28, 2014 at 03:09:58PM +0200, Laurentiu Palcu wrote:
> This adds support for Diolan DLN2 USB-SPI adapter.
> 
> Information about the USB protocol interface can be found in the
> Programmer's Reference Manual [1], see section 5.4.6 for the SPI
> master module commands and responses.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH v7] ASoC: dapm: add code to configure dai link parameters

[Mark Brown]

On Fri, Nov 28, 2014 at 05:01:41PM +, Nikesh Oswal wrote:

This doesn't apply cleanly against current code, it appears to have been
generated against Linus' tree rather than latest ASoC.

> index 7ba7130..db60701 100644
> --- a/include/sound/soc.h
> +++ b/include/sound/soc.h
> @@ -942,6 +942,7 @@ struct snd_soc_dai_link {
>   int be_id;  /* optional ID for machine driver BE identification */
>  
>   const struct snd_soc_pcm_stream *params;
> + unsigned int num_params;
>  
>   unsigned int dai_fmt;   /* format to set on init */
>  

Here we add num_params to the existing params; several existing drivers
use params but they've not been updated.

> +/* create new dapm dai link control */
> +static int dapm_new_dai_link(struct snd_soc_dapm_widget *w)
> +{
> + int i, ret;
> + struct snd_kcontrol *kcontrol;
> + struct snd_soc_dapm_context *dapm = w->dapm;
> + struct snd_card *card = dapm->card->snd_card;
> +
> + /* skip control creation for links with 1 config */
> + if (w->num_params == 1)
> + return 0;

Here we skip control creation if num_params is not 1.  This means we'll
try to create a control if num_params is zero which it will be for all
existing users.  This should actually work out fine due to the way loop
iteration works but this appears to be entirely by accident, it's not
obvious from the code.  Either num_params needs to become mandatory for
users and all existing users updated to provide it or the code should
explicitly cope with num_params being zero.

> @@ -3206,6 +3239,9 @@ static int snd_soc_dai_link_event(struct 
> snd_soc_dapm_widget *w,
>   source = source_p->source->priv;
>   sink = sink_p->sink->priv;
>  
> + /* Select the configuration set by alsa control */
> + config = [w->params_select];
> +

This is needlessly obscure.  We're first using config as shorthand for
the array of configuration options and then using it as the option we
selected.  It'd be better to change the initial dereference to also have
the array selection.

> + private_value =
> + (unsigned long) devm_kmemdup(card->dev,
> + (void *)(kcontrol_dai_link[0].private_value),
> + sizeof(struct soc_enum), GFP_KERNEL);

This doesn't resemble the Linux coding style very strongly; normally the
arguments of the function call would be indented with respect to the
line with the function name.

> +outfree_w:
> + kfree(w);
> +outfree_kcontrol_news:
> + kfree(template.kcontrol_news);
> +outfree_private_value:
> + kfree((void *)private_value);
> +outfree_link_name:
> + kfree(link_name);
> +outfree_w_param:
> + for (count = 0 ; count < num_params; count++)
> + kfree(w_param_text[count]);
> + kfree(w_param_text);

You're paring devm_ allocations with kfree(), that's going to break.
Managed allocations need managed frees.


signature.asc
Description: Digital signature

[Bisected] linux-next 20141205 fails to mount ext4 fs on arm64 with CONFIG_ARM64_64K_PAGES=y

[Liviu Dudau]

Hi Dmitry,

I was testing linux-next for 20141205 today with CONFIG_ARM64_64K_PAGES=y
when I've got the following in my kernel log when trying to mount the ext4
filesystem that I'm using:

hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1.2: new high-speed USB device number 3 using ehci-platform
usb-storage 1-1.2:1.0: USB Mass Storage device detected
scsi host0: usb-storage 1-1.2:1.0
atkbd serio0: keyboard reset failed on 1c06.kmi
Waiting for root device /dev/sda3...
usb 1-1.1: new low-speed USB device number 4 using ehci-platform
input: USB Keyboard as 
/devices/platform/7ffc.ehci/usb1/1-1/1-1.1/1-1.1:1.0/0003:0DC6:3910.0001/input/input2
hid-generic 0003:0DC6:3910.0001: input: USB HID v1.00 Keyboard [USB Keyboard] 
on usb-7ffc.ehci-1.1/input0
input: USB Keyboard as 
/devices/platform/7ffc.ehci/usb1/1-1/1-1.1/1-1.1:1.1/0003:0DC6:3910.0002/input/input3
hid-generic 0003:0DC6:3910.0002: input: USB HID v1.00 Mouse [USB Keyboard] on 
usb-7ffc.ehci-1.1/input1
atkbd serio1: keyboard reset failed on 1c07.kmi
scsi 0:0:0:0: Direct-Access Toshiba  StorE HDD PQ: 0 ANSI: 4
sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 38 00 00 00
sd 0:0:0:0: [sda] No Caching mode page found
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
EXT3-fs (sda3): error: couldn't mount because of unsupported optional features 
(240)
EXT2-fs (sda3): error: couldn't mount because of unsupported optional features 
(240)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 128 failed (15930!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 129 failed (54075!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 130 failed (42043!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 131 failed (18746!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 132 failed (19003!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 133 failed (42810!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 134 failed (53306!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 135 failed (15675!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 136 failed (54840!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 137 failed (15161!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 138 failed (19513!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 139 failed (41272!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 140 failed (41529!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 141 failed (20280!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 142 failed (14392!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 143 failed (54585!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 144 failed (44605!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 145 failed (17212!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 146 failed (13372!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 147 failed (55613!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 148 failed (55868!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 149 failed (14141!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 150 failed (16445!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 151 failed (44348!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 152 failed (17983!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 153 failed (43838!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 154 failed (56382!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 155 failed (12607!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 156 failed (12862!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 157 failed (57151!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 158 failed (43071!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 159 failed (17726!=0)
EXT4-fs (sda3): ext4_check_descriptors: Inode bitmap for group 160 not in group 
(block 89328390)!
EXT4-fs (sda3): group descriptors corrupted!
List of all partitions:
b300 1931264 mmcblk0  driver: mmcblk
  b301 1930240 mmcblk0p1 -01
0800   488386584 sda  driver: sd
  0801   125829120 sda1 -01
  0802 5242880 sda2 -02
  0803   357313560 sda3 -03
No filesystem could mount root, tried:  ext3 ext2 ext4 vfat fuseblk
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,3)
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc7-next-20141204+ #1

I've bisected the tree and I've got commit 
fdfe073987619ec375da8d8a2701ab271d1b1339
as the culprit:

This is my git bisect log:

git bisect start
# bad

Re: using DMA-API on ARM

[Catalin Marinas]

On Fri, Dec 05, 2014 at 06:24:43PM +, Russell King - ARM Linux wrote:
> On Fri, Dec 05, 2014 at 05:38:39PM +, Catalin Marinas wrote:
> > On Fri, Dec 05, 2014 at 11:11:14AM +, Russell King - ARM Linux wrote:
> > > In any case, wouldn't using a u64 type for "address" be better - isn't
> > > "long long" 128-bit on 64-bit architectures?
> > 
> > No, it's still 64-bit. There is no 128-bit integer in the C standard.
> 
> Actually, that's a fallicy.
> 
> The C99 standard (like previous versions) does not define exactly the
> number of bits in each type.  It defines ranks of type, and says that
> lower ranks are a subrange of integers with higher ranks (for the same
> signed-ness.)  See section 6.2.5.
> 
> So, it merely states that:
> 
> range(char) <= range(short) <= range(int) <= range(long) <= range(long long)

You are probably right, I haven't checked. But the ABI we use in Linux
for 64-bit, LP64, defines long long as 64-bit. Gcc has a int128_t type
but it's specific to this toolchain.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] dmaengine: Add driver for IMG MDC

[Andrew Bresticker]

Thanks for the review Vinod!

On Fri, Dec 5, 2014 at 9:35 AM, Vinod Koul  wrote:
> On Fri, Nov 14, 2014 at 01:59:43PM -0800, Andrew Bresticker wrote:
>> +static inline unsigned int to_mdc_width(enum dma_slave_buswidth bw)
>> +{
>> + switch (bw) {
>> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
>> + return 0;
>> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
>> + return 1;
>> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
>> + return 2;
>> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
>> + return 3;

> ffs()?

Ok.

>> + default:
>> + return 2;

> for slave cases default makes little sense, better to return error?

Sure.

>> + }
>> +}
>> +
>> +static void mdc_list_desc_config(struct mdc_chan *mchan,
>> +  struct mdc_hw_list_desc *ldesc,
>> +  enum dma_transfer_direction dir,
>> +  dma_addr_t src, dma_addr_t dst, size_t len)
>> +{
>> + struct mdc_dma *mdma = mchan->mdma;
>> + unsigned int max_burst, burst_size;
>> +
>> + ldesc->gen_conf = MDC_GENERAL_CONFIG_IEN | MDC_GENERAL_CONFIG_LIST_IEN 
>> |
>> + MDC_GENERAL_CONFIG_LEVEL_INT | MDC_GENERAL_CONFIG_PHYSICAL_W |
>> + MDC_GENERAL_CONFIG_PHYSICAL_R;
>> + ldesc->readport_conf =
>> + (mchan->thread << MDC_READ_PORT_CONFIG_STHREAD_SHIFT) |
>> + (mchan->thread << MDC_READ_PORT_CONFIG_RTHREAD_SHIFT) |
>> + (mchan->thread << MDC_READ_PORT_CONFIG_WTHREAD_SHIFT);
>> + ldesc->read_addr = src;
>> + ldesc->write_addr = dst;
>> + ldesc->xfer_size = len - 1;
>> + ldesc->node_addr = 0;
>> + ldesc->cmds_done = 0;
>> + ldesc->ctrl_status = MDC_CONTROL_AND_STATUS_LIST_EN |
>> + MDC_CONTROL_AND_STATUS_EN;
>> + ldesc->next_desc = NULL;
>> +
>> + if ((dst % mdma->bus_width == 0) && (src % mdma->bus_width == 0))
>> + max_burst = mdma->bus_width * mdma->max_burst_mult;
>> + else
>> + max_burst = mdma->bus_width * (mdma->max_burst_mult - 1);

> sounds like you should use something like ALIGN ?

Yup.

>> +
>> + if (dir == DMA_MEM_TO_DEV) {
>> + ldesc->gen_conf |= MDC_GENERAL_CONFIG_INC_R |
>> + ((fls(mdma->bus_width) - 1) <<

> bus_width calculation is repeated quite few times, would help readability if
> we hanlde this in macro.

Yes, will do.

> Also this be using src/dstn_addr_widths based on direction passed.

The above is setting the memory (not slave) bus width which is fixed
and not a per-slave property.

>> +  MDC_GENERAL_CONFIG_WIDTH_R_SHIFT) |
>> + (to_mdc_width(mchan->config.dst_addr_width) <<
>> +  MDC_GENERAL_CONFIG_WIDTH_W_SHIFT);

> and a macro for this calculation, which take args for different cases would
> help a lot!

Ok.

>> + ldesc->readport_conf |= MDC_READ_PORT_CONFIG_DREQ_ENABLE;
>> + burst_size = min(max_burst, mchan->config.dst_maxburst *
>> +  mchan->config.dst_addr_width);
>> + } else if (dir == DMA_DEV_TO_MEM) {
>> + ldesc->gen_conf |= MDC_GENERAL_CONFIG_INC_W |
>> + (to_mdc_width(mchan->config.src_addr_width) <<
>> +  MDC_GENERAL_CONFIG_WIDTH_R_SHIFT) |
>> + ((fls(mdma->bus_width) - 1) <<
>> +  MDC_GENERAL_CONFIG_WIDTH_W_SHIFT);
>> + ldesc->readport_conf |= MDC_READ_PORT_CONFIG_DREQ_ENABLE;
>> + burst_size = min(max_burst, mchan->config.src_maxburst *
>> +  mchan->config.src_addr_width);
>> + } else {

> DEV_TO_DEV too?

No, but it's not possible to have dir == DEV_TO_DEV here.  The callers
(mdc_prep_xxx) will check the direcioin.

>> + ldesc->gen_conf |= MDC_GENERAL_CONFIG_INC_R |
>> + MDC_GENERAL_CONFIG_INC_W |
>> + ((fls(mdma->bus_width) - 1) <<
>> +  MDC_GENERAL_CONFIG_WIDTH_R_SHIFT) |
>> + ((fls(mdma->bus_width) - 1) <<
>> +  MDC_GENERAL_CONFIG_WIDTH_W_SHIFT);
>> + burst_size = max_burst;

> btw this piece is very hard to read, please do improve upon

After adding a macro for setting the WIDTH_{R,W} fields it seems fine
to me.  Is there something else you had in mind?

>> +static struct dma_async_tx_descriptor *mdc_prep_dma_memcpy(
>> + struct dma_chan *chan, dma_addr_t dest, dma_addr_t src, size_t len,
>> + unsigned long flags)
>> +{
>> + struct mdc_chan *mchan = to_mdc_chan(chan);
>> + struct mdc_dma *mdma = mchan->mdma;
>> + struct mdc_tx_desc *mdesc;
>> + struct mdc_hw_list_desc *curr, *prev = NULL;
>> + dma_addr_t curr_phys, prev_phys;
>> +
>> + if (!len)
>> + return NULL;
>> +
>> + mdesc = kzalloc(sizeof(*mdesc), GFP_NOWAIT);
>> + if (!mdesc)
>> + return NULL;
>> + mdesc->chan = mchan;
>> +  

Re: using DMA-API on ARM

[Catalin Marinas]

On Fri, Dec 05, 2014 at 03:06:48PM +, Russell King - ARM Linux wrote:
> I've been doing more digging into the current DMA code, and I'm dismayed
> to see that there's new bugs in it...
> 
> commit 513510ddba9650fc7da456eefeb0ead7632324f6
> Author: Laura Abbott 
> Date:   Thu Oct 9 15:26:40 2014 -0700
> 
> common: dma-mapping: introduce common remapping functions
> 
> This uses map_vm_area() to achieve the remapping of pages allocated inside
> dma_alloc_coherent().  dma_alloc_coherent() is documented in a rather
> round-about way in Documentation/DMA-API.txt:
> 
> | Part Ia - Using large DMA-coherent buffers
> | --
> | 
> | void *
> | dma_alloc_coherent(struct device *dev, size_t size,
> |  dma_addr_t *dma_handle, gfp_t flag)
> | 
> | void
> | dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
> |dma_addr_t dma_handle)
> | 
> | Free a region of consistent memory you previously allocated.  dev,
> | size and dma_handle must all be the same as those passed into
> | dma_alloc_coherent().  cpu_addr must be the virtual address returned by
> | the dma_alloc_coherent().
> | 
> | Note that unlike their sibling allocation calls, these routines
> | may only be called with IRQs enabled.
> 
> Note that very last paragraph.  What this says is that it is explicitly
> permitted to call dma_alloc_coherent() with IRQs disabled.

This is solved by using a pre-allocated, pre-mapped atomic_pool which
avoids any further mapping. __dma_alloc() calls __alloc_from_pool() when
!__GFP_WAIT.

This code got pretty complex and we may find bugs. It can be simplified
by a pre-allocated non-cacheable region that is safe in atomic context
(how big you allocate this is hard to say).

> If the problem which you (Broadcom) are suffering from is down to the
> issue I suspect (that being having mappings with different cache
> attributes) then I'm not sure that there's anything we can realistically
> do about that.  There's a number of issues which make it hard to see a
> way forward.

I'm still puzzled by this problem, so I don't have any suggestion yet. I
wouldn't blame the mismatched attributes yet as I haven't seen such
problem in practice (but you never know).

How does the DT describe this device? Could it have some dma-coherent
property in there that causes dma_alloc_coherent() to create a cacheable
memory?

The reverse could also cause problems: the device is coherent but the
CPU creates a non-cacheable mapping.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: dts: rk3288: add arm,cpu-registers-not-fw-configured

[Olof Johansson]

On Tue, Nov 25, 2014 at 10:54:00AM -0800, Sonny Rao wrote:
> This will enable use of physical arch timers on rk3288, where each
> core comes out of reset with a different virtual offset.  Using
> physical timers will help with SMP booting on coreboot and older
> u-boot and should also allow suspend-resume and cpu-hotplug to work on
> all firmwares.
> 
> Firmware which does initialize the cpu registers properly at boot and
> cpu-hotplug can remove this property from the device tree.
> 
> Signed-off-by: Sonny Rao 
> ---
>  arch/arm/boot/dts/rk3288.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index 0f50d5d..c861f52 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -139,6 +139,7 @@
>  
>   timer {
>   compatible = "arm,armv7-timer";
> + arm,cpu-registers-not-fw-configured;
>   interrupts =  IRQ_TYPE_LEVEL_HIGH)>,
> IRQ_TYPE_LEVEL_HIGH)>,
> IRQ_TYPE_LEVEL_HIGH)>,

Applied, thanks.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: using DMA-API on ARM

[Russell King - ARM Linux]

On Fri, Dec 05, 2014 at 05:38:39PM +, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 11:11:14AM +, Russell King - ARM Linux wrote:
> > In any case, wouldn't using a u64 type for "address" be better - isn't
> > "long long" 128-bit on 64-bit architectures?
> 
> No, it's still 64-bit. There is no 128-bit integer in the C standard.

Actually, that's a fallicy.

The C99 standard (like previous versions) does not define exactly the
number of bits in each type.  It defines ranks of type, and says that
lower ranks are a subrange of integers with higher ranks (for the same
signed-ness.)  See section 6.2.5.

So, it merely states that:

range(char) <= range(short) <= range(int) <= range(long) <= range(long long)

So, an implementation could have:

char: 8  short: 16 int: 16 long: 32 long long: 64
char: 8  short: 16 int: 32 long: 32 long long: 64
char: 8  short: 16 int: 32 long: 64 long long: 64
char: 8  short: 16 int: 64 long: 64 long long: 64

or even:

char: 8  short: 16 int: 32 long: 64 long long: 128

and that would still be compliant with C99, since it continues to meet
the criteria about the required data types specified in the standard.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2] f2fs: call radix_tree_preload before radix_tree_insert

[Jaegeuk Kim]

Change log from v1:
 o remain GFP_ATOMIC for free_nid list due to its spin_lock

>From 769ec6e5b7d4a8115447736871be8bffaaba3a7d Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Wed, 3 Dec 2014 20:47:26 -0800
Subject: [PATCH] f2fs: call radix_tree_preload before radix_tree_insert

This patch tries to fix:

 BUG: using smp_processor_id() in preemptible [] code: f2fs_gc-254:0/384
  (radix_tree_node_alloc+0x14/0x74) from [] 
(radix_tree_insert+0x110/0x200)
  (radix_tree_insert+0x110/0x200) from [] 
(gc_data_segment+0x340/0x52c)
  (gc_data_segment+0x340/0x52c) from [] (f2fs_gc+0x208/0x400)
  (f2fs_gc+0x208/0x400) from [] (gc_thread_func+0x248/0x28c)
  (gc_thread_func+0x248/0x28c) from [] (kthread+0xa0/0xac)
  (kthread+0xa0/0xac) from [] (ret_from_fork+0x14/0x3c)

The reason is that f2fs calls radix_tree_insert under enabled preemption.
So, before calling it, we need to call radix_tree_preload.

Otherwise, we should use _GFP_WAIT for the radix tree, and use mutex or
semaphore to cover the radix tree operations.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/checkpoint.c |  8 
 fs/f2fs/gc.c |  6 ++
 fs/f2fs/node.c   | 11 +--
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 20a917b..6a81b73 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -304,6 +304,11 @@ static void __add_ino_entry(struct f2fs_sb_info *sbi, 
nid_t ino, int type)
struct inode_management *im = >im[type];
struct ino_entry *e;
 retry:
+   if (radix_tree_preload(GFP_NOFS)) {
+   cond_resched();
+   goto retry;
+   }
+
spin_lock(>ino_lock);
 
e = radix_tree_lookup(>ino_root, ino);
@@ -311,11 +316,13 @@ retry:
e = kmem_cache_alloc(ino_entry_slab, GFP_ATOMIC);
if (!e) {
spin_unlock(>ino_lock);
+   radix_tree_preload_end();
goto retry;
}
if (radix_tree_insert(>ino_root, ino, e)) {
spin_unlock(>ino_lock);
kmem_cache_free(ino_entry_slab, e);
+   radix_tree_preload_end();
goto retry;
}
memset(e, 0, sizeof(struct ino_entry));
@@ -326,6 +333,7 @@ retry:
im->ino_num++;
}
spin_unlock(>ino_lock);
+   radix_tree_preload_end();
 }
 
 static void __remove_ino_entry(struct f2fs_sb_info *sbi, nid_t ino, int type)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index a1af74f..2c58c58 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -351,7 +351,6 @@ static struct inode *find_gc_inode(struct gc_inode_list 
*gc_list, nid_t ino)
 static void add_gc_inode(struct gc_inode_list *gc_list, struct inode *inode)
 {
struct inode_entry *new_ie;
-   int ret;
 
if (inode == find_gc_inode(gc_list, inode->i_ino)) {
iput(inode);
@@ -361,8 +360,7 @@ retry:
new_ie = f2fs_kmem_cache_alloc(winode_slab, GFP_NOFS);
new_ie->inode = inode;
 
-   ret = radix_tree_insert(_list->iroot, inode->i_ino, new_ie);
-   if (ret) {
+   if (radix_tree_insert(_list->iroot, inode->i_ino, new_ie)) {
kmem_cache_free(winode_slab, new_ie);
goto retry;
}
@@ -703,7 +701,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi)
struct cp_control cpc;
struct gc_inode_list gc_list = {
.ilist = LIST_HEAD_INIT(gc_list.ilist),
-   .iroot = RADIX_TREE_INIT(GFP_ATOMIC),
+   .iroot = RADIX_TREE_INIT(GFP_NOFS),
};
 
cpc.reason = test_opt(sbi, FASTBOOT) ? CP_UMOUNT : CP_SYNC;
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index b47555f..8de4f55 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1447,15 +1447,22 @@ static int add_free_nid(struct f2fs_sb_info *sbi, nid_t 
nid, bool build)
i->nid = nid;
i->state = NID_NEW;
 
+   if (radix_tree_preload(GFP_NOFS)) {
+   kmem_cache_free(free_nid_slab, i);
+   return 0;
+   }
+
spin_lock(_i->free_nid_list_lock);
if (radix_tree_insert(_i->free_nid_root, i->nid, i)) {
spin_unlock(_i->free_nid_list_lock);
+   radix_tree_preload_end();
kmem_cache_free(free_nid_slab, i);
return 0;
}
list_add_tail(>list, _i->free_nid_list);
nm_i->fcnt++;
spin_unlock(_i->free_nid_list_lock);
+   radix_tree_preload_end();
return 1;
 }
 
@@ -1994,8 +2001,8 @@ static int init_node_manager(struct f2fs_sb_info *sbi)
 
INIT_RADIX_TREE(_i->free_nid_root, GFP_ATOMIC);
INIT_LIST_HEAD(_i->free_nid_list);
-   INIT_RADIX_TREE(_i->nat_root, GFP_ATOMIC);
-   INIT_RADIX_TREE(_i->nat_set_root, GFP_ATOMIC);
+   INIT_RADIX_TREE(_i->nat_root, GFP_NOIO);
+   INIT_RADIX_TREE(_i->nat_set_root, GFP_NOIO);

Re: [PATCH 1/3] f2fs: fix missing kmem_cache_free

[Jaegeuk Kim]

Hi Gu,

On Fri, Dec 05, 2014 at 11:34:49AM +0800, Gu Zheng wrote:
> Hi Jaegeuk, 
> On 12/05/2014 08:49 AM, Jaegeuk Kim wrote:
> 
> > This patch fixes missing kmem_cache_free when handling errors.
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/node.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index b1466cf..c59341d 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -158,7 +158,7 @@ retry:
> > head->entry_cnt = 0;
> >  
> > if (radix_tree_insert(_i->nat_set_root, set, head)) {
> > -   cond_resched();
> > +   kmem_cache_free(nat_entry_set_slab, head);
> 
> Why not reuse the allocated entry?
> This routine is under nat_tree_lock, so the free_old->research->alloc_new
> is needless, because no other ones can race with us.

IMO, this issue is quite different one that you're mentioning.
This patch just fixes a missing kfree.

> 
> > goto retry;
> 
> And radix_tree_insert can only fail -ENOMEM here, IMO, the in-time retry step
> makes very little sense here. How about retaining the "cond_resched()" and 
> retry
> insert later?

I think the following patches related to radix_tree_preload that I submitted
would address that.
But, still it seems that I need to review the retrial paths again.

Thanks,

> 
> If I misread something, please correct me.:)
> 
> Thanks,
> Gu
> 
> > }
> > }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: frequent lockups in 3.18rc4

[Linus Torvalds]

On Fri, Dec 5, 2014 at 7:03 AM, Sasha Levin  wrote:
>
> Yes, it's going to a serial line, but it's only about 100 lines/second on
> average. I wouldn't expect it to cause anything to hang!

A regular 16650 serial chip? Running at 115kbps, I assume? So that's
about 11kB/s.

And the serial console is polling, since it can't sleep or depend on interrupts.

At a average line length of what, 40 characters? At less than 300
lines/s, you'd be using up 100% of one CPU. And since the printouts
are serialized, that would be all other CPU's too..

100 lines/s _average_ means that I can easily see it be 300lines/s for a while.

So yeah. The serial console is simply not designed to handle
continuous output. It's for the "occasional" stuff.

The fact that your rcu lockups go away when you make the fault
injection be quiet makes me really suspect this is related.

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

Re: [PATCH linux-next] Documentation: Build mic/mpssd only for x86_64

[Ashutosh Dixit]

On Fri, Dec 05 2014 at 08:18:18 AM, Jonathan Corbet  wrote:
> On Thu,  4 Dec 2014 13:27:29 -0800
> Ashutosh Dixit  wrote:
>
>> mic/mpssd along with MIC drivers are currently only usable on
>> x86_64. So build mic/mpssd only for x86_64 to avoid build breaks on
>> big-endian systems.
>
> I can certainly apply this.  But it seems to me that this kind of code
> doesn't belong in the documentation directory.  How about a patch to move
> it to tools/ ?

Yes, let's resolve the situation for now and then we'll submit another
patch soon to move it to tools.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-next] Documentation: Build mic/mpssd only for x86_64

[Ashutosh Dixit]

On Fri, Dec 05 2014 at 08:18:18 AM, Jonathan Corbet  wrote:
> On Thu,  4 Dec 2014 13:27:29 -0800
> Ashutosh Dixit  wrote:
>
>> mic/mpssd along with MIC drivers are currently only usable on
>> x86_64. So build mic/mpssd only for x86_64 to avoid build breaks on
>> big-endian systems.
>
> I can certainly apply this.  But it seems to me that this kind of code
> doesn't belong in the documentation directory.  How about a patch to move
> it to tools/ ?

Yes, let's resolve the situation for now and then we'll submit another
patch soon to move it to tools.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kernfs_fop_write: Use GFP_ATOMIC instead of GFP_KERNEL.

[Greg Kroah-Hartman]

On Fri, Dec 05, 2014 at 09:07:07PM +0530, Anand Moon wrote:
> Use GFP_ATOMIC instead of GFP_KERNEL and update for kzalloc
> while we're here to fix this bug.
> 
> [   32.979662] [ cut here ]
> [   32.982865] WARNING: CPU: 3 PID: 1933 at kernel/locking/lockdep.c:2744 
> lockdep_trace_alloc+0xc0/0xfc()
> [   32.983409] _cpu_up: attempt to bring up CPU 6 failed
> [   32.997141] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> [   33.002511] Modules linked in:
> [   33.005697] CPU: 3 PID: 1933 Comm: systemd-udevd Not tainted 3.17.4-arm7 
> #11
> [   33.012783] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [   33.020492] [] (show_stack) from [] 
> (dump_stack+0x80/0xac)
> [   33.027679] [] (dump_stack) from [] 
> (warn_slowpath_common+0x60/0x84)
> [   33.035715] [] (warn_slowpath_common) from [] 
> (warn_slowpath_fmt+0x2c/0x3c)
> [   33.044408] [] (warn_slowpath_fmt) from [] 
> (lockdep_trace_alloc+0xc0/0xfc)
> [   33.052983] [] (lockdep_trace_alloc) from [] 
> (__kmalloc+0x50/0x1c0)
> [   33.060982] [] (__kmalloc) from [] 
> (kernfs_fop_write+0x44/0x154)
> [   33.068674] [] (kernfs_fop_write) from [] 
> (vfs_write+0xb8/0x170)
> [   33.076396] [] (vfs_write) from [] 
> (SyS_write+0x40/0x80)
> [   33.083392] [] (SyS_write) from [] 
> (ret_fast_syscall+0x0/0x48)
> [   33.090904] ---[ end trace 48da1fd0929e78f5 ]---
> [   33.095503] BUG: sleeping function called from invalid context at 
> mm/slub.c:1250
> [   33.102878] in_atomic(): 0, irqs_disabled(): 128, pid: 1933, name: 
> systemd-udevd
> [   33.110235] INFO: lockdep is turned off.
> [   33.114122] irq event stamp: 76128
> [   33.117484] hardirqs last  enabled at (76127): [] 
> _raw_spin_unlock_irq+0x24/0x44
> [   33.125723] hardirqs last disabled at (76128): [] 
> do_work_pending+0x6c/0xc4
> [   33.133532] softirqs last  enabled at (75542): [] 
> __do_softirq+0x1e8/0x270
> [   33.141244] softirqs last disabled at (75529): [] 
> irq_exit+0x84/0xf4
> [   33.148431] CPU: 3 PID: 1933 Comm: systemd-udevd Tainted: GW  
> 3.17.4-arm7 #11
> [   33.156626] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [   33.164334] [] (show_stack) from [] 
> (dump_stack+0x80/0xac)
> [   33.171523] [] (dump_stack) from [] 
> (__kmalloc+0x68/0x1c0)
> [   33.178719] [] (__kmalloc) from [] 
> (kernfs_fop_write+0x44/0x154)
> [   33.186432] [] (kernfs_fop_write) from [] 
> (vfs_write+0xb8/0x170)
> [   33.194147] [] (vfs_write) from [] 
> (SyS_write+0x40/0x80)
> [   33.201154] [] (SyS_write) from [] 
> (ret_fast_syscall+0x0/0x48)
> [   33.209634] _cpu_up: attempt to bring up CPU 5 failed
> [   33.213702] [ cut here ]

What sysfs file is being written to here in interrupt context?

> 
> Signed-off-by: Anand Moon 
> ---
>  fs/kernfs/file.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
> index 4429d6d..fa97883 100644
> --- a/fs/kernfs/file.c
> +++ b/fs/kernfs/file.c
> @@ -278,7 +278,7 @@ static ssize_t kernfs_fop_write(struct file *file, const 
> char __user *user_buf,
>   len = min_t(size_t, count, PAGE_SIZE);
>   }
>  
> - buf = kmalloc(len + 1, GFP_KERNEL);
> + buf = kzalloc(len + 1, GFP_ATOMIC);

kzalloc makes no sense as we copy right over the data right after this
in a copy_from_user() call.  Why change it?

And, the fact that we can sleep in copy_from_user(), makes this change
to GFP_ATOMIC really suspect.  We need to find the root cause here...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-next] Documentation: Build mic/mpssd only for x86_64

[Ashutosh Dixit]

On Thu, Dec 04 2014 at 07:27:06 PM, Dan Streetman  wrote:
> On Thu, Dec 4, 2014 at 4:27 PM, Ashutosh Dixit  
> wrote:
>> mic/mpssd along with MIC drivers are currently only usable on
>> x86_64. So build mic/mpssd only for x86_64 to avoid build breaks on
>> big-endian systems.
>
> Only building for x86_64 is fine, but in that case what's the point of
> leaving the htole16() et. al. functions in mpssd.c?  Shouldn't they be
> removed?

I am hoping that once glibc is fixed we can remove this limitation on
building only for x86_64, so I'd rather htole16() et. al. stayed.  As I
said earlier, I'm fine with your patch too, but restricting the build
for x86_64 seems to be the smallest patch which provides an acceptable
solution.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] optimize ktime_divns for constant divisors

[Nicolas Pitre]

BTW this is worth applying despite the on-going discussion with Arnd 
on a separate optimization.

On Wed, 3 Dec 2014, Nicolas Pitre wrote:

> At least on ARM, do_div() is optimized to turn constant divisors into
> an inline multiplication by the reciprocal value at compile time. 
> However this optimization is missed entirely whenever ktime_divns() is
> used and the slow out-of-line division code is used all the time.
> 
> Let ktime_divns() use do_div() inline whenever the divisor is constant
> and small enough.  This will make things like ktime_to_us() and 
> ktime_to_ms() much faster.
> 
> Signed-off-by: Nicolas Pitre 
> 
> diff --git a/include/linux/ktime.h b/include/linux/ktime.h
> index c9d645ad98..411dd8bfe5 100644
> --- a/include/linux/ktime.h
> +++ b/include/linux/ktime.h
> @@ -166,7 +166,17 @@ static inline bool ktime_before(const ktime_t cmp1, 
> const ktime_t cmp2)
>  }
>  
>  #if BITS_PER_LONG < 64
> -extern u64 ktime_divns(const ktime_t kt, s64 div);
> +extern u64 __ktime_divns(const ktime_t kt, s64 div);
> +static inline u64 ktime_divns(const ktime_t kt, s64 div)
> +{
> + if (__builtin_constant_p(div) && !(div >> 32)) {
> + u64 ns = kt.tv64;
> + do_div(ns, div);
> + return ns;
> + } else {
> + return __ktime_divns(kt, div);
> + }
> +}
>  #else /* BITS_PER_LONG < 64 */
>  # define ktime_divns(kt, div)(u64)((kt).tv64 / (div))
>  #endif
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index 37e50aadd4..890535c41c 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -266,7 +266,7 @@ lock_hrtimer_base(const struct hrtimer *timer, unsigned 
> long *flags)
>  /*
>   * Divide a ktime value by a nanosecond value
>   */
> -u64 ktime_divns(const ktime_t kt, s64 div)
> +u64 __ktime_divns(const ktime_t kt, s64 div)
>  {
>   u64 dclc;
>   int sft = 0;
> @@ -282,7 +282,7 @@ u64 ktime_divns(const ktime_t kt, s64 div)
>  
>   return dclc;
>  }
> -EXPORT_SYMBOL_GPL(ktime_divns);
> +EXPORT_SYMBOL_GPL(__ktime_divns);
>  #endif /* BITS_PER_LONG >= 64 */
>  
>  /*
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers/dma/pch_dma: declare pch_dma_id_table as static

[Vinod Koul]

On Tue, Dec 02, 2014 at 06:07:56PM +0100, Michele Curti wrote:
> pch_dma_id_table is used in pch_dma.c only, so declare
> it as static
Applied, thanks

-- 
~Vinod

> 
> Signed-off-by: Michele Curti 
> ---
>  drivers/dma/pch_dma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
> index 9f9ca9f..6e0e47d 100644
> --- a/drivers/dma/pch_dma.c
> +++ b/drivers/dma/pch_dma.c
> @@ -997,7 +997,7 @@ static void pch_dma_remove(struct pci_dev *pdev)
>  #define PCI_DEVICE_ID_ML7831_DMA1_8CH0x8810
>  #define PCI_DEVICE_ID_ML7831_DMA2_4CH0x8815
>  
> -const struct pci_device_id pch_dma_id_table[] = {
> +static const struct pci_device_id pch_dma_id_table[] = {
>   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_8CH), 8 },
>   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_EG20T_PCH_DMA_4CH), 4 },
>   { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_DMA1_8CH), 8}, /* UART Video */
> -- 
> 2.1.3
> 

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

Linux 3.12.34

[Jiri Slaby]

I'm announcing the release of the 3.12.34 kernel.

All users of the 3.12 kernel series must upgrade.

The updated 3.12.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.12.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary


The following changes since commit 0bbf78fb0ac62ef6f0970a49d7e0a1fb79d10dce:

  Linux 3.12.33 (2014-11-15 13:28:07 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jirislaby/linux-stable.git 
tags/v3.12.34

for you to fetch changes up to cbe6c8d6575ab39b78589f6083a842b6a9185295:

  Linux 3.12.34 (2014-12-03 12:07:28 +0100)


This is the 3.12.34 stable release


Al Viro (1):
  fix O_SYNC|O_APPEND syncing the wrong range on write()

Alex Deucher (2):
  drm/radeon: make sure mode init is complete in bandwidth_update
  drm/radeon: add missing crtc unlock when setting up the MC

Alexey Khoroshilov (1):
  ieee802154: fix error handling in ieee802154fake_probe()

Allen Pais (2):
  sunvdc: add cdrom and v1.1 protocol support
  sunvdc: compute vdisk geometry from capacity

Andreas Larsson (1):
  sparc32: Implement xchg and atomic_xchg using ATOMIC_HASH locks

Andreas Rohner (1):
  nilfs2: add missing blkdev_issue_flush() to nilfs_sync_fs()

Andrey Vagin (1):
  ipc: always handle a new value of auto_msgmni

Andy Lutomirski (1):
  x86, x32, audit: Fix x32's AUDIT_ARCH wrt audit

Arnd Bergmann (3):
  pcmcia: sa1100: H3100 and H3600 share a driver
  pcmcia: pxa2xx: fix logic for lubbock
  pcmcia: journada720: use sa1100 pin interfaces correctly

Ben Dooks (1):
  ARM: probes: fix instruction fetch order with 

Bjorn Helgaas (3):
  vmcore: Remove "weak" from function declarations
  kgdb: Remove "weak" from kgdb_arch_pc() declaration
  clocksource: Remove "weak" from clocksource_default_clock() declaration

Christoph Hellwig (1):
  scsi: only re-lock door after EH on devices that were reset

Cristian Stoica (1):
  crypto: caam - remove duplicated sg copy functions

Dan Carpenter (2):
  [media] usbvision-video: two use after frees
  drivers/vlynq/vlynq.c: fix another resource size off by 1 error

Daniel Borkmann (5):
  net: sctp: fix NULL pointer dereference in af->from_addr_param on 
malformed packet
  net: sctp: fix memory leak in auth key management
  net: sctp: fix remote memory pressure from excessive queueing
  net: sctp: fix panic on duplicate ASCONF chunks
  net: sctp: fix skb_over_panic when receiving malformed ASCONF chunks

David S. Miller (3):
  sparc64: Fix crashes in schizo_pcierr_intr_other().
  sparc64: Do irq_{enter,exit}() around generic_smp_call_function*().
  sparc64: Fix constraints on swab helpers.

Dmitry Eremin-Solenikov (1):
  Input: wm97xx - adapt parameters to tosa touchscreen.

Dmitry Torokhov (1):
  Input: evdev - fix EVIOCG{type} ioctl

Dwight Engen (3):
  sunvdc: limit each sg segment to a page
  vio: fix reuse of vio_dring slot
  sunvdc: don't call VD_OP_GET_VTOC

Emmanuel Grumbach (1):
  iwlwifi: configure the LTR

Ezequiel Garcia (1):
  parport: Add support for the WCH353 1S/1P multi-IO card

Fabian Frederick (1):
  fs/jfs/jfs_inode.c: atomically set inode->i_flags

Florian Westphal (2):
  netfilter: nf_log: account for size of NLMSG_DONE attribute
  netfilter: nfnetlink_log: fix maximum packet length logged to userspace

Greg Kurz (1):
  hwrng: pseries - port to new read API and fix stack corruption

Heinz Mauelshagen (1):
  dm raid: ensure superblock's size matches device's logical block size

Helge Deller (1):
  parisc: Use compat layer for msgctl, shmat, shmctl and semtimedop syscalls

Herbert Xu (2):
  tun: Fix csum_start with VLAN acceleration
  macvtap: Fix csum_start when VLAN tags are present

Houcheng Lin (1):
  netfilter: nf_log: release skbuff on nlmsg put failure

Ilya Dryomov (1):
  libceph: do not crash on large auth tickets

James Ralston (1):
  ahci: Add Device IDs for Intel Sunrise Point PCH

Jammy Zhou (1):
  drm/radeon: set correct CE ram size for CIK

Jan Kara (2):
  block: Fix computation of merged request priority
  nfs: Fix use of uninitialized variable in nfs_getattr()

Jiri Bohac (1):
  ipx: fix locking regression in ipx_sendmsg and ipx_recvmsg

Jiri Slaby (1):
  Linux 3.12.34

Joe Schultz (2):
  vme_tsi148: Fix PCI address mapping assumption
  vme_tsi148: Fix typo in tsi148_slave_get()

Joe Thornber (2):
  dm thin: grab a virtual cell before looking up the mapping
  dm btree: fix a recursion depth bug in btree walking code

Re: [PATCH 6/6] UBI: Fastmap: Make ubi_refill_pools() fair

[Tanya Brokhman]

Hi Richard,

On 11/24/2014 3:20 PM, Richard Weinberger wrote:

Currently ubi_refill_pools() first fills the first and then
the second one.
If only very few free PEBs are available the second pool can get
zero PEBs.
Change ubi_refill_pools() to distribute free PEBs fair between
all pools.

Signed-off-by: Richard Weinberger 
---
  drivers/mtd/ubi/wl.c | 77 +++-
  1 file changed, 40 insertions(+), 37 deletions(-)

diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index f028b68..c2822f7 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -583,59 +583,62 @@ static void return_unused_pool_pebs(struct ubi_device 
*ubi,
  }

  /**
- * refill_wl_pool - refills all the fastmap pool used by the
- * WL sub-system.
+ * ubi_refill_pools - refills all fastmap PEB pools.
   * @ubi: UBI device description object
   */
-static void refill_wl_pool(struct ubi_device *ubi)
+void ubi_refill_pools(struct ubi_device *ubi)
  {
+   struct ubi_fm_pool *wl_pool = >fm_wl_pool;
+   struct ubi_fm_pool *pool = >fm_pool;
struct ubi_wl_entry *e;
-   struct ubi_fm_pool *pool = >fm_wl_pool;
+   int enough;

+   spin_lock(>wl_lock);
+
+   return_unused_pool_pebs(ubi, wl_pool);
return_unused_pool_pebs(ubi, pool);

-   for (pool->size = 0; pool->size < pool->max_size; pool->size++) {
-   if (!ubi->free.rb_node ||
-  (ubi->free_count - ubi->beb_rsvd_pebs < 5))
-   break;
+   wl_pool->size = 0;
+   pool->size = 0;

-   e = find_wl_entry(ubi, >free, WL_FREE_MAX_DIFF);
-   self_check_in_wl_tree(ubi, e, >free);
-   rb_erase(>u.rb, >free);
-   ubi->free_count--;
+   for (;;) {


You loop for max(pool->max_size, wl_pool->max_size) itterations. IMO, 
the code will be more clear if you use for(i=0; imax_size, 
wl_pool->max_size); i++) instead of "int enough".
This is just coding style preference of course. I personally don't like 
for(;;) that much Just a suggestion. :)



+   enough = 0;
+   if (pool->size < pool->max_size) {
+   if (!ubi->free.rb_node ||
+  (ubi->free_count - ubi->beb_rsvd_pebs < 5))
+   break;

-   pool->pebs[pool->size] = e->pnum;
-   }
-   pool->used = 0;
-}
+   e = wl_get_wle(ubi);
+   if (!e)
+   break;

-/**
- * refill_wl_user_pool - refills all the fastmap pool used by ubi_wl_get_peb.
- * @ubi: UBI device description object
- */
-static void refill_wl_user_pool(struct ubi_device *ubi)
-{
-   struct ubi_fm_pool *pool = >fm_pool;
+   pool->pebs[pool->size] = e->pnum;
+   pool->size++;
+   } else
+   enough++;

-   return_unused_pool_pebs(ubi, pool);
+   if (wl_pool->size < wl_pool->max_size) {
+   if (!ubi->free.rb_node ||
+  (ubi->free_count - ubi->beb_rsvd_pebs < 5))
+   break;

-   for (pool->size = 0; pool->size < pool->max_size; pool->size++) {
-   pool->pebs[pool->size] = __wl_get_peb(ubi);
-   if (pool->pebs[pool->size] < 0)
+   e = find_wl_entry(ubi, >free, WL_FREE_MAX_DIFF);
+   self_check_in_wl_tree(ubi, e, >free);
+   rb_erase(>u.rb, >free);
+   ubi->free_count--;


why don't you use wl_get_peb() here?

Other then that - I agree with the patch. So if you want to keep it as 
is, I'll add Reviewed-by.



+
+   wl_pool->pebs[wl_pool->size] = e->pnum;
+   wl_pool->size++;
+   } else
+   enough++;
+
+   if (enough == 2)
break;
}
+
+   wl_pool->used = 0;
pool->used = 0;
-}

-/**
- * ubi_refill_pools - refills all fastmap PEB pools.
- * @ubi: UBI device description object
- */
-void ubi_refill_pools(struct ubi_device *ubi)
-{
-   spin_lock(>wl_lock);
-   refill_wl_pool(ubi);
-   refill_wl_user_pool(ubi);
spin_unlock(>wl_lock);
  }





Thanks,
Tanya Brokhman
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv5 2/3] kernel: add support for live patching

[Jiri Slaby]

On 12/04/2014, 04:53 PM, Seth Jennings wrote:
...
> --- /dev/null
> +++ b/kernel/livepatch/core.c
> @@ -0,0 +1,902 @@
...
> +static struct kobj_type klp_ktype_patch = {
> + .sysfs_ops = _sysfs_ops,
> + .default_attrs = klp_patch_attrs
> +};

Hi, I seem to have only a single comment here. If I am looking
correctly, the last put on this kobject will cause kobject_cleanup to
generate a warning:
   "kobject: '%s' (%p): does not have a release() "
   "function, it is broken and must be fixed.\n",

There should be some .release. IMO, this is a place where we will
release the module with the patch. So the .release hook should contain
something like a commented out module_put() with a pointer to
klp_register_patch. (Or be empty at worst.)

thanks,
-- 
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v2] arm:extend the reserved mrmory for initrd to be page aligned

[Peter Maydell]

On 5 December 2014 at 17:27, Russell King - ARM Linux
 wrote:
> On Fri, Dec 05, 2014 at 05:07:45PM +, Catalin Marinas wrote:
>> On Fri, Dec 05, 2014 at 12:05:06PM +, Will Deacon wrote:
>> > Care to submit this as a proper patch? We should at least fix Peter's issue
>> > before doing things like extending headers, which won't work for older
>> > kernels anyway.
>>
>> Quick fix is the revert of the whole patch, together with removing
>> PAGE_ALIGN(end) in poison_init_mem() on arm32. If Russell is ok with
>> this patch, we can take it via the arm64 tree, otherwise I'll send you a
>> partial revert only for the arm64 part.
>
> Not really.  Let's look at the history.
>
> For years, we've been poisoning memory, page aligning the end pointer.
> This has never been an issue.

Depends what you mean by "never been an issue". I had to change
QEMU (commit 98ed805c, January 2013) for 32-bit ARM back when the
kernel started trashing the tail end of the page after the initrd
with the poisoning, to 4K-align the dtb so it didn't share a page
with the initrd-tail. That nobody else complained suggests that most
bootloaders don't in practice overlap the two, though (ie that
QEMU is an outlier in how it chooses to arrange things in memory).

I should probably have reported the breakage at the time, but
I took the pragmatic (lazy?) approach of just changing our
bootloader code.

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: dts: am57xx-beagle-x15: Add GPIO controlled fan node

[Nishanth Menon]

TPS gpio now controls a 5v 500mA TL5209 regulator which may be supply
a fan (such as AFB02505HHB) over J1 connector for various purposes.
Provide device tree node to enable the same.

Signed-off-by: Nishanth Menon 
---

V2: review comment updates
review comments update
- Sanitized outlook-ified name back to normal ;) 
- removed unnecessary pinctrl-names property.
V1: https://patchwork.kernel.org/patch/5444911/


Depends on the following:
https://patchwork.kernel.org/patch/5439201/
https://patchwork.kernel.org/patch/5439191/

enable and disable can be controlled by (post the RPM, it finds
closest match - even a 1 will do)

echo '13000' > /sys/class/hwmon/hwmon0/fan1_target
and
echo '0' > /sys/class/hwmon/hwmon0/fan1_target

Test log: http://slexy.org/view/s2T0ajh46z

requires CONFIG_GPIO_PALMAS and CONFIG_SENSORS_GPIO_FAN to be operational
Applies on 
https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.19/dt-v2

 arch/arm/boot/dts/am57xx-beagle-x15.dts |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda..4e55e94 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -80,6 +80,14 @@
default-state = "off";
};
};
+
+   gpio_fan {
+   /* Based on 5v 500mA AFB02505HHB */
+   compatible = "gpio-fan";
+   gpios =  <_gpio 1 GPIO_ACTIVE_HIGH>;
+   gpio-fan,speed-map = <00
+ 13000 1>;
+   };
 };
 
 _pmx_core {
@@ -314,6 +322,12 @@
wakeup-source;
ti,palmas-long-press-seconds = <12>;
};
+
+   tps659038_gpio: tps659038_gpio {
+   compatible = "ti,palmas-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
};
 
tmp102: tmp102@48 {
-- 
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 5/6] UBI: Split __wl_get_peb()

[Tanya Brokhman]

On 11/24/2014 3:20 PM, Richard Weinberger wrote:

Make it two functions, wl_get_wle() and wl_get_peb().
wl_get_peb() works exactly like __wl_get_peb() but wl_get_wle()
does not call produce_free_peb().
While refilling the fastmap user pool we cannot release ubi->wl_lock
as produce_free_peb() does.
Hence the fastmap logic uses now wl_get_wle().


hmmm... confused... I don't see fastmap code changed



Signed-off-by: Richard Weinberger 
---
  drivers/mtd/ubi/wl.c | 61 
  1 file changed, 38 insertions(+), 23 deletions(-)

diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 7730b97..f028b68 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -499,13 +499,46 @@ out:
  #endif

  /**
- * __wl_get_peb - get a physical eraseblock.
+ * wl_get_wle - get a mean wl entry to be used by wl_get_peb() or
+ * refill_wl_user_pool().
+ * @ubi: UBI device description object
+ *
+ * This function returns a a wear leveling entry in case of success and


If you upload a new version, you have a double "a" here: "returns a a 
wear leveling"



+ * NULL in case of failure.
+ */
+static struct ubi_wl_entry *wl_get_wle(struct ubi_device *ubi)
+{
+   struct ubi_wl_entry *e;
+
+   e = find_mean_wl_entry(ubi, >free);
+   if (!e) {
+   ubi_err(ubi, "no free eraseblocks");
+   return NULL;
+   }
+
+   self_check_in_wl_tree(ubi, e, >free);
+
+   /*
+* Move the physical eraseblock to the protection queue where it will
+* be protected from being moved for some time.
+*/


I don't think this comment is valid anymore


+   rb_erase(>u.rb, >free);
+   ubi->free_count--;
+   dbg_wl("PEB %d EC %d", e->pnum, e->ec);
+
+   return e;
+}
+
+/**
+ * wl_get_peb - get a physical eraseblock.
   * @ubi: UBI device description object
   *
   * This function returns a physical eraseblock in case of success and a
   * negative error code in case of failure.
+ * It is the low level component of ubi_wl_get_peb() in the non-fastmap
+ * case.
   */
-static int __wl_get_peb(struct ubi_device *ubi)
+static int wl_get_peb(struct ubi_device *ubi)
  {
int err;
struct ubi_wl_entry *e;
@@ -524,27 +557,9 @@ retry:
goto retry;
}

-   e = find_mean_wl_entry(ubi, >free);
-   if (!e) {
-   ubi_err(ubi, "no free eraseblocks");
-   return -ENOSPC;
-   }
-
-   self_check_in_wl_tree(ubi, e, >free);
-
-   /*
-* Move the physical eraseblock to the protection queue where it will
-* be protected from being moved for some time.
-*/
-   rb_erase(>u.rb, >free);
-   ubi->free_count--;
-   dbg_wl("PEB %d EC %d", e->pnum, e->ec);
-#ifndef CONFIG_MTD_UBI_FASTMAP
-   /* We have to enqueue e only if fastmap is disabled,
-* is fastmap enabled prot_queue_add() will be called by
-* ubi_wl_get_peb() after removing e from the pool. */
+   e = wl_get_wle(ubi);
prot_queue_add(ubi, e);
-#endif
+
return e->pnum;
  }

@@ -704,7 +719,7 @@ int ubi_wl_get_peb(struct ubi_device *ubi)
int peb, err;

spin_lock(>wl_lock);
-   peb = __wl_get_peb(ubi);
+   peb = wl_get_peb(ubi);
spin_unlock(>wl_lock);

if (peb < 0)




Thanks,
Tanya Brokhman
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] CMA: add the amount of cma memory in meminfo

[Michal Nazarewicz]

On Thu, Dec 04 2014, Xishi Qiu  wrote:
> Add the amount of cma memory in the following meminfo.
> /proc/meminfo
> /sys/devices/system/node/nodeXX/meminfo
>
> Signed-off-by: Xishi Qiu 

No second look:

Acked-by: Michal Nazarewicz 

> ---
>  drivers/base/node.c | 16 ++--
>  fs/proc/meminfo.c   | 12 +---
>  2 files changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/base/node.c b/drivers/base/node.c
> index 472168c..a27e4e0 100644
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -120,6 +120,9 @@ static ssize_t node_read_meminfo(struct device *dev,
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  "Node %d AnonHugePages:  %8lu kB\n"
>  #endif
> +#ifdef CONFIG_CMA
> +"Node %d FreeCMAPages:   %8lu kB\n"
> +#endif
>   ,
>  nid, K(node_page_state(nid, NR_FILE_DIRTY)),
>  nid, K(node_page_state(nid, NR_WRITEBACK)),
> @@ -136,14 +139,15 @@ static ssize_t node_read_meminfo(struct device *dev,
>  nid, K(node_page_state(nid, NR_SLAB_RECLAIMABLE) +
>   node_page_state(nid, NR_SLAB_UNRECLAIMABLE)),
>  nid, K(node_page_state(nid, NR_SLAB_RECLAIMABLE)),
> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  nid, K(node_page_state(nid, NR_SLAB_UNRECLAIMABLE))
> - , nid,
> - K(node_page_state(nid, NR_ANON_TRANSPARENT_HUGEPAGES) *
> - HPAGE_PMD_NR));
> -#else
> -nid, K(node_page_state(nid, NR_SLAB_UNRECLAIMABLE)));
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +, nid, K(node_page_state(nid,
> + NR_ANON_TRANSPARENT_HUGEPAGES) * HPAGE_PMD_NR)
> +#endif
> +#ifdef CONFIG_CMA
> +, nid, K(node_page_state(nid, NR_FREE_CMA_PAGES))
>  #endif
> + );
>   n += hugetlb_report_node_meminfo(nid, buf + n);
>   return n;
>  }
> diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
> index aa1eee0..d42e082 100644
> --- a/fs/proc/meminfo.c
> +++ b/fs/proc/meminfo.c
> @@ -138,6 +138,9 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>   "AnonHugePages:  %8lu kB\n"
>  #endif
> +#ifdef CONFIG_CMA
> + "FreeCMAPages:   %8lu kB\n"
> +#endif
>   ,
>   K(i.totalram),
>   K(i.freeram),
> @@ -187,11 +190,14 @@ static int meminfo_proc_show(struct seq_file *m, void 
> *v)
>   vmi.used >> 10,
>   vmi.largest_chunk >> 10
>  #ifdef CONFIG_MEMORY_FAILURE
> - ,atomic_long_read(_poisoned_pages) << (PAGE_SHIFT - 10)
> + , atomic_long_read(_poisoned_pages) << (PAGE_SHIFT - 10)
>  #endif
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> - ,K(global_page_state(NR_ANON_TRANSPARENT_HUGEPAGES) *
> -HPAGE_PMD_NR)
> + , K(global_page_state(NR_ANON_TRANSPARENT_HUGEPAGES) *
> + HPAGE_PMD_NR)
> +#endif
> +#ifdef CONFIG_CMA
> + , K(global_page_state(NR_FREE_CMA_PAGES))
>  #endif
>   );
>  
> -- 
> 2.0.0
>
>

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] DMA: Fix allocation size for PL330 data buffer depth.

[Vinod Koul]

On Fri, Nov 14, 2014 at 12:33:01PM +, Liviu Dudau wrote:
> On Wed, Nov 12, 2014 at 09:39:52AM +, Vinod Koul wrote:
> > On Thu, Nov 06, 2014 at 05:20:12PM +, Liviu Dudau wrote:
> > > The datasheet for PL330 says that the data buffer value in the CRD
> > > register is 10bits wide. However, the value stored is "minus one",
> > > which the driver corrects for. Maximum value that the data buffer
> > > depth can have is 1024 lines, which requires 11 bits for storage.
> > > 
> > > While making updates I found printing the peripheral ID as a hex
> > > value to be more useful as the datasheet shows the values that way.
> > 
> > Applied, thanks
> 
> Thanks!
> 
> > 
> > Please snure you use the right subsytem name
> 
> Sorry about that. Just for clarity, it should've been 'dmaengine', right?
Yes...

-- 
~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: [alsa-devel][PATCH v3] ASoC: wm8960: Let wm8960 codec driver manage its own MCLK

[Mark Brown]

On Fri, Dec 05, 2014 at 05:01:56PM +, Charles Keepax wrote:
> On Thu, Dec 04, 2014 at 08:41:19PM +0800, Zidan Wang wrote:

> >  struct wm8960_data {
> > +   struct clk *mclk;

> Is this really pdata? Would the pdata entry to locate the clock
> not be a string holding the clock name that you call clk_get on,
> rather than a clk pointer itself? Probably this should go in
> wm8960_priv instead.

There should be no platform data of any kind for the clock, the name
should be fixed and defined in terms of the name of the clock on the
device requesting it.  The code is actually doing the right thing here,
it's just that it's put the variable into the platform data because
currently the driver just uses the platform data as the driver data.


signature.asc
Description: Digital signature

Re: [PATCH v5 34/61] dmaengine: omap: Split device_control

[Vinod Koul]

On Fri, Dec 05, 2014 at 06:07:44PM +0100, Maxime Ripard wrote:
> On Fri, Dec 05, 2014 at 08:26:42PM +0530, Vinod Koul wrote:
> > On Fri, Dec 05, 2014 at 03:33:59PM +0100, Maxime Ripard wrote:
> Ah, right.
> 
> I have no idea why it haven't been picked up by intel's build bot
> thuough.
possibly no defconfig enables this

> 
> Anyway. Do you want me to send a new version of these patches for this
> trivial fix and the mxs one, or do you want me to send a follow-up?
I am halfway thru series, if I dont find anything serious I will fix it up and
push over the weekend

-- 
~Vinod
> 
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com



-- 


signature.asc
Description: Digital signature

Re: using DMA-API on ARM

[Catalin Marinas]

On Fri, Dec 05, 2014 at 11:11:14AM +, Russell King - ARM Linux wrote:
> In any case, wouldn't using a u64 type for "address" be better - isn't
> "long long" 128-bit on 64-bit architectures?

No, it's still 64-bit. There is no 128-bit integer in the C standard.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/7] pinctrl: qcom-spmi-gpio: Migrate to pinconf-generic

[Sören Brinkmann]

On Fri, 2014-12-05 at 09:08AM -0800, Sören Brinkmann wrote:
> On Fri, 2014-12-05 at 09:59AM +0200, Ivan T. Ivanov wrote:
> > 
> > On Thu, 2014-11-27 at 17:26 -0800, Soren Brinkmann wrote:
> > > 
> > >  static const struct pinconf_ops pmic_gpio_pinconf_ops = {
> > > +   .is_generic= true,
> > > .pin_config_group_get= pmic_gpio_config_get,
> > > .pin_config_group_set= pmic_gpio_config_set,
> > > .pin_config_group_dbg_show= pmic_gpio_config_dbg_show,
> > > @@ -848,6 +742,9 @@ static int pmic_gpio_probe(struct platform_device 
> > > *pdev)
> > > pctrldesc->name = dev_name(dev);
> > > pctrldesc->pins = pindesc;
> > > pctrldesc->npins = npins;
> > > +   pctrldesc->num_dt_params = ARRAY_SIZE(pmic_gpio_bindings);
> > > +   pctrldesc->params = pmic_gpio_bindings;
> > > +   pctrldesc->conf_items = pmic_conf_items;
> > > 
> > 
> > What will happen if number of conf_items is less than number of params?
> 
> I suppose bad things :) You're right, that should probably be checked
> somewhere. Let me see whether I find a good place to put such a check.

Looking at it, it's not that straight forward. We only pass one size to
the core, so the core cannot really check that the number of entries in
both arrays are equal. And passing the size of both looks a little
redundant to me.
That would put the driver in charge of making sure these arrays are
aligned.

With the change given below, it would at least trigger a compiler
warning. I'll add that to the next iteration of this series.
Longer term, merging those arrays, as you suggested, may be a better
solution.

Thanks,
Sören

-8<-8<---8<8<---
diff --git a/drivers/pinctrl/pinctrl-zynq.c b/drivers/pinctrl/pinctrl-zynq.c
index 29b75134771f..5942af4c2e67 100644
--- a/drivers/pinctrl/pinctrl-zynq.c
+++ b/drivers/pinctrl/pinctrl-zynq.c
@@ -924,7 +924,7 @@ static const struct pinconf_generic_dt_params 
zynq_dt_params[] = {
{ "io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18},
 };
 
-static const struct pin_config_item zynq_conf_items[] = {
+static const struct pin_config_item 
zynq_conf_items[ARRAY_SIZE(zynq_dt_params)] = {
PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL, true),
 };
 
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c 
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index c612aaa653d5..17f811c9c2c0 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -136,7 +136,7 @@ static const struct pinconf_generic_dt_params 
pmic_gpio_bindings[] = {
{"qcom,drive-strength", PMIC_GPIO_CONF_STRENGTH,0},
 };
 
-static const struct pin_config_item pmic_conf_items[] = {
+static const struct pin_config_item 
pmic_conf_items[ARRAY_SIZE(pmic_gpio_bindings)] = {
PCONFDUMP(PMIC_GPIO_CONF_PULL_UP,  "pull up strength", NULL, true),
PCONFDUMP(PMIC_GPIO_CONF_STRENGTH, "drive-strength", NULL, true),
 };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: dts: am57xx-beagle-x15: Add GPIO controlled fan node

[Felipe Balbi]

On Fri, Dec 05, 2014 at 11:32:18AM -0600, Nishanth Menon wrote:
> From: "Menon, Nishanth" 

do you want to sanitize your name ?

> TPS gpio now controls a 5v 500mA TL5209 regulator which may be supply
> a fan (such as AFB02505HHB) over J1 connector for various purposes.
> Provide device tree node to enable the same.
> 
> Signed-off-by: Nishanth Menon 
> ---
> Depends on the following:
> https://patchwork.kernel.org/patch/5439201/
> https://patchwork.kernel.org/patch/5439191/
> 
> enable and disable can be controlled by
> echo '1' > /sys/class/hwmon/hwmon0/fan1_target
> and
> echo '0' > /sys/class/hwmon/hwmon0/fan1_target
> 
> requires CONFIG_GPIO_PALMAS and CONFIG_SENSORS_GPIO_FAN to be operational
> Applies on 
> https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.19/dt-v2
> 
>  arch/arm/boot/dts/am57xx-beagle-x15.dts |   15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 49edbda..7fe82ef 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -80,6 +80,15 @@
>   default-state = "off";
>   };
>   };
> +
> + gpio_fan {
> + /* Based on 5v 500mA AFB02505HHB */
> + compatible = "gpio-fan";
> + pinctrl-names = "default";

not needed.

> + gpios =  <_gpio 1 GPIO_ACTIVE_HIGH>;
> + gpio-fan,speed-map = <00
> +   13000 1>;
> + };
>  };
>  
>  _pmx_core {
> @@ -314,6 +323,12 @@
>   wakeup-source;
>   ti,palmas-long-press-seconds = <12>;
>   };
> +
> + tps659038_gpio: tps659038_gpio {
> + compatible = "ti,palmas-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
>   };
>  
>   tmp102: tmp102@48 {
> -- 
> 1.7.9.5
> 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH V2 2/2] dmaengine: Add driver for IMG MDC

[Vinod Koul]

On Fri, Nov 14, 2014 at 01:59:43PM -0800, Andrew Bresticker wrote:
> +static inline unsigned int to_mdc_width(enum dma_slave_buswidth bw)
> +{
> + switch (bw) {
> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
> + return 0;
> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
> + return 1;
> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
> + return 2;
> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
> + return 3;
ffs()?

> + default:
> + return 2;
for slave cases default makes little sense, better to return error?

> + }
> +}
> +
> +static void mdc_list_desc_config(struct mdc_chan *mchan,
> +  struct mdc_hw_list_desc *ldesc,
> +  enum dma_transfer_direction dir,
> +  dma_addr_t src, dma_addr_t dst, size_t len)
> +{
> + struct mdc_dma *mdma = mchan->mdma;
> + unsigned int max_burst, burst_size;
> +
> + ldesc->gen_conf = MDC_GENERAL_CONFIG_IEN | MDC_GENERAL_CONFIG_LIST_IEN |
> + MDC_GENERAL_CONFIG_LEVEL_INT | MDC_GENERAL_CONFIG_PHYSICAL_W |
> + MDC_GENERAL_CONFIG_PHYSICAL_R;
> + ldesc->readport_conf =
> + (mchan->thread << MDC_READ_PORT_CONFIG_STHREAD_SHIFT) |
> + (mchan->thread << MDC_READ_PORT_CONFIG_RTHREAD_SHIFT) |
> + (mchan->thread << MDC_READ_PORT_CONFIG_WTHREAD_SHIFT);
> + ldesc->read_addr = src;
> + ldesc->write_addr = dst;
> + ldesc->xfer_size = len - 1;
> + ldesc->node_addr = 0;
> + ldesc->cmds_done = 0;
> + ldesc->ctrl_status = MDC_CONTROL_AND_STATUS_LIST_EN |
> + MDC_CONTROL_AND_STATUS_EN;
> + ldesc->next_desc = NULL;
> +
> + if ((dst % mdma->bus_width == 0) && (src % mdma->bus_width == 0))
> + max_burst = mdma->bus_width * mdma->max_burst_mult;
> + else
> + max_burst = mdma->bus_width * (mdma->max_burst_mult - 1);
sounds like you should use something like ALIGN ?

> +
> + if (dir == DMA_MEM_TO_DEV) {
> + ldesc->gen_conf |= MDC_GENERAL_CONFIG_INC_R |
> + ((fls(mdma->bus_width) - 1) <<
bus_width calculation is repeated quite few times, would help readability if
we hanlde this in macro. Also this be using src/dstn_addr_widths based on
direction passed

> +  MDC_GENERAL_CONFIG_WIDTH_R_SHIFT) |
> + (to_mdc_width(mchan->config.dst_addr_width) <<
> +  MDC_GENERAL_CONFIG_WIDTH_W_SHIFT);
and a macro for this calculation, which take args for different cases would
help a lot!
> + ldesc->readport_conf |= MDC_READ_PORT_CONFIG_DREQ_ENABLE;
> + burst_size = min(max_burst, mchan->config.dst_maxburst *
> +  mchan->config.dst_addr_width);
> + } else if (dir == DMA_DEV_TO_MEM) {
> + ldesc->gen_conf |= MDC_GENERAL_CONFIG_INC_W |
> + (to_mdc_width(mchan->config.src_addr_width) <<
> +  MDC_GENERAL_CONFIG_WIDTH_R_SHIFT) |
> + ((fls(mdma->bus_width) - 1) <<
> +  MDC_GENERAL_CONFIG_WIDTH_W_SHIFT);
> + ldesc->readport_conf |= MDC_READ_PORT_CONFIG_DREQ_ENABLE;
> + burst_size = min(max_burst, mchan->config.src_maxburst *
> +  mchan->config.src_addr_width);
> + } else {
DEV_TO_DEV too?
> + ldesc->gen_conf |= MDC_GENERAL_CONFIG_INC_R |
> + MDC_GENERAL_CONFIG_INC_W |
> + ((fls(mdma->bus_width) - 1) <<
> +  MDC_GENERAL_CONFIG_WIDTH_R_SHIFT) |
> + ((fls(mdma->bus_width) - 1) <<
> +  MDC_GENERAL_CONFIG_WIDTH_W_SHIFT);
> + burst_size = max_burst;
btw this piece is very hard to read, please do improve upon

> +static struct dma_async_tx_descriptor *mdc_prep_dma_memcpy(
> + struct dma_chan *chan, dma_addr_t dest, dma_addr_t src, size_t len,
> + unsigned long flags)
> +{
> + struct mdc_chan *mchan = to_mdc_chan(chan);
> + struct mdc_dma *mdma = mchan->mdma;
> + struct mdc_tx_desc *mdesc;
> + struct mdc_hw_list_desc *curr, *prev = NULL;
> + dma_addr_t curr_phys, prev_phys;
> +
> + if (!len)
> + return NULL;
> +
> + mdesc = kzalloc(sizeof(*mdesc), GFP_NOWAIT);
> + if (!mdesc)
> + return NULL;
> + mdesc->chan = mchan;
> + mdesc->list_xfer_size = len;
> +
> + while (len > 0) {
> + size_t xfer_size;
> +
> + curr = dma_pool_alloc(mdma->desc_pool, GFP_NOWAIT, _phys);
> + if (!curr)
> + goto free_desc;
> +
> + if (prev) {
> + prev->node_addr = curr_phys;
> + prev->next_desc = curr;
> + } else {
> + mdesc->list_phys = curr_phys;
> + mdesc->list = curr;
> + }
> +
> + xfer_size = min_t(size_t, 

[PATCH] ARM: dts: am57xx-beagle-x15: Add GPIO controlled fan node

[Nishanth Menon]

From: "Menon, Nishanth" 

TPS gpio now controls a 5v 500mA TL5209 regulator which may be supply
a fan (such as AFB02505HHB) over J1 connector for various purposes.
Provide device tree node to enable the same.

Signed-off-by: Nishanth Menon 
---
Depends on the following:
https://patchwork.kernel.org/patch/5439201/
https://patchwork.kernel.org/patch/5439191/

enable and disable can be controlled by
echo '1' > /sys/class/hwmon/hwmon0/fan1_target
and
echo '0' > /sys/class/hwmon/hwmon0/fan1_target

requires CONFIG_GPIO_PALMAS and CONFIG_SENSORS_GPIO_FAN to be operational
Applies on 
https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.19/dt-v2

 arch/arm/boot/dts/am57xx-beagle-x15.dts |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda..7fe82ef 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -80,6 +80,15 @@
default-state = "off";
};
};
+
+   gpio_fan {
+   /* Based on 5v 500mA AFB02505HHB */
+   compatible = "gpio-fan";
+   pinctrl-names = "default";
+   gpios =  <_gpio 1 GPIO_ACTIVE_HIGH>;
+   gpio-fan,speed-map = <00
+ 13000 1>;
+   };
 };
 
 _pmx_core {
@@ -314,6 +323,12 @@
wakeup-source;
ti,palmas-long-press-seconds = <12>;
};
+
+   tps659038_gpio: tps659038_gpio {
+   compatible = "ti,palmas-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
};
 
tmp102: tmp102@48 {
-- 
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 3/3] MIPS: set stack/data protection as non-executable

[David Daney]

On 12/02/2014 05:58 PM, Leonid Yegoshin wrote:

This is a last step of 3 patches which shift FPU emulation out of
stack into protected area. So, it disables a default executable stack.

Additionally, it sets a default data area non-executable protection.

Signed-off-by: Leonid Yegoshin 


NAK!

Some programs require an executable stack, this patch will break them.

You can only select a non-executable stack in response to PT_GNU_STACK 
program headers in the ELF file of the executable program.


David Daney



---
  arch/mips/include/asm/page.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
index 3be81803595d..d49ba81cb4ed 100644
--- a/arch/mips/include/asm/page.h
+++ b/arch/mips/include/asm/page.h
@@ -230,7 +230,7 @@ extern int __virt_addr_valid(const volatile void *kaddr);
  #define virt_addr_valid(kaddr)
\
__virt_addr_valid((const volatile void *) (kaddr))

-#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | VM_EXEC | \
+#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | \
 VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)

  #define UNCAC_ADDR(addr)  ((addr) - PAGE_OFFSET + UNCAC_BASE)






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

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

[Russell King - ARM Linux]

On Fri, Dec 05, 2014 at 05:07:45PM +, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 12:05:06PM +, Will Deacon wrote:
> > Care to submit this as a proper patch? We should at least fix Peter's issue
> > before doing things like extending headers, which won't work for older
> > kernels anyway.
> 
> Quick fix is the revert of the whole patch, together with removing
> PAGE_ALIGN(end) in poison_init_mem() on arm32. If Russell is ok with
> this patch, we can take it via the arm64 tree, otherwise I'll send you a
> partial revert only for the arm64 part.

Not really.  Let's look at the history.

For years, we've been poisoning memory, page aligning the end pointer.
This has never been an issue.

However, patch 8167/1 changed things so we freed the overlapping pages.
Since we've always poisoned up to the end of the final page, freeing it
should not be a problem, especially as (I said above) we've been poisoning
it for years.

The issue is more about what happens at the start.

In any case:

> >From 8e317c6be00abe280de4dcdd598d2e92009174b6 Mon Sep 17 00:00:00 2001
> From: Catalin Marinas 
> Date: Fri, 5 Dec 2014 16:41:52 +
> Subject: [PATCH] Revert "ARM: 8167/1: extend the reserved memory for initrd to
>  be page aligned"
> 
> This reverts commit 421520ba98290a73b35b7644e877a48f18e06004. There is
> no guarantee that the boot-loader places other images like dtb in a
> different page than initrd start/end. When this happens, such pages must
> not be freed. The free_reserved_area() already takes care of rounding up
> "start" and rounding down "end" to avoid freeing partially used pages.
> 
> In addition to the revert, this patch also removes the arm32
> PAGE_ALIGN(end) when calculating the size of the memory to be poisoned.

which makes the summary line rather misleading, and I really don't think
we need to do this on ARM for the simple reason that we've been doing it
for soo long that it can't be an issue.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] i2c: cadence: Check for errata condition involving master receive

[Sören Brinkmann]

Hi Harini,

On Fri, 2014-12-05 at 01:38PM +0530, Harini Katakam wrote:
> Cadence I2C controller has the following bugs:
> - completion indication is not given to the driver at the end of
> a read/receive transfer with HOLD bit set.
> - Invalid read transaction are generated on the bus when HW timeout
> condition occurs with HOLD bit set.
> 
> As a result of the above, if a set of messages to be transferred with
> repeated start includes any transfer following a read transfer,
> completion is never indicated and timeout occurs.
> Hence a check is implemented to return -EOPNOTSUPP for such sequences.
> 
> Signed-off-by: Harini Katakam 
> Signed-off-by: Vishnu Motghare 
> ---
> 
> v3:
> Add warning in case of unsupported transfer.
> 
> v2:
> Dont defeteature repeated start. Just check for unsupported conditions in the
> driver and return error.
> 
> ---
>  drivers/i2c/busses/i2c-cadence.c |   15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-cadence.c 
> b/drivers/i2c/busses/i2c-cadence.c
> index 5f5d4fa..3ea3b7a 100644
> --- a/drivers/i2c/busses/i2c-cadence.c
> +++ b/drivers/i2c/busses/i2c-cadence.c
> @@ -541,6 +541,21 @@ static int cdns_i2c_master_xfer(struct i2c_adapter 
> *adap, struct i2c_msg *msgs,
>* processed with a repeated start.
>*/
>   if (num > 1) {
> + /*
> +  * This controller does not give completion interrupt after a
> +  * master receive transfer if HOLD bit is set (repeated start),
> +  * resulting in SW timeout. Hence, if a receive transfer is
> +  * followed by any other transfer, an error is returned
> +  * indicating that this sequence is not supported.
> +  */
> + for (count = 0; count < num-1; count++) {
> + if (msgs[count].flags & I2C_M_RD)
> + dev_warn(adap->dev.parent,
> + "No support for repeated start when\t");
> + dev_warn(adap->dev.parent,
> + "receive is followed by a transfer\n");

Please make this a single dev_warn without a line break in the string.
That way you can grep for the message in the sources.

Thanks,
Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] spi: st: Provide Device Tree binding documentation

[Mark Brown]

On Tue, Dec 02, 2014 at 03:40:42PM +, Lee Jones wrote:
> This patch adds DT documentation for the SPI portion of ST's SSC device.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [Xen-devel] [PATCH v5 9/9] xen/pciback: Implement PCI reset slot or bus with 'do_flr' SysFS attribute

[Konrad Rzeszutek Wilk]

On Fri, Dec 05, 2014 at 10:30:01AM +, David Vrabel wrote:
> On 04/12/14 15:39, Alex Williamson wrote:
> > 
> > I don't know what workaround you're talking about.  As devices are
> > released from the user, vfio-pci attempts to reset them.  If
> > pci_reset_function() returns success we mark the device clean, otherwise
> > it gets marked dirty.  Each time a device is released, if there are
> > dirty devices we test whether we can try a bus/slot reset to clean them.
> > In the case of assigning a GPU this typically means that the GPU or
> > audio function come through first, there's no reset mechanism so it gets
> > marked dirty, the next device comes through and we manage to try a bus
> > reset.  vfio-pci does not have any device specific resets, all
> > functionality is added to the PCI-core, thank-you-very-much.  I even
> > posted a generic PCI quirk patch recently that marks AMD VGA PM reset as
> > bad so that pci_reset_function() won't claim that worked.  All VGA
> > access quirks are done in QEMU, the kernel doesn't have any business in
> > remapping config space over MMIO regions or trapping other config space
> > backdoors.
> 
> Thanks for the info Alex, I hadn't got around to actually looking and
> the vfio-pci code and was just going to what Sander said.
> 
> We probably do need to have a more in depth look at now PCI devices and
> handled by both the toolstack and pciback but in the short term I would
> like a simple solution that does not extend the ABI.

Could you enumerate the 'simple solution' then please? I am having
a frustrating time figuring out what it is that you are proposing.


> 
> David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/4] spi: Add new driver for STMicroelectronics' SPI Controller

[Mark Brown]

On Tue, Dec 02, 2014 at 03:40:41PM +, Lee Jones wrote:
> This patch adds support for the SPI portion of ST's SSC device.

Applied, thanks.


signature.asc
Description: Digital signature

[PATCH] PM QoS: Add debugfs support to view the list of constraints

[Dave Gerlach]

From: Nishanth Menon 

PM QoS requests are notoriously hard to debug and made even
more so due to their highly dynamic nature. Having visibility
into the internal data representation per constraint allows
us to have much better appreciation of potential issues or
bad usage by drivers in the system.

So introduce for all classes of PM QoS, an entry in
/sys/kernel/debug/pm_qos that shall show all the current
requests as well as the snapshot of the value these requests
boil down to. For example:
==> /sys/kernel/debug/pm_qos/cpu_dma_latency <==
1: : Active
2: 20: Default
3: 20: Default
4: 20: Default
Type=Minimum, Value=, Requests: active=1 / total=4

==> /sys/kernel/debug/pm_qos/memory_bandwidth <==
Empty!

...

The actual value listed will have their meaning based
on the QoS it is on, the 'Type' indicates what logic
it would use to collate the information - Minimum,
Maximum, or Sum. Value is the collation of all requests.
This interface also compares the values with the defaults
for the QoS class and marks the ones that are
currently active.

Signed-off-by: Nishanth Menon 
Signed-off-by: Dave Gerlach 
---
 kernel/power/qos.c | 91 --
 1 file changed, 89 insertions(+), 2 deletions(-)

diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index 5f4c006..97b0df7 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -41,6 +41,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -182,6 +184,81 @@ static inline void pm_qos_set_value(struct 
pm_qos_constraints *c, s32 value)
c->target_value = value;
 }
 
+static inline int pm_qos_get_value(struct pm_qos_constraints *c);
+static int pm_qos_dbg_show_requests(struct seq_file *s, void *unused)
+{
+   struct pm_qos_object *qos = (struct pm_qos_object *)s->private;
+   struct pm_qos_constraints *c;
+   struct pm_qos_request *req;
+   char *type;
+   unsigned long flags;
+   int tot_reqs = 0;
+   int active_reqs = 0;
+
+   if (IS_ERR_OR_NULL(qos)) {
+   pr_err("%s: bad qos param!\n", __func__);
+   return -EINVAL;
+   }
+   c = qos->constraints;
+   if (IS_ERR_OR_NULL(c)) {
+   pr_err("%s: Bad constraints on qos?\n", __func__);
+   return -EINVAL;
+   }
+
+   /* Lock to ensure we have a snapshot */
+   spin_lock_irqsave(_qos_lock, flags);
+   if (plist_head_empty(>list)) {
+   seq_puts(s, "Empty!\n");
+   goto out;
+   }
+
+   switch (c->type) {
+   case PM_QOS_MIN:
+   type = "Minimum";
+   break;
+   case PM_QOS_MAX:
+   type = "Maximum";
+   break;
+   case PM_QOS_SUM:
+   type = "Sum";
+   break;
+   default:
+   type = "Unknown";
+   }
+
+   plist_for_each_entry(req, >list, node) {
+   char *state = "Default";
+
+   if ((req->node).prio != c->default_value) {
+   active_reqs++;
+   state = "Active";
+   }
+   tot_reqs++;
+   seq_printf(s, "%d: %d: %s\n", tot_reqs,
+  (req->node).prio, state);
+   }
+
+   seq_printf(s, "Type=%s, Value=%d, Requests: active=%d / total=%d\n",
+  type, pm_qos_get_value(c), active_reqs, tot_reqs);
+
+out:
+   spin_unlock_irqrestore(_qos_lock, flags);
+   return 0;
+}
+
+static int pm_qos_dbg_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, pm_qos_dbg_show_requests,
+  inode->i_private);
+}
+
+static const struct file_operations pm_qos_debug_fops = {
+   .open   = pm_qos_dbg_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+
 /**
  * pm_qos_update_target - manages the constraints list and calls the notifiers
  *  if needed
@@ -509,12 +586,17 @@ int pm_qos_remove_notifier(int pm_qos_class, struct 
notifier_block *notifier)
 EXPORT_SYMBOL_GPL(pm_qos_remove_notifier);
 
 /* User space interface to PM QoS classes via misc devices */
-static int register_pm_qos_misc(struct pm_qos_object *qos)
+static int register_pm_qos_misc(struct pm_qos_object *qos, struct dentry *d)
 {
qos->pm_qos_power_miscdev.minor = MISC_DYNAMIC_MINOR;
qos->pm_qos_power_miscdev.name = qos->name;
qos->pm_qos_power_miscdev.fops = _qos_power_fops;
 
+   if (d) {
+   (void)debugfs_create_file(qos->name, S_IRUGO, d,
+ (void *)qos, _qos_debug_fops);
+   }
+
return misc_register(>pm_qos_power_miscdev);
 }
 
@@ -608,11 +690,16 @@ static int __init pm_qos_power_init(void)
 {
int ret = 0;
int i;
+   struct dentry *d;
 
BUILD_BUG_ON(ARRAY_SIZE(pm_qos_array) != PM_QOS_NUM_CLASSES);
 
+   d = 

Re: [RFC 1/2] i2c: omap: fix buffer overruns during RX/TX data processing

[Alexander Kochetkov]

Hello, Tony!

> The issue I'm seeing on 2430sdp is some earlier regression that
> has started happening over the past year or so. 

I don't have 2430sdp. And I couldn't  find 2430sdp schematics.
Looks, like this is NDA stuff.

> Of course the issue I'm seeing could be caused by hung twl4030
> PMIC too.

This could be switching twl4030 into inappropriate for 2430sdp mode.

For example, SMARTREFLEX_ENABLE bit is dangerous, because
it switch twl-pads from VMODE to i2c.
And when you set SMARTREFLEX_ENABLE, twl automatically drop
VDD1 and VDD2 to 1.2V (if VDD1_SR_CONTROL was not initialized through
BYPASS register early in the boot loader).

What mode is used in the 2430sdp? VMODE or Smartreflex?

And, that is my assumption, may be it wrong again.

I'd added trace in the twl_i2c_read_u8/twl_i2c_write_u8 functions to
easy find concrete line of code, what cause problem (by register address).

Hang happens on access to 0x004b address group.
That could be: BACKUP_REG, INT, PM_MASTER, PM_RECEIVER, RTC or
SECURED_REG. It hard to tell which one cause hang without trace.

Hope this helps.

Regards,
Alexander.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] optimize ktime_divns for constant divisors

[Nicolas Pitre]

On Fri, 5 Dec 2014, Arnd Bergmann wrote:


> > 
> > That, too, risk overflowing.
> > 
> > Let's say x_lo = 0x and x_hi = 0x.  You get:
> > 
> > 0x * 0x83126e97 ->  0x83126e967ced9169
> > 0x * 0x8d4fdf3b ->  0x8d4fdf3a72b020c5
> >---
> >0x110624dd0ef9db22e
> > 
> > Therefore the sum doesn't fit into a u64 variable.
> > 
> > It is possible to skip carry handling but only when the MSB of both 
> > constants are zero.  Here it is not the case.
> 
> If I understand this right, there are two possible optimizations to
> avoid the overflow:
> 
> - for anything using monotonic time, or elapsed time, we can guarantee
>   that the upper bits are zero. Relying on monotonic time is a bit
>   dangerous, because that would mean introducing an API that works
>   with ktime_get() but not ktime_get_real(), and risk introducing
>   subtle bugs.
>   However, ktime_us_delta() could be optimized, and we can introduce
>   similar ktime_sec_delta() and ktime_ms_delta() functions with
>   the same properties.

Well, as Pang mentioned, ktime_t.tv64 is signed.  So if a negative value 
were to be passed to the current version of ktime_divns() you wouldn't 
get the expected answer as the first thing it does is

u64 dclc = ktime_to_ns(kt);

And do_div() works with unsigned values.

So to say that we can assume that currently and for the forseeable 
future, the top bit of ktime_t will never be set.  And if it does due to 
a negative value then the code is already buggy.

With that assumption in mind, we now have a maximum value of 
0x7fff to divide i.e. 63 rather than 64 bits.  That means we 
don't need the initial bias anymore to get correct results.  And the 
constant looses its MSB too, removing the possibility for overflows in 
the cross product.

Therefore the code becomes:

u64 ktime_to_us(ktime_t kt)
{
u64 ns = ktime_to_ns(kt);
u32 x_lo, x_hi, y_lo, y_hi;
u64 res;

x_hi = ns >> 32;
x_lo = ns;
y_hi = 0x4189374b;
y_lo = 0xc6a7ef9e;

res =  (u64)x_lo * y_lo;
res >>= 32;
res += (u64)x_lo * y_hi;
res += (u64)x_hi * y_lo;
res >>= 32;
res += (u64)x_hi * y_hi;

return res >> 8;
}

This is probably the best that can be done portably.

> - one could always pre-shift the ktime_t value. For a division by
>   1000, we can shift right by 3 bits first, then do the multiplication
>   and then do another shift. Not sure if that helps at all or if
>   the extra shift operation makes this counterproductive.

It could help in the full 64-bit range case as the remaining dividend 
doesn't require a full 64-bit reciprocal constant, avoiding once again 
the need for the initial bias and the carry handling.  Depending on the 
actual reciprocal bit pattern this may not always be necessary.  It also 
depends how cheap shifting a 64-bit value is (on ARM this requires 3 
instructions and 3 registers).

But in the specific case above this provides no gain.


Nicolas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: frequent lockups in 3.18rc4

[Dave Jones]

On Wed, Dec 03, 2014 at 10:45:57AM -0800, Linus Torvalds wrote:
 > On Wed, Dec 3, 2014 at 10:41 AM, Dave Jones  wrote:
 > >
 > > I've been stuck on this kernel for a few days now trying to prove it
 > > good/bad one way or the other, and I'm leaning towards good, given
 > > that it recovers, even though the traces look similar.
 > 
 > Ugh. But this does *not* happen with 3.16, right? Even the non-fatal case?
 > 
 > If so, I'd be inclined to call it "bad". But there might well be two
 > bugs: one that makes that NMI watchdog trigger, and another one that
 > then makes it be a hard lockup. I'd think it would be good to figure
 > out the "NMI watchdog starts triggering" one first, though.

A bisect later, and I landed on a kernel that ran for a day, before
spewing NMI messages, recovering, and then..

http://codemonkey.org.uk/junk/log.txt

I could log in, but every command I tried (even shell built-ins) just printed 
'bus error'.

I saw those end_request messages in an earlier bisect, I wonder if there
was an actual bug that got fixed where allowed non-root to try and do
bad things to raw devices. It's always sector 0 too.

Yet again, I'm wondering if this whole thing is just signs of early hardware 
death.

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 v5 34/61] dmaengine: omap: Split device_control

[Maxime Ripard]

On Fri, Dec 05, 2014 at 08:26:42PM +0530, Vinod Koul wrote:
> On Fri, Dec 05, 2014 at 03:33:59PM +0100, Maxime Ripard wrote:
> > Hi Vinod,
> > 
> > On Fri, Dec 05, 2014 at 07:57:02PM +0530, Vinod Koul wrote:
> > > On Mon, Nov 17, 2014 at 02:42:28PM +0100, Maxime Ripard wrote:
> > > > Split the device_control callback of the TI OMAP DMA driver to make use
> > > > of the newly introduced callbacks, that will eventually be used to 
> > > > retrieve
> > > > slave capabilities.
> > > > 
> > > > Signed-off-by: Maxime Ripard 
> > > > ---
> > > >  drivers/dma/omap-dma.c | 51 
> > > > +++---
> > > >  1 file changed, 15 insertions(+), 36 deletions(-)
> > > > 
> > > > diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> > > > index a8aa5b6bb5e2..1cadf812f3b3 100644
> > > > --- a/drivers/dma/omap-dma.c
> > > > +++ b/drivers/dma/omap-dma.c
> > > > @@ -948,8 +948,10 @@ static struct dma_async_tx_descriptor 
> > > > *omap_dma_prep_dma_cyclic(
> > > > return vchan_tx_prep(>vc, >vd, flags);
> > > >  }
> > > >  
> > > > -static int omap_dma_slave_config(struct omap_chan *c, struct 
> > > > dma_slave_config *cfg)
> > > > +static int omap_dma_slave_config(struct dma_chan *chan, struct 
> > > > dma_slave_config *cfg)
> > > >  {
> > > > +   struct omap_chan *c = to_omap_dma_chan(chan);
> > > > +
> > > > if (cfg->src_addr_width == DMA_SLAVE_BUSWIDTH_8_BYTES ||
> > > > cfg->dst_addr_width == DMA_SLAVE_BUSWIDTH_8_BYTES)
> > > > return -EINVAL;
> > > > @@ -959,8 +961,9 @@ static int omap_dma_slave_config(struct omap_chan 
> > > > *c, struct dma_slave_config *c
> > > > return 0;
> > > >  }
> > > >  
> > > > -static int omap_dma_terminate_all(struct omap_chan *c)
> > > > +static int omap_dma_terminate_all(struct dma_chan *chan)
> > > >  {
> > > > +   struct omap_chan *c = to_omap_dma_chan(chan);
> > > > struct omap_dmadev *d = to_omap_dma_dev(c->vc.chan.device);
> > > > unsigned long flags;
> > > > LIST_HEAD(head);
> > > > @@ -996,8 +999,10 @@ static int omap_dma_terminate_all(struct omap_chan 
> > > > *c)
> > > > return 0;
> > > >  }
> > > >  
> > > > -static int omap_dma_pause(struct omap_chan *c)
> > > > +static int omap_dma_pause(struct dma_chan *chan)
> > > >  {
> > > > +   struct omap_chan *c = to_omap_dma_chan(chan);
> > > > +
> > > > /* Pause/Resume only allowed with cyclic mode */
> > > > if (!c->cyclic)
> > > > return -EINVAL;
> > > > @@ -1010,8 +1015,10 @@ static int omap_dma_pause(struct omap_chan *c)
> > > > return 0;
> > > >  }
> > > >  
> > > > -static int omap_dma_resume(struct omap_chan *c)
> > > > +static int omap_dma_resume(struct dma_chan *chan)
> > > >  {
> > > > +   struct omap_chan *c = to_omap_dma_chan(chan);
> > > > +
> > > > /* Pause/Resume only allowed with cyclic mode */
> > > > if (!c->cyclic)
> > > > return -EINVAL;
> > > > @@ -1029,37 +1036,6 @@ static int omap_dma_resume(struct omap_chan *c)
> > > > return 0;
> > > >  }
> > > >  
> > > > -static int omap_dma_control(struct dma_chan *chan, enum dma_ctrl_cmd 
> > > > cmd,
> > > > -   unsigned long arg)
> > > > -{
> > > > -   struct omap_chan *c = to_omap_dma_chan(chan);
> > > > -   int ret;
> > > > -
> > > > -   switch (cmd) {
> > > > -   case DMA_SLAVE_CONFIG:
> > > > -   ret = omap_dma_slave_config(c, (struct dma_slave_config 
> > > > *)arg);
> > > > -   break;
> > > > -
> > > > -   case DMA_TERMINATE_ALL:
> > > > -   ret = omap_dma_terminate_all(c);
> > > > -   break;
> > > > -
> > > > -   case DMA_PAUSE:
> > > > -   ret = omap_dma_pause(c);
> > > > -   break;
> > > > -
> > > > -   case DMA_RESUME:
> > > > -   ret = omap_dma_resume(c);
> > > > -   break;
> > > > -
> > > > -   default:
> > > > -   ret = -ENXIO;
> > > > -   break;
> > > > -   }
> > > > -
> > > > -   return ret;
> > > > -}
> > > > -
> > > >  static int omap_dma_chan_init(struct omap_dmadev *od, int dma_sig)
> > > >  {
> > > > struct omap_chan *c;
> > > > @@ -1136,7 +1112,10 @@ static int omap_dma_probe(struct platform_device 
> > > > *pdev)
> > > > od->ddev.device_issue_pending = omap_dma_issue_pending;
> > > > od->ddev.device_prep_slave_sg = omap_dma_prep_slave_sg;
> > > > od->ddev.device_prep_dma_cyclic = omap_dma_prep_dma_cyclic;
> > > > -   od->ddev.device_control = omap_dma_control;
> > > this should be assigned to omap_dma_slave_config. omap_dma_control is not
> > > here :(
> > 
> > I'm not sure what you mean here. I'm removing this line, together with
> > the whole omap_dma_control function.
> Sorry wrong quote and not good explanations. the lines i quoted is
> wrong one... 
> 
> -   od->ddev.device_control = omap_dma_control;
> +   

Re: [PATCH v2 7/7] pinctrl: qcom-spmi-gpio: Migrate to pinconf-generic

[Sören Brinkmann]

On Fri, 2014-12-05 at 09:59AM +0200, Ivan T. Ivanov wrote:
> 
> On Thu, 2014-11-27 at 17:26 -0800, Soren Brinkmann wrote:
> > 
> >  static const struct pinconf_ops pmic_gpio_pinconf_ops = {
> > +   .is_generic= true,
> > .pin_config_group_get= pmic_gpio_config_get,
> > .pin_config_group_set= pmic_gpio_config_set,
> > .pin_config_group_dbg_show= pmic_gpio_config_dbg_show,
> > @@ -848,6 +742,9 @@ static int pmic_gpio_probe(struct platform_device *pdev)
> > pctrldesc->name = dev_name(dev);
> > pctrldesc->pins = pindesc;
> > pctrldesc->npins = npins;
> > +   pctrldesc->num_dt_params = ARRAY_SIZE(pmic_gpio_bindings);
> > +   pctrldesc->params = pmic_gpio_bindings;
> > +   pctrldesc->conf_items = pmic_conf_items;
> > 
> 
> What will happen if number of conf_items is less than number of params?

I suppose bad things :) You're right, that should probably be checked
somewhere. Let me see whether I find a good place to put such a check.

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