* [PATCH v3 1/1] i2c: qcom-geni: Provide an option to disable DMA processing
From: Lee Jones @ 2019-09-05 10:22 UTC (permalink / raw)
To: alokc, agross, robh+dt, mark.rutland, bjorn.andersson, vkoul, wsa
Cc: devicetree, linux-arm-msm, linux-kernel, linux-i2c, Lee Jones,
linux-arm-kernel
We have a production-level laptop (Lenovo Yoga C630) which is exhibiting
a rather horrific bug. When I2C HID devices are being scanned for at
boot-time the QCom Geni based I2C (Serial Engine) attempts to use DMA.
When it does, the laptop reboots and the user never sees the OS.
The beautiful thing about this approach is that, *if* the Geni SE DMA
ever starts working, we can remove the C code and any old properties
left in older DTs just become NOOP. Older kernels with newer DTs (less
of a priority) *still* will not work - but they do not work now anyway.
Fixes: 8bc529b25354 ("soc: qcom: geni: Add support for ACPI")
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
---
drivers/i2c/busses/i2c-qcom-geni.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
index a89bfce5388e..17abf60c94ae 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -355,11 +355,13 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
{
dma_addr_t rx_dma;
unsigned long time_left;
- void *dma_buf;
+ void *dma_buf = NULL;
struct geni_se *se = &gi2c->se;
size_t len = msg->len;
- dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
+ if (!of_machine_is_compatible("lenovo,yoga-c630"))
+ dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
+
if (dma_buf)
geni_se_select_mode(se, GENI_SE_DMA);
else
@@ -394,11 +396,13 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
{
dma_addr_t tx_dma;
unsigned long time_left;
- void *dma_buf;
+ void *dma_buf = NULL;
struct geni_se *se = &gi2c->se;
size_t len = msg->len;
- dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
+ if (!of_machine_is_compatible("lenovo,yoga-c630"))
+ dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
+
if (dma_buf)
geni_se_select_mode(se, GENI_SE_DMA);
else
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 00/16] Initial support for Marvell MMP3 SoC
From: Arnd Bergmann @ 2019-09-05 10:24 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, DTML, Jason Cooper, Stephen Boyd, Michael Turquette,
linux-kernel@vger.kernel.org, Russell King, Cc : Rob Herring,
To : Olof Johansson, Thomas Gleixner, Kishon Vijay Abraham I,
linux-clk, Linux ARM
In-Reply-To: <20190830220743.439670-1-lkundrak@v3.sk>
On Sat, Aug 31, 2019 at 12:08 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> this is the third spin of a patch set that adds support for the Marvell
> MMP3 processor, that I'd eventually love to see land in the Arm SoC
> tree. MMP3 is used in OLPC XO-4 laptops, Panasonic Toughpad FZ-A1 tablet
> and Dell Wyse 3020/Tx0D thin clients.
>
> Compared to v2, there's a handful of fixes in response to reviews. Four
> irqchip patches have been removed because they've been applied to the
> irqchip-next tree. Details in individual patches.
I just looked at the series, looks great overall, but the timing means
this is going to be 5.5 material by now. Please send a pull request
to soc@kernel.org cc:lakml after -rc1 is out.
I replied with a couple of comments for details I noticed.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V2, 2/2] media: i2c: Add DW9768 VCM driver
From: Andy Shevchenko @ 2019-09-05 10:26 UTC (permalink / raw)
To: dongchun.zhu
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, sam.hung,
shengnan.wang, tfiga, sj.huang, robh+dt, linux-mediatek,
sakari.ailus, matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel,
linux-media
In-Reply-To: <20190905072142.14606-3-dongchun.zhu@mediatek.com>
On Thu, Sep 05, 2019 at 03:21:42PM +0800, dongchun.zhu@mediatek.com wrote:
> From: Dongchun Zhu <dongchun.zhu@mediatek.com>
>
> This patch adds a V4L2 sub-device driver for DW9768 lens voice coil,
> and provides control to set the desired focus.
>
> The DW9768 is a 10 bit DAC with 100mA output current sink capability
> from Dongwoon, designed for linear control of voice coil motor,
> and controlled via I2C serial interface.
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> MAINTAINERS | 1 +
This should go to the same patch, where you introduce a record in the
MAINTAINERS database.
> +#define DW9768_SET_POSITION_ADDR 0x03
Indentation issue.
> +static struct regval_list dw9768_init_regs[] = {
> + {0x02, 0x02},
> + {DW9768_CMD_DELAY, DW9768_CMD_DELAY},
> + {0x06, 0x41},
> + {0x07, 0x39},
> + {DW9768_CMD_DELAY, DW9768_CMD_DELAY},
> +};
> +
> +static struct regval_list dw9768_release_regs[] = {
> + {0x02, 0x00},
> + {DW9768_CMD_DELAY, DW9768_CMD_DELAY},
> + {0x01, 0x00},
> + {DW9768_CMD_DELAY, DW9768_CMD_DELAY},
> +};
> +
> +static int dw9768_write_smbus(struct dw9768 *dw9768, unsigned char reg,
> + unsigned char value)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
> + int ret;
> +
> + if (reg == DW9768_CMD_DELAY && value == DW9768_CMD_DELAY)
Indentation issue.
But see other's comments.
> + usleep_range(DW9768_CTRL_DELAY_US,
> + DW9768_CTRL_DELAY_US + 100);
> + else
This needs an explanation.
> + ret = i2c_smbus_write_byte_data(client, reg, value);
> + return ret;
> +}
I'm wondering if we can benefit from regmap I²C API in this driver.
> +static int __maybe_unused dw9768_vcm_suspend(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
isn't is simple dev_get_drvdata() ?
> + struct dw9768 *dw9768 = sd_to_dw9768_vcm(sd);
> +
> + return dw9768_power_off(dw9768);
> +}
> +
> +static int __maybe_unused dw9768_vcm_resume(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
Ditto.
> + struct dw9768 *dw9768 = sd_to_dw9768_vcm(sd);
> +
> + return dw9768_power_on(dw9768);
> +}
> +static const struct i2c_device_id dw9768_id_table[] = {
> + { DW9768_NAME, 0 },
> + { },
No comma.
> +};
> +static const struct of_device_id dw9768_of_table[] = {
> + { .compatible = "dongwoon,dw9768" },
> + { },
Ditto.
> +};
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/2] Fix GMII2RGMII private field
From: David Miller @ 2019-09-05 10:32 UTC (permalink / raw)
To: harini.katakam
Cc: andrew, f.fainelli, netdev, radhey.shyam.pandey, michal.simek,
harinikatakamlinux, linux-kernel, linux-arm-kernel, hkallweit1
In-Reply-To: <1567605621-6818-1-git-send-email-harini.katakam@xilinx.com>
From: Harini Katakam <harini.katakam@xilinx.com>
Date: Wed, 4 Sep 2019 19:30:19 +0530
> Fix the usage of external phy's priv field by gmii2rgmii driver.
>
> Based on net-next.
Series applied to net-next.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: mt8183: Add node for the Mali GPU
From: Rob Herring @ 2019-09-05 10:32 UTC (permalink / raw)
To: Nicolas Boichat
Cc: Mark Rutland, devicetree, linux-kernel@vger.kernel.org,
Boris Brezillon, moderated list:ARM/Mediatek SoC support,
Alyssa Rosenzweig, Matthias Brugger, Nick Fan,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CANMq1KCTPdFhJG1SLf-i+-557Yx-1WLzWCHu3tT_5Q2BF+JgdQ@mail.gmail.com>
On Thu, Sep 5, 2019 at 10:49 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> Thanks for the quick review!
>
> On Thu, Sep 5, 2019 at 5:09 PM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > On Thu, Sep 5, 2019 at 9:16 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
> > >
> > > Add a basic GPU node and opp table for mt8183.
> > >
> > > The binding we use with out-of-tree Mali drivers includes more
> > > clocks, I assume this would be required eventually if we have an
> > > in-tree driver:
> >
> > We have an in-tree driver...
>
> Right but AFAICT it does not support Bifrost GPU (yet?).
It's mostly the mesa userspace side that's missing. The kernel driver
needs the compatible string and page table support[1]. The former
should be enough to access the registers which is typically enough to
sort out an platform specific clock, reset, power issues.
> > > clocks =
> > > <&topckgen CLK_TOP_MFGPLL_CK>,
> > > <&topckgen CLK_TOP_MUX_MFG>,
> > > <&clk26m>,
> > > <&mfgcfg CLK_MFG_BG3D>;
> > > clock-names =
> > > "clk_main_parent",
> > > "clk_mux",
> > > "clk_sub_parent",
> > > "subsys_mfg_cg";
>
> Do you think we should add those to the binding document? May not be
> easy to match what the amlogic binding does (I'm not sure to
> understand the details of this device, but I can dig further/ask).
I somewhat expect this needs more investigation. I'm doubtful that
there's a 26MHz clock going to Mali. Ideally, the clocks are what are
actually connected to the h/w, not just a list of all the clocks
needed on some platform because we fail to manage them elsewhere (like
an interconnect driver). Otherwise we end up with a different list for
every platform.
> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > >
> > > ---
> > > Upstreaming what matches existing bindings from our Chromium OS tree:
> > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1348
> > >
> > > The evb part of this change depends on this patch to add PMIC dtsi:
> > > https://patchwork.kernel.org/patch/10928161/
> > >
> > > arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++
> > > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 103 ++++++++++++++++++++
> > > 2 files changed, 110 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > > index 1fb195c683c3d01..200d8e65a6368a1 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > > @@ -7,6 +7,7 @@
> > >
> > > /dts-v1/;
> > > #include "mt8183.dtsi"
> > > +#include "mt6358.dtsi"
> > >
> > > / {
> > > model = "MediaTek MT8183 evaluation board";
> > > @@ -30,6 +31,12 @@
> > > status = "okay";
> > > };
> > >
> > > +&gpu {
> > > + supply-names = "mali", "mali_sram";
> > > + mali-supply = <&mt6358_vgpu_reg>;
> > > + mali_sram-supply = <&mt6358_vsram_gpu_reg>;
> >
> > Not documented. Just 'sram-supply' is enough.
>
> Will fix.
>
> > Note that the binding doc queued up for 5.4 has been converted to DT schema.
>
> Yep I see that in linux-next.
>
> >
> > > +};
> > > +
> > > &i2c0 {
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&i2c_pins_0>;
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > > index 97f84aa9fc6e1c1..8ea548a762ea252 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > > @@ -579,6 +579,109 @@
> > > #clock-cells = <1>;
> > > };
> > >
> > > + gpu: mali@13040000 {
> >
> > gpu@...
> >
> > > + compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
> >
> > You need to add this compatible string too.
>
> Will do.
>
> >
> > > + reg = <0 0x13040000 0 0x4000>;
> > > + interrupts =
> > > + <GIC_SPI 280 IRQ_TYPE_LEVEL_LOW>,
> > > + <GIC_SPI 279 IRQ_TYPE_LEVEL_LOW>,
> > > + <GIC_SPI 278 IRQ_TYPE_LEVEL_LOW>;
> > > + interrupt-names = "job", "mmu", "gpu";
> > > +
> > > + clocks = <&topckgen CLK_TOP_MFGPLL_CK>;
> > > + power-domains =
> > > + <&scpsys MT8183_POWER_DOMAIN_MFG_CORE0>,
> > > + <&scpsys MT8183_POWER_DOMAIN_MFG_CORE1>,
> > > + <&scpsys MT8183_POWER_DOMAIN_MFG_2D>;
> >
> > This needs to be documented too.
>
> I see that Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
> has power-domains in the example both not in the yaml, is that
> expected?
Err, no. Probably some copy-n-paste from utgard.
Rob
[1] https://patchwork.freedesktop.org/patch/304731/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V2, 2/2] media: i2c: Add DW9768 VCM driver
From: Sakari Ailus @ 2019-09-05 10:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, sam.hung,
shengnan.wang, Javier Martinez Canillas, tfiga, sj.huang, robh+dt,
linux-mediatek, dongchun.zhu, matthias.bgg, bingbu.cao, mchehab,
linux-arm-kernel, linux-media
In-Reply-To: <20190905101908.GB2680@smile.fi.intel.com>
On Thu, Sep 05, 2019 at 01:19:08PM +0300, Andy Shevchenko wrote:
> On Thu, Sep 05, 2019 at 11:21:34AM +0300, Sakari Ailus wrote:
> > On Thu, Sep 05, 2019 at 03:21:42PM +0800, dongchun.zhu@mediatek.com wrote:
> > > From: Dongchun Zhu <dongchun.zhu@mediatek.com>
>
> > > +static const struct i2c_device_id dw9768_id_table[] = {
> > > + { DW9768_NAME, 0 },
> > > + { },
> >
> > Could you drop the I²C ID table?
>
> But why?
> It will allow you to instanciate the device from user space.
The device is supposed to be present in DT (or ACPI tables) already.
>
> +Cc: Javier.
>
> Javier, is it needed in new code?
--
Sakari Ailus
sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver
From: Sakari Ailus @ 2019-09-05 10:45 UTC (permalink / raw)
To: Dongchun Zhu
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, shengnan.wang,
tfiga, louis.kuo, sj.huang, robh+dt, linux-mediatek, matthias.bgg,
bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <1567676465.21623.100.camel@mhfsdcap03>
Hi Dongchun,
On Thu, Sep 05, 2019 at 05:41:05PM +0800, Dongchun Zhu wrote:
...
> > > + ret = regulator_bulk_enable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
> > > + if (ret < 0) {
> > > + dev_err(dev, "Failed to enable regulators\n");
> > > + goto disable_clk;
> > > + }
> > > + msleep_range(7);
> >
> > This has some potential of clashing with more generic functions in the
> > future. Please use usleep_range directly, or msleep.
> >
>
> Did you mean using usleep_range(7*1000, 8*1000), as used in patch v1?
> https://patchwork.kernel.org/patch/10957225/
Yes, please.
--
Sakari Ailus
sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Christian Brauner @ 2019-09-05 10:45 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Shuah Khan, linux-arch, linux-s390, Tycho Andersen,
Aleksa Sarai, Jiri Olsa, Alexander Shishkin, Ingo Molnar,
linux-arm-kernel, linux-mips, linux-xtensa, Kees Cook,
Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k, Al Viro,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, J. Bruce Fields, linux-parisc, linux-api,
Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
containers
In-Reply-To: <20190905095026.gjemg2gqua2vufxb@yavin.dot.cyphar.com>
On Thu, Sep 05, 2019 at 07:50:26PM +1000, Aleksa Sarai wrote:
> On 2019-09-05, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
> > On 04/09/2019 22.19, Aleksa Sarai wrote:
> > > A common pattern for syscall extensions is increasing the size of a
> > > struct passed from userspace, such that the zero-value of the new fields
> > > result in the old kernel behaviour (allowing for a mix of userspace and
> > > kernel vintages to operate on one another in most cases). This is done
> > > in both directions -- hence two helpers -- though it's more common to
> > > have to copy user space structs into kernel space.
> > >
> > > Previously there was no common lib/ function that implemented
> > > the necessary extension-checking semantics (and different syscalls
> > > implemented them slightly differently or incompletely[1]). A future
> > > patch replaces all of the common uses of this pattern to use the new
> > > copy_struct_{to,from}_user() helpers.
> > >
> > > [1]: For instance {sched_setattr,perf_event_open,clone3}(2) all do do
> > > similar checks to copy_struct_from_user() while rt_sigprocmask(2)
> > > always rejects differently-sized struct arguments.
> > >
> > > Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> > > Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
> > > ---
> > > diff --git a/lib/struct_user.c b/lib/struct_user.c
> > > new file mode 100644
> > > index 000000000000..7301ab1bbe98
> > > --- /dev/null
> > > +++ b/lib/struct_user.c
> > > @@ -0,0 +1,182 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Copyright (C) 2019 SUSE LLC
> > > + * Copyright (C) 2019 Aleksa Sarai <cyphar@cyphar.com>
> > > + */
> > > +
> > > +#include <linux/types.h>
> > > +#include <linux/export.h>
> > > +#include <linux/uaccess.h>
> > > +#include <linux/kernel.h>
> > > +#include <linux/string.h>
> > > +
> > > +#define BUFFER_SIZE 64
> > > +
> > > +/*
> > > + * "memset(p, 0, size)" but for user space buffers. Caller must have already
> > > + * checked access_ok(p, size).
> > > + */
> >
> > Isn't this __clear_user() exactly (perhaps except for the return value)?
> > Perhaps not every arch has that?
>
> I didn't know about clear_user() -- I will switch to it.
>
> > > +static int __memzero_user(void __user *p, size_t s)
> > > +{
> > > + const char zeros[BUFFER_SIZE] = {};
> > > + while (s > 0) {
> > > + size_t n = min(s, sizeof(zeros));
> > > +
> > > + if (__copy_to_user(p, zeros, n))
> > > + return -EFAULT;
> > > +
> > > + p += n;
> > > + s -= n;
> > > + }
> > > + return 0;
> > > +}
> > > +
> > > +/**
> > > + * copy_struct_to_user: copy a struct to user space
> > > + * @dst: Destination address, in user space.
> > > + * @usize: Size of @dst struct.
> > > + * @src: Source address, in kernel space.
> > > + * @ksize: Size of @src struct.
> > > + *
> > > + * Returns (in all cases, some data may have been copied):
> > > + * * -EFBIG: (@usize < @ksize) and there are non-zero trailing bytes in @src.
> > > + * * -EFAULT: access to user space failed.
> > > + */
> > > +int copy_struct_to_user(void __user *dst, size_t usize,
> > > + const void *src, size_t ksize)
> > > +{
> > > + size_t size = min(ksize, usize);
> > > + size_t rest = abs(ksize - usize);
> >
> > Eh, I'd avoid abs() here due to the funkiness of the implicit type
> > conversions - ksize-usize has type size_t, then that's coerced to an int
> > (or a long maybe?), the abs is applied which return an int/long (or
> > unsigned versions?). Something like "rest = max(ksize, usize) - size;"
> > is more obviously correct and doesn't fall into any
> > narrowing/widening/sign extending traps.
>
> Yeah, I originally used "max(ksize, usize) - size" for that reason but
> was worried it looked too funky (and some quick tests showed that abs()
> gives the right results in most cases -- though I just realised it would
> probably not give the right results around SIZE_MAX). I'll switch back.
>
> > > + if (unlikely(usize > PAGE_SIZE))
> > > + return -EFAULT;
> >
> > Please don't. That is a restriction on all future extensions - once a
> > kernel is shipped with a syscall using this helper with that arbitrary
> > restriction in place, that syscall is forever prevented from extending
> > its arg struct beyond PAGE_SIZE (which is arch-dependent anyway). Sure,
> > it's hard to imagine, but who'd have thought 32 O_* or CLONE_* bits
> > weren't enough for everybody?
> >
> > This is only for future compatibility, and if someone runs an app
> > compiled against 7.3 headers on a 5.4 kernel, they probably don't care
> > about performance, but they would like their app to run.
>
> I'm not sure I agree that the limit is in place *forever* -- it's
> generally not a break in compatibility to convert an error into a
> success (though, there are counterexamples such as mknod(2) -- but that
> was a very specific case).
>
> You're right that it would mean that some very new code won't run on
> very ancient kernels (assuming we ever pass around structs that
> massive), but there should be a reasonable trade-off here IMHO.
Passing a struct larger than a PAGE_SIZE right now (at least for all
those calls that would make use of this helper at the moment) is to be
considered a bug.
The PAGE_SIZE check is a reasonable heuristic. It's an assumption that
is pretty common in the kernel in other places as well. Plus the
possibility of DoS.
>
> If we allow very large sizes, a program could probably DoS the kernel by
> allocating a moderately-large block of memory and then spawning a bunch
> of threads that all cause the kernel to re-check that the same 1GB block
> of memory is zeroed. I haven't tried, but it seems like it's best to
> avoid the possibility altogether.
>
> > > + }
> > > + /* Copy the interoperable parts of the struct. */
> > > + if (__copy_to_user(dst, src, size))
> > > + return -EFAULT;
> >
> > I think I understand why you put this last instead of handling the
> > buffer in the "natural" order. However,
> > I'm wondering whether we should actually do this copy before checking
> > that the extra kernel bytes are 0 - the user will still be told that
> > there was some extra information via the -EFBIG/-E2BIG return, but maybe
> > in some cases the part he understands is good enough. But I also guess
> > we have to look to existing users to see whether that would prevent them
> > from being converted to using this helper.
> >
> > linux-api folks, WDYT?
>
> Regarding the order, I just copied what sched and perf already do. I
> wouldn't mind doing it the other way around -- though I am a little
> cautious about implicitly making guarantees like that. The syscall that
> uses copy_struct_to_user() might not want to make that guarantee (it
> might not make sense for them), and there are some -E2BIG returns that
> won't result in data being copied (usize > PAGE_SIZE).
>
> As for feedback, this is syscall-dependent at the moment. The sched and
> perf users explicitly return the size of the kernel structure (by
> overwriting uattr->size if -E2BIG is returned) for copies in either
> direction. So users arguably already have some kind of feedback about
> size issues. clone3() on the other hand doesn't do that (though it
> doesn't copy anything to user-space so this isn't relevant to this
> particular question).
>
> Effectively, I'd like to see someone argue that this is something that
> they would personally want (before we do it).
I think the order you have right now is fine. I don't see the point of
doing work first before we have verified that things are sane.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V4 0/6] PCI: tegra: Enable PCIe C5 controller of Tegra194 in p2972-0000 platform
From: Vidya Sagar @ 2019-09-05 10:45 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, robh+dt, thierry.reding, jonathanh,
andrew.murray
Cc: devicetree, mmaddireddy, kthota, gustavo.pimentel, vidyas,
linux-kernel, mperttunen, linux-pci, linux-tegra, digetx, kishon,
linux-arm-kernel, sagar.tv
This patch series enables Tegra194's C5 controller which owns x16 slot in
p2972-0000 platform. C5 controller's PERST# and CLKREQ# are not configured as
output and bi-directional signals by default and hence they need to be
configured explicitly. Also, x16 slot's 3.3V and 12V supplies are controlled
through GPIOs and hence they need to be enabled through regulator framework.
This patch series adds required infrastructural support to address both the
aforementioned requirements.
Testing done on p2972-0000 platform
- Able to enumerate devices connected to x16 slot (owned by C5 controller)
- Enumerated device's functionality verified
- Suspend-Resume sequence is verified with device connected to x16 slot
V4:
* Rebased (Patch-4/6 particularly) on top of Lorenzo's pci/tegra branch
V3:
* Addressed some more review comments from Andrew Murray and Thierry Reding
V2:
* Changed the order of patches in the series for easy merging
* Addressed review comments from Thierry Reding and Andrew Murray
Vidya Sagar (6):
dt-bindings: PCI: tegra: Add sideband pins configuration entries
dt-bindings: PCI: tegra: Add PCIe slot supplies regulator entries
PCI: tegra: Add support to configure sideband pins
PCI: tegra: Add support to enable slot regulators
arm64: tegra: Add configuration for PCIe C5 sideband signals
arm64: tegra: Add PCIe slot supply information in p2972-0000 platform
.../bindings/pci/nvidia,tegra194-pcie.txt | 16 ++++
.../arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 24 +++++
.../boot/dts/nvidia/tegra194-p2972-0000.dts | 4 +-
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 38 +++++++-
drivers/pci/controller/dwc/pcie-tegra194.c | 94 ++++++++++++++++++-
5 files changed, 172 insertions(+), 4 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V4 1/6] dt-bindings: PCI: tegra: Add sideband pins configuration entries
From: Vidya Sagar @ 2019-09-05 10:45 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, robh+dt, thierry.reding, jonathanh,
andrew.murray
Cc: devicetree, mmaddireddy, kthota, gustavo.pimentel, vidyas,
linux-kernel, mperttunen, linux-pci, linux-tegra, digetx, kishon,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190905104553.2884-1-vidyas@nvidia.com>
Add optional bindings "pinctrl-names" and "pinctrl-0" to describe pin
configuration information of a particular PCIe controller.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
---
V4:
* None
V3:
* None
V2:
* None
.../devicetree/bindings/pci/nvidia,tegra194-pcie.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
index 674e5adb2895..0ac1b867ac24 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
@@ -83,6 +83,11 @@ Required properties:
- vddio-pex-ctl-supply: Regulator supply for PCIe side band signals
Optional properties:
+- pinctrl-names: A list of pinctrl state names.
+ It is mandatory for C5 controller and optional for other controllers.
+ - "default": Configures PCIe I/O for proper operation.
+- pinctrl-0: phandle for the 'default' state of pin configuration.
+ It is mandatory for C5 controller and optional for other controllers.
- supports-clkreq: Refer to Documentation/devicetree/bindings/pci/pci.txt
- nvidia,update-fc-fixup: This is a boolean property and needs to be present to
improve performance when a platform is designed in such a way that it
@@ -120,6 +125,9 @@ Tegra194:
num-lanes = <8>;
linux,pci-domain = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pex_rst_c5_out_state>, <&clkreq_c5_bi_dir_state>;
+
clocks = <&bpmp TEGRA194_CLK_PEX0_CORE_0>;
clock-names = "core";
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V4 2/6] dt-bindings: PCI: tegra: Add PCIe slot supplies regulator entries
From: Vidya Sagar @ 2019-09-05 10:45 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, robh+dt, thierry.reding, jonathanh,
andrew.murray
Cc: devicetree, mmaddireddy, kthota, gustavo.pimentel, vidyas,
linux-kernel, mperttunen, linux-pci, linux-tegra, digetx, kishon,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190905104553.2884-1-vidyas@nvidia.com>
Add optional bindings "vpcie3v3-supply" and "vpcie12v-supply" to describe
regulators of a PCIe slot's supplies 3.3V and 12V provided the platform
is designed to have regulator controlled slot supplies.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
---
V4:
* None
V3:
* None
V2:
* None
.../devicetree/bindings/pci/nvidia,tegra194-pcie.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
index 0ac1b867ac24..b739f92da58e 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
@@ -104,6 +104,12 @@ Optional properties:
specified in microseconds
- nvidia,aspm-l0s-entrance-latency-us: ASPM L0s entrance latency to be
specified in microseconds
+- vpcie3v3-supply: A phandle to the regulator node that supplies 3.3V to the slot
+ if the platform has one such slot. (Ex:- x16 slot owned by C5 controller
+ in p2972-0000 platform).
+- vpcie12v-supply: A phandle to the regulator node that supplies 12V to the slot
+ if the platform has one such slot. (Ex:- x16 slot owned by C5 controller
+ in p2972-0000 platform).
Examples:
=========
@@ -156,6 +162,8 @@ Tegra194:
0xc2000000 0x18 0x00000000 0x18 0x00000000 0x4 0x00000000>; /* prefetchable memory (16GB) */
vddio-pex-ctl-supply = <&vdd_1v8ao>;
+ vpcie3v3-supply = <&vdd_3v3_pcie>;
+ vpcie12v-supply = <&vdd_12v_pcie>;
phys = <&p2u_hsio_2>, <&p2u_hsio_3>, <&p2u_hsio_4>,
<&p2u_hsio_5>;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V4 3/6] PCI: tegra: Add support to configure sideband pins
From: Vidya Sagar @ 2019-09-05 10:45 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, robh+dt, thierry.reding, jonathanh,
andrew.murray
Cc: devicetree, mmaddireddy, kthota, gustavo.pimentel, vidyas,
linux-kernel, mperttunen, linux-pci, linux-tegra, digetx, kishon,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190905104553.2884-1-vidyas@nvidia.com>
Add support to configure sideband signal pins when information is present
in respective controller's device-tree node.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Acked-by: Thierry Reding <treding@nvidia.com>
---
V4:
* None
V3:
* Used 'dev' instead of 'pcie->dev'
V2:
* Addressed review comment from Andrew Murray
* Handled failure case of pinctrl_pm_select_default_state() cleanly
drivers/pci/controller/dwc/pcie-tegra194.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
index db598beafd92..2048ef6fad90 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -1304,8 +1304,13 @@ static int tegra_pcie_config_rp(struct tegra_pcie_dw *pcie)
if (ret < 0) {
dev_err(dev, "Failed to get runtime sync for PCIe dev: %d\n",
ret);
- pm_runtime_disable(dev);
- return ret;
+ goto fail_pm_get_sync;
+ }
+
+ ret = pinctrl_pm_select_default_state(dev);
+ if (ret < 0) {
+ dev_err(dev, "Failed to configure sideband pins: %d\n", ret);
+ goto fail_pinctrl;
}
tegra_pcie_init_controller(pcie);
@@ -1332,7 +1337,9 @@ static int tegra_pcie_config_rp(struct tegra_pcie_dw *pcie)
fail_host_init:
tegra_pcie_deinit_controller(pcie);
+fail_pinctrl:
pm_runtime_put_sync(dev);
+fail_pm_get_sync:
pm_runtime_disable(dev);
return ret;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V4 4/6] PCI: tegra: Add support to enable slot regulators
From: Vidya Sagar @ 2019-09-05 10:45 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, robh+dt, thierry.reding, jonathanh,
andrew.murray
Cc: devicetree, mmaddireddy, kthota, gustavo.pimentel, vidyas,
linux-kernel, mperttunen, linux-pci, linux-tegra, digetx, kishon,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190905104553.2884-1-vidyas@nvidia.com>
Add support to get regulator information of 3.3V and 12V supplies of a PCIe
slot from the respective controller's device-tree node and enable those
supplies. This is required in platforms like p2972-0000 where the supplies
to x16 slot owned by C5 controller need to be enabled before attempting to
enumerate the devices.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Acked-by: Thierry Reding <treding@nvidia.com>
---
V4:
* Rebased on top of Lorenzo's pci/tegra branch
V3:
* Added a dev_err() print for failure case of tegra_pcie_get_slot_regulators() API
* Modified to make 100ms sleep valid only if at least one of the regulator handles exist
V2:
* Addressed review comments from Thierry Reding and Andrew Murray
* Handled failure case of devm_regulator_get_optional() for -ENODEV cleanly
drivers/pci/controller/dwc/pcie-tegra194.c | 83 ++++++++++++++++++++++
1 file changed, 83 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
index 2048ef6fad90..398ba55418ba 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -277,6 +277,8 @@ struct tegra_pcie_dw {
u32 aspm_l0s_enter_lat;
struct regulator *pex_ctl_supply;
+ struct regulator *slot_ctl_3v3;
+ struct regulator *slot_ctl_12v;
unsigned int phy_count;
struct phy **phys;
@@ -1047,6 +1049,73 @@ static void tegra_pcie_downstream_dev_to_D0(struct tegra_pcie_dw *pcie)
}
}
+static int tegra_pcie_get_slot_regulators(struct tegra_pcie_dw *pcie)
+{
+ pcie->slot_ctl_3v3 = devm_regulator_get_optional(pcie->dev, "vpcie3v3");
+ if (IS_ERR(pcie->slot_ctl_3v3)) {
+ if (PTR_ERR(pcie->slot_ctl_3v3) != -ENODEV)
+ return PTR_ERR(pcie->slot_ctl_3v3);
+
+ pcie->slot_ctl_3v3 = NULL;
+ }
+
+ pcie->slot_ctl_12v = devm_regulator_get_optional(pcie->dev, "vpcie12v");
+ if (IS_ERR(pcie->slot_ctl_12v)) {
+ if (PTR_ERR(pcie->slot_ctl_12v) != -ENODEV)
+ return PTR_ERR(pcie->slot_ctl_12v);
+
+ pcie->slot_ctl_12v = NULL;
+ }
+
+ return 0;
+}
+
+static int tegra_pcie_enable_slot_regulators(struct tegra_pcie_dw *pcie)
+{
+ int ret;
+
+ if (pcie->slot_ctl_3v3) {
+ ret = regulator_enable(pcie->slot_ctl_3v3);
+ if (ret < 0) {
+ dev_err(pcie->dev,
+ "Failed to enable 3.3V slot supply: %d\n", ret);
+ return ret;
+ }
+ }
+
+ if (pcie->slot_ctl_12v) {
+ ret = regulator_enable(pcie->slot_ctl_12v);
+ if (ret < 0) {
+ dev_err(pcie->dev,
+ "Failed to enable 12V slot supply: %d\n", ret);
+ goto fail_12v_enable;
+ }
+ }
+
+ /*
+ * According to PCI Express Card Electromechanical Specification
+ * Revision 1.1, Table-2.4, T_PVPERL (Power stable to PERST# inactive)
+ * should be a minimum of 100ms.
+ */
+ if (pcie->slot_ctl_3v3 || pcie->slot_ctl_12v)
+ msleep(100);
+
+ return 0;
+
+fail_12v_enable:
+ if (pcie->slot_ctl_3v3)
+ regulator_disable(pcie->slot_ctl_3v3);
+ return ret;
+}
+
+static void tegra_pcie_disable_slot_regulators(struct tegra_pcie_dw *pcie)
+{
+ if (pcie->slot_ctl_12v)
+ regulator_disable(pcie->slot_ctl_12v);
+ if (pcie->slot_ctl_3v3)
+ regulator_disable(pcie->slot_ctl_3v3);
+}
+
static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
bool en_hw_hot_rst)
{
@@ -1060,6 +1129,10 @@ static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
return ret;
}
+ ret = tegra_pcie_enable_slot_regulators(pcie);
+ if (ret < 0)
+ goto fail_slot_reg_en;
+
ret = regulator_enable(pcie->pex_ctl_supply);
if (ret < 0) {
dev_err(pcie->dev, "Failed to enable regulator: %d\n", ret);
@@ -1142,6 +1215,8 @@ static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
fail_core_clk:
regulator_disable(pcie->pex_ctl_supply);
fail_reg_en:
+ tegra_pcie_disable_slot_regulators(pcie);
+fail_slot_reg_en:
tegra_pcie_bpmp_set_ctrl_state(pcie, false);
return ret;
@@ -1174,6 +1249,8 @@ static int __deinit_controller(struct tegra_pcie_dw *pcie)
return ret;
}
+ tegra_pcie_disable_slot_regulators(pcie);
+
ret = tegra_pcie_bpmp_set_ctrl_state(pcie, false);
if (ret) {
dev_err(pcie->dev, "Failed to disable controller %d: %d\n",
@@ -1373,6 +1450,12 @@ static int tegra_pcie_dw_probe(struct platform_device *pdev)
return ret;
}
+ ret = tegra_pcie_get_slot_regulators(pcie);
+ if (ret < 0) {
+ dev_err(dev, "Failed to get slot regulators: %d\n", ret);
+ return ret;
+ }
+
pcie->pex_ctl_supply = devm_regulator_get(dev, "vddio-pex-ctl");
if (IS_ERR(pcie->pex_ctl_supply)) {
ret = PTR_ERR(pcie->pex_ctl_supply);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V4 5/6] arm64: tegra: Add configuration for PCIe C5 sideband signals
From: Vidya Sagar @ 2019-09-05 10:45 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, robh+dt, thierry.reding, jonathanh,
andrew.murray
Cc: devicetree, mmaddireddy, kthota, gustavo.pimentel, vidyas,
linux-kernel, mperttunen, linux-pci, linux-tegra, digetx, kishon,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190905104553.2884-1-vidyas@nvidia.com>
Add support to configure PCIe C5's sideband signals PERST# and CLKREQ#
as output and bi-directional signals respectively which unlike other
PCIe controllers sideband signals are not configured by default.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
---
V4:
* None
V3:
* None
V2:
* None
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 38 +++++++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index adebbbf36bd0..3c0cf54f0aab 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -3,8 +3,9 @@
#include <dt-bindings/gpio/tegra194-gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/mailbox/tegra186-hsp.h>
-#include <dt-bindings/reset/tegra194-reset.h>
+#include <dt-bindings/pinctrl/pinctrl-tegra.h>
#include <dt-bindings/power/tegra194-powergate.h>
+#include <dt-bindings/reset/tegra194-reset.h>
#include <dt-bindings/thermal/tegra194-bpmp-thermal.h>
/ {
@@ -130,6 +131,38 @@
};
};
+ pinmux: pinmux@2430000 {
+ compatible = "nvidia,tegra194-pinmux";
+ reg = <0x2430000 0x17000
+ 0xc300000 0x4000>;
+
+ status = "okay";
+
+ pex_rst_c5_out_state: pex_rst_c5_out {
+ pex_rst {
+ nvidia,pins = "pex_l5_rst_n_pgg1";
+ nvidia,schmitt = <TEGRA_PIN_DISABLE>;
+ nvidia,lpdr = <TEGRA_PIN_ENABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ nvidia,io-high-voltage = <TEGRA_PIN_ENABLE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ };
+ };
+
+ clkreq_c5_bi_dir_state: clkreq_c5_bi_dir {
+ clkreq {
+ nvidia,pins = "pex_l5_clkreq_n_pgg0";
+ nvidia,schmitt = <TEGRA_PIN_DISABLE>;
+ nvidia,lpdr = <TEGRA_PIN_ENABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ nvidia,io-high-voltage = <TEGRA_PIN_ENABLE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ };
+ };
+ };
+
uarta: serial@3100000 {
compatible = "nvidia,tegra194-uart", "nvidia,tegra20-uart";
reg = <0x03100000 0x40>;
@@ -1365,6 +1398,9 @@
num-viewport = <8>;
linux,pci-domain = <5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pex_rst_c5_out_state>, <&clkreq_c5_bi_dir_state>;
+
clocks = <&bpmp TEGRA194_CLK_PEX1_CORE_5>,
<&bpmp TEGRA194_CLK_PEX1_CORE_5M>;
clock-names = "core", "core_m";
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V4 6/6] arm64: tegra: Add PCIe slot supply information in p2972-0000 platform
From: Vidya Sagar @ 2019-09-05 10:45 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, robh+dt, thierry.reding, jonathanh,
andrew.murray
Cc: devicetree, mmaddireddy, kthota, gustavo.pimentel, vidyas,
linux-kernel, mperttunen, linux-pci, linux-tegra, digetx, kishon,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190905104553.2884-1-vidyas@nvidia.com>
Add 3.3V and 12V supplies regulators information of x16 PCIe slot in
p2972-0000 platform which is owned by C5 controller and also enable C5
controller.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
---
V4:
* None
V3:
* None
V2:
* None
.../arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 24 +++++++++++++++++++
.../boot/dts/nvidia/tegra194-p2972-0000.dts | 4 +++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
index 62e07e1197cc..4c38426a6969 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
@@ -289,5 +289,29 @@
gpio = <&gpio TEGRA194_MAIN_GPIO(A, 3) GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ vdd_3v3_pcie: regulator@2 {
+ compatible = "regulator-fixed";
+ reg = <2>;
+
+ regulator-name = "PEX_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio TEGRA194_MAIN_GPIO(Z, 2) GPIO_ACTIVE_HIGH>;
+ regulator-boot-on;
+ enable-active-high;
+ };
+
+ vdd_12v_pcie: regulator@3 {
+ compatible = "regulator-fixed";
+ reg = <3>;
+
+ regulator-name = "VDD_12V";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ gpio = <&gpio TEGRA194_MAIN_GPIO(A, 1) GPIO_ACTIVE_LOW>;
+ regulator-boot-on;
+ enable-active-low;
+ };
};
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
index 23597d53c9c9..d47cd8c4dd24 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
@@ -93,9 +93,11 @@
};
pcie@141a0000 {
- status = "disabled";
+ status = "okay";
vddio-pex-ctl-supply = <&vdd_1v8ao>;
+ vpcie3v3-supply = <&vdd_3v3_pcie>;
+ vpcie12v-supply = <&vdd_12v_pcie>;
phys = <&p2u_nvhs_0>, <&p2u_nvhs_1>, <&p2u_nvhs_2>,
<&p2u_nvhs_3>, <&p2u_nvhs_4>, <&p2u_nvhs_5>,
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [V2, 1/2] media: i2c: dw9768: Add DT support and MAINTAINERS entry
From: Sakari Ailus @ 2019-09-05 10:48 UTC (permalink / raw)
To: Andy Shevchenko
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, sam.hung,
shengnan.wang, tfiga, sj.huang, robh+dt, linux-mediatek,
dongchun.zhu, matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel,
linux-media
In-Reply-To: <20190905101406.GA2680@smile.fi.intel.com>
On Thu, Sep 05, 2019 at 01:14:06PM +0300, Andy Shevchenko wrote:
> On Thu, Sep 05, 2019 at 03:21:41PM +0800, dongchun.zhu@mediatek.com wrote:
> > From: Dongchun Zhu <dongchun.zhu@mediatek.com>
> >
> > This patch is to add the Devicetree binding documentation and
> > MAINTAINERS entry for dw9768 actuator.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt | 9 +++++++++
> > MAINTAINERS | 7 +++++++
>
> This should be:
> 1) two separate patches
Why? The MAINTAINERS entry is usually added in the first patch needing it,
isn't it?
--
Sakari Ailus
sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 0/6] PCI: tegra: Enable PCIe C5 controller of Tegra194 in p2972-0000 platform
From: Vidya Sagar @ 2019-09-05 10:50 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: devicetree, mperttunen, mmaddireddy, kthota, gustavo.pimentel,
linux-kernel, kishon, linux-tegra, robh+dt, thierry.reding,
linux-pci, bhelgaas, andrew.murray, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190905093444.GA16642@e121166-lin.cambridge.arm.com>
On 9/5/2019 3:04 PM, Lorenzo Pieralisi wrote:
> On Thu, Sep 05, 2019 at 01:44:46PM +0530, Vidya Sagar wrote:
>> Hi Lorenzo / Bjorn,
>> Can you please review this series?
>> I have Reviewed-by and Acked-by from Rob, Thierry and Andrew already.
>
> Rebase it on top of my pci/tegra branch (it does not apply),
> resend it and I will merge it.
I just sent V4 after rebasing the series on top of pci/tegra.
Thanks,
Vidya Sagar
>
> Thanks,
> Lorenzo
>
>> Thanks,
>> Vidya Sagar
>>
>> On 8/28/2019 10:58 PM, Vidya Sagar wrote:
>>> This patch series enables Tegra194's C5 controller which owns x16 slot in
>>> p2972-0000 platform. C5 controller's PERST# and CLKREQ# are not configured as
>>> output and bi-directional signals by default and hence they need to be
>>> configured explicitly. Also, x16 slot's 3.3V and 12V supplies are controlled
>>> through GPIOs and hence they need to be enabled through regulator framework.
>>> This patch series adds required infrastructural support to address both the
>>> aforementioned requirements.
>>> Testing done on p2972-0000 platform
>>> - Able to enumerate devices connected to x16 slot (owned by C5 controller)
>>> - Enumerated device's functionality verified
>>> - Suspend-Resume sequence is verified with device connected to x16 slot
>>>
>>> V3:
>>> * Addressed some more review comments from Andrew Murray and Thierry Reding
>>>
>>> V2:
>>> * Changed the order of patches in the series for easy merging
>>> * Addressed review comments from Thierry Reding and Andrew Murray
>>>
>>> Vidya Sagar (6):
>>> dt-bindings: PCI: tegra: Add sideband pins configuration entries
>>> dt-bindings: PCI: tegra: Add PCIe slot supplies regulator entries
>>> PCI: tegra: Add support to configure sideband pins
>>> PCI: tegra: Add support to enable slot regulators
>>> arm64: tegra: Add configuration for PCIe C5 sideband signals
>>> arm64: tegra: Add PCIe slot supply information in p2972-0000 platform
>>>
>>> .../bindings/pci/nvidia,tegra194-pcie.txt | 16 ++++
>>> .../arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 24 +++++
>>> .../boot/dts/nvidia/tegra194-p2972-0000.dts | 4 +-
>>> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 38 +++++++-
>>> drivers/pci/controller/dwc/pcie-tegra194.c | 94 ++++++++++++++++++-
>>> 5 files changed, 172 insertions(+), 4 deletions(-)
>>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver
From: Tomasz Figa @ 2019-09-05 10:53 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mark Rutland, devicetree, Nicolas Boichat, srv_heupstream,
shengnan.wang, Louis Kuo, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <20190905104546.GA5475@paasikivi.fi.intel.com>
On Thu, Sep 5, 2019 at 7:45 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Hi Dongchun,
>
> On Thu, Sep 05, 2019 at 05:41:05PM +0800, Dongchun Zhu wrote:
>
> ...
>
> > > > + ret = regulator_bulk_enable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
> > > > + if (ret < 0) {
> > > > + dev_err(dev, "Failed to enable regulators\n");
> > > > + goto disable_clk;
> > > > + }
> > > > + msleep_range(7);
> > >
> > > This has some potential of clashing with more generic functions in the
> > > future. Please use usleep_range directly, or msleep.
> > >
> >
> > Did you mean using usleep_range(7*1000, 8*1000), as used in patch v1?
> > https://patchwork.kernel.org/patch/10957225/
>
> Yes, please.
Why not just msleep()?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V2, 2/2] media: i2c: Add DW9768 VCM driver
From: Javier Martinez Canillas @ 2019-09-05 10:57 UTC (permalink / raw)
To: Sakari Ailus, Andy Shevchenko
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, sam.hung,
shengnan.wang, tfiga, sj.huang, robh+dt, linux-mediatek,
dongchun.zhu, matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel,
linux-media
In-Reply-To: <20190905104001.GZ5475@paasikivi.fi.intel.com>
On 9/5/19 12:40 PM, Sakari Ailus wrote:
> On Thu, Sep 05, 2019 at 01:19:08PM +0300, Andy Shevchenko wrote:
>> On Thu, Sep 05, 2019 at 11:21:34AM +0300, Sakari Ailus wrote:
>>> On Thu, Sep 05, 2019 at 03:21:42PM +0800, dongchun.zhu@mediatek.com wrote:
>>>> From: Dongchun Zhu <dongchun.zhu@mediatek.com>
>>
>>>> +static const struct i2c_device_id dw9768_id_table[] = {
>>>> + { DW9768_NAME, 0 },
>>>> + { },
>>>
>>> Could you drop the I²C ID table?
>>
>> But why?
>> It will allow you to instanciate the device from user space.
Yes, the I2C device table is still needed if the device can be instantiated
from user-space using the sysfs interface, or otherwise the module won't be
automatically loaded.
Kieran posted a "[PATCH RFC] modpost: Support I2C Aliases from OF tables"
patch that adds a MODULE_DEVICE_TABLE(i2c_of, ..) macro so modpost could
add legacy I2C modalias using the information in the OF device ID tables:
https://patchwork.kernel.org/patch/11038861/
If that lands, then we could get rid of the I2C device tables altogether
for non-legacy I2C drivers.
>
> The device is supposed to be present in DT (or ACPI tables) already.
>
Agreed. Also by looking at the driver's probe function I see that the
device lookups a 'vin' and 'vdd' regulators supplies and it fails if
aren't defined, so it can't be instantiated from user-space anyways.
BTW, these two regulators supplies should be listed as 'vin-supply'
and 'vdd-supply' as required properties in the DT binding document.
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Peter Zijlstra @ 2019-09-05 10:57 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Jiri Olsa, linux-arch, linux-s390, Tycho Andersen,
Aleksa Sarai, Shuah Khan, Ingo Molnar, linux-arm-kernel,
linux-mips, linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn,
linuxppc-dev, linux-m68k, Al Viro, Andy Lutomirski, Shuah Khan,
Namhyung Kim, David Drysdale, Christian Brauner, J. Bruce Fields,
linux-parisc, linux-api, Chanho Min, Jeff Layton, Oleg Nesterov,
patrick.bellasi, Eric Biederman, linux-alpha, linux-fsdevel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190905094305.GJ2349@hirez.programming.kicks-ass.net>
On Thu, Sep 05, 2019 at 11:43:05AM +0200, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 07:26:22PM +1000, Aleksa Sarai wrote:
> > On 2019-09-05, Peter Zijlstra <peterz@infradead.org> wrote:
> > > On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> > > > +/**
> > > > + * copy_struct_to_user: copy a struct to user space
> > > > + * @dst: Destination address, in user space.
> > > > + * @usize: Size of @dst struct.
> > > > + * @src: Source address, in kernel space.
> > > > + * @ksize: Size of @src struct.
> > > > + *
> > > > + * Copies a struct from kernel space to user space, in a way that guarantees
> > > > + * backwards-compatibility for struct syscall arguments (as long as future
> > > > + * struct extensions are made such that all new fields are *appended* to the
> > > > + * old struct, and zeroed-out new fields have the same meaning as the old
> > > > + * struct).
> > > > + *
> > > > + * @ksize is just sizeof(*dst), and @usize should've been passed by user space.
> > > > + * The recommended usage is something like the following:
> > > > + *
> > > > + * SYSCALL_DEFINE2(foobar, struct foo __user *, uarg, size_t, usize)
> > > > + * {
> > > > + * int err;
> > > > + * struct foo karg = {};
> > > > + *
> > > > + * // do something with karg
> > > > + *
> > > > + * err = copy_struct_to_user(uarg, usize, &karg, sizeof(karg));
> > > > + * if (err)
> > > > + * return err;
> > > > + *
> > > > + * // ...
> > > > + * }
> > > > + *
> > > > + * There are three cases to consider:
> > > > + * * If @usize == @ksize, then it's copied verbatim.
> > > > + * * If @usize < @ksize, then kernel space is "returning" a newer struct to an
> > > > + * older user space. In order to avoid user space getting incomplete
> > > > + * information (new fields might be important), all trailing bytes in @src
> > > > + * (@ksize - @usize) must be zerored
> > >
> > > s/zerored/zero/, right?
> >
> > It should've been "zeroed".
>
> That reads wrong to me; that way it reads like this function must take
> that action and zero out the 'rest'; which is just wrong.
>
> This function must verify those bytes are zero, not make them zero.
>
> > > > , otherwise -EFBIG is returned.
> > >
> > > 'Funny' that, copy_struct_from_user() below seems to use E2BIG.
> >
> > This is a copy of the semantics that sched_[sg]etattr(2) uses -- E2BIG for
> > a "too big" struct passed to the kernel, and EFBIG for a "too big"
> > struct passed to user-space. I would personally have preferred EMSGSIZE
> > instead of EFBIG, but felt using the existing error codes would be less
> > confusing.
>
> Sadly a recent commit:
>
> 1251201c0d34 ("sched/core: Fix uclamp ABI bug, clean up and robustify sched_read_attr() ABI logic and code")
>
> Made the situation even 'worse'.
And thinking more about things; I'm not convinced the above patch is
actually right.
Do we really want to simply truncate all the attributes of the task?
And should we not at least set sched_flags when there are non-default
clamp values applied?
See; that is I think the primary bug that had chrt failing; we tried to
publish the default clamp values as !0.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: coresight: Add ETM4.1 support for ThunderX2
From: Tanmay Vilas Kumar Jagdale @ 2019-09-05 10:59 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Tomasz Nowicki, Jayachandran Chandrasekharan Nair,
Ganapatrao Kulkarni, linux-arm-kernel@lists.infradead.org,
suzuki.poulose@arm.com
In-Reply-To: <20190819203325.GB8268@xps15>
Hi Mathieu,
> Same comment as the previous patch along with the following...
>
> On Thu, Aug 15, 2019 at 01:53:46PM +0000, Tanmay Vilas Kumar Jagdale wrote:
> > Add ETM4.1 periperhal ID for Marvell's ThunderX2 chip.
> >
> > Signed-off-by: Tanmay Jagdale <tanmay@marvell.com>
> > ---
> > drivers/hwtracing/coresight/coresight-etm4x.c | 2 ++
> > drivers/hwtracing/coresight/coresight-etm4x.h | 1 +
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c
> > b/drivers/hwtracing/coresight/coresight-etm4x.c
> > index 7bcac8896fc1..ac3bd617907b 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> > @@ -58,6 +58,7 @@ static bool etm4_arch_supported(u8 arch)
> > /* Mask out the minor version number */
> > switch (arch & 0xf0) {
> > case ETM_ARCH_V4:
> > + case ETM_ARCH_V4_1:
>
> Why add ETM_ARCH_V4_1 when the switch statement strips off the first byte?
>
> Look at[1], someone already added support for 4.2.
>
> [1]. 5666dfd1d8a4 coresight: etm4x: Add support to enable ETMv4.2
>
>
> > break;
> > default:
> > return false;
> > @@ -1196,6 +1197,7 @@ static const struct amba_id etm4_ids[] = {
> > CS_AMBA_ID(0x000bb95e), /* Cortex-A57 */
> > CS_AMBA_ID(0x000bb95a), /* Cortex-A72 */
> > CS_AMBA_ID(0x000bb959), /* Cortex-A73 */
> > + CS_AMBA_ID(0x000cc0af), /* Marvell ThunderX2 */
>
> I suspect this processor also has "coresight-cpu-debug" IPs. If that is the
> case it is very possible they both have the same CID and a UCI (see next line)
> is required.
>
Yes, our processor has the coresight-cpu-debug IP. Currently I am working with
the hardware team to test this feature. Once that is done I will post a patch
that supports it. In the meantime I will post a v2 patch for ETMv4 with UCI.
Hope that is okay.
> > CS_AMBA_UCI_ID(0x000bb9da, uci_id_etm4), /* Cortex-A35 */
> > {},
> > };
>
> Thanks,
> Mathieu
>
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h
> > b/drivers/hwtracing/coresight/coresight-etm4x.h
> > index 4523f10ddd0f..03369e56b2eb 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> > @@ -137,6 +137,7 @@
> > #define ETM_MAX_SS_CMP 8
> >
> > #define ETM_ARCH_V4 0x40
> > +#define ETM_ARCH_V4_1 0x41
> > #define ETMv4_SYNC_MASK 0x1F
> > #define ETM_CYC_THRESHOLD_MASK 0xFFF
> > #define ETM_CYC_THRESHOLD_DEFAULT 0x100
> > --
> > 2.17.1
> >
Thanks,
Tanmay
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Christian Brauner @ 2019-09-05 11:05 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Shuah Khan, linux-arch, linux-s390, Tycho Andersen,
Aleksa Sarai, Jiri Olsa, Alexander Shishkin, Ingo Molnar,
linux-arm-kernel, linux-mips, linux-xtensa, Kees Cook,
Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k, Al Viro,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, J. Bruce Fields, linux-parisc, linux-api,
Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
containers
In-Reply-To: <20190904201933.10736-2-cyphar@cyphar.com>
On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> A common pattern for syscall extensions is increasing the size of a
> struct passed from userspace, such that the zero-value of the new fields
> result in the old kernel behaviour (allowing for a mix of userspace and
> kernel vintages to operate on one another in most cases). This is done
> in both directions -- hence two helpers -- though it's more common to
> have to copy user space structs into kernel space.
>
> Previously there was no common lib/ function that implemented
> the necessary extension-checking semantics (and different syscalls
> implemented them slightly differently or incompletely[1]). A future
> patch replaces all of the common uses of this pattern to use the new
> copy_struct_{to,from}_user() helpers.
>
> [1]: For instance {sched_setattr,perf_event_open,clone3}(2) all do do
> similar checks to copy_struct_from_user() while rt_sigprocmask(2)
> always rejects differently-sized struct arguments.
>
> Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
> ---
> include/linux/uaccess.h | 5 ++
> lib/Makefile | 2 +-
> lib/struct_user.c | 182 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 188 insertions(+), 1 deletion(-)
> create mode 100644 lib/struct_user.c
>
> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
> index 34a038563d97..0ad9544a1aee 100644
> --- a/include/linux/uaccess.h
> +++ b/include/linux/uaccess.h
> @@ -230,6 +230,11 @@ static inline unsigned long __copy_from_user_inatomic_nocache(void *to,
>
> #endif /* ARCH_HAS_NOCACHE_UACCESS */
>
> +extern int copy_struct_to_user(void __user *dst, size_t usize,
> + const void *src, size_t ksize);
> +extern int copy_struct_from_user(void *dst, size_t ksize,
> + const void __user *src, size_t usize);
> +
> /*
> * probe_kernel_read(): safely attempt to read from a location
> * @dst: pointer to the buffer that shall take the data
> diff --git a/lib/Makefile b/lib/Makefile
> index 29c02a924973..d86c71feaf0a 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -28,7 +28,7 @@ endif
> CFLAGS_string.o := $(call cc-option, -fno-stack-protector)
> endif
>
> -lib-y := ctype.o string.o vsprintf.o cmdline.o \
> +lib-y := ctype.o string.o struct_user.o vsprintf.o cmdline.o \
> rbtree.o radix-tree.o timerqueue.o xarray.o \
> idr.o extable.o \
> sha1.o chacha.o irq_regs.o argv_split.o \
> diff --git a/lib/struct_user.c b/lib/struct_user.c
> new file mode 100644
> index 000000000000..7301ab1bbe98
> --- /dev/null
> +++ b/lib/struct_user.c
> @@ -0,0 +1,182 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2019 SUSE LLC
> + * Copyright (C) 2019 Aleksa Sarai <cyphar@cyphar.com>
> + */
> +
> +#include <linux/types.h>
> +#include <linux/export.h>
> +#include <linux/uaccess.h>
> +#include <linux/kernel.h>
> +#include <linux/string.h>
> +
> +#define BUFFER_SIZE 64
> +
> +/*
> + * "memset(p, 0, size)" but for user space buffers. Caller must have already
> + * checked access_ok(p, size).
> + */
> +static int __memzero_user(void __user *p, size_t s)
> +{
> + const char zeros[BUFFER_SIZE] = {};
> + while (s > 0) {
> + size_t n = min(s, sizeof(zeros));
> +
> + if (__copy_to_user(p, zeros, n))
> + return -EFAULT;
> +
> + p += n;
> + s -= n;
> + }
> + return 0;
> +}
> +
> +/**
> + * copy_struct_to_user: copy a struct to user space
> + * @dst: Destination address, in user space.
> + * @usize: Size of @dst struct.
> + * @src: Source address, in kernel space.
> + * @ksize: Size of @src struct.
> + *
> + * Copies a struct from kernel space to user space, in a way that guarantees
> + * backwards-compatibility for struct syscall arguments (as long as future
> + * struct extensions are made such that all new fields are *appended* to the
> + * old struct, and zeroed-out new fields have the same meaning as the old
> + * struct).
> + *
> + * @ksize is just sizeof(*dst), and @usize should've been passed by user space.
> + * The recommended usage is something like the following:
> + *
> + * SYSCALL_DEFINE2(foobar, struct foo __user *, uarg, size_t, usize)
> + * {
> + * int err;
> + * struct foo karg = {};
> + *
> + * // do something with karg
> + *
> + * err = copy_struct_to_user(uarg, usize, &karg, sizeof(karg));
> + * if (err)
> + * return err;
> + *
> + * // ...
> + * }
> + *
> + * There are three cases to consider:
> + * * If @usize == @ksize, then it's copied verbatim.
> + * * If @usize < @ksize, then kernel space is "returning" a newer struct to an
> + * older user space. In order to avoid user space getting incomplete
> + * information (new fields might be important), all trailing bytes in @src
> + * (@ksize - @usize) must be zerored, otherwise -EFBIG is returned.
> + * * If @usize > @ksize, then the kernel is "returning" an older struct to a
> + * newer user space. The trailing bytes in @dst (@usize - @ksize) will be
> + * zero-filled.
> + *
> + * Returns (in all cases, some data may have been copied):
> + * * -EFBIG: (@usize < @ksize) and there are non-zero trailing bytes in @src.
> + * * -EFAULT: access to user space failed.
> + */
> +int copy_struct_to_user(void __user *dst, size_t usize,
> + const void *src, size_t ksize)
> +{
> + size_t size = min(ksize, usize);
> + size_t rest = abs(ksize - usize);
> +
> + if (unlikely(usize > PAGE_SIZE))
> + return -EFAULT;
Looks like this should be -EFBIG.
> + if (unlikely(!access_ok(dst, usize)))
> + return -EFAULT;
> +
> + /* Deal with trailing bytes. */
> + if (usize < ksize) {
> + if (memchr_inv(src + size, 0, rest))
> + return -EFBIG;
> + } else if (usize > ksize) {
> + if (__memzero_user(dst + size, rest))
> + return -EFAULT;
Is zeroing that memory really our job? Seems to me we should just check
it is zeroed.
> + }
> + /* Copy the interoperable parts of the struct. */
> + if (__copy_to_user(dst, src, size))
> + return -EFAULT;
> + return 0;
> +}
> +EXPORT_SYMBOL(copy_struct_to_user);
> +
> +/**
> + * copy_struct_from_user: copy a struct from user space
> + * @dst: Destination address, in kernel space. This buffer must be @ksize
> + * bytes long.
> + * @ksize: Size of @dst struct.
> + * @src: Source address, in user space.
> + * @usize: (Alleged) size of @src struct.
> + *
> + * Copies a struct from user space to kernel space, in a way that guarantees
> + * backwards-compatibility for struct syscall arguments (as long as future
> + * struct extensions are made such that all new fields are *appended* to the
> + * old struct, and zeroed-out new fields have the same meaning as the old
> + * struct).
> + *
> + * @ksize is just sizeof(*dst), and @usize should've been passed by user space.
> + * The recommended usage is something like the following:
> + *
> + * SYSCALL_DEFINE2(foobar, const struct foo __user *, uarg, size_t, usize)
> + * {
> + * int err;
> + * struct foo karg = {};
> + *
> + * err = copy_struct_from_user(&karg, sizeof(karg), uarg, size);
> + * if (err)
> + * return err;
> + *
> + * // ...
> + * }
> + *
> + * There are three cases to consider:
> + * * If @usize == @ksize, then it's copied verbatim.
> + * * If @usize < @ksize, then the user space has passed an old struct to a
> + * newer kernel. The rest of the trailing bytes in @dst (@ksize - @usize)
> + * are to be zero-filled.
> + * * If @usize > @ksize, then the user space has passed a new struct to an
> + * older kernel. The trailing bytes unknown to the kernel (@usize - @ksize)
> + * are checked to ensure they are zeroed, otherwise -E2BIG is returned.
> + *
> + * Returns (in all cases, some data may have been copied):
> + * * -E2BIG: (@usize > @ksize) and there are non-zero trailing bytes in @src.
> + * * -E2BIG: @usize is "too big" (at time of writing, >PAGE_SIZE).
> + * * -EFAULT: access to user space failed.
> + */
> +int copy_struct_from_user(void *dst, size_t ksize,
> + const void __user *src, size_t usize)
> +{
> + size_t size = min(ksize, usize);
> + size_t rest = abs(ksize - usize);
> +
> + if (unlikely(usize > PAGE_SIZE))
> + return -EFAULT;
That should be -E2BIG.
> + if (unlikely(!access_ok(src, usize)))
> + return -EFAULT;
> +
> + /* Deal with trailing bytes. */
> + if (usize < ksize)
> + memset(dst + size, 0, rest);
I think kernel style mandates that if one branch in an if-else ladder
requires {} all other must use {} as well. So this should be:
if () {
// one line
} else {
// one line
// another line
}
That's a change in behavior for clone3() and sched at least, no? Unless
- which I guess you might have done - you have moved the "error out when
the struct is too small" part before the call to copy_struct_from_user()
for them.
> + else if (usize > ksize) {
> + const void __user *addr = src + size;
> + char buffer[BUFFER_SIZE] = {};
> +
> + while (rest > 0) {
> + size_t bufsize = min(rest, sizeof(buffer));
> +
> + if (__copy_from_user(buffer, addr, bufsize))
> + return -EFAULT;
> + if (memchr_inv(buffer, 0, bufsize))
> + return -E2BIG;
> +
> + addr += bufsize;
> + rest -= bufsize;
> + }
> + }
> + /* Copy the interoperable parts of the struct. */
> + if (__copy_from_user(dst, src, size))
> + return -EFAULT;
> + return 0;
> +}
> +EXPORT_SYMBOL(copy_struct_from_user);
> --
> 2.23.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 12/15] thermal: tango: use devm_platform_ioremap_resource() to simplify code
From: Måns Rullgård @ 2019-09-05 11:06 UTC (permalink / raw)
To: YueHaibing
Cc: mmayer, eric, miquel.raynal, linux-stm32, heiko, amit.kucheria,
f.fainelli, daniel.lezcano, phil, linux-rockchip, agross,
bcm-kernel-feedback-list, linux-arm-msm, rui.zhang,
david.hernandezsanchez, alexandre.torgue, marc.w.gonzalez, rjui,
edubezval, linux-mediatek, linux-rpi-kernel, gregory.0xf0,
matthias.bgg, horms+renesas, talel, linux-arm-kernel, sbranden,
wsa+renesas, gregkh, linux-pm, linux-kernel, wahrenst,
mcoquelin.stm32, jun.nie, computersforpeace, shawnguo
In-Reply-To: <20190904122939.23780-13-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> writes:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Mans Rullgard <mans@mansr.com>
> ---
> drivers/thermal/tango_thermal.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/tango_thermal.c b/drivers/thermal/tango_thermal.c
> index 304b461..f44441b 100644
> --- a/drivers/thermal/tango_thermal.c
> +++ b/drivers/thermal/tango_thermal.c
> @@ -73,7 +73,6 @@ static void tango_thermal_init(struct tango_thermal_priv *priv)
>
> static int tango_thermal_probe(struct platform_device *pdev)
> {
> - struct resource *res;
> struct tango_thermal_priv *priv;
> struct thermal_zone_device *tzdev;
>
> @@ -81,8 +80,7 @@ static int tango_thermal_probe(struct platform_device *pdev)
> if (!priv)
> return -ENOMEM;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - priv->base = devm_ioremap_resource(&pdev->dev, res);
> + priv->base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(priv->base))
> return PTR_ERR(priv->base);
>
> --
> 2.7.4
>
--
Måns Rullgård
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Christian Brauner @ 2019-09-05 11:09 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Shuah Khan, linux-arch, linux-s390, Tycho Andersen,
Aleksa Sarai, Jiri Olsa, Alexander Shishkin, Ingo Molnar,
linux-arm-kernel, linux-mips, linux-xtensa, Kees Cook,
Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k, Al Viro,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, J. Bruce Fields, linux-parisc, linux-api,
Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
containers
In-Reply-To: <20190904201933.10736-2-cyphar@cyphar.com>
On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> A common pattern for syscall extensions is increasing the size of a
> struct passed from userspace, such that the zero-value of the new fields
> result in the old kernel behaviour (allowing for a mix of userspace and
> kernel vintages to operate on one another in most cases). This is done
> in both directions -- hence two helpers -- though it's more common to
> have to copy user space structs into kernel space.
>
> Previously there was no common lib/ function that implemented
> the necessary extension-checking semantics (and different syscalls
> implemented them slightly differently or incompletely[1]). A future
> patch replaces all of the common uses of this pattern to use the new
> copy_struct_{to,from}_user() helpers.
>
> [1]: For instance {sched_setattr,perf_event_open,clone3}(2) all do do
> similar checks to copy_struct_from_user() while rt_sigprocmask(2)
> always rejects differently-sized struct arguments.
>
> Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
I would probably split this out into a separate patchset. It can very
well go in before openat2(). Thoughts?
Christian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Rasmus Villemoes @ 2019-09-05 11:17 UTC (permalink / raw)
To: Christian Brauner, Aleksa Sarai
Cc: linux-ia64, linux-sh, Peter Zijlstra, Alexei Starovoitov,
linux-kernel, David Howells, linux-kselftest, sparclinux,
Jiri Olsa, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
Shuah Khan, Alexander Shishkin, Ingo Molnar, linux-arm-kernel,
linux-mips, linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn,
linuxppc-dev, linux-m68k, Al Viro, Andy Lutomirski, Shuah Khan,
Namhyung Kim, David Drysdale, Christian Brauner, J. Bruce Fields,
linux-parisc, linux-api, Chanho Min, Jeff Layton, Oleg Nesterov,
Eric Biederman, linux-alpha, linux-fsdevel, Andrew Morton,
Linus Torvalds, containers
In-Reply-To: <20190905110544.d6c5t7rx25kvywmi@wittgenstein>
On 05/09/2019 13.05, Christian Brauner wrote:
> On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
>> + if (unlikely(!access_ok(dst, usize)))
>> + return -EFAULT;
>> +
>> + /* Deal with trailing bytes. */
>> + if (usize < ksize) {
>> + if (memchr_inv(src + size, 0, rest))
>> + return -EFBIG;
>> + } else if (usize > ksize) {
>> + if (__memzero_user(dst + size, rest))
>> + return -EFAULT;
>
> Is zeroing that memory really our job? Seems to me we should just check
> it is zeroed.
Of course it is, otherwise you'd require userspace to clear the output
buffer it gives us, which in the majority of cases is wasted work. It's
much easier to reason about if we just say "the kernel populates [uaddr,
uaddr + usize)".
It's completely symmetric to copy_struct_from_user doing a memset() of
the tail of the kernel buffer in case of ksize>usize - you wouldn't want
to require the kernel callers to pass a zeroed buffer to
copy_struct_from_user() - it's just that when we memset(__user*),
there's an error check to do.
Rasmus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox