* Re: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready
From: Stefan Agner @ 2016-11-09 0:34 UTC (permalink / raw)
To: stable; +Cc: Wolfram Sang, stable
In-Reply-To: <20161109003239.16940-1-stefan@agner.ch>
On 2016-11-08 16:32, Stefan Agner wrote:
> commit 533169d164c6b4c8571d0d48779f6ff6be593d72 upstream.
>
> Some SoC might load the GPIO driver after the I2C driver and
> using the I2C bus recovery mechanism via GPIOs. In this case
> it is crucial to defer probing if the GPIO request functions
> do so, otherwise the I2C driver gets loaded without recovery
> mechanisms enabled.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Acked-by: Li Yang <leoyang.li@nxp.com>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> Cc: stable@kernel.org
I forgot to mention, this should be applied to 4.4 only.
Later versions made the return value void, and it would require a larger
rework. I am mainly concerned about LTS...
--
Stefan
> ---
> drivers/i2c/busses/i2c-imx.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index d4d8536..32fae2c 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1002,10 +1002,13 @@ static void i2c_imx_init_recovery_info(struct
> imx_i2c_struct *i2c_imx,
> rinfo->scl_gpio = of_get_named_gpio_flags(pdev->dev.of_node,
> "scl-gpios", 0, NULL);
>
> - if (!gpio_is_valid(rinfo->sda_gpio) ||
> - !gpio_is_valid(rinfo->scl_gpio) ||
> - IS_ERR(i2c_imx->pinctrl_pins_default) ||
> - IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
> + if (rinfo->sda_gpio == -EPROBE_DEFER ||
> + rinfo->scl_gpio == -EPROBE_DEFER) {
> + return -EPROBE_DEFER;
> + } else if (!gpio_is_valid(rinfo->sda_gpio) ||
> + !gpio_is_valid(rinfo->scl_gpio) ||
> + IS_ERR(i2c_imx->pinctrl_pins_default) ||
> + IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
> dev_dbg(&pdev->dev, "recovery information incomplete\n");
> return;
> }
^ permalink raw reply
* Re: [pinctrl:devel 43/47] drivers/pinctrl/samsung/pinctrl-s3c64xx.c:283:9: error: 'struct samsung_pinctrl_drv_data' has no member named 'virt_base'; did you mean 'pin_base'?
From: Chanwoo Choi @ 2016-11-09 0:47 UTC (permalink / raw)
To: Linus Walleij
Cc: kbuild-all@01.org, linux-gpio@vger.kernel.org,
Krzysztof Kozlowski
In-Reply-To: <CACRpkdZ=Uc5Ugw8=VM823tPKzsA=UghQc75pkd1pcWp4QAbJ5A@mail.gmail.com>
Hi Linus,
On 2016년 11월 08일 22:17, Linus Walleij wrote:
> On Tue, Nov 8, 2016 at 1:58 PM, kbuild test robot
> <fengguang.wu@intel.com> wrote:
>
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
>> head: 05e51a4da2af5f68c911adcb888f103460a2e5b3
>> commit: e40fde2c098df8bbaf82b5b80b43aa49eb2cb9af [43/47] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank
>> config: arm-allmodconfig (attached as .config)
>> compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
>> reproduce:
>> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> git checkout e40fde2c098df8bbaf82b5b80b43aa49eb2cb9af
>> # save the attached .config to linux build tree
>> make.cross ARCH=arm
>>
>> All error/warnings (new ones prefixed by >>):
>>
>> drivers/pinctrl/samsung/pinctrl-s3c64xx.c: In function 's3c64xx_irq_set_function':
>>>> drivers/pinctrl/samsung/pinctrl-s3c64xx.c:283:9: error: 'struct samsung_pinctrl_drv_data' has no member named 'virt_base'; did you mean 'pin_base'?
>> reg = d->virt_base + bank->pctl_offset;
>> ^~
>
> This patch does not compile. I took out both patches from my tree as they
> are causing build regressions.
>
> Please develop against the latest release candidate or the "devel" branch
> in the pin control tree.
>
> Please also split the patches better as Krzysztof requested.
I'm sorry for my mistake. I'll resend the patch after fixing it.
Best Regards,
Chanwoo Choi
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] docs: add document to explain the usage of vNVDIMM
From: Haozhong Zhang @ 2016-11-09 0:47 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: qemu-devel, Xiao Guangrong
In-Reply-To: <20161108170812.GI11274@stefanha-x1.localdomain>
On 11/08/16 17:08 +0000, Stefan Hajnoczi wrote:
>On Tue, Nov 08, 2016 at 08:46:14PM +0800, Haozhong Zhang wrote:
>> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
>> Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
>> ---
>> docs/nvdimm.txt | 124 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 124 insertions(+)
>> create mode 100644 docs/nvdimm.txt
>>
>> diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt
>> new file mode 100644
>> index 0000000..fafca39
>> --- /dev/null
>> +++ b/docs/nvdimm.txt
>> @@ -0,0 +1,124 @@
>> +QEMU Virtual NVDIMM
>> +===================
>> +
>> +This document explains the usage of virtual NVDIMM (vNVDIMM) feature
>> +which is available since QEMU v2.6.0.
>> +
>> +The current QEMU only implements the persistent memory mode of vNVDIMM
>> +device.
>
>"and not the block window mode."
>
>Explicitly naming block window mode would be useful for anyone looking
>through the docs to find out whether this mode is supported or not.
>
will add in the next version.
Thanks,
Haozhong
[..]
^ permalink raw reply
* Re: [PATCH v3 01/18] Input: synaptics-rmi4 - Move IRQ handling to rmi_driver
From: Dmitry Torokhov @ 2016-11-09 0:47 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Andrew Duggan, Lyude Paul, Christopher Heiny, Nick Dyer,
Bjorn Andersson, Dennis Wassenberg, linux-kernel, linux-input
In-Reply-To: <1476373872-18027-2-git-send-email-benjamin.tissoires@redhat.com>
On Thu, Oct 13, 2016 at 05:50:55PM +0200, Benjamin Tissoires wrote:
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> The attn IRQ is related to the chip, rather than the transport, so move
> all handling of interrupts to the core driver. This also makes sure that
> there are no races between interrupts and availability of the resources
> used by the core driver.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Applied, thank you.
>
> ---
>
> new in v3
>
> changes since Bjorn's submission:
> - call disable_irq on remove()
> ---
> drivers/input/rmi4/rmi_driver.c | 73 +++++++++++++++++++++++++++++++++++++---
> drivers/input/rmi4/rmi_i2c.c | 74 +++--------------------------------------
> drivers/input/rmi4/rmi_spi.c | 72 +++------------------------------------
> include/linux/rmi.h | 7 ++--
> 4 files changed, 83 insertions(+), 143 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
> index c83bce8..cf780ef 100644
> --- a/drivers/input/rmi4/rmi_driver.c
> +++ b/drivers/input/rmi4/rmi_driver.c
> @@ -17,6 +17,7 @@
> #include <linux/bitmap.h>
> #include <linux/delay.h>
> #include <linux/fs.h>
> +#include <linux/irq.h>
> #include <linux/kconfig.h>
> #include <linux/pm.h>
> #include <linux/slab.h>
> @@ -134,7 +135,7 @@ static void process_one_interrupt(struct rmi_driver_data *data,
> }
> }
>
> -int rmi_process_interrupt_requests(struct rmi_device *rmi_dev)
> +static int rmi_process_interrupt_requests(struct rmi_device *rmi_dev)
> {
> struct rmi_driver_data *data = dev_get_drvdata(&rmi_dev->dev);
> struct device *dev = &rmi_dev->dev;
> @@ -179,7 +180,42 @@ int rmi_process_interrupt_requests(struct rmi_device *rmi_dev)
>
> return 0;
> }
> -EXPORT_SYMBOL_GPL(rmi_process_interrupt_requests);
> +
> +static irqreturn_t rmi_irq_fn(int irq, void *dev_id)
> +{
> + struct rmi_device *rmi_dev = dev_id;
> + int ret;
> +
> + ret = rmi_process_interrupt_requests(rmi_dev);
> + if (ret)
> + rmi_dbg(RMI_DEBUG_CORE, &rmi_dev->dev,
> + "Failed to process interrupt request: %d\n", ret);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int rmi_irq_init(struct rmi_device *rmi_dev)
> +{
> + struct rmi_device_platform_data *pdata = rmi_get_platform_data(rmi_dev);
> + int irq_flags = irq_get_trigger_type(pdata->irq);
> + int ret;
> +
> + if (!irq_flags)
> + irq_flags = IRQF_TRIGGER_LOW;
> +
> + ret = devm_request_threaded_irq(&rmi_dev->dev, pdata->irq, NULL,
> + rmi_irq_fn, irq_flags | IRQF_ONESHOT,
> + dev_name(rmi_dev->xport->dev),
> + rmi_dev);
> + if (ret < 0) {
> + dev_warn(&rmi_dev->dev, "Failed to register interrupt %d\n",
> + pdata->irq);
> +
> + return ret;
> + }
> +
> + return 0;
> +}
>
> static int suspend_one_function(struct rmi_function *fn)
> {
> @@ -787,8 +823,10 @@ err_put_fn:
> return error;
> }
>
> -int rmi_driver_suspend(struct rmi_device *rmi_dev)
> +int rmi_driver_suspend(struct rmi_device *rmi_dev, bool enable_wake)
> {
> + struct rmi_device_platform_data *pdata = rmi_get_platform_data(rmi_dev);
> + int irq = pdata->irq;
> int retval = 0;
>
> retval = rmi_suspend_functions(rmi_dev);
> @@ -796,14 +834,33 @@ int rmi_driver_suspend(struct rmi_device *rmi_dev)
> dev_warn(&rmi_dev->dev, "Failed to suspend functions: %d\n",
> retval);
>
> + disable_irq(irq);
> + if (enable_wake && device_may_wakeup(rmi_dev->xport->dev)) {
> + retval = enable_irq_wake(irq);
> + if (!retval)
> + dev_warn(&rmi_dev->dev,
> + "Failed to enable irq for wake: %d\n",
> + retval);
> + }
> return retval;
> }
> EXPORT_SYMBOL_GPL(rmi_driver_suspend);
>
> -int rmi_driver_resume(struct rmi_device *rmi_dev)
> +int rmi_driver_resume(struct rmi_device *rmi_dev, bool clear_wake)
> {
> + struct rmi_device_platform_data *pdata = rmi_get_platform_data(rmi_dev);
> + int irq = pdata->irq;
> int retval;
>
> + enable_irq(irq);
> + if (clear_wake && device_may_wakeup(rmi_dev->xport->dev)) {
> + retval = disable_irq_wake(irq);
> + if (!retval)
> + dev_warn(&rmi_dev->dev,
> + "Failed to disable irq for wake: %d\n",
> + retval);
> + }
> +
> retval = rmi_resume_functions(rmi_dev);
> if (retval)
> dev_warn(&rmi_dev->dev, "Failed to suspend functions: %d\n",
> @@ -816,6 +873,10 @@ EXPORT_SYMBOL_GPL(rmi_driver_resume);
> static int rmi_driver_remove(struct device *dev)
> {
> struct rmi_device *rmi_dev = to_rmi_device(dev);
> + struct rmi_device_platform_data *pdata = rmi_get_platform_data(rmi_dev);
> + int irq = pdata->irq;
> +
> + disable_irq(irq);
>
> rmi_free_function_list(rmi_dev);
>
> @@ -1004,6 +1065,10 @@ static int rmi_driver_probe(struct device *dev)
> }
> }
>
> + retval = rmi_irq_init(rmi_dev);
> + if (retval < 0)
> + goto err_destroy_functions;
> +
> if (data->f01_container->dev.driver)
> /* Driver already bound, so enable ATTN now. */
> return enable_sensor(rmi_dev);
> diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
> index 6f2e0e4..64a5488 100644
> --- a/drivers/input/rmi4/rmi_i2c.c
> +++ b/drivers/input/rmi4/rmi_i2c.c
> @@ -9,7 +9,6 @@
>
> #include <linux/i2c.h>
> #include <linux/rmi.h>
> -#include <linux/irq.h>
> #include <linux/of.h>
> #include <linux/delay.h>
> #include <linux/regulator/consumer.h>
> @@ -35,8 +34,6 @@ struct rmi_i2c_xport {
> struct mutex page_mutex;
> int page;
>
> - int irq;
> -
> u8 *tx_buf;
> size_t tx_buf_size;
>
> @@ -177,42 +174,6 @@ static const struct rmi_transport_ops rmi_i2c_ops = {
> .read_block = rmi_i2c_read_block,
> };
>
> -static irqreturn_t rmi_i2c_irq(int irq, void *dev_id)
> -{
> - struct rmi_i2c_xport *rmi_i2c = dev_id;
> - struct rmi_device *rmi_dev = rmi_i2c->xport.rmi_dev;
> - int ret;
> -
> - ret = rmi_process_interrupt_requests(rmi_dev);
> - if (ret)
> - rmi_dbg(RMI_DEBUG_XPORT, &rmi_dev->dev,
> - "Failed to process interrupt request: %d\n", ret);
> -
> - return IRQ_HANDLED;
> -}
> -
> -static int rmi_i2c_init_irq(struct i2c_client *client)
> -{
> - struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
> - int irq_flags = irqd_get_trigger_type(irq_get_irq_data(rmi_i2c->irq));
> - int ret;
> -
> - if (!irq_flags)
> - irq_flags = IRQF_TRIGGER_LOW;
> -
> - ret = devm_request_threaded_irq(&client->dev, rmi_i2c->irq, NULL,
> - rmi_i2c_irq, irq_flags | IRQF_ONESHOT, client->name,
> - rmi_i2c);
> - if (ret < 0) {
> - dev_warn(&client->dev, "Failed to register interrupt %d\n",
> - rmi_i2c->irq);
> -
> - return ret;
> - }
> -
> - return 0;
> -}
> -
> #ifdef CONFIG_OF
> static const struct of_device_id rmi_i2c_of_match[] = {
> { .compatible = "syna,rmi4-i2c" },
> @@ -240,8 +201,7 @@ static int rmi_i2c_probe(struct i2c_client *client,
> if (!client->dev.of_node && client_pdata)
> *pdata = *client_pdata;
>
> - if (client->irq > 0)
> - rmi_i2c->irq = client->irq;
> + pdata->irq = client->irq;
>
> rmi_dbg(RMI_DEBUG_XPORT, &client->dev, "Probing %s.\n",
> dev_name(&client->dev));
> @@ -295,10 +255,6 @@ static int rmi_i2c_probe(struct i2c_client *client,
> return retval;
> }
>
> - retval = rmi_i2c_init_irq(client);
> - if (retval < 0)
> - return retval;
> -
> dev_info(&client->dev, "registered rmi i2c driver at %#04x.\n",
> client->addr);
> return 0;
> @@ -322,18 +278,10 @@ static int rmi_i2c_suspend(struct device *dev)
> struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
> int ret;
>
> - ret = rmi_driver_suspend(rmi_i2c->xport.rmi_dev);
> + ret = rmi_driver_suspend(rmi_i2c->xport.rmi_dev, true);
> if (ret)
> dev_warn(dev, "Failed to resume device: %d\n", ret);
>
> - disable_irq(rmi_i2c->irq);
> - if (device_may_wakeup(&client->dev)) {
> - ret = enable_irq_wake(rmi_i2c->irq);
> - if (!ret)
> - dev_warn(dev, "Failed to enable irq for wake: %d\n",
> - ret);
> - }
> -
> regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies),
> rmi_i2c->supplies);
>
> @@ -353,15 +301,7 @@ static int rmi_i2c_resume(struct device *dev)
>
> msleep(rmi_i2c->startup_delay);
>
> - enable_irq(rmi_i2c->irq);
> - if (device_may_wakeup(&client->dev)) {
> - ret = disable_irq_wake(rmi_i2c->irq);
> - if (!ret)
> - dev_warn(dev, "Failed to disable irq for wake: %d\n",
> - ret);
> - }
> -
> - ret = rmi_driver_resume(rmi_i2c->xport.rmi_dev);
> + ret = rmi_driver_resume(rmi_i2c->xport.rmi_dev, true);
> if (ret)
> dev_warn(dev, "Failed to resume device: %d\n", ret);
>
> @@ -376,12 +316,10 @@ static int rmi_i2c_runtime_suspend(struct device *dev)
> struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
> int ret;
>
> - ret = rmi_driver_suspend(rmi_i2c->xport.rmi_dev);
> + ret = rmi_driver_suspend(rmi_i2c->xport.rmi_dev, false);
> if (ret)
> dev_warn(dev, "Failed to resume device: %d\n", ret);
>
> - disable_irq(rmi_i2c->irq);
> -
> regulator_bulk_disable(ARRAY_SIZE(rmi_i2c->supplies),
> rmi_i2c->supplies);
>
> @@ -401,9 +339,7 @@ static int rmi_i2c_runtime_resume(struct device *dev)
>
> msleep(rmi_i2c->startup_delay);
>
> - enable_irq(rmi_i2c->irq);
> -
> - ret = rmi_driver_resume(rmi_i2c->xport.rmi_dev);
> + ret = rmi_driver_resume(rmi_i2c->xport.rmi_dev, false);
> if (ret)
> dev_warn(dev, "Failed to resume device: %d\n", ret);
>
> diff --git a/drivers/input/rmi4/rmi_spi.c b/drivers/input/rmi4/rmi_spi.c
> index 55bd1b3..f3e9e48 100644
> --- a/drivers/input/rmi4/rmi_spi.c
> +++ b/drivers/input/rmi4/rmi_spi.c
> @@ -12,7 +12,6 @@
> #include <linux/rmi.h>
> #include <linux/slab.h>
> #include <linux/spi/spi.h>
> -#include <linux/irq.h>
> #include <linux/of.h>
> #include "rmi_driver.h"
>
> @@ -44,8 +43,6 @@ struct rmi_spi_xport {
> struct mutex page_mutex;
> int page;
>
> - int irq;
> -
> u8 *rx_buf;
> u8 *tx_buf;
> int xfer_buf_size;
> @@ -326,41 +323,6 @@ static const struct rmi_transport_ops rmi_spi_ops = {
> .read_block = rmi_spi_read_block,
> };
>
> -static irqreturn_t rmi_spi_irq(int irq, void *dev_id)
> -{
> - struct rmi_spi_xport *rmi_spi = dev_id;
> - struct rmi_device *rmi_dev = rmi_spi->xport.rmi_dev;
> - int ret;
> -
> - ret = rmi_process_interrupt_requests(rmi_dev);
> - if (ret)
> - rmi_dbg(RMI_DEBUG_XPORT, &rmi_dev->dev,
> - "Failed to process interrupt request: %d\n", ret);
> -
> - return IRQ_HANDLED;
> -}
> -
> -static int rmi_spi_init_irq(struct spi_device *spi)
> -{
> - struct rmi_spi_xport *rmi_spi = spi_get_drvdata(spi);
> - int irq_flags = irqd_get_trigger_type(irq_get_irq_data(rmi_spi->irq));
> - int ret;
> -
> - if (!irq_flags)
> - irq_flags = IRQF_TRIGGER_LOW;
> -
> - ret = devm_request_threaded_irq(&spi->dev, rmi_spi->irq, NULL,
> - rmi_spi_irq, irq_flags | IRQF_ONESHOT,
> - dev_name(&spi->dev), rmi_spi);
> - if (ret < 0) {
> - dev_warn(&spi->dev, "Failed to register interrupt %d\n",
> - rmi_spi->irq);
> - return ret;
> - }
> -
> - return 0;
> -}
> -
> #ifdef CONFIG_OF
> static int rmi_spi_of_probe(struct spi_device *spi,
> struct rmi_device_platform_data *pdata)
> @@ -433,8 +395,7 @@ static int rmi_spi_probe(struct spi_device *spi)
> return retval;
> }
>
> - if (spi->irq > 0)
> - rmi_spi->irq = spi->irq;
> + pdata->irq = spi->irq;
>
> rmi_spi->spi = spi;
> mutex_init(&rmi_spi->page_mutex);
> @@ -465,10 +426,6 @@ static int rmi_spi_probe(struct spi_device *spi)
> return retval;
> }
>
> - retval = rmi_spi_init_irq(spi);
> - if (retval < 0)
> - return retval;
> -
> dev_info(&spi->dev, "registered RMI SPI driver\n");
> return 0;
> }
> @@ -489,17 +446,10 @@ static int rmi_spi_suspend(struct device *dev)
> struct rmi_spi_xport *rmi_spi = spi_get_drvdata(spi);
> int ret;
>
> - ret = rmi_driver_suspend(rmi_spi->xport.rmi_dev);
> + ret = rmi_driver_suspend(rmi_spi->xport.rmi_dev, true);
> if (ret)
> dev_warn(dev, "Failed to resume device: %d\n", ret);
>
> - disable_irq(rmi_spi->irq);
> - if (device_may_wakeup(&spi->dev)) {
> - ret = enable_irq_wake(rmi_spi->irq);
> - if (!ret)
> - dev_warn(dev, "Failed to enable irq for wake: %d\n",
> - ret);
> - }
> return ret;
> }
>
> @@ -509,15 +459,7 @@ static int rmi_spi_resume(struct device *dev)
> struct rmi_spi_xport *rmi_spi = spi_get_drvdata(spi);
> int ret;
>
> - enable_irq(rmi_spi->irq);
> - if (device_may_wakeup(&spi->dev)) {
> - ret = disable_irq_wake(rmi_spi->irq);
> - if (!ret)
> - dev_warn(dev, "Failed to disable irq for wake: %d\n",
> - ret);
> - }
> -
> - ret = rmi_driver_resume(rmi_spi->xport.rmi_dev);
> + ret = rmi_driver_resume(rmi_spi->xport.rmi_dev, true);
> if (ret)
> dev_warn(dev, "Failed to resume device: %d\n", ret);
>
> @@ -532,12 +474,10 @@ static int rmi_spi_runtime_suspend(struct device *dev)
> struct rmi_spi_xport *rmi_spi = spi_get_drvdata(spi);
> int ret;
>
> - ret = rmi_driver_suspend(rmi_spi->xport.rmi_dev);
> + ret = rmi_driver_suspend(rmi_spi->xport.rmi_dev, false);
> if (ret)
> dev_warn(dev, "Failed to resume device: %d\n", ret);
>
> - disable_irq(rmi_spi->irq);
> -
> return 0;
> }
>
> @@ -547,9 +487,7 @@ static int rmi_spi_runtime_resume(struct device *dev)
> struct rmi_spi_xport *rmi_spi = spi_get_drvdata(spi);
> int ret;
>
> - enable_irq(rmi_spi->irq);
> -
> - ret = rmi_driver_resume(rmi_spi->xport.rmi_dev);
> + ret = rmi_driver_resume(rmi_spi->xport.rmi_dev, false);
> if (ret)
> dev_warn(dev, "Failed to resume device: %d\n", ret);
>
> diff --git a/include/linux/rmi.h b/include/linux/rmi.h
> index e0aca14..5944e6c 100644
> --- a/include/linux/rmi.h
> +++ b/include/linux/rmi.h
> @@ -204,9 +204,11 @@ struct rmi_device_platform_data_spi {
> * @reset_delay_ms - after issuing a reset command to the touch sensor, the
> * driver waits a few milliseconds to give the firmware a chance to
> * to re-initialize. You can override the default wait period here.
> + * @irq: irq associated with the attn gpio line, or negative
> */
> struct rmi_device_platform_data {
> int reset_delay_ms;
> + int irq;
>
> struct rmi_device_platform_data_spi spi_data;
>
> @@ -352,8 +354,7 @@ struct rmi_driver_data {
>
> int rmi_register_transport_device(struct rmi_transport_dev *xport);
> void rmi_unregister_transport_device(struct rmi_transport_dev *xport);
> -int rmi_process_interrupt_requests(struct rmi_device *rmi_dev);
>
> -int rmi_driver_suspend(struct rmi_device *rmi_dev);
> -int rmi_driver_resume(struct rmi_device *rmi_dev);
> +int rmi_driver_suspend(struct rmi_device *rmi_dev, bool enable_wake);
> +int rmi_driver_resume(struct rmi_device *rmi_dev, bool clear_wake);
> #endif
> --
> 2.7.4
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 03/18] Input: synaptics-rmi4 - Handle incomplete input data
From: Dmitry Torokhov @ 2016-11-09 0:46 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Andrew Duggan, Lyude Paul, Christopher Heiny, Nick Dyer,
Bjorn Andersson, Dennis Wassenberg, linux-kernel, linux-input
In-Reply-To: <1476373872-18027-4-git-send-email-benjamin.tissoires@redhat.com>
On Thu, Oct 13, 2016 at 05:50:57PM +0200, Benjamin Tissoires wrote:
> From: Andrew Duggan <aduggan@synaptics.com>
>
> Commit 5b65c2a02966 ("HID: rmi: check sanity of the incoming report") added
> support for handling incomplete HID reports do to the input data being
> corrupted in transit. This patch reimplements this functionality in the
> function drivers so they can handle getting less valid data then they
> expect.
>
> Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Applied, thank you.
>
> ---
>
> new in v3
> ---
> drivers/input/rmi4/rmi_f11.c | 54 ++++++++++++++++++++++++++++++++------------
> drivers/input/rmi4/rmi_f12.c | 23 ++++++++++++++-----
> drivers/input/rmi4/rmi_f30.c | 4 ++++
> 3 files changed, 61 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
> index 20c7134..3218742 100644
> --- a/drivers/input/rmi4/rmi_f11.c
> +++ b/drivers/input/rmi4/rmi_f11.c
> @@ -572,31 +572,48 @@ static inline u8 rmi_f11_parse_finger_state(const u8 *f_state, u8 n_finger)
>
> static void rmi_f11_finger_handler(struct f11_data *f11,
> struct rmi_2d_sensor *sensor,
> - unsigned long *irq_bits, int num_irq_regs)
> + unsigned long *irq_bits, int num_irq_regs,
> + int size)
> {
> const u8 *f_state = f11->data.f_state;
> u8 finger_state;
> u8 i;
> + int abs_fingers;
> + int rel_fingers;
> + int abs_size = sensor->nbr_fingers * RMI_F11_ABS_BYTES;
>
> int abs_bits = bitmap_and(f11->result_bits, irq_bits, f11->abs_mask,
> num_irq_regs * 8);
> int rel_bits = bitmap_and(f11->result_bits, irq_bits, f11->rel_mask,
> num_irq_regs * 8);
>
> - for (i = 0; i < sensor->nbr_fingers; i++) {
> - /* Possible of having 4 fingers per f_statet register */
> - finger_state = rmi_f11_parse_finger_state(f_state, i);
> - if (finger_state == F11_RESERVED) {
> - pr_err("Invalid finger state[%d]: 0x%02x", i,
> - finger_state);
> - continue;
> - }
> + if (abs_bits) {
> + if (abs_size > size)
> + abs_fingers = size / RMI_F11_ABS_BYTES;
> + else
> + abs_fingers = sensor->nbr_fingers;
> +
> + for (i = 0; i < abs_fingers; i++) {
> + /* Possible of having 4 fingers per f_state register */
> + finger_state = rmi_f11_parse_finger_state(f_state, i);
> + if (finger_state == F11_RESERVED) {
> + pr_err("Invalid finger state[%d]: 0x%02x", i,
> + finger_state);
> + continue;
> + }
>
> - if (abs_bits)
> rmi_f11_abs_pos_process(f11, sensor, &sensor->objs[i],
> finger_state, i);
> + }
> + }
> +
> + if (rel_bits) {
> + if ((abs_size + sensor->nbr_fingers * RMI_F11_REL_BYTES) > size)
> + rel_fingers = (size - abs_size) / RMI_F11_REL_BYTES;
> + else
> + rel_fingers = sensor->nbr_fingers;
>
> - if (rel_bits)
> + for (i = 0; i < rel_fingers; i++)
> rmi_f11_rel_pos_report(f11, i);
> }
>
> @@ -612,7 +629,7 @@ static void rmi_f11_finger_handler(struct f11_data *f11,
> sensor->nbr_fingers,
> sensor->dmax);
>
> - for (i = 0; i < sensor->nbr_fingers; i++) {
> + for (i = 0; i < abs_fingers; i++) {
> finger_state = rmi_f11_parse_finger_state(f_state, i);
> if (finger_state == F11_RESERVED)
> /* no need to send twice the error */
> @@ -1242,10 +1259,19 @@ static int rmi_f11_attention(struct rmi_function *fn, unsigned long *irq_bits)
> struct f11_data *f11 = dev_get_drvdata(&fn->dev);
> u16 data_base_addr = fn->fd.data_base_addr;
> int error;
> + int valid_bytes = f11->sensor.pkt_size;
>
> if (rmi_dev->xport->attn_data) {
> + /*
> + * The valid data in the attention report is less then
> + * expected. Only process the complete fingers.
> + */
> + if (f11->sensor.attn_size > rmi_dev->xport->attn_size)
> + valid_bytes = rmi_dev->xport->attn_size;
> + else
> + valid_bytes = f11->sensor.attn_size;
> memcpy(f11->sensor.data_pkt, rmi_dev->xport->attn_data,
> - f11->sensor.attn_size);
> + valid_bytes);
> rmi_dev->xport->attn_data += f11->sensor.attn_size;
> rmi_dev->xport->attn_size -= f11->sensor.attn_size;
> } else {
> @@ -1257,7 +1283,7 @@ static int rmi_f11_attention(struct rmi_function *fn, unsigned long *irq_bits)
> }
>
> rmi_f11_finger_handler(f11, &f11->sensor, irq_bits,
> - drvdata->num_of_irq_regs);
> + drvdata->num_of_irq_regs, valid_bytes);
>
> return 0;
> }
> diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
> index 332c02f..767ac79 100644
> --- a/drivers/input/rmi4/rmi_f12.c
> +++ b/drivers/input/rmi4/rmi_f12.c
> @@ -26,6 +26,8 @@ enum rmi_f12_object_type {
> RMI_F12_OBJECT_SMALL_OBJECT = 0x0D,
> };
>
> +#define F12_DATA1_BYTES_PER_OBJ 8
> +
> struct f12_data {
> struct rmi_2d_sensor sensor;
> struct rmi_2d_sensor_platform_data sensor_pdata;
> @@ -146,12 +148,16 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
> return 0;
> }
>
> -static void rmi_f12_process_objects(struct f12_data *f12, u8 *data1)
> +static void rmi_f12_process_objects(struct f12_data *f12, u8 *data1, int size)
> {
> int i;
> struct rmi_2d_sensor *sensor = &f12->sensor;
> + int objects = f12->data1->num_subpackets;
> +
> + if ((f12->data1->num_subpackets * F12_DATA1_BYTES_PER_OBJ) > size)
> + objects = size / F12_DATA1_BYTES_PER_OBJ;
>
> - for (i = 0; i < f12->data1->num_subpackets; i++) {
> + for (i = 0; i < objects; i++) {
> struct rmi_2d_sensor_abs_object *obj = &sensor->objs[i];
>
> obj->type = RMI_2D_OBJECT_NONE;
> @@ -182,7 +188,7 @@ static void rmi_f12_process_objects(struct f12_data *f12, u8 *data1)
>
> rmi_2d_sensor_abs_process(sensor, obj, i);
>
> - data1 += 8;
> + data1 += F12_DATA1_BYTES_PER_OBJ;
> }
>
> if (sensor->kernel_tracking)
> @@ -192,7 +198,7 @@ static void rmi_f12_process_objects(struct f12_data *f12, u8 *data1)
> sensor->nbr_fingers,
> sensor->dmax);
>
> - for (i = 0; i < sensor->nbr_fingers; i++)
> + for (i = 0; i < objects; i++)
> rmi_2d_sensor_abs_report(sensor, &sensor->objs[i], i);
> }
>
> @@ -203,10 +209,15 @@ static int rmi_f12_attention(struct rmi_function *fn,
> struct rmi_device *rmi_dev = fn->rmi_dev;
> struct f12_data *f12 = dev_get_drvdata(&fn->dev);
> struct rmi_2d_sensor *sensor = &f12->sensor;
> + int valid_bytes = sensor->pkt_size;
>
> if (rmi_dev->xport->attn_data) {
> + if (sensor->attn_size > rmi_dev->xport->attn_size)
> + valid_bytes = rmi_dev->xport->attn_size;
> + else
> + valid_bytes = sensor->attn_size;
> memcpy(sensor->data_pkt, rmi_dev->xport->attn_data,
> - sensor->attn_size);
> + valid_bytes);
> rmi_dev->xport->attn_data += sensor->attn_size;
> rmi_dev->xport->attn_size -= sensor->attn_size;
> } else {
> @@ -221,7 +232,7 @@ static int rmi_f12_attention(struct rmi_function *fn,
>
> if (f12->data1)
> rmi_f12_process_objects(f12,
> - &sensor->data_pkt[f12->data1_offset]);
> + &sensor->data_pkt[f12->data1_offset], valid_bytes);
>
> input_mt_sync_frame(sensor->input);
>
> diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
> index 760aff1..485907f 100644
> --- a/drivers/input/rmi4/rmi_f30.c
> +++ b/drivers/input/rmi4/rmi_f30.c
> @@ -110,6 +110,10 @@ static int rmi_f30_attention(struct rmi_function *fn, unsigned long *irq_bits)
>
> /* Read the gpi led data. */
> if (rmi_dev->xport->attn_data) {
> + if (rmi_dev->xport->attn_size < f30->register_count) {
> + dev_warn(&fn->dev, "F30 interrupted, but data is missing\n");
> + return 0;
> + }
> memcpy(f30->data_regs, rmi_dev->xport->attn_data,
> f30->register_count);
> rmi_dev->xport->attn_data += f30->register_count;
> --
> 2.7.4
>
--
Dmitry
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] docs: add document to explain the usage of vNVDIMM
From: Haozhong Zhang @ 2016-11-09 0:46 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: qemu-devel, Xiao Guangrong
In-Reply-To: <20161108165004.GA2593@work-vm>
On 11/08/16 16:50 +0000, Dr. David Alan Gilbert wrote:
>* Haozhong Zhang (haozhong.zhang@intel.com) wrote:
[..]
>> +Label
>> +-----
>> +
>> +QEMU v2.7.0 and later implement the label support for vNVDIMM devices.
>> +To enable label on vNVDIMM devices, users can simply add
>> +"label-size=$SZ" option to "-device nvdimm", e.g.
>> +
>> + -device nvdimm,id=nvdimm1,memdev=mem1,label_size=128K
>
>Is that label-size rather than label_size ?
>
label-size. I'll update in the next version.
Thanks,
Haozhong
[..]
^ permalink raw reply
* Re: [Qemu-arm] [PATCH 4/5] MAINTAINERS: Add an entry for the CHRP NVRAM files
From: David Gibson @ 2016-11-09 0:38 UTC (permalink / raw)
To: Thomas Huth
Cc: Fam Zheng, qemu-devel, Mark Cave-Ayland, Laurent Vivier,
Max Reitz, qemu-arm, Paolo Bonzini, John Snow
In-Reply-To: <1478607473-25851-5-git-send-email-thuth@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]
On Tue, Nov 08, 2016 at 01:17:52PM +0100, Thomas Huth wrote:
> I recently added new files to the source tree that are not
> covered by any maintainer yet -- and since every new source
> file should have a maintainer nowadays, I volunteer to look
> after these files now, too.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> MAINTAINERS | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d8b584..05b1c97 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1093,6 +1093,13 @@ S: Maintained
> F: hw/core/generic-loader.c
> F: include/hw/core/generic-loader.h
>
> +CHRP NVRAM
> +M: Thomas Huth <thuth@redhat.com>
> +S: Maintained
> +F: hw/nvram/chrp_nvram.c
> +F: include/hw/nvram/chrp_nvram.h
> +F: tests/prom-env-test.c
> +
> Subsystems
> ----------
> Audio
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 4/5] MAINTAINERS: Add an entry for the CHRP NVRAM files
From: David Gibson @ 2016-11-09 0:38 UTC (permalink / raw)
To: Thomas Huth
Cc: Laurent Vivier, qemu-devel, qemu-arm, Max Reitz, John Snow,
Fam Zheng, Paolo Bonzini, Mark Cave-Ayland
In-Reply-To: <1478607473-25851-5-git-send-email-thuth@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]
On Tue, Nov 08, 2016 at 01:17:52PM +0100, Thomas Huth wrote:
> I recently added new files to the source tree that are not
> covered by any maintainer yet -- and since every new source
> file should have a maintainer nowadays, I volunteer to look
> after these files now, too.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> MAINTAINERS | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d8b584..05b1c97 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1093,6 +1093,13 @@ S: Maintained
> F: hw/core/generic-loader.c
> F: include/hw/core/generic-loader.h
>
> +CHRP NVRAM
> +M: Thomas Huth <thuth@redhat.com>
> +S: Maintained
> +F: hw/nvram/chrp_nvram.c
> +F: include/hw/nvram/chrp_nvram.h
> +F: tests/prom-env-test.c
> +
> Subsystems
> ----------
> Audio
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [Patch v2 12/14] ltp: Reduce duplication in MIPS variants.
From: Khem Raj @ 2016-11-09 0:46 UTC (permalink / raw)
To: Burton, Ross, Zubair Lutfullah Kakakhel; +Cc: OE-core
In-Reply-To: <CAJTo0LZTHPYsot=YkNGXh=p2AP37X89JqW2xMgdYjanftpDxxQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 467 bytes --]
On 11/8/16 4:13 PM, Burton, Ross wrote:
>
> On 8 November 2016 at 17:12, Zubair Lutfullah Kakakhel
> <Zubair.Kakakhel@imgtec.com <mailto:Zubair.Kakakhel@imgtec.com>> wrote:
>
> Reduce duplication in MIPS variants now that the MACHINEOVERRIDES
> variable is defined
>
>
> I'm guessing that this is the cause of this error for qemumips64:
>
> http://errors.yoctoproject.org/Errors/Details/99744/
seems to be yes.
>
> Ross
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: [PATCH] u-boot: mkimage: Fix build of u-boot-mkimage
From: Burton, Ross @ 2016-11-09 0:45 UTC (permalink / raw)
To: Khem Raj; +Cc: Marek Vasut, OE-core
In-Reply-To: <03d91527-2e2f-0694-8339-22fe7158880e@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
On 9 November 2016 at 00:43, Khem Raj <raj.khem@gmail.com> wrote:
> > I'm guessing that it is using the host compiler instead of the cross
> compiler.
>
> isnt mkimage a host tool ? why are we building it for target ?
>
If there's no chance that it will be ran on the target for in a SDK then
patches welcome to force the recipe to native only.
The recipe is using _append without adding whitespace, but fixing that
doesn't fix the build.
Ross
[-- Attachment #2: Type: text/html, Size: 910 bytes --]
^ permalink raw reply
* Re: [PATCH kernel v4 3/4] vfio/spapr: Reference mm in tce_container
From: David Gibson @ 2016-11-09 0:46 UTC (permalink / raw)
To: Alex Williamson
Cc: Alexey Kardashevskiy, linuxppc-dev, Nicholas Piggin,
Paul Mackerras
In-Reply-To: <20161108152519.7bfadf32@t450s.home>
[-- Attachment #1: Type: text/plain, Size: 10753 bytes --]
On Tue, Nov 08, 2016 at 03:25:19PM -0700, Alex Williamson wrote:
> On Mon, 24 Oct 2016 17:53:09 +1100
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>
> > In some situations the userspace memory context may live longer than
> > the userspace process itself so if we need to do proper memory context
> > cleanup, we better have tce_container take a reference to mm_struct and
> > use it later when the process is gone (@current or @current->mm is NULL).
> >
> > This references mm and stores the pointer in the container; this is done
> > when a container is just created so checking for !current->mm in other
> > places becomes pointless.
> >
> > This replaces current->mm with container->mm everywhere except debug
> > prints.
> >
> > This adds a check that current->mm is the same as the one stored in
> > the container to prevent userspace from making changes to a memory
> > context of other processes; in order to add this check,
> > VFIO_CHECK_EXTENSION is moved out of the switch(cmd) as it is
> > quite special anyway - it is the only ioctl() called when neither
> > container nor container->mm is initialized.
> >
> > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > ---
> > Changes:
> > v4:
> > * added check for container->mm!=current->mm in tce_iommu_ioctl()
> > for all ioctls and removed other redundand checks
> > ---
> > drivers/vfio/vfio_iommu_spapr_tce.c | 131 ++++++++++++++++++------------------
> > 1 file changed, 66 insertions(+), 65 deletions(-)
> >
> > diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
> > index d0c38b2..81ab93f 100644
> > --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> > +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> > @@ -31,49 +31,46 @@
> > static void tce_iommu_detach_group(void *iommu_data,
> > struct iommu_group *iommu_group);
> >
> > -static long try_increment_locked_vm(long npages)
> > +static long try_increment_locked_vm(struct mm_struct *mm, long npages)
> > {
> > long ret = 0, locked, lock_limit;
> >
> > - if (!current || !current->mm)
> > - return -ESRCH; /* process exited */
> > -
> > if (!npages)
> > return 0;
> >
> > - down_write(¤t->mm->mmap_sem);
> > - locked = current->mm->locked_vm + npages;
> > + down_write(&mm->mmap_sem);
> > + locked = mm->locked_vm + npages;
> > lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> > if (locked > lock_limit && !capable(CAP_IPC_LOCK))
> > ret = -ENOMEM;
> > else
> > - current->mm->locked_vm += npages;
> > + mm->locked_vm += npages;
> >
> > pr_debug("[%d] RLIMIT_MEMLOCK +%ld %ld/%ld%s\n", current->pid,
> > npages << PAGE_SHIFT,
> > - current->mm->locked_vm << PAGE_SHIFT,
> > + mm->locked_vm << PAGE_SHIFT,
> > rlimit(RLIMIT_MEMLOCK),
> > ret ? " - exceeded" : "");
> >
> > - up_write(¤t->mm->mmap_sem);
> > + up_write(&mm->mmap_sem);
> >
> > return ret;
> > }
> >
> > -static void decrement_locked_vm(long npages)
> > +static void decrement_locked_vm(struct mm_struct *mm, long npages)
> > {
> > - if (!current || !current->mm || !npages)
> > - return; /* process exited */
> > + if (!npages)
> > + return;
> >
> > - down_write(¤t->mm->mmap_sem);
> > - if (WARN_ON_ONCE(npages > current->mm->locked_vm))
> > - npages = current->mm->locked_vm;
> > - current->mm->locked_vm -= npages;
> > + down_write(&mm->mmap_sem);
> > + if (WARN_ON_ONCE(npages > mm->locked_vm))
> > + npages = mm->locked_vm;
> > + mm->locked_vm -= npages;
> > pr_debug("[%d] RLIMIT_MEMLOCK -%ld %ld/%ld\n", current->pid,
> > npages << PAGE_SHIFT,
> > - current->mm->locked_vm << PAGE_SHIFT,
> > + mm->locked_vm << PAGE_SHIFT,
> > rlimit(RLIMIT_MEMLOCK));
> > - up_write(¤t->mm->mmap_sem);
> > + up_write(&mm->mmap_sem);
> > }
> >
> > /*
> > @@ -98,6 +95,7 @@ struct tce_container {
> > bool enabled;
> > bool v2;
> > unsigned long locked_pages;
> > + struct mm_struct *mm;
> > struct iommu_table *tables[IOMMU_TABLE_GROUP_MAX_TABLES];
> > struct list_head group_list;
> > };
> > @@ -107,17 +105,14 @@ static long tce_iommu_unregister_pages(struct tce_container *container,
> > {
> > struct mm_iommu_table_group_mem_t *mem;
> >
> > - if (!current || !current->mm)
> > - return -ESRCH; /* process exited */
> > -
> > if ((vaddr & ~PAGE_MASK) || (size & ~PAGE_MASK))
> > return -EINVAL;
> >
> > - mem = mm_iommu_find(current->mm, vaddr, size >> PAGE_SHIFT);
> > + mem = mm_iommu_find(container->mm, vaddr, size >> PAGE_SHIFT);
> > if (!mem)
> > return -ENOENT;
> >
> > - return mm_iommu_put(current->mm, mem);
> > + return mm_iommu_put(container->mm, mem);
> > }
> >
> > static long tce_iommu_register_pages(struct tce_container *container,
> > @@ -127,14 +122,11 @@ static long tce_iommu_register_pages(struct tce_container *container,
> > struct mm_iommu_table_group_mem_t *mem = NULL;
> > unsigned long entries = size >> PAGE_SHIFT;
> >
> > - if (!current || !current->mm)
> > - return -ESRCH; /* process exited */
> > -
> > if ((vaddr & ~PAGE_MASK) || (size & ~PAGE_MASK) ||
> > ((vaddr + size) < vaddr))
> > return -EINVAL;
> >
> > - ret = mm_iommu_get(current->mm, vaddr, entries, &mem);
> > + ret = mm_iommu_get(container->mm, vaddr, entries, &mem);
> > if (ret)
> > return ret;
> >
> > @@ -143,7 +135,8 @@ static long tce_iommu_register_pages(struct tce_container *container,
> > return 0;
> > }
> >
> > -static long tce_iommu_userspace_view_alloc(struct iommu_table *tbl)
> > +static long tce_iommu_userspace_view_alloc(struct iommu_table *tbl,
> > + struct mm_struct *mm)
> > {
> > unsigned long cb = _ALIGN_UP(sizeof(tbl->it_userspace[0]) *
> > tbl->it_size, PAGE_SIZE);
> > @@ -152,13 +145,13 @@ static long tce_iommu_userspace_view_alloc(struct iommu_table *tbl)
> >
> > BUG_ON(tbl->it_userspace);
> >
> > - ret = try_increment_locked_vm(cb >> PAGE_SHIFT);
> > + ret = try_increment_locked_vm(mm, cb >> PAGE_SHIFT);
> > if (ret)
> > return ret;
> >
> > uas = vzalloc(cb);
> > if (!uas) {
> > - decrement_locked_vm(cb >> PAGE_SHIFT);
> > + decrement_locked_vm(mm, cb >> PAGE_SHIFT);
> > return -ENOMEM;
> > }
> > tbl->it_userspace = uas;
> > @@ -166,7 +159,8 @@ static long tce_iommu_userspace_view_alloc(struct iommu_table *tbl)
> > return 0;
> > }
> >
> > -static void tce_iommu_userspace_view_free(struct iommu_table *tbl)
> > +static void tce_iommu_userspace_view_free(struct iommu_table *tbl,
> > + struct mm_struct *mm)
> > {
> > unsigned long cb = _ALIGN_UP(sizeof(tbl->it_userspace[0]) *
> > tbl->it_size, PAGE_SIZE);
> > @@ -176,7 +170,7 @@ static void tce_iommu_userspace_view_free(struct iommu_table *tbl)
> >
> > vfree(tbl->it_userspace);
> > tbl->it_userspace = NULL;
> > - decrement_locked_vm(cb >> PAGE_SHIFT);
> > + decrement_locked_vm(mm, cb >> PAGE_SHIFT);
> > }
> >
> > static bool tce_page_is_contained(struct page *page, unsigned page_shift)
> > @@ -236,9 +230,6 @@ static int tce_iommu_enable(struct tce_container *container)
> > struct iommu_table_group *table_group;
> > struct tce_iommu_group *tcegrp;
> >
> > - if (!current->mm)
> > - return -ESRCH; /* process exited */
> > -
> > if (container->enabled)
> > return -EBUSY;
> >
> > @@ -284,7 +275,7 @@ static int tce_iommu_enable(struct tce_container *container)
> > return -EPERM;
> >
> > locked = table_group->tce32_size >> PAGE_SHIFT;
> > - ret = try_increment_locked_vm(locked);
> > + ret = try_increment_locked_vm(container->mm, locked);
> > if (ret)
> > return ret;
> >
> > @@ -302,10 +293,7 @@ static void tce_iommu_disable(struct tce_container *container)
> >
> > container->enabled = false;
> >
> > - if (!current->mm)
> > - return;
> > -
> > - decrement_locked_vm(container->locked_pages);
> > + decrement_locked_vm(container->mm, container->locked_pages);
> > }
> >
> > static void *tce_iommu_open(unsigned long arg)
> > @@ -326,13 +314,18 @@ static void *tce_iommu_open(unsigned long arg)
> >
> > container->v2 = arg == VFIO_SPAPR_TCE_v2_IOMMU;
> >
> > + /* current->mm cannot be NULL in this context */
> > + container->mm = current->mm;
> > + atomic_inc(&container->mm->mm_count);
>
> Are you sure you wouldn't rather do this on the actual
> preregistration? The advise I gave to Kirti for mdev was that it's
> currently possible to have a configuration where a privileged user
> opens a container, adds a group, sets the iommu, and then passes the
> file descriptors to another user. We can then set an mm once mappings,
> or preregistration occurs, and from there require that the unmapping mm
> matches the mapping mm, or that both of those match the preregistration
> mm. I'm not sure I see any reason to impose that current->mm that
> performs this operation is the only one that's allowed to perform those
> later tasks.
>
> > +
> > return container;
> > }
> >
> > static int tce_iommu_clear(struct tce_container *container,
> > struct iommu_table *tbl,
> > unsigned long entry, unsigned long pages);
> > -static void tce_iommu_free_table(struct iommu_table *tbl);
> > +static void tce_iommu_free_table(struct tce_container *container,
> > + struct iommu_table *tbl);
> >
> > static void tce_iommu_release(void *iommu_data)
> > {
> > @@ -357,10 +350,11 @@ static void tce_iommu_release(void *iommu_data)
> > continue;
> >
> > tce_iommu_clear(container, tbl, tbl->it_offset, tbl->it_size);
> > - tce_iommu_free_table(tbl);
> > + tce_iommu_free_table(container, tbl);
> > }
> >
> > tce_iommu_disable(container);
> > + mmdrop(container->mm);
>
> I imagine you'd still do this here, just:
>
> if (container->mm)
> mmdrop(container->mm);
>
> Of course you'd need to check how many places you'd need similar
> tests, maybe some of the current->mm tests would be converted to
> container->mm rather than dropped. Thanks,
Right, as you've implied here, the advantage of locking the mm on open
is simplicity - open always happens, and it always happens before
anything else, so there's no conditionals about whether we have or
haven't set the mm yet.
That said, you have just described a plausible use case where it's
useful to have one mm open the container, then another one use it, so
it might be worth adding that ability.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] pstore/dump: solution pstore data abort.
From: Kees Cook @ 2016-11-09 0:44 UTC (permalink / raw)
To: Li Pengcheng
Cc: Anton Vorontsov, Colin Cross, Tony Luck, LKML, liuhailong5,
lizhong11, liuyongfu, dan.zhao, suzhuangluan
In-Reply-To: <1478312159-32968-1-git-send-email-lipengcheng8@huawei.com>
On Fri, Nov 4, 2016 at 7:15 PM, Li Pengcheng <lipengcheng8@huawei.com> wrote:
> If not return,data abort will happen
> when two threads call pstore_dump at the same time.
>
> Signed-off-by: Liu Hailong <liuhailong5@huawei.com>
> Signed-off-by: Li Pengcheng <lipengcheng8@huawei.com>
> Signed-off-by: Li Zhong <lizhong11@hisilicon.com>
> ---
> fs/pstore/platform.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
> index 14984d9..60e6db6 100644
> --- a/fs/pstore/platform.c
> +++ b/fs/pstore/platform.c
> @@ -493,6 +493,7 @@ static void pstore_dump(struct kmsg_dumper *dumper,
> if (!is_locked) {
> pr_err("pstore dump routine blocked in %s path, may corrupt error record\n"
> , in_nmi() ? "NMI" : why);
> + return;
> }
> } else {
> spin_lock_irqsave(&psinfo->buf_lock, flags);
> --
> 1.9.1
Ah, thanks! I've queued this for -next.
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* RE: ACPI module-level code (MLC) not working?
From: Zheng, Lv @ 2016-11-09 0:43 UTC (permalink / raw)
To: Peter Wu
Cc: Rick Kerkhof, Bartosz Skrzypczak, Moore, Robert,
linux-acpi@vger.kernel.org
In-Reply-To: <20161109003250.GA16755@al>
Hi,
> -----Original Message-----
> From: Peter Wu [mailto:peter@lekensteyn.nl]
> Sent: Tuesday, November 8, 2016 4:33 PM
> To: Zheng, Lv <lv.zheng@intel.com>
> Cc: Rick Kerkhof <rick.2889@gmail.com>; Bartosz Skrzypczak <barteks2x@gmail.com>; Moore, Robert
> <robert.moore@intel.com>; linux-acpi@vger.kernel.org
> Subject: Re: ACPI module-level code (MLC) not working?
>
> On Wed, Nov 09, 2016 at 12:07:47AM +0000, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Peter Wu [mailto:peter@lekensteyn.nl]
> > > Subject: Re: ACPI module-level code (MLC) not working?
> > >
> > > On Tue, Nov 08, 2016 at 05:35:07PM +0000, Zheng, Lv wrote:
> > > > Hi,
> > > >
> > > > > From: Peter Wu [mailto:peter@lekensteyn.nl]
> > > > > Subject: ACPI module-level code (MLC) not working?
> > > > >
> > > > > Hi Lv,
> > > > >
> > > > > According to some tests, setting acpi_gbl_parse_table_as_term_list to
> > > > > TRUE does is not effective. The code within the If-block is still not
> > > > > executed early enough or something else is wrong.
> > > > >
> > > > > Previously Rick had an issue with an Acer Aspire V7-582PG where the dGPU
> > > > > could not be powered off and I demonstrated an isolated test case in
> > > > > http://www.spinics.net/lists/linux-acpi/msg70069.html
> > > > >
> > > > > In Bartosz's case, the dGPU cannot be powered on (also using nouveau),
> > > > > preventing suspend from working. Situation is as follows (tested with
> > > > > Linux 3.16, 4.8.4, 4.9-rc2, 4.9-rc4):
> > > > >
> > > > > His Lenovo IdeaPad Z510 laptop (BIOS date 2014) enables power resources
> > > > > and related _PR3 objects under the conditional If(_OSI("Windows 2013")).
> > > > > Both with and without acpi_gbl_parse_table_as_term_list set to TRUE, the
> > > > > module-level code is not loaded properly. Via a SSDT override, it was
> > > > > confirmed that removing the If conditional results in the expected
> > > > > behavior.
> > > > >
> > > > > Various details are given in https://github.com/Bumblebee-Project/bbswitch/issues/142
> > > > > including lots of dmesg logs (see posts at the bottom).
> > > > > With above MLC flag set (v4.9-rc4): https://pastebin.com/raw/vCEPGezX
> > > > > With SSDT override (v4.9-rc2): https://pastebin.com/raw/3Fsf2VPU
> > > >
> > > > I checked the post.
> > > > It seems the current working way is: disabling _OSI(Windows 2013) which disables power resources.
> > >
> > > That is how Lenovo probably intended to use it (only add Power Resources
> > > when Windows 8 is detected).
> > >
> > > > I have several questions related to this issue:
> > > > 1. The following messages are prompt up when "acpi_gbl_parse_table_as_term_list = TRUE":
> > > > [ 2.519113] ACPI Error: [\_SB_.PCI0.GFX0.DD02._BCL] Namespace lookup failure, AE_NOT_FOUND
> > > (20160831/psargs-359)
> > > > [ 2.519121] ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG1.PEGP.DD02._BCL] (Node
> > > ffff8802568d3cf8), AE_NOT_FOUND (20160831/psparse-543)
> > > > How was this triggered?
> > >
> > > This comes from acpi_video.c, ssdt4.dsl contains a \_SB.PCI0.GFX0.DD02
> > > device with an _ADR method, but no _BCL one. It is not a regression
> > > though, let's ignore this for now.
> > >
> > > > 2. I noticed the following statement:
> > > > So, for some reason Lenovo has decided to give all tables the same name.
> > > > The ACPI table override functionality matches possible candidates by signature, OEM ID and
> OEM
> > > Revision ID which are all the same.
> > > > As a result, the wrong SSDT is overridden.
> > > > Could you provide the detail of the tables from the platform?
> > > > What is the reason of doing such kind of craps in BIOS?
> > >
> > > I have no idea why Lenovo would do such a silly thing, but that is why
> > > we had to patch tables.c with:
> > >
> > > if (existing_table->checksum != 0xAF) {
> > > acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
> > > pr_info("Skipping next table\n");
> > > goto next_table;
> > > }
> > >
> > > This is of course an unacceptable hard-coded value, but it was needed in
> > > as a quick hack. For a longterm solution, maybe we can name the table
> > > files specially such that additional match conditions can be given. This
> > > is a different issue though.
> > >
> > > What would you like to know about the platform? The acpidump is
> > > available at
> > > https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4773050/+files/LENOVO-
> 20287.tar.gz
> > >
> > > ssdt5.dsl is the file of interest, grep for "Windows 2013".
> >
> > The table headers are:
> >
> > DefinitionBlock ("dsdt.aml", "DSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> > DefinitionBlock ("ssdt1.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> > DefinitionBlock ("ssdt2.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> > DefinitionBlock ("ssdt3.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> > DefinitionBlock ("ssdt4.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> > DefinitionBlock ("ssdt5.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> >
> > They will be deemed as different versions of the same table from linux ACPI's point of view.
> > Whether override will be done or not depends on Linux version.
>
> When I mentioned override, I referred to the method described in
> Documentation/acpi/method-customizing.txt where any ACPI table can be
> overridden via the initrd. Indeed, that method is unable to pick
> arbitrary tables when they all have the same ID.
>
> > In recent Linux, ssdt1.aml will be used (no override), while in old Linux, ssdt5.aml will be used
> (override).
>
> Does this refer to the same override method as described above? The
> tables are loaded normally even if they have the same name.
>
> > Let me ask further.
> > 1. Should OSPM load only ssdt5.aml or load only ssdt1.aml, or load
> ssdt1.aml,ssdt2.aml,ssdt3.aml,ssdt4.aml,ssdt5.aml?
> > 2. Can you confirm Windows behavior here via amli?
> >
> > Anyway, this is a special case that violates spec and seems to be aiming to trigger regressions
> against changed logic brought by me.
> > No matter whether the change is reasonable.
>
> OSPM should load all tables, they are all different. Perhaps you are
> confusing this override method with how Linux normally loads tables?
> (Aren't the identifiers just used for visual purposes and irrelevant for
> normal operation?)
No, I'm not confusing it.
I want to know the exact behavior here.
Because I'm actually about to change acpi_tb_compare_tables().
This allows and acpi_install_table() invocations to override matched tables.
So I'll remove Linux table override callback.
Please see my recent comment in the following link:
https://github.com/Bumblebee-Project/bbswitch/issues/142
Thanks
Lv
>
> I have not checked Windows, but I would guess that it loads normally.
> Otherwise Lenovo QA has really been sleeping.
>
> Kind regards,
> Peter
>
> > Linux only need a quirk for this platform.
> >
> > Thanks
> > Lv
> >
> > >
> > > Kind regards,
> > > Peter
> > >
> > > > Thanks and best regards
> > > > Lv
> > > >
> > > > >
> > > > > If you would like a new bugzilla entry or have some patches to test, you
> > > > > know where to find us :)
> > > > > --
> > > > > Kind regards,
> > > > > Peter Wu
> > > > > https://lekensteyn.nl
^ permalink raw reply
* Re: [PATCH] u-boot: mkimage: Fix build of u-boot-mkimage
From: Khem Raj @ 2016-11-09 0:43 UTC (permalink / raw)
To: Burton, Ross, Marek Vasut; +Cc: OE-core
In-Reply-To: <CAJTo0LaSLN1eVRH1ju1w5Ba3PLh6d+E0ZwmRimxcN1DjKRk6iQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1232 bytes --]
On 11/8/16 4:15 PM, Burton, Ross wrote:
>
> On 7 November 2016 at 18:20, Marek Vasut <marex@denx.de
> <mailto:marex@denx.de>> wrote:
>
> -EXTRA_OEMAKE = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC} ${CFLAGS}
> ${LDFLAGS}" STRIP=true V=1'
> +EXTRA_OEMAKE = 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"'
> +EXTRA_OEMAKE_append_class-target = 'CROSS_COMPILE="${TARGET_PREFIX}"
> CC="${CC} ${CFLAGS} ${LDFLAGS}" STRIP=true V=1'
> +EXTRA_OEMAKE_append_class-native = 'CC="${BUILD_CC} ${BUILD_CFLAGS}
> ${BUILD_LDFLAGS}" STRIP=true V=1'
> +EXTRA_OEMAKE_append_class-nativesdk = 'CC="${BUILD_CC} ${BUILD_CFLAGS}
> ${BUILD_LDFLAGS}" STRIP=true V=1'
>
>
> You're going to start hating u-boot...
>
> Fails on the autobuilder if you're building for a 32-bit x86 target on a
> 64-bit x86 host:
>
> ERROR: QA Issue: Architecture did not match (x86-64, expected x86) on
> /work/i586-poky-linux-musl/u-boot-mkimage/1_2016.09.01-r0/packages-split/u-boot-mkimage/usr/bin/uboot-mkimage
> [arch]
>
> I'm guessing that it is using the host compiler instead of the cross compiler.
isnt mkimage a host tool ? why are we building it for target ?
>
> Ross
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 14/24] ARM: vITS: handle INT command
From: Stefano Stabellini @ 2016-11-09 0:42 UTC (permalink / raw)
To: Andre Przywara; +Cc: xen-devel, Julien Grall, Stefano Stabellini
In-Reply-To: <20160928182457.12433-15-andre.przywara@arm.com>
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The INT command sets a given LPI identified by a DeviceID/EventID pair
> as pending and thus triggers it to be injected.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> xen/arch/arm/vgic-its.c | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index 99d9e9c..7072753 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -192,6 +192,37 @@ static int its_handle_clear(struct virt_its *its, uint64_t *cmdptr)
> return 0;
> }
>
> +static int its_handle_int(struct virt_its *its, uint64_t *cmdptr)
> +{
> + uint32_t devid = its_cmd_get_deviceid(cmdptr);
> + uint32_t eventid = its_cmd_get_id(cmdptr);
> + struct vits_itte *itte;
> + struct vcpu *vcpu;
> + int ret = -1;
> + uint32_t vlpi;
> +
> + spin_lock(&its->its_lock);
> +
> + itte = get_devid_evid(its, devid, eventid);
> + if ( !itte )
> + goto out_unlock;
> +
> + vcpu = its->d->vcpu[itte->collection];
We need to check that itte->collection is a valid vcpu before using as
array index.
> + vlpi = itte->vlpi;
> +
> + ret = 0;
> +
> + put_devid_evid(its, itte);
> +
> +out_unlock:
> + spin_unlock(&its->its_lock);
> +
> + if ( !ret)
code style
> + vgic_vcpu_inject_irq(vcpu, vlpi);
> +
> + return ret;
> +}
> +
> #define ITS_CMD_BUFFER_SIZE(baser) ((((baser) & 0xff) + 1) << 12)
>
> static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> @@ -215,6 +246,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> case GITS_CMD_CLEAR:
> its_handle_clear(its, cmdptr);
> break;
> + case GITS_CMD_INT:
> + its_handle_int(its, cmdptr);
> + break;
> case GITS_CMD_SYNC:
> /* We handle ITS commands synchronously, so we ignore SYNC. */
> break;
> --
> 2.9.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v1 2/2] depmod: ignore related modules in depmod_report_cycles
From: Lucas De Marchi @ 2016-11-09 0:40 UTC (permalink / raw)
To: Mian Yousaf Kaukab
Cc: linux-modules, Lucas De Marchi, bjorn.andersson, afaerber
In-Reply-To: <1478623550-18716-2-git-send-email-yousaf.kaukab@suse.com>
On Tue, Nov 8, 2016 at 2:45 PM, Mian Yousaf Kaukab
<yousaf.kaukab@suse.com> wrote:
> Only print actual cyclic dependencies. Print count of all the modules
> in cyclic dependency at the end of the function so that dependent
> modules which are not in cyclic chain can be ignored.
>
> Printing dependent modules which are not in cyclic chain causes buffer
> overflow as m->modnamesz is not included in buffer size calculations
> (loop =3D=3D m is never true). This buffer overflow causes kmod to crash.
>
> Update depmod test to reflect the change as well.
>
> Reported-by: Andreas F=C3=A4rber <afaerber@suse.de>
> Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@suse.com>
> ---
> Change-log:
> v1: Keep the old output stings. Only change their order
> Add test case to reproduce the problem
>
> .../rootfs-pristine/test-depmod/detect-loop/correct.txt | 2 +-
> tools/depmod.c | 13 +++++++=
+++++-
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/testsuite/rootfs-pristine/test-depmod/detect-loop/correct.tx=
t b/testsuite/rootfs-pristine/test-depmod/detect-loop/correct.txt
> index 4eb26df..01ecb89 100644
> --- a/testsuite/rootfs-pristine/test-depmod/detect-loop/correct.txt
> +++ b/testsuite/rootfs-pristine/test-depmod/detect-loop/correct.txt
> @@ -1,3 +1,3 @@
> -depmod: ERROR: Found 5 modules in dependency cycles!
> depmod: ERROR: Cycle detected: mod_loop_d -> mod_loop_e -> mod_loop_d
> depmod: ERROR: Cycle detected: mod_loop_b -> mod_loop_c -> mod_loop_a ->=
mod_loop_b
> +depmod: ERROR: Found 5 modules in dependency cycles!
> diff --git a/tools/depmod.c b/tools/depmod.c
> index ad01f66..f2b370f 100644
> --- a/tools/depmod.c
> +++ b/tools/depmod.c
> @@ -1456,7 +1456,7 @@ static void depmod_report_cycles(struct depmod *dep=
mod, uint16_t n_mods,
> {
> const char sep[] =3D " -> ";
> int ir =3D 0;
> - ERR("Found %u modules in dependency cycles!\n", n_roots);
> + int num_cyclic =3D 0;
>
> while (n_roots > 0) {
> int is, ie;
> @@ -1491,6 +1491,7 @@ static void depmod_report_cycles(struct depmod *dep=
mod, uint16_t n_mods,
> if (m->visited) {
> int i, n =3D 0, sz =3D 0;
> char *buf;
> + bool is_cyclic =3D false;
>
> for (i =3D ie - 1; i >=3D 0; i--) {
> struct mod *loop =3D depmod->modu=
les.array[edges[i]];
> @@ -1498,9 +1499,17 @@ static void depmod_report_cycles(struct depmod *de=
pmod, uint16_t n_mods,
> n++;
> if (loop =3D=3D m) {
> sz +=3D loop->modnamesz -=
1;
> + is_cyclic =3D true;
> break;
> }
> }
> + /* Current module not found in dependency=
list.
> + * Must be a related module. Ignore it.
> + */
> + if (!is_cyclic)
> + continue;
> +
> + num_cyclic +=3D n;
>
> buf =3D malloc(sz + n * strlen(sep) + 1);
> sz =3D 0;
> @@ -1538,6 +1547,8 @@ static void depmod_report_cycles(struct depmod *dep=
mod, uint16_t n_mods,
> }
> }
> }
> +
> + ERR("Found %d modules in dependency cycles!\n", num_cyclic);
> }
thanks, much better now.
Applied.
Lucas De Marchi
^ permalink raw reply
* Re: [PATCH 2/2] kernel: Support compiling out the prctl syscall
From: Kees Cook @ 2016-11-09 0:40 UTC (permalink / raw)
To: Josh Triplett
Cc: Andrew Morton, Johannes Weiner, Arnd Bergmann, Ingo Molnar,
Andy Lutomirski, Petr Mladek, Thomas Garnier, Ard Biesheuvel,
Nicolas Pitre, Zefan Li, Li Bin, Eric W. Biederman, Dmitry Vyukov,
Ralf Baechle, Alex Thorlton, Michal Hocko, Mateusz Guzik,
Cyrill Gorcunov, John Stultz, Al Viro, Zach Brown, Anna Schumaker,
Dave Hansen, LKML, Linux API
In-Reply-To: <b5c45594261252a486b891090eba8f10aa7ed329.1478650356.git-series.josh@joshtriplett.org>
On Tue, Nov 8, 2016 at 4:18 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> Some embedded systems can do without the prctl syscall, saving some
> space.
>
> This also avoids regular increases in tinyconfig size as people add more
> non-optional functionality to prctl (observed via the 0-day kernel
> infrastructure).
>
> bloat-o-meter results:
>
> add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-2143 (-2143)
> function old new delta
> offsets 23 12 -11
> prctl_set_auxv 97 - -97
> sys_prctl 794 - -794
> prctl_set_mm 1241 - -1241
> Total: Before=1902583, After=1900440, chg -0.11%
>
> Signed-off-by: Josh Triplett <josh@joshtriplett.org>
I'm absolutely a fan of doing this, but I wonder how this interacts
with the LSMs that define prctl hooks, etc. I wouldn't expect a system
that didn't want prctl to want an LSM, but maybe the LSMs all need to
depend on CONFIG_PRCTL now?
-Kees
> ---
> init/Kconfig | 12 ++++++++++++
> kernel/Makefile | 3 ++-
> kernel/sys_ni.c | 1 +
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 34407f1..1dd671c 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1408,6 +1408,18 @@ config MULTIUSER
>
> If unsure, say Y here.
>
> +config PRCTL
> + bool "prctl syscall" if EXPERT
> + default y
> + help
> + This option enables the prctl syscall, used for a variety of
> + operations on the current process.
> +
> + If building an embedded system where no applications or libraries use
> + prctl, you can disable this option to save space.
> +
> + If unsure, say Y here.
> +
> config SGETMASK_SYSCALL
> bool "sgetmask/ssetmask syscalls support" if EXPERT
> def_bool PARISC || MN10300 || BLACKFIN || M68K || PPC || MIPS || X86 || SPARC || CRIS || MICROBLAZE || SUPERH
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 37c6d4c..43fb4ca 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -9,9 +9,10 @@ obj-y = fork.o exec_domain.o panic.o \
> extable.o params.o \
> kthread.o sys_ni.o nsproxy.o \
> notifier.o ksysfs.o cred.o reboot.o \
> - async.o range.o smpboot.o ucount.o prctl.o
> + async.o range.o smpboot.o ucount.o
>
> obj-$(CONFIG_MULTIUSER) += groups.o
> +obj-$(CONFIG_PRCTL) += prctl.o
>
> ifdef CONFIG_FUNCTION_TRACER
> # Do not trace internal ftrace files
> diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
> index 635482e..84fd646 100644
> --- a/kernel/sys_ni.c
> +++ b/kernel/sys_ni.c
> @@ -175,6 +175,7 @@ cond_syscall(sys_setfsgid);
> cond_syscall(sys_capget);
> cond_syscall(sys_capset);
> cond_syscall(sys_copy_file_range);
> +cond_syscall(sys_prctl);
>
> /* arch-specific weak syscall entries */
> cond_syscall(sys_pciconfig_read);
> --
> git-series 0.8.11
--
Kees Cook
Nexus Security
^ permalink raw reply
* Re: [PATCH 2/2] kernel: Support compiling out the prctl syscall
From: Kees Cook @ 2016-11-09 0:40 UTC (permalink / raw)
To: Josh Triplett
Cc: Andrew Morton, Johannes Weiner, Arnd Bergmann, Ingo Molnar,
Andy Lutomirski, Petr Mladek, Thomas Garnier, Ard Biesheuvel,
Nicolas Pitre, Zefan Li, Li Bin, Eric W. Biederman, Dmitry Vyukov,
Ralf Baechle, Alex Thorlton, Michal Hocko, Mateusz Guzik,
Cyrill Gorcunov, John Stultz, Al Viro, Zach Brown
In-Reply-To: <b5c45594261252a486b891090eba8f10aa7ed329.1478650356.git-series.josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>
On Tue, Nov 8, 2016 at 4:18 PM, Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org> wrote:
> Some embedded systems can do without the prctl syscall, saving some
> space.
>
> This also avoids regular increases in tinyconfig size as people add more
> non-optional functionality to prctl (observed via the 0-day kernel
> infrastructure).
>
> bloat-o-meter results:
>
> add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-2143 (-2143)
> function old new delta
> offsets 23 12 -11
> prctl_set_auxv 97 - -97
> sys_prctl 794 - -794
> prctl_set_mm 1241 - -1241
> Total: Before=1902583, After=1900440, chg -0.11%
>
> Signed-off-by: Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>
I'm absolutely a fan of doing this, but I wonder how this interacts
with the LSMs that define prctl hooks, etc. I wouldn't expect a system
that didn't want prctl to want an LSM, but maybe the LSMs all need to
depend on CONFIG_PRCTL now?
-Kees
> ---
> init/Kconfig | 12 ++++++++++++
> kernel/Makefile | 3 ++-
> kernel/sys_ni.c | 1 +
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 34407f1..1dd671c 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1408,6 +1408,18 @@ config MULTIUSER
>
> If unsure, say Y here.
>
> +config PRCTL
> + bool "prctl syscall" if EXPERT
> + default y
> + help
> + This option enables the prctl syscall, used for a variety of
> + operations on the current process.
> +
> + If building an embedded system where no applications or libraries use
> + prctl, you can disable this option to save space.
> +
> + If unsure, say Y here.
> +
> config SGETMASK_SYSCALL
> bool "sgetmask/ssetmask syscalls support" if EXPERT
> def_bool PARISC || MN10300 || BLACKFIN || M68K || PPC || MIPS || X86 || SPARC || CRIS || MICROBLAZE || SUPERH
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 37c6d4c..43fb4ca 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -9,9 +9,10 @@ obj-y = fork.o exec_domain.o panic.o \
> extable.o params.o \
> kthread.o sys_ni.o nsproxy.o \
> notifier.o ksysfs.o cred.o reboot.o \
> - async.o range.o smpboot.o ucount.o prctl.o
> + async.o range.o smpboot.o ucount.o
>
> obj-$(CONFIG_MULTIUSER) += groups.o
> +obj-$(CONFIG_PRCTL) += prctl.o
>
> ifdef CONFIG_FUNCTION_TRACER
> # Do not trace internal ftrace files
> diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
> index 635482e..84fd646 100644
> --- a/kernel/sys_ni.c
> +++ b/kernel/sys_ni.c
> @@ -175,6 +175,7 @@ cond_syscall(sys_setfsgid);
> cond_syscall(sys_capget);
> cond_syscall(sys_capset);
> cond_syscall(sys_copy_file_range);
> +cond_syscall(sys_prctl);
>
> /* arch-specific weak syscall entries */
> cond_syscall(sys_pciconfig_read);
> --
> git-series 0.8.11
--
Kees Cook
Nexus Security
^ permalink raw reply
* Re: [RFC PATCH 13/24] ARM: vITS: handle CLEAR command
From: Stefano Stabellini @ 2016-11-09 0:39 UTC (permalink / raw)
To: Andre Przywara; +Cc: xen-devel, Julien Grall, Stefano Stabellini
In-Reply-To: <20160928182457.12433-14-andre.przywara@arm.com>
On Wed, 28 Sep 2016, Andre Przywara wrote:
> This introduces the ITS command handler for the CLEAR command, which
> clears the pending state of an LPI.
> This removes a not-yet injected, but already queued IRQ from a VCPU.
>
> In addition this patch introduces the lookup function which translates
> a given DeviceID/EventID pair into a pointer to our vITTE structure.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> xen/arch/arm/vgic-its.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 115 insertions(+)
>
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index 875b992..99d9e9c 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -61,6 +61,73 @@ struct vits_itte
> uint64_t collection:16;
> };
>
> +#define UNMAPPED_COLLECTION ((uint16_t)~0)
> +
> +/* Must be called with the ITS lock held. */
> +static struct vcpu *get_vcpu_from_collection(struct virt_its *its, int collid)
> +{
> + uint16_t vcpu_id;
> +
> + if ( collid >= its->max_collections )
> + return NULL;
> +
> + vcpu_id = its->coll_table[collid];
> + if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
> + return NULL;
> +
> + return its->d->vcpu[vcpu_id];
> +}
> +
> +#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
> +#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(7, 0)) + 1))
> +#define DEV_TABLE_ENTRY(addr, bits) \
> + (((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(7, 0)))
> +
> +static paddr_t get_itte_address(struct virt_its *its,
> + uint32_t devid, uint32_t evid)
> +{
> + paddr_t addr;
> +
> + if ( devid >= its->max_devices )
> + return ~0;
Please #define the error
> + if ( evid >= DEV_TABLE_ITT_SIZE(its->dev_table[devid]) )
> + return ~0;
same here
> + addr = DEV_TABLE_ITT_ADDR(its->dev_table[devid]);
> +
> + return addr + evid * sizeof(struct vits_itte);
> +}
> +
> +/* Looks up a given deviceID/eventID pair on an ITS and returns a pointer to
> + * the corresponding ITTE. This maps the respective guest page into Xen.
> + * Once finished with handling the ITTE, call put_devid_evid() to unmap
> + * the page again.
> + * Must be called with the ITS lock held.
> + */
> +static struct vits_itte *get_devid_evid(struct virt_its *its,
> + uint32_t devid, uint32_t evid)
> +{
> + paddr_t addr = get_itte_address(its, devid, evid);
> + struct vits_itte *itte;
> +
> + if (addr == ~0)
> + return NULL;
> +
> + /* TODO: check locking for map_guest_pages() */
> + itte = map_guest_pages(its->d, addr & PAGE_MASK, 1);
> + if ( !itte )
> + return NULL;
No need to use the vmap to map 1 page
> + return itte + (addr & ~PAGE_MASK) / sizeof(struct vits_itte);
Please use () around the div operation for clarity
> +}
> +
> +/* Must be called with the ITS lock held. */
> +static void put_devid_evid(struct virt_its *its, struct vits_itte *itte)
> +{
> + unmap_guest_pages(itte, 1);
No need for this, once you use __pa instead of the vmap
> +}
> +
> /**************************************
> * Functions that handle ITS commands *
> **************************************/
> @@ -80,6 +147,51 @@ static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
> #define its_cmd_get_target_addr(cmd) its_cmd_mask_field(cmd, 2, 16, 32)
> #define its_cmd_get_validbit(cmd) its_cmd_mask_field(cmd, 2, 63, 1)
>
> +static int its_handle_clear(struct virt_its *its, uint64_t *cmdptr)
> +{
> + uint32_t devid = its_cmd_get_deviceid(cmdptr);
> + uint32_t eventid = its_cmd_get_id(cmdptr);
> + struct pending_irq *pirq;
> + struct vits_itte *itte;
> + struct vcpu *vcpu;
> + uint32_t vlpi;
> +
> + spin_lock(&its->its_lock);
> +
> + itte = get_devid_evid(its, devid, eventid);
> + if ( !itte )
> + {
> + spin_unlock(&its->its_lock);
> + return -1;
> + }
> +
> + vcpu = get_vcpu_from_collection(its, itte->collection);
> + if ( !vcpu )
> + {
> + spin_unlock(&its->its_lock);
> + return -1;
> + }
> +
> + vlpi = itte->vlpi;
> +
> + put_devid_evid(its, itte);
> + spin_unlock(&its->its_lock);
> +
> + /* Remove a pending, but not yet injected guest IRQ. */
We need to check that the vlpi hasn't already been added to an LR
register. We can do that with GIC_IRQ_GUEST_VISIBLE.
In case GIC_IRQ_GUEST_VISIBLE is set, we need to clear the lr
(clear_lr). If we don't handle this case, we should at least print a
warning.
> + pirq = lpi_to_pending(vcpu, vlpi, false);
> + if ( pirq )
> + {
> + clear_bit(GIC_IRQ_GUEST_QUEUED, &pirq->status);
> + gic_remove_from_queues(vcpu, vlpi);
> +
> + /* Mark this pending IRQ struct as availabe again. */
> + if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, &pirq->status) )
> + pirq->irq = 0;
> + }
> +
> + return 0;
> +}
> +
> #define ITS_CMD_BUFFER_SIZE(baser) ((((baser) & 0xff) + 1) << 12)
>
> static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> @@ -100,6 +212,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
> switch (its_cmd_get_command(cmdptr))
> {
> + case GITS_CMD_CLEAR:
> + its_handle_clear(its, cmdptr);
> + break;
> case GITS_CMD_SYNC:
> /* We handle ITS commands synchronously, so we ignore SYNC. */
> break;
> --
> 2.9.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH 2/2] rtc: jz4740: make the driver builtin only
From: Alexandre Belloni @ 2016-11-09 0:37 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Paul Cercueil, rtc-linux, linux-kernel, Alexandre Belloni
In-Reply-To: <20161109003753.29759-1-alexandre.belloni@free-electrons.com>
Since the driver is now calling machine_halt() that is not exported, it has
to be built in the kernel. Building it as a module will fail at linking
time.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/rtc/Kconfig | 5 +----
drivers/rtc/rtc-jz4740.c | 10 +---------
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 4259ce61c31b..24b0778f6e28 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1550,15 +1550,12 @@ config RTC_DRV_MPC5121
will be called rtc-mpc5121.
config RTC_DRV_JZ4740
- tristate "Ingenic JZ4740 SoC"
+ bool "Ingenic JZ4740 SoC"
depends on MACH_INGENIC || COMPILE_TEST
help
If you say yes here you get support for the Ingenic JZ47xx SoCs RTC
controllers.
- This driver can also be buillt as a module. If so, the module
- will be called rtc-jz4740.
-
config RTC_DRV_LPC24XX
tristate "NXP RTC for LPC178x/18xx/408x/43xx"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c
index 18feae6c4e95..72918c1ba092 100644
--- a/drivers/rtc/rtc-jz4740.c
+++ b/drivers/rtc/rtc-jz4740.c
@@ -17,7 +17,6 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/kernel.h>
-#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/reboot.h>
@@ -303,7 +302,6 @@ static const struct of_device_id jz4740_rtc_of_match[] = {
{ .compatible = "ingenic,jz4780-rtc", .data = (void *)ID_JZ4780 },
{},
};
-MODULE_DEVICE_TABLE(of, jz4740_rtc_of_match);
static int jz4740_rtc_probe(struct platform_device *pdev)
{
@@ -431,7 +429,6 @@ static const struct platform_device_id jz4740_rtc_ids[] = {
{ "jz4780-rtc", ID_JZ4780 },
{}
};
-MODULE_DEVICE_TABLE(platform, jz4740_rtc_ids);
static struct platform_driver jz4740_rtc_driver = {
.probe = jz4740_rtc_probe,
@@ -443,9 +440,4 @@ static struct platform_driver jz4740_rtc_driver = {
.id_table = jz4740_rtc_ids,
};
-module_platform_driver(jz4740_rtc_driver);
-
-MODULE_AUTHOR("Lars-Peter Clausen <lars@metafoo.de>");
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("RTC driver for the JZ4740 SoC\n");
-MODULE_ALIAS("platform:jz4740-rtc");
+builtin_platform_driver(jz4740_rtc_driver);
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] rtc: jz4740: remove unused EXPORT_SYMBOL
From: Alexandre Belloni @ 2016-11-09 0:37 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Paul Cercueil, rtc-linux, linux-kernel, Alexandre Belloni
jz4740_rtc_poweroff() is only called from the driver, stop exporting it.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/rtc/rtc-jz4740.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c
index 33ccd73ee947..18feae6c4e95 100644
--- a/drivers/rtc/rtc-jz4740.c
+++ b/drivers/rtc/rtc-jz4740.c
@@ -252,12 +252,11 @@ static irqreturn_t jz4740_rtc_irq(int irq, void *data)
return IRQ_HANDLED;
}
-void jz4740_rtc_poweroff(struct device *dev)
+static void jz4740_rtc_poweroff(struct device *dev)
{
struct jz4740_rtc *rtc = dev_get_drvdata(dev);
jz4740_rtc_reg_write(rtc, JZ_REG_RTC_HIBERNATE, 1);
}
-EXPORT_SYMBOL_GPL(jz4740_rtc_poweroff);
static void jz4740_rtc_power_off(void)
{
--
2.10.2
^ permalink raw reply related
* [rtc-linux] [PATCH 2/2] rtc: jz4740: make the driver builtin only
From: Alexandre Belloni @ 2016-11-09 0:37 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Paul Cercueil, rtc-linux, linux-kernel, Alexandre Belloni
In-Reply-To: <20161109003753.29759-1-alexandre.belloni@free-electrons.com>
Since the driver is now calling machine_halt() that is not exported, it has
to be built in the kernel. Building it as a module will fail at linking
time.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/rtc/Kconfig | 5 +----
drivers/rtc/rtc-jz4740.c | 10 +---------
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 4259ce61c31b..24b0778f6e28 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1550,15 +1550,12 @@ config RTC_DRV_MPC5121
will be called rtc-mpc5121.
config RTC_DRV_JZ4740
- tristate "Ingenic JZ4740 SoC"
+ bool "Ingenic JZ4740 SoC"
depends on MACH_INGENIC || COMPILE_TEST
help
If you say yes here you get support for the Ingenic JZ47xx SoCs RTC
controllers.
- This driver can also be buillt as a module. If so, the module
- will be called rtc-jz4740.
-
config RTC_DRV_LPC24XX
tristate "NXP RTC for LPC178x/18xx/408x/43xx"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c
index 18feae6c4e95..72918c1ba092 100644
--- a/drivers/rtc/rtc-jz4740.c
+++ b/drivers/rtc/rtc-jz4740.c
@@ -17,7 +17,6 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/kernel.h>
-#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/reboot.h>
@@ -303,7 +302,6 @@ static const struct of_device_id jz4740_rtc_of_match[] = {
{ .compatible = "ingenic,jz4780-rtc", .data = (void *)ID_JZ4780 },
{},
};
-MODULE_DEVICE_TABLE(of, jz4740_rtc_of_match);
static int jz4740_rtc_probe(struct platform_device *pdev)
{
@@ -431,7 +429,6 @@ static const struct platform_device_id jz4740_rtc_ids[] = {
{ "jz4780-rtc", ID_JZ4780 },
{}
};
-MODULE_DEVICE_TABLE(platform, jz4740_rtc_ids);
static struct platform_driver jz4740_rtc_driver = {
.probe = jz4740_rtc_probe,
@@ -443,9 +440,4 @@ static struct platform_driver jz4740_rtc_driver = {
.id_table = jz4740_rtc_ids,
};
-module_platform_driver(jz4740_rtc_driver);
-
-MODULE_AUTHOR("Lars-Peter Clausen <lars@metafoo.de>");
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("RTC driver for the JZ4740 SoC\n");
-MODULE_ALIAS("platform:jz4740-rtc");
+builtin_platform_driver(jz4740_rtc_driver);
--
2.10.2
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply related
* [rtc-linux] [PATCH 1/2] rtc: jz4740: remove unused EXPORT_SYMBOL
From: Alexandre Belloni @ 2016-11-09 0:37 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Paul Cercueil, rtc-linux, linux-kernel, Alexandre Belloni
jz4740_rtc_poweroff() is only called from the driver, stop exporting it.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/rtc/rtc-jz4740.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c
index 33ccd73ee947..18feae6c4e95 100644
--- a/drivers/rtc/rtc-jz4740.c
+++ b/drivers/rtc/rtc-jz4740.c
@@ -252,12 +252,11 @@ static irqreturn_t jz4740_rtc_irq(int irq, void *data)
return IRQ_HANDLED;
}
-void jz4740_rtc_poweroff(struct device *dev)
+static void jz4740_rtc_poweroff(struct device *dev)
{
struct jz4740_rtc *rtc = dev_get_drvdata(dev);
jz4740_rtc_reg_write(rtc, JZ_REG_RTC_HIBERNATE, 1);
}
-EXPORT_SYMBOL_GPL(jz4740_rtc_poweroff);
static void jz4740_rtc_power_off(void)
{
--
2.10.2
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply related
* Re: [PATCH v3 1/8] exec: introduce cred_guard_light
From: Eric W. Biederman @ 2016-11-09 0:34 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Jann Horn, Alexander Viro, Roland McGrath, John Johansen,
James Morris, Serge E. Hallyn, Paul Moore, Stephen Smalley,
Eric Paris, Casey Schaufler, Kees Cook, Andrew Morton,
Janis Danisevskis, Seth Forshee, Thomas Gleixner,
Benjamin LaHaise, Ben Hutchings, Andy Lutomirski, Linus Torvalds,
Krister Johansen, linux-fsdevel, linux-security-module, security
In-Reply-To: <20161105145623.GA21207@redhat.com>
Oleg Nesterov <oleg@redhat.com> writes:
> On 11/04, Oleg Nesterov wrote:
>>
>> On 11/04, Oleg Nesterov wrote:
>> >
>> > On 11/04, Eric W. Biederman wrote:
>> > >
>> > > The following mostly correct patch modifies zap_other_threads in
>> > > the case of a de_thread to not wait for zombies to be reaped. The only
>> > > case that cares is ptrace (as threads are self reaping). So I don't
>> > > think this will cause any problems except removing the strace -f race.
>> >
>> > From my previous email:
>> >
>> > So the only plan I currently have is change de_thread() to wait until
>> > other threads pass exit_notify() or even exit_signals(), but I don't
>> > like this.
>> >
>> > And yes, I don't like this, but perhaps this is what we should do.
>> >
>> > The patch is incomplete and racy (afaics), and the SIGNAL_GROUP_EXIT
>> > checks doesn't look right, but off course technically this change should
>> > be simple enough.
>> >
>> > But not that simple. Just for example, the exiting sub-threads should
>> > not run with ->group_leader pointing to nowhere, in case it was reaped
>> > by de_thread.
>>
>> Not to mention other potential problems outside of ptrace/exec. For example
>> userns_install() can fail after mt-exec even without ptrace, simply because
>> thread_group_empty() can be false. Sure, easy to fix, and probably _install()
>> should use signal->live anyway, but still.
>>
>> And I didn't mention the fun with sighand unsharing. We simply can't do this
>> until all sub-threads go away. IOW, your patch breaks the usage of ->siglock.
>> The execing thread and the zombie threads will use different locks to, say,
>> remove the task from thread-group. Again, this is fixable, but not that
>> simple.
>>
>> > And we have another problem with PTRACE_EVENT_EXIT which can lead to the
>> > same deadlock. Unfortunately, the semantics of PTRACE_EVENT_EXIT was never
>> > defined. But this change will add the user-visible change.
>> >
>> > And if we add the user-visible changes, then perhaps we could simply untrace
>> > the traced sub-threads on exec. This change is simple, we do not even need
>> > to touch exec/de_thread, we could just change exit_notify() to ignore ->ptrace
>> > if exec is in progress. But I'm afraid we can't do this.
>
> So I was thinking about something like below. Untested, probably buggy/incomplete
> too, but hopefully can work.
>
> flush_old_exec() calls the new kill_sub_threads() helper which waits until
> all the sub-threads pass exit_notify().
>
> de_thread() is called after install_exec_creds(), it is simplified and waits
> for thread_group_empty() without cred_guard_mutex.
>
> But again, I do not really like this, and we need to do something with
> PTRACE_EVENT_EXIT anyway, this needs another/separate change. User-visible.
>
> And I disagree that this has nothing to do with cred_guard_mutex. And in any
> case we should narrow its scope in do_execve() path. Why do we take it so early?
> Why do we need to do, say, copy_strings() with this lock held? The original
> motivation for this has gone, acct_arg_size() can work just fine even if
> multiple threads call sys_execve().
The little piece of this puzzle that I understand is that we don't want
to ptrace_attach while a processes is in the middle of exec. The name
cred_guard_mutex is odd for that, but that is what I see that lock
doing.
But ptrace really needs to consider either the original creds and mm or
the final creds and mm. Halfway states are problem.
Solution to avoid that may simply be some code motion that allows the
mutex to have a smaller hold time.
Eric
^ permalink raw reply
* Re: [PATCH] thinkpad_acpi: adding new hotkey ID for Lenovo thinkpad
From: Hui Wang @ 2016-11-09 0:34 UTC (permalink / raw)
To: Henrique de Moraes Holschuh; +Cc: dvhart, platform-driver-x86, ibm-acpi-devel
In-Reply-To: <20161108134352.GG8609@khazad-dum.debian.net>
On 11/08/2016 09:43 PM, Henrique de Moraes Holschuh wrote:
> On Tue, 08 Nov 2016, Hui Wang wrote:
>
>> laptops are not released to market yet), the issue is that the
>> thinkpad_acpi.ko can't be automatically loaded as before.
>>
>> Through debugging, we found the HKEY_HID is LEN0268 instead of
>> LEN0068 on those machines, and the MHKV is 0x200 instead of
>> 0x100. So adding the new ID into the driver.
> This usually means Lenovo expects to have different windows drivers.
> Does thinkpad-acpi work properly on these new thinkpads?
Yes, It works well as before. And thanks for your review.
Cheers,
Hui.
>
> If it does, you have my
> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
>
>> Signed-off-by: Hui Wang <hui.wang@canonical.com>
>> ---
>> drivers/platform/x86/thinkpad_acpi.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
>> index b65ce75..dbd2e27 100644
>> --- a/drivers/platform/x86/thinkpad_acpi.c
>> +++ b/drivers/platform/x86/thinkpad_acpi.c
>> @@ -128,6 +128,7 @@ enum {
>> /* ACPI HIDs */
>> #define TPACPI_ACPI_IBM_HKEY_HID "IBM0068"
>> #define TPACPI_ACPI_LENOVO_HKEY_HID "LEN0068"
>> +#define TPACPI_ACPI_LENOVO_HKEY_V2_HID "LEN0268"
>> #define TPACPI_ACPI_EC_HID "PNP0C09"
>>
>> /* Input IDs */
>> @@ -4143,6 +4144,7 @@ static int hotkey_write(char *buf)
>> static const struct acpi_device_id ibm_htk_device_ids[] = {
>> {TPACPI_ACPI_IBM_HKEY_HID, 0},
>> {TPACPI_ACPI_LENOVO_HKEY_HID, 0},
>> + {TPACPI_ACPI_LENOVO_HKEY_V2_HID, 0},
>> {"", 0},
>> };
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.