Re: [PATCH 4/6] arm64: tegra: Add XUSB and pad controller on Tegra186
Reviewed-by: JC Kuo
On 1/25/19 7:30 PM, Thierry Reding wrote:
From: Thierry Reding
Adds the XUSB pad and XUSB controllers on Tegra186.
Signed-off-by: Thierry Reding
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 135 +++
1 file changed, 135 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 22815db4a3ed..09d3b0d60e41 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -338,6 +338,141 @@
status = "disabled";
};
+ padctl: padctl@352 {
+ compatible = "nvidia,tegra186-xusb-padctl";
+ reg = <0x0 0x0352 0x0 0x1000>,
+ <0x0 0x0354 0x0 0x1000>;
+ reg-names = "padctl", "ao";
+
+ resets = < TEGRA186_RESET_XUSB_PADCTL>;
+ reset-names = "padctl";
+
+ status = "disabled";
+
+ pads {
+ usb2 {
+ clocks = < TEGRA186_CLK_USB2_TRK>;
+ clock-names = "trk";
+ status = "disabled";
+
+ lanes {
+ usb2-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ hsic {
+ clocks = < TEGRA186_CLK_HSIC_TRK>;
+ clock-names = "trk";
+ status = "disabled";
+
+ lanes {
+ hsic-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ usb3 {
+ status = "disabled";
+
+ lanes {
+ usb3-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-1 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-2 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ status = "disabled";
+ };
+
+ usb2-1 {
+ status = "disabled";
+ };
+
+ usb2-2 {
+ status = "disabled";
+ };
+
+ hsic-0 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ status = "disabled";
+ };
+
+ usb3-1 {
+ status = "disabled";
+ };
+
+ usb3-2 {
+ status = "disabled";
+ };
+ };
+ };
+
+ usb@353 {
+ compatible = "nvidia,tegra186-xusb";
+ reg = <0x0 0x0353 0x0 0x8000>,
+ <0x0 0x03538000 0x0 0x1000>;
+ reg-names = "hcd", "fpci";
+
+ interrupts = ,
+,
+;
+
+ clocks = < TEGRA186_CLK_XUSB_HOST>,
+< TEGRA186_CLK_XUSB_FALCON>,
+< TEGRA186_CLK_XUSB_SS>,
+< TEGRA186_CLK_XUSB_CORE_SS>,
+< TEGRA186_CLK_CLK_M>,
+< TEGRA186_CLK_XUSB_FS>,
+< TEGRA186_CLK_PLLU>,
+< TEGRA186_CLK_CLK_M>,
+
Re: [PATCH] selftests/seccomp: Actually sleep for 1/10th second
On Mon, Jan 28, 2019 at 8:37 AM Nick Desaulniers wrote: > So this test has been broken? If so, do you know for how long? Or > who's monitoring them? Either way, thanks for noticing and fixing. No, it's been working fine. It just consumes 100% cpu during the spin-wait. The intention was to sleep for a little bit to avoid a tight loop. It was just resource-inefficient. -- Kees Cook
Re: [PATCH v2 3/3] dt-bindings: iio: chemical: pms7003: add device tree support
On Sun, Jan 27, 2019 at 07:19:16PM +0100, Tomasz Duszynski wrote:
> Add device tree support for Plantower PMS7003 particulate matter sensor.
>
> Signed-off-by: Tomasz Duszynski
> ---
> .../iio/chemical/plantower,pms7003.txt| 19 +++
> 1 file changed, 19 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt
>
> diff --git
> a/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt
> b/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt
> new file mode 100644
> index ..e4c7f2fb1e30
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt
> @@ -0,0 +1,19 @@
> +* Plantower PMS7003 particulate matter sensor
> +
> +Required properties:
> +- compatible: must be "plantower,pms7003"
> +
> +Optional properties:
> +- vcc-supply: phandle to the regulator that provides power to the sensor
Shouldn't this one be a required property?
> +- set-gpios: phandle to the GPIO connected to the SET line
> +- reset-gpios: phandle to the GPIO connected to the RESET line
> +
> +Refer to serial/slave-device.txt for generic serial attached device bindings.
> +
> +Example:
> +
> + {
> + pms7003 {
The node name should be generic and reflect the functionality rather
than model. Perhaps "pms" will do here.
> + compatible = "plantower,pms7003";
> + };
> +};
Johan
Re: [tip:sched/core] sched/core: Fix a potential double-fetch bug in sched_copy_attr()
On Sun, Jan 27, 2019 at 12:04:44PM +0100, Thomas Gleixner wrote: > On Mon, 21 Jan 2019, tip-bot for Kangjie Lu wrote: > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > index a674c7db2f29..d4d3514c4fe9 100644 > > --- a/kernel/sched/core.c > > +++ b/kernel/sched/core.c > > @@ -4499,6 +4499,9 @@ static int sched_copy_attr(struct sched_attr __user > > *uattr, struct sched_attr *a > > if (ret) > > return -EFAULT; > > > > + /* In case attr->size was changed by user-space: */ > > + attr->size = size; > > + > > Just when pondering to send that to Linus, I tried to write up a concise > summary for this which made me look at the patch. > > If the size changed, then its clear that user space fiddled with the date > between the size fetch and the full copy from user. So why restoring the > size instead of doing the obvious: > >if (attr->size != size) > return -ECRAP; > > Hmm? Sure; but if we do that we should also change perf_copy_attr() which has the exact same thing.
Re: [PATCH 3/6] usb: host: xhci-tegra: Add Tegra186 XUSB support
Reviewed-by: JC Kuo
On 1/25/19 7:30 PM, Thierry Reding wrote:
From: JC Kuo
This commit adds Tegra186 XUSB host mode controller support. This is
very similar to the existing support for Tegra124 and Tegra210, except
that the number of ports and PHYs differs and the IPFS wrapper being
gone.
Signed-off-by: JC Kuo
Signed-off-by: Thierry Reding
---
drivers/usb/host/xhci-tegra.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index 49e033f953a2..9a07ea0f9c97 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -1423,9 +1423,34 @@ static const struct tegra_xusb_soc tegra210_soc = {
};
MODULE_FIRMWARE("nvidia/tegra210/xusb.bin");
+static const char * const tegra186_supply_names[] = {
+};
+
+static const struct tegra_xusb_phy_type tegra186_phy_types[] = {
+ { .name = "usb3", .num = 3, },
+ { .name = "usb2", .num = 3, },
+ { .name = "hsic", .num = 1, },
+};
+
+static const struct tegra_xusb_soc tegra186_soc = {
+ .firmware = "nvidia/tegra186/xusb.bin",
+ .supply_names = tegra186_supply_names,
+ .num_supplies = ARRAY_SIZE(tegra186_supply_names),
+ .phy_types = tegra186_phy_types,
+ .num_types = ARRAY_SIZE(tegra186_phy_types),
+ .ports = {
+ .usb3 = { .offset = 0, .count = 3, },
+ .usb2 = { .offset = 3, .count = 3, },
+ .hsic = { .offset = 6, .count = 1, },
+ },
+ .scale_ss_clock = false,
+ .has_ipfs = false,
+};
+
static const struct of_device_id tegra_xusb_of_match[] = {
{ .compatible = "nvidia,tegra124-xusb", .data = _soc },
{ .compatible = "nvidia,tegra210-xusb", .data = _soc },
+ { .compatible = "nvidia,tegra186-xusb", .data = _soc },
{ },
};
MODULE_DEVICE_TABLE(of, tegra_xusb_of_match);
Re: [PATCH 05/15] habanalabs: add command buffer module
On Sun, Jan 27, 2019 at 8:49 AM Mike Rapoport wrote:
>
> On Fri, Jan 25, 2019 at 11:47:03PM +0200, Oded Gabbay wrote:
> > On Wed, Jan 23, 2019 at 2:28 PM Mike Rapoport wrote:
> > >
> > > On Wed, Jan 23, 2019 at 02:00:47AM +0200, Oded Gabbay wrote:
> > > > This patch adds the CB module, which allows the user to create and
> > > > destroy CBs and to map them to the user's process address-space.
> > >
> > > Can you please spell "command buffer" at least first time it's mentioned?
> > fixed
> > >
> > > > A command buffer is a memory blocks that reside in DMA-able
> > > > address-space
> > > > and is physically contiguous so it can be accessed by the device without
> > > > MMU translation. The command buffer memory is allocated using the
> > > > coherent DMA API.
> > > >
> > > > When creating a new CB, the IOCTL returns a handle of it, and the
> > > > user-space process needs to use that handle to mmap the buffer to get a
> > > > VA
> > > > in the user's address-space.
> > > >
> > > > Before destroying (freeing) a CB, the user must unmap the CB's VA using
> > > > the
> > > > CB handle.
> > > >
> > > > Each CB has a reference counter, which tracks its usage in command
> > > > submissions and also its mmaps (only a single mmap is allowed).
> > > >
> > > > The driver maintains a pool of pre-allocated CBs in order to reduce
> > > > latency during command submissions. In case the pool is empty, the
> > > > driver
> > > > will go to the slow-path of allocating a new CB, i.e. calling
> > > > dma_alloc_coherent.
> > > >
> > > > Signed-off-by: Oded Gabbay
> > > > ---
> > > > drivers/misc/habanalabs/Makefile | 3 +-
> > > > drivers/misc/habanalabs/command_buffer.c | 414 +
> > > > drivers/misc/habanalabs/device.c | 43 ++-
> > > > drivers/misc/habanalabs/goya/goya.c| 28 ++
> > > > drivers/misc/habanalabs/habanalabs.h | 95 -
> > > > drivers/misc/habanalabs/habanalabs_drv.c | 2 +
> > > > drivers/misc/habanalabs/habanalabs_ioctl.c | 102 +
> > > > include/uapi/misc/habanalabs.h | 62 +++
> > > > 8 files changed, 746 insertions(+), 3 deletions(-)
> > > > create mode 100644 drivers/misc/habanalabs/command_buffer.c
> > > > create mode 100644 drivers/misc/habanalabs/habanalabs_ioctl.c
> > > > create mode 100644 include/uapi/misc/habanalabs.h
>
> [ ... ]
>
> > > > +int hl_cb_create(struct hl_device *hdev, struct hl_cb_mgr *mgr,
> > > > + u32 cb_size, u64 *handle, int ctx_id)
> > > > +{
> > > > + struct hl_cb *cb;
> > > > + bool alloc_new_cb = true;
> > > > + int rc;
> > > > +
> > > > + if (hdev->disabled) {
> > > > + dev_warn_ratelimited(hdev->dev,
> > > > + "Device is disabled !!! Can't create new CBs\n");
> > > > + rc = -EBUSY;
> > > > + goto out_err;
> > > > + }
> > > > +
> > > > + /* Minimum allocation must be PAGE SIZE */
> > > > + if (cb_size < PAGE_SIZE)
> > > > + cb_size = PAGE_SIZE;
> > > > +
> > > > + if (ctx_id == HL_KERNEL_ASID_ID &&
> > > > + cb_size <= hdev->asic_prop.cb_pool_cb_size) {
> > > > +
> > > > + spin_lock(>cb_pool_lock);
> > > > + if (!list_empty(>cb_pool)) {
> > > > + cb = list_first_entry(>cb_pool, typeof(*cb),
> > > > + pool_list);
> > > > + list_del(>pool_list);
> > > > + spin_unlock(>cb_pool_lock);
> > > > + alloc_new_cb = false;
> > > > + } else {
> > > > + spin_unlock(>cb_pool_lock);
> > > > + dev_warn_once(hdev->dev, "CB pool is empty\n");
> > >
> > > Isn't it going to be a false alarm when you allocate the cb for the first
> > > time?
> > Why ?
> > The cb_pool list holds a list of available CBs. See hl_cb_pool_init()
> > - it adds newly allocated CBs to this pool list.
> >
> > if (!list_empty(>cb_pool)) { - this checks whether the
> > pool is not empty so we can take an available CB from it. If the list
> > is empty (hence the pool is empty), we print the warning.
>
> Sorry if it's too much nitpicking, but why the allocation of the first cb
> should be a warning? There's nothing wrong there... Maybe dev_dbg()
> instead?
Yeah, that's a fair point. The issue is I would like to know if we
reach to this state and dev_dbg isn't usually enabled.
Still, I get what you are saying and I'll change this to dev_dbg.
>
> > > > + }
> > > > + }
> > > > +
> > > > + if (alloc_new_cb) {
> > > > + cb = hl_cb_alloc(hdev, cb_size, ctx_id);
> > > > + if (!cb) {
> > > > + rc = -ENOMEM;
> > > > + goto out_err;
> > > > + }
> > > > + }
> > > > +
> > > > + cb->hdev = hdev;
> > > > + cb->ctx_id = ctx_id;
> > > > +
> > > > + spin_lock(>cb_lock);
> > > > + rc =
Re: [PATCH] arm: dts: gta04: add gps support
On Fri, Jan 25, 2019 at 08:43:10PM +0100, Andreas Kemnade wrote:
> The GTA04 has a w2sg0004 or w2sg0084 gps chip. Not detectable
> which one is mounted so use the compatibility entry for w2sg0004
> for all which will work for both.
>
> Signed-off-by: Andreas Kemnade
> ---
> w2sg0004 bindings (together with the corresponding support is in
> https://git.kernel.org/pub/scm/linux/kernel/git/johan/gnss gnss-next)
> arch/arm/boot/dts/omap3-gta04.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index e53d32691308..d58c117e429f 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -312,6 +312,12 @@
> >;
> };
>
> + gps_pins: pinmux_gps_pins {
> + pinctrl-single,pins = <
> + OMAP3_CORE1_IOPAD(0x2176, PIN_OUTPUT_PULLDOWN |
> MUX_MODE4) /* gpio145 */
> + >;
> + };
> +
> hdq_pins: hdq_pins {
> pinctrl-single,pins = <
> OMAP3_CORE1_IOPAD(0x21c6, PIN_INPUT_PULLUP | MUX_MODE0)
> /* i2c3_sda.hdq */
> @@ -644,6 +650,13 @@
> {
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> + gps: gps {
The node should be named "gnss" as per the binding.
> + compatible = "wi2wi,w2sg0004";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + sirf,onoff-gpios = < 17 GPIO_ACTIVE_HIGH>;
> + lna-supply = <>;
Also, the vcc-supply is a required property.
> + };
> };
>
> {
Johan
Re: [PATCH 2/6] usb: host: xhci-tegra: Selectively program IPFS
Reviewed-by: JC Kuo
On 1/25/19 7:30 PM, Thierry Reding wrote:
From: JC Kuo
Starting with Tegra186, the XUSB controller no longer has the IPFS
wrapper. This commit adds a "has_ipfs" field to struct tegra_xusb_soc
that can be used to declare the existence of the IPFS wrapper.
For the existing chips (i.e. Tegra124 and Tegra210), the new field is
set to true. A future patch adding support for Tegra186 will set it to
false.
Signed-off-by: JC Kuo
Signed-off-by: Thierry Reding
---
drivers/usb/host/xhci-tegra.c | 43 +--
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index 938ff06c0349..49e033f953a2 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -161,6 +161,7 @@ struct tegra_xusb_soc {
} ports;
bool scale_ss_clock;
+ bool has_ipfs;
};
struct tegra_xusb {
@@ -637,16 +638,18 @@ static irqreturn_t tegra_xusb_mbox_thread(int irq, void
*data)
return IRQ_HANDLED;
}
-static void tegra_xusb_ipfs_config(struct tegra_xusb *tegra,
- struct resource *regs)
+static void tegra_xusb_config(struct tegra_xusb *tegra,
+ struct resource *regs)
{
u32 value;
- value = ipfs_readl(tegra, IPFS_XUSB_HOST_CONFIGURATION_0);
- value |= IPFS_EN_FPCI;
- ipfs_writel(tegra, value, IPFS_XUSB_HOST_CONFIGURATION_0);
+ if (tegra->soc->has_ipfs) {
+ value = ipfs_readl(tegra, IPFS_XUSB_HOST_CONFIGURATION_0);
+ value |= IPFS_EN_FPCI;
+ ipfs_writel(tegra, value, IPFS_XUSB_HOST_CONFIGURATION_0);
- usleep_range(10, 20);
+ usleep_range(10, 20);
+ }
/* Program BAR0 space */
value = fpci_readl(tegra, XUSB_CFG_4);
@@ -661,13 +664,15 @@ static void tegra_xusb_ipfs_config(struct tegra_xusb
*tegra,
value |= XUSB_IO_SPACE_EN | XUSB_MEM_SPACE_EN | XUSB_BUS_MASTER_EN;
fpci_writel(tegra, value, XUSB_CFG_1);
- /* Enable interrupt assertion */
- value = ipfs_readl(tegra, IPFS_XUSB_HOST_INTR_MASK_0);
- value |= IPFS_IP_INT_MASK;
- ipfs_writel(tegra, value, IPFS_XUSB_HOST_INTR_MASK_0);
+ if (tegra->soc->has_ipfs) {
+ /* Enable interrupt assertion */
+ value = ipfs_readl(tegra, IPFS_XUSB_HOST_INTR_MASK_0);
+ value |= IPFS_IP_INT_MASK;
+ ipfs_writel(tegra, value, IPFS_XUSB_HOST_INTR_MASK_0);
- /* Set hysteresis */
- ipfs_writel(tegra, 0x80, IPFS_XUSB_HOST_CLKGATE_HYSTERESIS_0);
+ /* Set hysteresis */
+ ipfs_writel(tegra, 0x80, IPFS_XUSB_HOST_CLKGATE_HYSTERESIS_0);
+ }
}
static int tegra_xusb_clk_enable(struct tegra_xusb *tegra)
@@ -1015,10 +1020,12 @@ static int tegra_xusb_probe(struct platform_device
*pdev)
if (IS_ERR(tegra->fpci_base))
return PTR_ERR(tegra->fpci_base);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
- tegra->ipfs_base = devm_ioremap_resource(>dev, res);
- if (IS_ERR(tegra->ipfs_base))
- return PTR_ERR(tegra->ipfs_base);
+ if (tegra->soc->has_ipfs) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+ tegra->ipfs_base = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(tegra->ipfs_base))
+ return PTR_ERR(tegra->ipfs_base);
+ }
tegra->xhci_irq = platform_get_irq(pdev, 0);
if (tegra->xhci_irq < 0)
@@ -1208,7 +1215,7 @@ static int tegra_xusb_probe(struct platform_device *pdev)
goto disable_rpm;
}
- tegra_xusb_ipfs_config(tegra, regs);
+ tegra_xusb_config(tegra, regs);
err = tegra_xusb_load_firmware(tegra);
if (err < 0) {
@@ -1380,6 +1387,7 @@ static const struct tegra_xusb_soc tegra124_soc = {
.usb3 = { .offset = 0, .count = 2, },
},
.scale_ss_clock = true,
+ .has_ipfs = true,
};
MODULE_FIRMWARE("nvidia/tegra124/xusb.bin");
@@ -1411,6 +1419,7 @@ static const struct tegra_xusb_soc tegra210_soc = {
.usb3 = { .offset = 0, .count = 4, },
},
.scale_ss_clock = false,
+ .has_ipfs = true,
};
MODULE_FIRMWARE("nvidia/tegra210/xusb.bin");
Re: implement generic dma_map_ops for IOMMUs
Any chance to get a review on this one? On Mon, Jan 14, 2019 at 10:41:40AM +0100, Christoph Hellwig wrote: > Hi Robin, > > please take a look at this series, which implements a completely generic > set of dma_map_ops for IOMMU drivers. This is done by taking the > existing arm64 code, moving it to drivers/iommu and then massaging it > so that it can also work for architectures with DMA remapping. This > should help future ports to support IOMMUs more easily, and also allow > to remove various custom IOMMU dma_map_ops implementations, like Tom > was planning to for the AMD one. > > A git tree is also available at: > > git://git.infradead.org/users/hch/misc.git dma-iommu-ops > > Gitweb: > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-iommu-ops > ___ > iommu mailing list > io...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu ---end quoted text---
Re: [PATCH v2] iio: adc: ad7476: Add support for ADS786X ADCs
HI Alexandru
On Mon, Jan 28, 2019 at 8:47 AM Alexandru Ardelean
wrote:
>
> On Mon, Jan 28, 2019 at 9:43 AM Ricardo Ribalda Delgado
> wrote:
> >
> > HI Alexandru
> >
> > On Mon, Jan 28, 2019 at 8:38 AM Alexandru Ardelean
> > wrote:
> > >
> > > On Sat, Jan 26, 2019 at 8:21 PM Jonathan Cameron wrote:
> > > >
> > > > On Fri, 25 Jan 2019 11:04:51 +0100
> > > > Ricardo Ribalda Delgado wrote:
> > > >
> > > > > Add support for ADS7866, ADS7867 and ADS7868 8/10/12 bit Single
> > > > > channel
> > > > > ADC.
> > > > >
> > >
> > > I don't want this reply be offensive or anything.
> > > But since I've seen this precedence, I do have to ask if these driver
> > > changes were tested on at least one of the TI chips/eval-boards.
> > >
> > > Ideally, before adding new drivers it would be nice to make sure that
> > > they were run on actual HW.
> > > Good code-review can get us only so far.
> > >
> > > We could ask someone who has any of these chips to test.
> > > Or maybe some eval boards from TI could be obtained to test these changes.
> > >
> > > Overall changes seem good [I haven't taken a close look], but HW
> > > testing is king.
> > >
> >
> > I have access to ADS7868 (the 8 bit version) which has been connected
> > in "loopback" to the ti-dac7612 (also new driver). I can run any test
> > that you need or even give you or someone access (privately) to the
> > board via vpn
> > or something like that.
> >
> > Would that work for you?
>
> No, that's fine :)
> Thank you for the answer.
> And apologies [again] if this was a bit too forward/harsh from my side.
>
Absolutely no worries! it wasn't. When I use a driver from kernel.org
I expect it
to have the maximum quality and work on real hardware. This is how we get there.
Best regards!
> Thanks
> Alex
>
> >
> > Best regards!
> >
> > > Thanks
> > > Alex
> > >
> > > > > Datasheet: http://www.ti.com/lit/ds/symlink/ads7868.pdf
> > > > >
> > > > > Signed-off-by: Ricardo Ribalda Delgado
> > > > > ---
> > > > > v2: I have missnamed the devices
> > > > > drivers/iio/adc/Kconfig | 3 ++-
> > > > > drivers/iio/adc/ad7476.c | 20
> > > > > 2 files changed, 22 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > > > > index f9354e5ee65c..d86900fc2634 100644
> > > > > --- a/drivers/iio/adc/Kconfig
> > > > > +++ b/drivers/iio/adc/Kconfig
> > > > > @@ -64,7 +64,8 @@ config AD7476
> > > > > help
> > > > > Say yes here to build support for Analog Devices AD7273,
> > > > > AD7274, AD7276,
> > > > > AD7277, AD7278, AD7475, AD7476, AD7477, AD7478, AD7466,
> > > > > AD7467, AD7468,
> > > > > - AD7495, AD7910, AD7920, AD7920 SPI analog to digital
> > > > > converters (ADC).
> > > > > + AD7495, AD7910, AD7920, AD7920, ADS7866, ADS7867, ADS7868 SPI
> > > > > analog
> > > > > + to digital converters (ADC).
> > > >
> > > > As commented in the earlier thread (after you sent this!), please make
> > > > sure
> > > > the help text makes it clear that these aren't all Analog devices parts.
> > > >
> > > > Likely to cause confusion otherwise.
> > > >
> > > > Good to see you didn't spin another driver but instead tracked down that
> > > > this one would work well!
> > > >
> > > > Thanks,
> > > >
> > > > Jonathan
> > > >
> > > > >
> > > > > To compile this driver as a module, choose M here: the
> > > > > module will be called ad7476.
> > > > > diff --git a/drivers/iio/adc/ad7476.c b/drivers/iio/adc/ad7476.c
> > > > > index 0549686b9ef8..76747488044b 100644
> > > > > --- a/drivers/iio/adc/ad7476.c
> > > > > +++ b/drivers/iio/adc/ad7476.c
> > > > > @@ -59,6 +59,9 @@ enum ad7476_supported_device_ids {
> > > > > ID_ADC081S,
> > > > > ID_ADC101S,
> > > > > ID_ADC121S,
> > > > > + ID_ADS7866,
> > > > > + ID_ADS7867,
> > > > > + ID_ADS7868,
> > > > > };
> > > > >
> > > > > static irqreturn_t ad7476_trigger_handler(int irq, void *p)
> > > > > @@ -157,6 +160,8 @@ static int ad7476_read_raw(struct iio_dev
> > > > > *indio_dev,
> > > > > #define AD7940_CHAN(bits) _AD7476_CHAN((bits), 15 - (bits), \
> > > > > BIT(IIO_CHAN_INFO_RAW))
> > > > > #define AD7091R_CHAN(bits) _AD7476_CHAN((bits), 16 - (bits), 0)
> > > > > +#define ADS786X_CHAN(bits) _AD7476_CHAN((bits), 12 - (bits), \
> > > > > + BIT(IIO_CHAN_INFO_RAW))
> > > > >
> > > > > static const struct ad7476_chip_info ad7476_chip_info_tbl[] = {
> > > > > [ID_AD7091R] = {
> > > > > @@ -209,6 +214,18 @@ static const struct ad7476_chip_info
> > > > > ad7476_chip_info_tbl[] = {
> > > > > .channel[0] = ADC081S_CHAN(12),
> > > > > .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > > > },
> > > > > + [ID_ADS7866] = {
> > > > > + .channel[0] = ADS786X_CHAN(12),
> > > > > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > > > + },
> > > > > + [ID_ADS7867] = {
> > > > > +
Re: [PATCH] PCI / ACPI: Don't clear pme_poll on device that has unreliable ACPI wake
> On Jan 25, 2019, at 4:05 AM, Bjorn Helgaas wrote: > > On Thu, Jan 24, 2019 at 11:29:37PM +0800, Kai Heng Feng wrote: >>> On Jan 24, 2019, at 11:15 PM, Bjorn Helgaas wrote: >>> On Wed, Jan 23, 2019 at 03:17:37PM +0800, Kai Heng Feng wrote: > On Jan 23, 2019, at 7:51 AM, Bjorn Helgaas wrote: > On Tue, Jan 22, 2019 at 02:45:44PM +0800, Kai-Heng Feng wrote: >> There are some e1000e devices can only be woken up from D3 one time, by >> plugging ethernet cable. Subsequent cable plugging does set PME bit >> correctly, but it still doesn't get woken up. >> >> Since e1000e connects to the root complex directly, we rely on ACPI to >> wake it up. In this case, the GPE from _PRW only works once and stops >> working after that. >> >> So introduce a new PCI quirk, to avoid clearing pme_poll flag for buggy >> platform firmwares that have unreliable GPE wake. > > This quirk applies to all 0x15bb (E1000_DEV_ID_PCH_CNP_I219_LM7) and > 0x15bd (E1000_DEV_ID_PCH_CNP_I219_LM6) devices. The e1000e driver > claims about a zillion different device IDs. > > I would be surprised if these two devices are defective but all the > others work correctly. Could it be that there is a problem with the > wiring on this particular motherboard or with the ACPI _PRW methods > (or the way Linux interprets them) in this firmware? If this is a motherboard issue or platform specific, do you prefer to use DMI matches here? >>> >>> I'm not sure what the problem is yet, so let's hold off on the exact >>> structure of the fix. >> >> I think DMI table can put in e1000e driver instead of PCI quirk. > > I don't think we should add a quirk or DMI table yet because we > haven't gotten to the root cause of this problem. If the root cause > is a problem in the Linux code, adding a quirk will mask the problem > for this specific system, but will leave other systems with similar > problems. > >>> If I understand correctly, e1000e wakeup works once, but doesn't work >>> after that. Your lspci (from after that first wakeup, from >>> https://bugzilla.kernel.org/attachment.cgi?id=280691) shows this: >>> >>> 00:14.0 XHC XHCI USB >>> Flags: PMEClk- DSI- D1- D2- ... PME(D0-,D1-,D2-,D3hot+,D3cold+) >>> Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME- >>> 00:1f.3 HDAS audio >>> Flags: PMEClk- DSI- D1- D2- ... PME(D0-,D1-,D2-,D3hot+,D3cold+) >>> Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME- >>> 00:1f.6 GLAN e1000e >>> Flags: PMEClk- DSI+ D1- D2- ... PME(D0+,D1-,D2-,D3hot+,D3cold+) >>> Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=1 PME+ >>> >>> So the e1000e PME_Status bit is still set, which means it probably >>> won't generate another PME interrupt, which would explain why wakeup >>> doesn't work. To test this theory, can you try this: >>> >>> - sleep >>> - wakeup via e1000e >>> # DEV=00:1f.6 >>> # lspci -vvs $DEV >>> # setpci -s $DEV CAP_PM+4.W >>> # setpci -s $DEV CAP_PM+4.W=0x8100 >>> - sleep >>> - attempt another wakeup via e1000e >>> >>> If this second wakeup works, it would suggest that PME_Status isn't >>> being cleared correctly. I see code, e.g., in >>> acpi_setup_gpe_for_wake(), that *looks* like it would arrange to clear >>> it, but I'm not very familiar with it. Maybe there's some issue with >>> multiple devices sharing an "implicit notification" situation like >>> this. >> >> The PME status is being cleared correctly. > > I was hoping to understand this better via the experiment above, but > I'm still confused. Here's the scenario as I understand it: > > 0) fresh boot > 1) e1000e PME_Status should be 0 > 2) sleep > 3) wakeup via e1000e succeeds > 4) e1000e PME_Status should be 0 > 5) sleep > 6) wakeup via e1000e fails > 7) wakeup via USB succeeds > 8) e1000e PME_Status should be 0, but is actually 1 Sorry for not illustrating the scenario more clearly, here’s the test scenario: 0) fresh boot 1) no ethernet cable plugged 2) e1000e runtime suspend 3) PME_Status is 0 4) plug ethernet cable 5) e1000e gets woken up by ACPI wakeup 6) network connection established 6) unplug the ethernet cable 7) e1000e runtime suspend 8) plug ethernet cable again 9) PME_Status=1 but it’s not woken up, stays suspended 10) Plug a USB device, e1000e wakes up. This shows somehow the ACPI GPE still works for USB controller but not ethernet device. > > If I understand correctly, the bugzilla lspci > (https://bugzilla.kernel.org/attachment.cgi?id=280691) was collected > at point 8, and it shows PME_Status=1 when it should be 0. > > If we write a 1 to PME_Status to clear it, and it remains set, that's > obviously a hardware defect, and Intel should document that in an > erratum, and a quirk would be the appropriate way to work around it. > But I doubt that's what's happening. I’ll ask them if they can provide an erratum. > > If e1000e changes PME_Status from 0 to 1 and we don't get an interrupt >
Re: [PATCH] media: ov5640: Fix set 15fps regression
On Fri, Jan 25, 2019 at 9:10 PM Maxime Ripard wrote:
>
> On Thu, Jan 24, 2019 at 11:28:01PM +0530, Jagan Teki wrote:
> > The ov5640_try_frame_interval operation updates the FPS as per user
> > input based on default ov5640_frame_rate, OV5640_30_FPS which is failed
> > to update when user trigger 15fps.
> >
> > So, initialize the default ov5640_frame_rate to OV5640_15_FPS so-that
> > it can satisfy to update all fps.
> >
> > Fixes: 5a3ad937bc78 ("media: ov5640: Make the return rate type more
> > explicit")
> > Signed-off-by: Jagan Teki
>
> I'm pretty sure I tested this and it was working fine. You're
> mentionning a regression, but what regression is there exactly (ie,
> what was working before that commit that doesn't work anymore?). What
> tools/commands are you using to see this behaviour?
In fact I have mentioned this on your v9 [1], may be you missed it.
I have reproduced with media-ctl, below is the full log. let me know
if I still miss anything.
Before this change:
# media-ctl -p
Media controller API version 5.0.0
Media device information
driver sun6i-csi
model Allwinner Video Capture Device
serial
bus info
hw revision 0x0
driver version 5.0.0
Device topology
- entity 1: sun6i-csi (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "ov5640 1-003c":0 [ENABLED,IMMUTABLE]
- entity 5: ov5640 1-003c (1 pad, 1 link)
type V4L2 subdev subtype Sensor flags 0
device node name /dev/v4l-subdev0
pad0: Source
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range]
-> "sun6i-csi":0 [ENABLED,IMMUTABLE]
# media-ctl --set-v4l2 "'ov5640 1-003c':0[fmt:UYVY8_2X8/640x480@1/15 field:none]
"
# media-ctl -p
Media controller API version 5.0.0
Media device information
driver sun6i-csi
model Allwinner Video Capture Device
serial
bus info
hw revision 0x0
driver version 5.0.0
Device topology
- entity 1: sun6i-csi (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "ov5640 1-003c":0 [ENABLED,IMMUTABLE]
- entity 5: ov5640 1-003c (1 pad, 1 link)
type V4L2 subdev subtype Sensor flags 0
device node name /dev/v4l-subdev0
pad0: Source
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range]
-> "sun6i-csi":0 [ENABLED,IMMUTABLE]
After this change:
# media-ctl -p
Media controller API version 5.0.0
Media device information
driver sun6i-csi
model Allwinner Video Capture Device
serial
bus info
hw revision 0x0
driver version 5.0.0
Device topology
- entity 1: sun6i-csi (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "ov5640 1-003c":0 [ENABLED,IMMUTABLE]
- entity 5: ov5640 1-003c (1 pad, 1 link)
type V4L2 subdev subtype Sensor flags 0
device node name /dev/v4l-subdev0
pad0: Source
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range]
-> "sun6i-csi":0 [ENABLED,IMMUTABLE]
# media-ctl --set-v4l2 "'ov5640 1-003c':0[fmt:UYVY8_2X8/640x480@1/15 field:none]
"
# media-ctl -p
Media controller API version 5.0.0
Media device information
driver sun6i-csi
model Allwinner Video Capture Device
serial
bus info
hw revision 0x0
driver version 5.0.0
Device topology
- entity 1: sun6i-csi (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "ov5640 1-003c":0 [ENABLED,IMMUTABLE]
- entity 5: ov5640 1-003c (1 pad, 1 link)
type V4L2 subdev subtype Sensor flags 0
device node name /dev/v4l-subdev0
pad0: Source
[fmt:UYVY8_2X8/640x480@1/15 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range]
-> "sun6i-csi":0 [ENABLED,IMMUTABLE]
[1] https://patchwork.kernel.org/patch/10708931/
Re: [PATCH v2] iio: adc: ad7476: Add support for ADS786X ADCs
On Mon, Jan 28, 2019 at 9:43 AM Ricardo Ribalda Delgado
wrote:
>
> HI Alexandru
>
> On Mon, Jan 28, 2019 at 8:38 AM Alexandru Ardelean
> wrote:
> >
> > On Sat, Jan 26, 2019 at 8:21 PM Jonathan Cameron wrote:
> > >
> > > On Fri, 25 Jan 2019 11:04:51 +0100
> > > Ricardo Ribalda Delgado wrote:
> > >
> > > > Add support for ADS7866, ADS7867 and ADS7868 8/10/12 bit Single channel
> > > > ADC.
> > > >
> >
> > I don't want this reply be offensive or anything.
> > But since I've seen this precedence, I do have to ask if these driver
> > changes were tested on at least one of the TI chips/eval-boards.
> >
> > Ideally, before adding new drivers it would be nice to make sure that
> > they were run on actual HW.
> > Good code-review can get us only so far.
> >
> > We could ask someone who has any of these chips to test.
> > Or maybe some eval boards from TI could be obtained to test these changes.
> >
> > Overall changes seem good [I haven't taken a close look], but HW
> > testing is king.
> >
>
> I have access to ADS7868 (the 8 bit version) which has been connected
> in "loopback" to the ti-dac7612 (also new driver). I can run any test
> that you need or even give you or someone access (privately) to the
> board via vpn
> or something like that.
>
> Would that work for you?
No, that's fine :)
Thank you for the answer.
And apologies [again] if this was a bit too forward/harsh from my side.
Thanks
Alex
>
> Best regards!
>
> > Thanks
> > Alex
> >
> > > > Datasheet: http://www.ti.com/lit/ds/symlink/ads7868.pdf
> > > >
> > > > Signed-off-by: Ricardo Ribalda Delgado
> > > > ---
> > > > v2: I have missnamed the devices
> > > > drivers/iio/adc/Kconfig | 3 ++-
> > > > drivers/iio/adc/ad7476.c | 20
> > > > 2 files changed, 22 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > > > index f9354e5ee65c..d86900fc2634 100644
> > > > --- a/drivers/iio/adc/Kconfig
> > > > +++ b/drivers/iio/adc/Kconfig
> > > > @@ -64,7 +64,8 @@ config AD7476
> > > > help
> > > > Say yes here to build support for Analog Devices AD7273,
> > > > AD7274, AD7276,
> > > > AD7277, AD7278, AD7475, AD7476, AD7477, AD7478, AD7466, AD7467,
> > > > AD7468,
> > > > - AD7495, AD7910, AD7920, AD7920 SPI analog to digital converters
> > > > (ADC).
> > > > + AD7495, AD7910, AD7920, AD7920, ADS7866, ADS7867, ADS7868 SPI
> > > > analog
> > > > + to digital converters (ADC).
> > >
> > > As commented in the earlier thread (after you sent this!), please make
> > > sure
> > > the help text makes it clear that these aren't all Analog devices parts.
> > >
> > > Likely to cause confusion otherwise.
> > >
> > > Good to see you didn't spin another driver but instead tracked down that
> > > this one would work well!
> > >
> > > Thanks,
> > >
> > > Jonathan
> > >
> > > >
> > > > To compile this driver as a module, choose M here: the
> > > > module will be called ad7476.
> > > > diff --git a/drivers/iio/adc/ad7476.c b/drivers/iio/adc/ad7476.c
> > > > index 0549686b9ef8..76747488044b 100644
> > > > --- a/drivers/iio/adc/ad7476.c
> > > > +++ b/drivers/iio/adc/ad7476.c
> > > > @@ -59,6 +59,9 @@ enum ad7476_supported_device_ids {
> > > > ID_ADC081S,
> > > > ID_ADC101S,
> > > > ID_ADC121S,
> > > > + ID_ADS7866,
> > > > + ID_ADS7867,
> > > > + ID_ADS7868,
> > > > };
> > > >
> > > > static irqreturn_t ad7476_trigger_handler(int irq, void *p)
> > > > @@ -157,6 +160,8 @@ static int ad7476_read_raw(struct iio_dev
> > > > *indio_dev,
> > > > #define AD7940_CHAN(bits) _AD7476_CHAN((bits), 15 - (bits), \
> > > > BIT(IIO_CHAN_INFO_RAW))
> > > > #define AD7091R_CHAN(bits) _AD7476_CHAN((bits), 16 - (bits), 0)
> > > > +#define ADS786X_CHAN(bits) _AD7476_CHAN((bits), 12 - (bits), \
> > > > + BIT(IIO_CHAN_INFO_RAW))
> > > >
> > > > static const struct ad7476_chip_info ad7476_chip_info_tbl[] = {
> > > > [ID_AD7091R] = {
> > > > @@ -209,6 +214,18 @@ static const struct ad7476_chip_info
> > > > ad7476_chip_info_tbl[] = {
> > > > .channel[0] = ADC081S_CHAN(12),
> > > > .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > > },
> > > > + [ID_ADS7866] = {
> > > > + .channel[0] = ADS786X_CHAN(12),
> > > > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > > + },
> > > > + [ID_ADS7867] = {
> > > > + .channel[0] = ADS786X_CHAN(10),
> > > > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > > + },
> > > > + [ID_ADS7868] = {
> > > > + .channel[0] = ADS786X_CHAN(8),
> > > > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > > + },
> > > > };
> > > >
> > > > static const struct iio_info ad7476_info = {
> > > > @@ -314,6 +331,9 @@ static const struct spi_device_id ad7476_id[] = {
> > > > {"adc081s", ID_ADC081S},
> > > > {"adc101s", ID_ADC101S},
> > > >
Re: [RFC PATCH v2 08/10] rtc: bd70528: Initial support for ROHM bd70528 RTC
Thanks again Guenter,
On Sat, Jan 26, 2019 at 08:30:24AM -0800, Guenter Roeck wrote:
> On 1/25/19 3:05 AM, Matti Vaittinen wrote:
> > +/*
> > + * We read regs RTC_SEC => RTC_YEAR
> > + * this struct is ordered according to chip registers.
> > + * Keep it u8 only to avoid padding issues.
> > + */
> > +struct bd70528_rtc_day {
> > + u8 sec;
> > + u8 min;
> > + u8 hour;
> > +};
> > +
> > +struct bd70528_rtc_data {
> > + struct bd70528_rtc_day time;
> > + u8 week;
> > + u8 day;
> > + u8 month;
> > + u8 year;
> > +};
> > +
> > +struct bd70528_rtc_wake {
> > + struct bd70528_rtc_day time;
> > + u8 ctrl;
> > +};
> > +
> > +struct bd70528_rtc_alm {
> > + struct bd70528_rtc_data data;
> > + u8 alm_mask;
> > + u8 alm_repeat;
> > +};
>
> At least some of the above are directly associated with chip registers.
> I don't think this will work for all architectures without explicit packed
> attribute.
Allright. I was thinking of that but thought that most of the
architectures using this PMIC would handle alignments fine if I used
only u8 members. I did consider using __attribute__((packed)) - but I'm
not sure if we hit into troubles with that too. I guess some people
would like to compile kernel with other compiler(s) but gcc - although
I'm not sure if this should be taken into account. I'll try doing some
study on this - unless someone replies to this and just tells how this
should be done. (I am pretty sure I can find the answer from mail
archives though). I'll try adding some packing hint for compiler at v3.
> > + if ((!enable) == (!(*old_state & BD70528_WAKE_STATE_BIT)))
> > + return 0;
>
> I think
> if (enable == !!(*old_state & BD70528_WAKE_STATE_BIT))
> would be much better readable. Even if not, there are way too many ()
> in the above conditional.
Allright. I'll fix this
> > + if (alm.alm_mask & BD70528_MASK_ALM_EN)
> > + a->enabled = 0;
> > + else
> > + a->enabled = 1;
> > +
> Without conditional:
> a->enabled = !(alm.alm_mask & BD70528_MASK_ALM_EN);
>
Right. Much nicer, thanks! I'll change this.
> > +static int bd70528_set_time(struct device *dev, struct rtc_time *t)
> > +{
> > + int ret, old_states;
> > + struct bd70528_rtc_data rtc_data;
> > + struct bd70528_rtc *r = dev_get_drvdata(dev);
> > + struct bd70528 *bd70528 = r->mfd;
> > +
> > + ret = bd70528_disable_rtc_based_timers(r, _states);
> > +
>
> AFAICS the disable/enable functions are only called once. Since they
> also apply set / clear a mutex, I find that a bit confusing. I think
> it would be better to fold the code into this function. If anything,
> I could imagine something like
>
> mutex_lock();
> ret = bd70528_set_time_locked();
> mutex_unlock()
>
> to simplify error handling.
Yep. Makes sense. I'll tidy this.
> > + ret = regmap_bulk_read(bd70528->chip.regmap,
> > + BD70528_REG_RTC_START, _data,
> > + sizeof(rtc_data));
> > +
> > + tm2rtc(t, _data);
> > +
> > + ret = regmap_bulk_write(bd70528->chip.regmap,
> > + BD70528_REG_RTC_START, _data,
> > + sizeof(rtc_data));
> > +
> > + ret = bd70528_re_enable_rtc_based_timers(r, old_states);
> > +
>
> Kind of off that all the error returns are ignored here.
And I'll fix this too.
Br,
Matti Vaittinen
Re: [PATCH 1/6] dt-bindings: usb: xhci-tegra: Add Tegra186 support
Reviewed-by: JC Kuo On 1/25/19 7:30 PM, Thierry Reding wrote: From: Thierry Reding Extend the bindings to cover the set of features found in Tegra186. Signed-off-by: Thierry Reding --- .../devicetree/bindings/usb/nvidia,tegra124-xusb.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt index 4156c3e181c5..5bfcc0b4d6b9 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt @@ -10,6 +10,7 @@ Required properties: - Tegra124: "nvidia,tegra124-xusb" - Tegra132: "nvidia,tegra132-xusb", "nvidia,tegra124-xusb" - Tegra210: "nvidia,tegra210-xusb" + - Tegra186: "nvidia,tegra186-xusb" - reg: Must contain the base and length of the xHCI host registers, XUSB FPCI registers and XUSB IPFS registers. - reg-names: Must contain the following entries: @@ -59,6 +60,8 @@ For Tegra210: - avdd-pll-uerefe-supply: PLLE reference PLL power supply. Must supply 1.05 V. - dvdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V. - hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 1.8 V. + +For Tegra210 and Tegra186: - power-domains: A list of PM domain specifiers that reference each power-domain used by the xHCI controller. This list must comprise of a specifier for the XUSBA and XUSBC power-domains. See ../power/power_domain.txt and @@ -78,6 +81,7 @@ Optional properties: - Tegra132: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1 - Tegra210: usb2-0, usb2-1, usb2-2, usb2-3, hsic-0, usb3-0, usb3-1, usb3-2, usb3-3 + - Tegra186: usb2-0, usb2-1, usb2-2, hsic-0, usb3-0, usb3-1, usb3-2 Example:
Re: [PATCH 5/5] phy: tegra: xusb: Add Tegra186 support
Reviewed-by: JC Kuo On 1/25/19 7:25 PM, Thierry Reding wrote: From: JC Kuo Add support for the XUSB pad controller found on Tegra186 SoCs. It is mostly similar to the same IP found on earlier chips, but the number of pads exposed differs, as do the programming sequences. Note that the DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL power supplies of the XUSB pad controller require strict power sequencing and are therefore controlled by the PMIC on Tegra186. Signed-off-by: JC Kuo Signed-off-by: Thierry Reding --- MAINTAINERS | 5 + drivers/phy/tegra/Makefile| 1 + drivers/phy/tegra/xusb-tegra186.c | 908 ++ drivers/phy/tegra/xusb.c | 6 + drivers/phy/tegra/xusb.h | 27 + 5 files changed, 947 insertions(+) create mode 100644 drivers/phy/tegra/xusb-tegra186.c diff --git a/MAINTAINERS b/MAINTAINERS index ddcdc29dfe1f..754f7e757361 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15099,6 +15099,11 @@ M: Laxman Dewangan S:Supported F:drivers/spi/spi-tegra* +TEGRA XUSB PADCTL DRIVER +M: JC Kuo +S: Supported +F: drivers/phy/tegra/xusb* + TEHUTI ETHERNET DRIVER M:Andy Gospodarek L:net...@vger.kernel.org diff --git a/drivers/phy/tegra/Makefile b/drivers/phy/tegra/Makefile index 898589238fd9..a93cd9a499b2 100644 --- a/drivers/phy/tegra/Makefile +++ b/drivers/phy/tegra/Makefile @@ -4,3 +4,4 @@ phy-tegra-xusb-y += xusb.o phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_124_SOC) += xusb-tegra124.o phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_132_SOC) += xusb-tegra124.o phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_210_SOC) += xusb-tegra210.o +phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_186_SOC) += xusb-tegra186.o diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c new file mode 100644 index ..0dbcaddade90 --- /dev/null +++ b/drivers/phy/tegra/xusb-tegra186.c @@ -0,0 +1,908 @@ +/* + * Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "xusb.h" + +/* FUSE USB_CALIB registers */ +#define HS_CURR_LEVEL_PADX_SHIFT(x)((x) ? (11 + (x - 1) * 6) : 0) +#define HS_CURR_LEVEL_PAD_MASK 0x3f +#define HS_TERM_RANGE_ADJ_SHIFT7 +#define HS_TERM_RANGE_ADJ_MASK 0xf +#define HS_SQUELCH_SHIFT 29 +#define HS_SQUELCH_MASK0x7 + +#define RPD_CTRL_SHIFT 0 +#define RPD_CTRL_MASK 0x1f + +/* XUSB PADCTL registers */ +#define XUSB_PADCTL_USB2_PAD_MUX 0x4 +#define USB2_PORT_SHIFT(x)((x) * 2) +#define USB2_PORT_MASK0x3 +#define PORT_XUSB1 +#define HSIC_PORT_SHIFT(x)((x) + 20) +#define HSIC_PORT_MASK0x1 +#define PORT_HSIC0 + +#define XUSB_PADCTL_USB2_PORT_CAP 0x8 +#define XUSB_PADCTL_SS_PORT_CAP0xc +#define PORTX_CAP_SHIFT(x)((x) * 4) +#define PORT_CAP_MASK 0x3 +#define PORT_CAP_DISABLED0x0 +#define PORT_CAP_HOST0x1 +#define PORT_CAP_DEVICE 0x2 +#define PORT_CAP_OTG 0x3 + +#define XUSB_PADCTL_ELPG_PROGRAM 0x20 +#define USB2_PORT_WAKE_INTERRUPT_ENABLE(x)(1 << (x)) +#define USB2_PORT_WAKEUP_EVENT(x) ( 1 << ((x) + 7)) +#define SS_PORT_WAKE_INTERRUPT_ENABLE(x) (1 << ((x) + 14)) +#define SS_PORT_WAKEUP_EVENT(x) (1 << ((x) + 21)) +#define USB2_HSIC_PORT_WAKE_INTERRUPT_ENABLE(x) (1 << ((x) + 28)) +#define USB2_HSIC_PORT_WAKEUP_EVENT(x)(1 << ((x) + 30)) +#define ALL_WAKE_EVENTS \ + (USB2_PORT_WAKEUP_EVENT(0) | USB2_PORT_WAKEUP_EVENT(1) |\ + USB2_PORT_WAKEUP_EVENT(2) | SS_PORT_WAKEUP_EVENT(0) | \ + SS_PORT_WAKEUP_EVENT(1) | SS_PORT_WAKEUP_EVENT(2) | \ + USB2_HSIC_PORT_WAKEUP_EVENT(0)) + +#define XUSB_PADCTL_ELPG_PROGRAM_1 0x24 +#define SSPX_ELPG_CLAMP_EN(x) (1 << (0 + (x) * 3)) +#define SSPX_ELPG_CLAMP_EN_EARLY(x) (1 << (1 + (x) * 3)) +#define SSPX_ELPG_VCORE_DOWN(x) (1 << (2 + (x) * 3)) + +#define XUSB_PADCTL_USB2_OTG_PADX_CTL0(x) (0x88 + (x) * 0x40) +#define HS_CURR_LEVEL(x)
Re: [PATCH v2] iio: adc: ad7476: Add support for ADS786X ADCs
HI Alexandru
On Mon, Jan 28, 2019 at 8:38 AM Alexandru Ardelean
wrote:
>
> On Sat, Jan 26, 2019 at 8:21 PM Jonathan Cameron wrote:
> >
> > On Fri, 25 Jan 2019 11:04:51 +0100
> > Ricardo Ribalda Delgado wrote:
> >
> > > Add support for ADS7866, ADS7867 and ADS7868 8/10/12 bit Single channel
> > > ADC.
> > >
>
> I don't want this reply be offensive or anything.
> But since I've seen this precedence, I do have to ask if these driver
> changes were tested on at least one of the TI chips/eval-boards.
>
> Ideally, before adding new drivers it would be nice to make sure that
> they were run on actual HW.
> Good code-review can get us only so far.
>
> We could ask someone who has any of these chips to test.
> Or maybe some eval boards from TI could be obtained to test these changes.
>
> Overall changes seem good [I haven't taken a close look], but HW
> testing is king.
>
I have access to ADS7868 (the 8 bit version) which has been connected
in "loopback" to the ti-dac7612 (also new driver). I can run any test
that you need or even give you or someone access (privately) to the
board via vpn
or something like that.
Would that work for you?
Best regards!
> Thanks
> Alex
>
> > > Datasheet: http://www.ti.com/lit/ds/symlink/ads7868.pdf
> > >
> > > Signed-off-by: Ricardo Ribalda Delgado
> > > ---
> > > v2: I have missnamed the devices
> > > drivers/iio/adc/Kconfig | 3 ++-
> > > drivers/iio/adc/ad7476.c | 20
> > > 2 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > > index f9354e5ee65c..d86900fc2634 100644
> > > --- a/drivers/iio/adc/Kconfig
> > > +++ b/drivers/iio/adc/Kconfig
> > > @@ -64,7 +64,8 @@ config AD7476
> > > help
> > > Say yes here to build support for Analog Devices AD7273, AD7274,
> > > AD7276,
> > > AD7277, AD7278, AD7475, AD7476, AD7477, AD7478, AD7466, AD7467,
> > > AD7468,
> > > - AD7495, AD7910, AD7920, AD7920 SPI analog to digital converters
> > > (ADC).
> > > + AD7495, AD7910, AD7920, AD7920, ADS7866, ADS7867, ADS7868 SPI
> > > analog
> > > + to digital converters (ADC).
> >
> > As commented in the earlier thread (after you sent this!), please make sure
> > the help text makes it clear that these aren't all Analog devices parts.
> >
> > Likely to cause confusion otherwise.
> >
> > Good to see you didn't spin another driver but instead tracked down that
> > this one would work well!
> >
> > Thanks,
> >
> > Jonathan
> >
> > >
> > > To compile this driver as a module, choose M here: the
> > > module will be called ad7476.
> > > diff --git a/drivers/iio/adc/ad7476.c b/drivers/iio/adc/ad7476.c
> > > index 0549686b9ef8..76747488044b 100644
> > > --- a/drivers/iio/adc/ad7476.c
> > > +++ b/drivers/iio/adc/ad7476.c
> > > @@ -59,6 +59,9 @@ enum ad7476_supported_device_ids {
> > > ID_ADC081S,
> > > ID_ADC101S,
> > > ID_ADC121S,
> > > + ID_ADS7866,
> > > + ID_ADS7867,
> > > + ID_ADS7868,
> > > };
> > >
> > > static irqreturn_t ad7476_trigger_handler(int irq, void *p)
> > > @@ -157,6 +160,8 @@ static int ad7476_read_raw(struct iio_dev *indio_dev,
> > > #define AD7940_CHAN(bits) _AD7476_CHAN((bits), 15 - (bits), \
> > > BIT(IIO_CHAN_INFO_RAW))
> > > #define AD7091R_CHAN(bits) _AD7476_CHAN((bits), 16 - (bits), 0)
> > > +#define ADS786X_CHAN(bits) _AD7476_CHAN((bits), 12 - (bits), \
> > > + BIT(IIO_CHAN_INFO_RAW))
> > >
> > > static const struct ad7476_chip_info ad7476_chip_info_tbl[] = {
> > > [ID_AD7091R] = {
> > > @@ -209,6 +214,18 @@ static const struct ad7476_chip_info
> > > ad7476_chip_info_tbl[] = {
> > > .channel[0] = ADC081S_CHAN(12),
> > > .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > },
> > > + [ID_ADS7866] = {
> > > + .channel[0] = ADS786X_CHAN(12),
> > > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > + },
> > > + [ID_ADS7867] = {
> > > + .channel[0] = ADS786X_CHAN(10),
> > > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > + },
> > > + [ID_ADS7868] = {
> > > + .channel[0] = ADS786X_CHAN(8),
> > > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > + },
> > > };
> > >
> > > static const struct iio_info ad7476_info = {
> > > @@ -314,6 +331,9 @@ static const struct spi_device_id ad7476_id[] = {
> > > {"adc081s", ID_ADC081S},
> > > {"adc101s", ID_ADC101S},
> > > {"adc121s", ID_ADC121S},
> > > + {"ads7866", ID_ADS7866},
> > > + {"ads7867", ID_ADS7867},
> > > + {"ads7868", ID_ADS7868},
> > > {}
> > > };
> > > MODULE_DEVICE_TABLE(spi, ad7476_id);
> >
--
Ricardo Ribalda
Re: [PATCH 03/15] habanalabs: add basic Goya support
On Sun, Jan 27, 2019 at 8:39 AM Mike Rapoport wrote:
>
> On Fri, Jan 25, 2019 at 10:32:55PM +0200, Oded Gabbay wrote:
> > On Wed, Jan 23, 2019 at 2:28 PM Mike Rapoport wrote:
> > >
> > > On Wed, Jan 23, 2019 at 02:00:45AM +0200, Oded Gabbay wrote:
> > > > This patch adds a basic support for the Goya device. The code
> > > > initializes
> > > > the device's PCI controller and PCI bars. It also initializes various
> > > > S/W
> > > > structures and adds some basic helper functions.
> > > >
> > > > Signed-off-by: Oded Gabbay
> > > > ---
> > > > drivers/misc/habanalabs/Makefile| 5 +-
> > > > drivers/misc/habanalabs/device.c| 71 +++
> > > > drivers/misc/habanalabs/goya/Makefile | 3 +
> > > > drivers/misc/habanalabs/goya/goya.c | 633
> > > > drivers/misc/habanalabs/goya/goyaP.h| 125
> > > > drivers/misc/habanalabs/habanalabs.h| 131
> > > > drivers/misc/habanalabs/habanalabs_drv.c| 3 +
> > > > drivers/misc/habanalabs/include/goya/goya.h | 115
> > > > 8 files changed, 1085 insertions(+), 1 deletion(-)
> > > > create mode 100644 drivers/misc/habanalabs/goya/Makefile
> > > > create mode 100644 drivers/misc/habanalabs/goya/goya.c
> > > > create mode 100644 drivers/misc/habanalabs/goya/goyaP.h
> > > > create mode 100644 drivers/misc/habanalabs/include/goya/goya.h
>
> [ ... ]
>
> > > > +
> > > > +/**
> > > > + * goya_sw_init - Goya software initialization code
> > > > + *
> > > > + * @hdev: pointer to hl_device structure
> > > > + *
> > > > + */
> > > > +static int goya_sw_init(struct hl_device *hdev)
> > > > +{
> > > > + struct goya_device *goya;
> > > > + int rc;
> > > > +
> > > > + /* Allocate device structure */
> > > > + goya = kzalloc(sizeof(*goya), GFP_KERNEL);
> > >
> > > Consider using devm_k[mz]alloc() for memory allocations throughout the
> > > driver. I didn't check all the spots where it can be applicable.
> > I honestly wasn't aware of that. We never used that in AMD drivers
> > (which where I spent most of my kernel time).
> > I'll look into that offline but for now I don't really want to change
> > into it blindly in all locations, unless there is some hard kernel
> > rule for using that in drivers.
>
> AFAIK, there's no such rule. It's just supposed to make driver
> developer/maintainer life easier ;-)
>
> > >
> > > > + if (!goya)
> > > > + return -ENOMEM;
> > > > +
> > > > + /* according to goya_init_iatu */
> > > > + goya->ddr_bar_cur_addr = DRAM_PHYS_BASE;
> > > > + hdev->asic_specific = goya;
> > > > +
> > > > + /* Create DMA pool for small allocations */
> > > > + hdev->dma_pool = dma_pool_create(dev_name(hdev->dev),
> > > > + >pdev->dev, GOYA_DMA_POOL_BLK_SIZE, 8, 0);
> > > > + if (!hdev->dma_pool) {
> > > > + dev_err(hdev->dev, "failed to create DMA pool\n");
> > > > + rc = -ENOMEM;
> > > > + goto free_goya_device;
> > > > + }
> > > > +
>
> [ ... ]
>
> > > > +
> > > > +static const struct hl_asic_funcs goya_funcs = {
> > > > + .early_init = goya_early_init,
> > > > + .early_fini = goya_early_fini,
> > > > + .sw_init = goya_sw_init,
> > > > + .sw_fini = goya_sw_fini,
> > > > + .suspend = goya_suspend,
> > > > + .resume = goya_resume,
> > > > + .dma_alloc_coherent = goya_dma_alloc_coherent,
> > > > + .dma_free_coherent = goya_dma_free_coherent,
> > >
> > > Is there any additional functionality that is planned in goya or gaudi in
> > > these two functions?
> > > It seems like they are not really needed, at least at the moment and for
> > > sure that don't need to be part of ASIC ops.
> >
> > So this relates to the simulator support, because there the
> > implementation of these two functions is totally different as I don't
> > have pci device.
>
> Can you please add a comment about it here?
Of course, done.
Thanks,
Oded
>
> --
> Sincerely yours,
> Mike.
>
Re: [PATCH 1/2] spi: support inter-word delay requirement for devices
Hi Jonas,
On Sat, Jan 26, 2019 at 4:40 PM Jonas Bonn wrote:
> On 26/01/2019 11:25, Geert Uytterhoeven wrote:
> > On Sat, Jan 26, 2019 at 8:53 AM Jonas Bonn wrote:
> >> On 25/01/2019 18:50, Mark Brown wrote:
> >>> On Fri, Jan 25, 2019 at 05:47:13PM +, Mark Brown wrote:
> On Fri, Jan 25, 2019 at 01:06:45PM +0100, Jonas Bonn wrote:
> > Having this as device property rather than a transfer property allows
> > this
> > to be configured one time in setup() rather than having to fiddle with
> > the
> > configuration register for every transfer.
> >>>
> That doesn't mean that the coniguration should be done in DT though, and
> given that this presumably is a property of the device there seems to be
> no reason why we'd have it in DT - if every instance of the device is
> going to need to set the property we should just figure it out from the
> compatble string instead.
> >>>
> >>> To be clear here: the suggestion is to add a parameter the slave device
> >>> can set in spi_device which sets the default word_delay similarly to how
> >>> max_speed_hz works.
> >>
> >> I'm confused... isn't that exactly what this patch does? It adds a
> >> field word_delay to spi_device in the same manner as max_speed_hz.
> >>
> >> I also added the ability to set it via DT, which I can break out into a
> >> separate patch if that's an issue. Or is the problem that it's set via
> >> DT, at all? Documentation/devicetree/bindings/spi-bus.txt documents 10
> >> other slave-node properties related to transfer characteristics;
> >> word_delay is just another such characteristic.
> >>
> >> But again, I'm having trouble parsing your response Is the patch wrong,
> >> should be broken up, or you just misunderstood it?
> >
> > IIUIC, Mark means that it may be a non-configurable property of the slave
> > device, and thus should be handled (fixed setting) in the SPI slave driver.
>
> OK, so given that the "compatible" property identifies the hardware and
> there is no other _hardware_ configuration detail that affects the
> required inter-word delay, then setting the property in the device tree
> is not allowed as the driver has enough info to set it properly. Fair
> enough!
>
> >
> > Compare this to CPHA/CPOL, which are properties of the SPI slave device,
> > but which may be configurable. E.g. many SPI FLASHes support multiple
> > configurations. See e.g. commit 9c5becce21af35e5 ("ARM: shmobile: koelsch:
> > Fix QSPI mode of SPI-Flash into mode3").
>
> There is nothing about the hardware referenced in that patch that
> enforces either mode. Why does the driver get to defer to DT here?
The default is non-cpol and non-pha.
The device supports both (perhaps even all four modes, didn't check).
> Looking at Documentation/devicetree/bindings/spi/spi-bus.txt:
>
> spi-lsb-first: used only by MAXIM DS-1302 which is always LSB first;
> driver should set this
For DS1302, this is probable true.
For e.g. a generic shift register (e.g. hc595), the driver cannot know.
> spi-3wire: again, only set by MAXIM DS-1302 which always needs this
> setting; driver could set this
For DS1302, this is probable true.
Some devices may support both 4-wire or 3-wire mode?
> spi-tx-delay-us:
> spi-rx-delay-us: only parsed by RMI4 driver... no DTS files in kernel
> set these. I hardly see how these are "hardware" settings rather than
> message settings, but the driver can set these in any case.
>
> Anyway, the point is, looking at the current documentation, it's pretty
> difficult to understand whether devicetree is restricted to describing
> hardware or is also for configuring drivers...
True.
> > Again, max_speed_hz is something different: while both the SPI master and
> > slave may support high speeds, board wiring (capacitance/inductance) may
> > need to force a slower speed than supported by the devices, so it makes
> > sense to make that configurable from DT.
>
> Yeah, that one make sense. But if the DT is only overriding the maximum
> device frequency that the driver should otherwise be setting, why is
> spi-max-frequency a _required_ property?
That's a good question. Legacy?
> Thanks for taking the time to provide the additional explanation. I had
> to ruminate on it for a bit, but I think it's starting to sink in now!
You're welcome!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API
On Fri, Jan 25, 2019 at 7:25 PM Stanimir Varbanov
wrote:
>
> Hi Tomasz,
>
> Thanks for the comments!
>
> On 1/25/19 9:59 AM, Tomasz Figa wrote:
> > .Hi Stan,
> >
> > On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
> > wrote:
> >>
> >> This refactored code for start/stop streaming vb2 operations and
> >> adds a state machine handling similar to the one in stateful codec
> >> API documentation. One major change is that now the HFI session is
> >> started on STREAMON(OUTPUT) and stopped on REQBUF(OUTPUT,count=0),
> >> during that time streamoff(cap,out) just flush buffers but doesn't
> >> stop the session. The other major change is that now the capture
> >> and output queues are completely separated.
> >>
> >> Signed-off-by: Stanimir Varbanov
> >> ---
> >> drivers/media/platform/qcom/venus/core.h| 20 +-
> >> drivers/media/platform/qcom/venus/helpers.c | 23 +-
> >> drivers/media/platform/qcom/venus/helpers.h | 5 +
> >> drivers/media/platform/qcom/venus/vdec.c| 449
> >> 4 files changed, 389 insertions(+), 108 deletions(-)
> >>
> >
> > Thanks for the patch! Please see some comments inline.
> >
> >> diff --git a/drivers/media/platform/qcom/venus/core.h
> >> b/drivers/media/platform/qcom/venus/core.h
> >> index 79c7e816c706..5a133c203455 100644
> >> --- a/drivers/media/platform/qcom/venus/core.h
> >> +++ b/drivers/media/platform/qcom/venus/core.h
> >> @@ -218,6 +218,15 @@ struct venus_buffer {
> >>
> >> #define to_venus_buffer(ptr) container_of(ptr, struct venus_buffer, vb)
> >>
> >> +#define DEC_STATE_UNINIT 0
> >> +#define DEC_STATE_INIT 1
> >> +#define DEC_STATE_CAPTURE_SETUP2
> >> +#define DEC_STATE_STOPPED 3
> >> +#define DEC_STATE_SEEK 4
> >> +#define DEC_STATE_DRAIN5
> >> +#define DEC_STATE_DECODING 6
> >> +#define DEC_STATE_DRC 7
> >> +
> >> /**
> >> * struct venus_inst - holds per instance paramerters
> >> *
> >> @@ -241,6 +250,10 @@ struct venus_buffer {
> >> * @colorspace:current color space
> >> * @quantization: current quantization
> >> * @xfer_func: current xfer function
> >> + * @codec_state: current codec API state (see DEC/ENC_STATE_)
> >> + * @reconf_wait: wait queue for resolution change event
> >> + * @ten_bits: does new stream is 10bits depth
> >> + * @buf_count: used to count number number of buffers (reqbuf(0))
> >> * @fps: holds current FPS
> >> * @timeperframe: holds current time per frame structure
> >> * @fmt_out: a reference to output format structure
> >> @@ -255,8 +268,6 @@ struct venus_buffer {
> >> * @opb_buftype: output picture buffer type
> >> * @opb_fmt: output picture buffer raw format
> >> * @reconfig: a flag raised by decoder when the stream resolution changed
> >> - * @reconfig_width:holds the new width
> >> - * @reconfig_height: holds the new height
> >> * @hfi_codec: current codec for this instance in HFI space
> >> * @sequence_cap: a sequence counter for capture queue
> >> * @sequence_out: a sequence counter for output queue
> >> @@ -296,6 +307,9 @@ struct venus_inst {
> >> u8 ycbcr_enc;
> >> u8 quantization;
> >> u8 xfer_func;
> >> + unsigned int codec_state;
> >> + wait_queue_head_t reconf_wait;
> >> + int buf_count;
> >> u64 fps;
> >> struct v4l2_fract timeperframe;
> >> const struct venus_format *fmt_out;
> >> @@ -310,8 +324,6 @@ struct venus_inst {
> >> u32 opb_buftype;
> >> u32 opb_fmt;
> >> bool reconfig;
> >> - u32 reconfig_width;
> >> - u32 reconfig_height;
> >> u32 hfi_codec;
> >> u32 sequence_cap;
> >> u32 sequence_out;
> >> diff --git a/drivers/media/platform/qcom/venus/helpers.c
> >> b/drivers/media/platform/qcom/venus/helpers.c
> >> index 637ce7b82d94..25d8cceccae4 100644
> >> --- a/drivers/media/platform/qcom/venus/helpers.c
> >> +++ b/drivers/media/platform/qcom/venus/helpers.c
> >> @@ -1030,16 +1030,15 @@ void venus_helper_vb2_buf_queue(struct vb2_buffer
> >> *vb)
> >>
> >> v4l2_m2m_buf_queue(m2m_ctx, vbuf);
> >>
> >> - if (!(inst->streamon_out & inst->streamon_cap))
> >> - goto unlock;
> >> -
> >> - ret = is_buf_refed(inst, vbuf);
> >> - if (ret)
> >> - goto unlock;
> >> + if (IS_OUT(vb->vb2_queue, inst) || IS_CAP(vb->vb2_queue, inst)) {
> >
> > Wouldn't a simple vb2_is_streaming() work here?
>
> I'd say no, because the buffer can be queued but the streaming on that
> queue isn't started yet. The idea is to send buffers to firmware only
> when the streaming is on on that queue,
Isn't it exactly what vb2_is_streaming(vb->vb2_queue) would check?
> otherwise we only queue the
> buffer in m2m_buf_queue (and send for processing once the streaming on
> that particular
Re: [PATCH v2] iio: adc: ad7476: Add support for ADS786X ADCs
On Sat, Jan 26, 2019 at 8:21 PM Jonathan Cameron wrote:
>
> On Fri, 25 Jan 2019 11:04:51 +0100
> Ricardo Ribalda Delgado wrote:
>
> > Add support for ADS7866, ADS7867 and ADS7868 8/10/12 bit Single channel
> > ADC.
> >
I don't want this reply be offensive or anything.
But since I've seen this precedence, I do have to ask if these driver
changes were tested on at least one of the TI chips/eval-boards.
Ideally, before adding new drivers it would be nice to make sure that
they were run on actual HW.
Good code-review can get us only so far.
We could ask someone who has any of these chips to test.
Or maybe some eval boards from TI could be obtained to test these changes.
Overall changes seem good [I haven't taken a close look], but HW
testing is king.
Thanks
Alex
> > Datasheet: http://www.ti.com/lit/ds/symlink/ads7868.pdf
> >
> > Signed-off-by: Ricardo Ribalda Delgado
> > ---
> > v2: I have missnamed the devices
> > drivers/iio/adc/Kconfig | 3 ++-
> > drivers/iio/adc/ad7476.c | 20
> > 2 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index f9354e5ee65c..d86900fc2634 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -64,7 +64,8 @@ config AD7476
> > help
> > Say yes here to build support for Analog Devices AD7273, AD7274,
> > AD7276,
> > AD7277, AD7278, AD7475, AD7476, AD7477, AD7478, AD7466, AD7467,
> > AD7468,
> > - AD7495, AD7910, AD7920, AD7920 SPI analog to digital converters
> > (ADC).
> > + AD7495, AD7910, AD7920, AD7920, ADS7866, ADS7867, ADS7868 SPI analog
> > + to digital converters (ADC).
>
> As commented in the earlier thread (after you sent this!), please make sure
> the help text makes it clear that these aren't all Analog devices parts.
>
> Likely to cause confusion otherwise.
>
> Good to see you didn't spin another driver but instead tracked down that
> this one would work well!
>
> Thanks,
>
> Jonathan
>
> >
> > To compile this driver as a module, choose M here: the
> > module will be called ad7476.
> > diff --git a/drivers/iio/adc/ad7476.c b/drivers/iio/adc/ad7476.c
> > index 0549686b9ef8..76747488044b 100644
> > --- a/drivers/iio/adc/ad7476.c
> > +++ b/drivers/iio/adc/ad7476.c
> > @@ -59,6 +59,9 @@ enum ad7476_supported_device_ids {
> > ID_ADC081S,
> > ID_ADC101S,
> > ID_ADC121S,
> > + ID_ADS7866,
> > + ID_ADS7867,
> > + ID_ADS7868,
> > };
> >
> > static irqreturn_t ad7476_trigger_handler(int irq, void *p)
> > @@ -157,6 +160,8 @@ static int ad7476_read_raw(struct iio_dev *indio_dev,
> > #define AD7940_CHAN(bits) _AD7476_CHAN((bits), 15 - (bits), \
> > BIT(IIO_CHAN_INFO_RAW))
> > #define AD7091R_CHAN(bits) _AD7476_CHAN((bits), 16 - (bits), 0)
> > +#define ADS786X_CHAN(bits) _AD7476_CHAN((bits), 12 - (bits), \
> > + BIT(IIO_CHAN_INFO_RAW))
> >
> > static const struct ad7476_chip_info ad7476_chip_info_tbl[] = {
> > [ID_AD7091R] = {
> > @@ -209,6 +214,18 @@ static const struct ad7476_chip_info
> > ad7476_chip_info_tbl[] = {
> > .channel[0] = ADC081S_CHAN(12),
> > .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > },
> > + [ID_ADS7866] = {
> > + .channel[0] = ADS786X_CHAN(12),
> > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > + },
> > + [ID_ADS7867] = {
> > + .channel[0] = ADS786X_CHAN(10),
> > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > + },
> > + [ID_ADS7868] = {
> > + .channel[0] = ADS786X_CHAN(8),
> > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > + },
> > };
> >
> > static const struct iio_info ad7476_info = {
> > @@ -314,6 +331,9 @@ static const struct spi_device_id ad7476_id[] = {
> > {"adc081s", ID_ADC081S},
> > {"adc101s", ID_ADC101S},
> > {"adc121s", ID_ADC121S},
> > + {"ads7866", ID_ADS7866},
> > + {"ads7867", ID_ADS7867},
> > + {"ads7868", ID_ADS7868},
> > {}
> > };
> > MODULE_DEVICE_TABLE(spi, ad7476_id);
>
Re: [RFC PATCH v2 00/10] support ROHM BD70528 PMIC
Hello Lee, All On Mon, Jan 28, 2019 at 07:19:36AM +, Lee Jones wrote: > On Fri, 25 Jan 2019, Matti Vaittinen wrote: > > > Patch series introducing support for ROHM BD70528 PMIC > > > > Please note that patch 1 breaks compilation without patches 2 and 3 > > > > ROHM BD70528 is a programmable Power Management IC for battery > > powered 'ultra low power' systems like the pre-announced NXP > > i.MX7 ULP. This patch series introduces support for the PMIC. > > It looks like you've sent this set un-threaded, which means as people > reply to the patches, they are going to be spread out into the four > winds (in Inbox terms). Sigh. Sorry for trouble then. I must've forgotten the --thread from git format-patch. You can skip the v2 if it's all scattered out, I will address issues spotted by Guenter and send out the v3 - and this time I make sure to use --thread =) Br, Matti Vaittinen > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog
Re: DMA-related cleanups for parisc
On Sat, Jan 26, 2019 at 06:11:24PM +0100, Helge Deller wrote: > Thanks for doing that! > I tested it. Your patches work, but you need the fixup below (0-day > testing complained as well). I actually sent a v2 series since then which makes sure the new iommu.h includes , so that we don't rely on header ordering. > > With the one below, you may add > Tested-by: Helge Deller While this series prepares for DMA layerer work it isn't urgent, so if you want to pick it up through the parisc tree that is perfectly fine with me.
Re: [2/2] mfd: max77620: Add low battery monitor support
On 1/28/19, Lee Jones wrote: > Re-sending due to dodgy looking 'reply-to'. > > On Sun, 27 Jan 2019, Billy Laws wrote: > >> >This patch adds PMIC configurations for low-battery >> >monitoring by handling max77620 register CNFGGLBL1. >> > >> It might be an idea to add lbhyst configuration here and support using >> custom lbdac values to specify a different cutoff point. > > Do you know why this email was sent independent of the original > submission? Something wrong with your mailer? > I tried to add the reply to manually in thunderbird as I wasn't subscribed to the mailing list, seems it didn't exactly work. > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog >
Re: [PATCH v7 2/5] media: sun6i: Add A64 CSI block support
On Fri, Jan 25, 2019 at 9:12 PM Maxime Ripard wrote:
>
> On Thu, Jan 24, 2019 at 11:37:33PM +0530, Jagan Teki wrote:
> > CSI block in Allwinner A64 has similar features as like in H3,
> > but the default CSI_SCLK rate cannot work properly to drive the
> > connected sensor interface.
> >
> > The tested mod cock rate is 300 MHz and BSP vfe media driver is also
> > using the same rate. Unfortunately there is no valid information about
> > clock rate in manual or any other sources except the BSP driver. so more
> > faith on BSP code, because same has tested in mainline.
> >
> > So, add support for A64 CSI block by setting updated mod clock rate.
> >
> > Signed-off-by: Jagan Teki
> > ---
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 13 -
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > index ee882b66a5ea..cd2d33242c17 100644
> > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -154,6 +155,7 @@ bool sun6i_csi_is_format_supported(struct sun6i_csi
> > *csi,
> > int sun6i_csi_set_power(struct sun6i_csi *csi, bool enable)
> > {
> > struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
> > + struct device *dev = sdev->dev;
> > struct regmap *regmap = sdev->regmap;
> > int ret;
> >
> > @@ -161,15 +163,20 @@ int sun6i_csi_set_power(struct sun6i_csi *csi, bool
> > enable)
> > regmap_update_bits(regmap, CSI_EN_REG, CSI_EN_CSI_EN, 0);
> >
> > clk_disable_unprepare(sdev->clk_ram);
> > + if (of_device_is_compatible(dev->of_node,
> > "allwinner,sun50i-a64-csi"))
> > + clk_rate_exclusive_put(sdev->clk_mod);
> > clk_disable_unprepare(sdev->clk_mod);
> > reset_control_assert(sdev->rstc_bus);
> > return 0;
> > }
> >
> > + if (of_device_is_compatible(dev->of_node, "allwinner,sun50i-a64-csi"))
> > + clk_set_rate_exclusive(sdev->clk_mod, 3);
> > +
> > ret = clk_prepare_enable(sdev->clk_mod);
> > if (ret) {
> > dev_err(sdev->dev, "Enable csi clk err %d\n", ret);
> > - return ret;
> > + goto clk_mod_put;
> > }
> >
> > ret = clk_prepare_enable(sdev->clk_ram);
> > @@ -192,6 +199,9 @@ int sun6i_csi_set_power(struct sun6i_csi *csi, bool
> > enable)
> > clk_disable_unprepare(sdev->clk_ram);
> > clk_mod_disable:
> > clk_disable_unprepare(sdev->clk_mod);
> > +clk_mod_put:
> > + if (of_device_is_compatible(dev->of_node, "allwinner,sun50i-a64-csi"))
> > + clk_rate_exclusive_put(sdev->clk_mod);
> > return ret;
>
> The sequence in the error path and in the disable path aren't the same, why?
True, it should be similar sequence, will fix and send next version. thanks!
[PATCH] [media] v4l: add I / P frame min max QP definitions
Add following V4L2 QP parameters for H.264:
* V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP
* V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP
* V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP
* V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP
These controls will limit QP range for intra and inter frame,
provide more manual control to improve video encode quality.
Signed-off-by: Fish Lin
---
drivers/media/v4l2-core/v4l2-ctrls.c | 4
include/uapi/linux/v4l2-controls.h | 6 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 5e3806feb5d7..e2b0af0d2283 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -825,6 +825,10 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER:return "H264
Number of HC Layers";
case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP:
return "H264
Set QP Value for HC Layers";
+ case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP: return "H264
I-Frame Minimum QP Value";
+ case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP: return "H264
I-Frame Maximum QP Value";
+ case V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP: return "H264
P-Frame Minimum QP Value";
+ case V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP: return "H264
P-Frame Maximum QP Value";
case V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP: return "MPEG4
I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP: return "MPEG4
P-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_MPEG4_B_FRAME_QP: return "MPEG4
B-Frame QP Value";
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 3dcfc6148f99..9519673e6437 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -533,6 +533,12 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type {
};
#define V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER
(V4L2_CID_MPEG_BASE+381)
#define V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP
(V4L2_CID_MPEG_BASE+382)
+
+#define V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP(V4L2_CID_MPEG_BASE+390)
+#define V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP(V4L2_CID_MPEG_BASE+391)
+#define V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP(V4L2_CID_MPEG_BASE+392)
+#define V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP(V4L2_CID_MPEG_BASE+393)
+
#define V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP (V4L2_CID_MPEG_BASE+400)
#define V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP (V4L2_CID_MPEG_BASE+401)
#define V4L2_CID_MPEG_VIDEO_MPEG4_B_FRAME_QP (V4L2_CID_MPEG_BASE+402)
--
2.20.1.495.gaa96b0ce6b-goog
Re: [PATCH] staging:iio:ad7152: Rename misspelled RESEVERD -> RESERVED
On Sat, Jan 26, 2019 at 8:09 PM Jonathan Cameron wrote: > > On Fri, 25 Jan 2019 10:19:54 +0200 > Alexandru Ardelean wrote: > > > On Thu, Jan 24, 2019 at 9:35 PM Rodrigo Ribeiro > > wrote: > > > > > > Remove the checkpatch.pl check: > > > > > > CHECK: 'RESEVERD' may be misspelled - perhaps 'RESERVED'? > > > > Hey, > > > > A bit curios about this one. > > Are you using this chip/driver ? > > > > Thing is: the part is nearing EOL, and it could be an idea to be > > marked for removal (since it's still in staging). > > But if there are users for this driver, it could be left around for a while. > > While it might be going away soon, I'm also not that bothered about > the small amount of churn that a tidy up patch like this causes, > and it might not go away ;) > > However it is rather odd to have a 'reserved' entry for a register. > can't see that providing any useful information. Normally I'm > happy to have complete register sets as a form of documentation > if the author wants to do it that way. This however seems silly. > > Alex, we haven't really gone with marking things as 'going away' > before. I'd suggest we take a guess and remove it if you and the > team an analog don't think it's in use. Happy to get a patch for > that if you want to send one. Of course, Rodrigo could do that > patch to get started if that works for everyone? :) > We'll also start a discussion about this particular driver internally. And maybe a procedure for removing drivers that become obsolete [or come close to it]. We also don't/didn't have one for removing "going away" drivers; I just remembered that we took a look over this one and decided not to invest time into it as it's close to being obsolete. Thanks Alex > Jonathan > > > > Thanks > > Alex > > > > > > > > Signed-off-by: Rodrigo Ribeiro > > > Signed-off-by: Rafael Tsuha > > > --- > > > This macro is not used anywhere. Should we just correct the > > > spelling or remove the macro? > > > > > > drivers/staging/iio/cdc/ad7152.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/staging/iio/cdc/ad7152.c > > > b/drivers/staging/iio/cdc/ad7152.c > > > index 25f51db..c9da6d4 100644 > > > --- a/drivers/staging/iio/cdc/ad7152.c > > > +++ b/drivers/staging/iio/cdc/ad7152.c > > > @@ -35,7 +35,7 @@ > > > #define AD7152_REG_CH2_GAIN_HIGH 12 > > > #define AD7152_REG_CH2_SETUP 14 > > > #define AD7152_REG_CFG 15 > > > -#define AD7152_REG_RESEVERD16 > > > +#define AD7152_REG_RESERVED16 > > > #define AD7152_REG_CAPDAC_POS 17 > > > #define AD7152_REG_CAPDAC_NEG 18 > > > #define AD7152_REG_CFG226 > > > -- > > > 2.7.4 > > > >
Re: [for next][PATCH 1/2] mfd: Fix unmet dependency warning for MFD_TPS68470
On Thu, 24 Jan 2019, Sinan Kaya wrote: > On 1/24/2019 5:51 AM, Rafael J. Wysocki wrote: > > Is anyone taking this or should I? > > Nobody replied to this yet. I was hoping this series to go through acpi > tree like the rest of the other fixes. [post-vacation reply] That's not how these things are usually handled, but I taking into consideration the trivialises of the patch, I don't really mind. Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 4/5] phy: tegra: xusb: Add support for power supplies
Hi Thierry,
I think any non-zero return value of
regulator_bulk_enable()/devm_regulator_bulk_get() means error.
Thanks,
JC
On 1/25/19 7:25 PM, Thierry Reding wrote:
From: Thierry Reding
Support enabling various supplies needed to provide power to the PLLs
and logic used to drive the USB, PCI and SATA pads.
Signed-off-by: Thierry Reding
---
drivers/phy/tegra/xusb.c | 34 +-
drivers/phy/tegra/xusb.h | 5 +
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
index 57a2d08ef6da..e510629f4f1c 100644
--- a/drivers/phy/tegra/xusb.c
+++ b/drivers/phy/tegra/xusb.c
@@ -864,6 +864,7 @@ static int tegra_xusb_padctl_probe(struct platform_device
*pdev)
struct tegra_xusb_padctl *padctl;
const struct of_device_id *match;
struct resource *res;
+ unsigned int i;
int err;
/* for backwards compatibility with old device trees */
@@ -901,14 +902,38 @@ static int tegra_xusb_padctl_probe(struct platform_device
*pdev)
goto remove;
}
+ padctl->supplies = devm_kcalloc(>dev, padctl->soc->num_supplies,
+ sizeof(*padctl->supplies), GFP_KERNEL);
+ if (!padctl->supplies) {
+ err = -ENOMEM;
+ goto remove;
+ }
+
+ for (i = 0; i < padctl->soc->num_supplies; i++)
+ padctl->supplies[i].supply = padctl->soc->supply_names[i];
+
+ err = devm_regulator_bulk_get(>dev, padctl->soc->num_supplies,
+ padctl->supplies);
+ if (err < 0) {
+ dev_err(>dev, "failed to get regulators: %d\n", err);
+ goto remove;
+ }
+
err = reset_control_deassert(padctl->rst);
if (err < 0)
goto remove;
+ err = regulator_bulk_enable(padctl->soc->num_supplies,
+ padctl->supplies);
+ if (err < 0) {
+ dev_err(>dev, "failed to enable supplies: %d\n", err);
+ goto reset;
+ }
+
err = tegra_xusb_setup_pads(padctl);
if (err < 0) {
dev_err(>dev, "failed to setup pads: %d\n", err);
- goto reset;
+ goto power_down;
}
err = tegra_xusb_setup_ports(padctl);
@@ -921,6 +946,8 @@ static int tegra_xusb_padctl_probe(struct platform_device
*pdev)
remove_pads:
tegra_xusb_remove_pads(padctl);
+power_down:
+ regulator_bulk_disable(padctl->soc->num_supplies, padctl->supplies);
reset:
reset_control_assert(padctl->rst);
remove:
@@ -936,6 +963,11 @@ static int tegra_xusb_padctl_remove(struct platform_device
*pdev)
tegra_xusb_remove_ports(padctl);
tegra_xusb_remove_pads(padctl);
+ err = regulator_bulk_disable(padctl->soc->num_supplies,
+padctl->supplies);
+ if (err < 0)
+ dev_err(>dev, "failed to disable supplies: %d\n", err);
+
err = reset_control_assert(padctl->rst);
if (err < 0)
dev_err(>dev, "failed to assert reset: %d\n", err);
diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
index bb60fc09c752..5d5d22f6cb41 100644
--- a/drivers/phy/tegra/xusb.h
+++ b/drivers/phy/tegra/xusb.h
@@ -370,6 +370,9 @@ struct tegra_xusb_padctl_soc {
} ports;
const struct tegra_xusb_padctl_ops *ops;
+
+ const char * const *supply_names;
+ unsigned int num_supplies;
};
struct tegra_xusb_padctl {
@@ -393,6 +396,8 @@ struct tegra_xusb_padctl {
unsigned int enable;
struct clk *clk;
+
+ struct regulator_bulk_data *supplies;
};
static inline void padctl_writel(struct tegra_xusb_padctl *padctl, u32 value,
Re: [PATCH] sched/debug: Show intergroup and hierarchy sum wait time of a task group
Hi Michael > Task competition inside a cgroup won't be considered as cgroup's > competition, please try create another cgroup with dead loop on > each CPU Yes, you are right, but I don't think we just need to account for cgroup's competition, because this factor does not reflect cgroup internal conditions. We still need a proper method to evaluate CPU competition inside a cgroup. > Running tasks doesn't means no competition, only if that cgroup occupied > the CPU exclusively at that moment. I care much about CPU competiton inside a cgroup. I can only read '/proc/$pid/schedstat' thousands of times to get every task's wait_sum time without cgroup hierarchy wait_sum, and it definitely tasks a real long time(40ms for 8000 tasks in a container). > No offense but I'm afraid you misunderstand the problem we try to solve > by wait_sum, if your purpose is to have a way to tell whether there are > sufficient CPU inside a container, please try lxcfs + top, if there are > almost no idle and load is high, then the CPU resource is not sufficient. e... Maybe I didn't make it clear. We need to dynamically adjust the number of CPUs for a container based on the running state of tasks inside the container. If we find tasks' wait_sum are really high, we will add more CPU cores to this container, or else we will decline some CPU to this container. In a word, we want to ensure 'co-scheduling' for high priority containers. >Frankly speaking this sounds like a supplement rather than a missing piece, >although we don't rely on lxcfs and modify the kernel ourselves to support >container environment, I still don't think such kind of solutions should be >in kernel. I don't care if this value is considered as a supplement or a missing piece. I only care about how can I assess the running state inside a container. I think lxcfs is really a good solution to improve the visibility of container resources, but it is not good enough at the moment. /proc/cpuinfo /proc/diskstats /proc/meminfo /proc/stat /proc/swaps /proc/uptime we can read this procfs file inside a container,but this file still cannot reflect real-time information. Please think about the following scenario: a 'rabbit' process will generate 2000 tasks in every 30ms, and these children tasks just run 1~5ms and then exit. How can we detect this thrashing workload without hierarchy wait_sum? Thanks, Yuzhoujian
Re: [RFC PATCH v2 00/10] support ROHM BD70528 PMIC
On Fri, 25 Jan 2019, Matti Vaittinen wrote: > Patch series introducing support for ROHM BD70528 PMIC > > Please note that patch 1 breaks compilation without patches 2 and 3 > > ROHM BD70528 is a programmable Power Management IC for battery > powered 'ultra low power' systems like the pre-announced NXP > i.MX7 ULP. This patch series introduces support for the PMIC. It looks like you've sent this set un-threaded, which means as people reply to the patches, they are going to be spread out into the four winds (in Inbox terms). -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] arm64: dts: allwinner: a64-amarula-relic: Add STLM75 sensor
On Fri, Jan 25, 2019 at 2:10 PM Maxime Ripard wrote:
>
> On Thu, Jan 24, 2019 at 11:22:54PM +0530, Jagan Teki wrote:
> > Amarula A64 Relic has STLM75 sensor for digital temperature
> > and thermal watchdog.
> >
> > Add support for it.
> >
> > Signed-off-by: Jagan Teki
> > ---
> > Note: the respective driver change is already in mainline
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=2e9a41bbc1079776dabe42ed8113b086b99ae56c
> >
> > .../dts/allwinner/sun50i-a64-amarula-relic.dts| 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > index 6cb2b7f0c817..5d942543d978 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > @@ -34,6 +34,21 @@
> > status = "okay";
> > };
> >
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins>;
> > + status = "okay";
> > +
> > + temp@48 {
>
> That would be sensor@48
>
> > + compatible = "st,stlm75";
>
> That compatible isn't documented.
True, but none of the compatible strings used on the driver doesn't
documented in binding instead there are documented in
Documentation/hwmon/lm75.
Don't know the exact reason, do we need to document this in binding as well?
Re: [2/2] mfd: max77620: Add low battery monitor support
Re-sending due to dodgy looking 'reply-to'. On Sun, 27 Jan 2019, Billy Laws wrote: > >This patch adds PMIC configurations for low-battery > >monitoring by handling max77620 register CNFGGLBL1. > > > It might be an idea to add lbhyst configuration here and support using > custom lbdac values to specify a different cutoff point. Do you know why this email was sent independent of the original submission? Something wrong with your mailer? -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [2/2] mfd: max77620: Add low battery monitor support
On Sun, 27 Jan 2019, Billy Laws wrote: > >This patch adds PMIC configurations for low-battery > >monitoring by handling max77620 register CNFGGLBL1. > > > It might be an idea to add lbhyst configuration here and support using > custom lbdac values to specify a different cutoff point. Do you know why this email was sent independent of the original submission? Something wrong with your mailer? -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] irqchip/gic-v3-its: Lock its device list during find and create its device
Hi Marc,
Thanks for your review.
On 2019/1/26 19:38, Marc Zyngier wrote:
> Hi Zheng,
>
> On Sat, 26 Jan 2019 06:16:24 +,
> Zheng Xiang wrote:
>>
>> Currently each PCI device under a PCI Bridge shares the same device id
>> and ITS device. Assume there are two PCI devices call its_msi_prepare
>> concurrently and they are both going to find and create their ITS
>> device. There is a chance that the later one couldn't find ITS device
>> before the other one creating the ITS device. It will cause the later
>> one to create a different ITS device even if they have the same
>> device_id.
>
> Interesting finding. Is this something you've actually seen in practice
> with two devices being probed in parallel? Or something that you found
> by inspection?
Yes, I find this problem after analyzing the reason of VM hung. At last, I
find that the virtio-gpu cannot receive the MSI interrupts due to sharing
a same event_id as virtio-serial.
See https://lkml.org/lkml/2019/1/10/299 for the bug report.
This problem can be reproducted with high probability by booting a Qemu/KVM
VM with a virtio-serial controller and a virtio-gpu adding to a PCI Bridge
and also adding some delay before creating ITS device.
>
> The whole RID aliasing is such a mess, I wish we never supported
> it. Anyway, comments below.
>
>>
>> Signed-off-by: Zheng Xiang
>> ---
>> drivers/irqchip/irq-gic-v3-its.c | 52
>> +++-
>> 1 file changed, 19 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c
>> b/drivers/irqchip/irq-gic-v3-its.c
>> index db20e99..397edc8 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -2205,25 +2205,6 @@ static void its_cpu_init_collections(void)
>> raw_spin_unlock(_lock);
>> }
>>
>> -static struct its_device *its_find_device(struct its_node *its, u32 dev_id)
>> -{
>> -struct its_device *its_dev = NULL, *tmp;
>> -unsigned long flags;
>> -
>> -raw_spin_lock_irqsave(>lock, flags);
>> -
>> -list_for_each_entry(tmp, >its_device_list, entry) {
>> -if (tmp->device_id == dev_id) {
>> -its_dev = tmp;
>> -break;
>> -}
>> -}
>> -
>> -raw_spin_unlock_irqrestore(>lock, flags);
>> -
>> -return its_dev;
>> -}
>> -
>> static struct its_baser *its_get_baser(struct its_node *its, u32 type)
>> {
>> int i;
>> @@ -2321,7 +2302,7 @@ static bool its_alloc_vpe_table(u32 vpe_id)
>> static struct its_device *its_create_device(struct its_node *its, u32
>> dev_id,
>> int nvecs, bool alloc_lpis)
>> {
>> -struct its_device *dev;
>> +struct its_device *dev = NULL, *tmp;
>> unsigned long *lpi_map = NULL;
>> unsigned long flags;
>> u16 *col_map = NULL;
>> @@ -2331,6 +2312,24 @@ static struct its_device *its_create_device(struct
>> its_node *its, u32 dev_id,
>> int nr_ites;
>> int sz;
>>
>> +raw_spin_lock_irqsave(>lock, flags);
>> +list_for_each_entry(tmp, >its_device_list, entry) {
>> +if (tmp->device_id == dev_id) {
>> +dev = tmp;
>> +break;
>> +}
>> +}
>> +if (dev) {
>> +/*
>> + * We already have seen this ID, probably through
>> + * another alias (PCI bridge of some sort). No need to
>> + * create the device.
>> + */
>> +pr_debug("Reusing ITT for devID %x\n", dev_id);
>> +raw_spin_unlock_irqrestore(>lock, flags);
>> +return dev;
>> +}
>> +
>> if (!its_alloc_device_table(its, dev_id))
>
> You're now performing all sort of allocations in an atomic context,
> which is pretty horrible (and the kernel will shout at you for doing
> so).
>
> We could probably keep the current logic and wrap it around a mutex
> instead, which would give us the appropriate guarantees WRT allocations.
> Something along those lines (untested):>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index db20e992a40f..99feb62e63ba 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -97,9 +97,14 @@ struct its_device;
> * The ITS structure - contains most of the infrastructure, with the
> * top-level MSI domain, the command queue, the collections, and the
> * list of devices writing to it.
> + *
> + * alloc_lock has to be taken for any allocation that can happen at
> + * run time, while the spinlock must be taken to parse data structures
> + * such as the device list.
> */
> struct its_node {
> raw_spinlock_t lock;
> + struct mutexalloc_lock;
> struct list_headentry;
> void __iomem*base;
> phys_addr_t phys_base;
> @@ -2421,6 +2426,7 @@ static int its_msi_prepare(struct irq_domain *domain,
> struct device *dev,
> struct
Re: [PATCH v5 0/4] Reduce NUMA related overhead in perf record profiling on large server systems
Hi Jiri, Arnaldo, On 22.01.2019 20:45, Alexey Budankov wrote: > > It has been observed that trace reading thread runs on the same hw thread > most of the time during perf record sampling collection. This scheduling > layout leads up to 30% profiling overhead in case when some cpu intensive > workload fully utilizes a large server system with NUMA. Overhead usually > arises from remote (cross node) HW and memory references that have much > longer latencies than local ones [1]. > > This patch set implements --affinity option that lowers 30% overhead > completely for serial trace streaming (--affinity=cpu) and from 30% to > 10% for AIO1 (--aio=1) trace streaming (--affinity=node|cpu). > See OVERHEAD section below for more details. > > Implemented extension provides users with capability to instruct Perf > tool to bounce trace reading thread's affinity mask between NUMA nodes > (--affinity=node) or assign the thread to the exact cpu (--affinity=cpu) > that trace buffer being processed belongs to. > > The extension brings improvement in case of full system utilization when > Perf tool process contends with workload process on cpu cores. In case a > system has free cores to execute Perf tool process during profiling the > default system scheduling layout induces the lowest overhead. > > The patch set has been validated on BT benchmark from NAS Parallel > Benchmarks [2] running on dual socket, 44 cores, 88 hw threads Broadwell > system with kernels v4.4-21-generic (Ubuntu 16.04) and v4.20.0-rc5 > (tip perf/core). > > The patch set is for Arnaldo's perf/core repository. > > OVERHEAD: > BENCH REPORT BASED ELAPSED TIME BASED > v4.20.0-rc5 > (tip perf/core): > > (current) SERIAL-SYS / BASE : 1.27x (14.37/11.31), 1.29x (15.19/11.69) > SERIAL-NODE / BASE : 1.15x (13.04/11.31), 1.17x (13.79/11.69) > SERIAL-CPU / BASE : 1.00x (11.32/11.31), 1.01x (11.89/11.69) > > AIO1-SYS/ BASE : 1.29x (14.58/11.31), 1.29x (15.26/11.69) > AIO1-NODE / BASE : 1.08x (12.23/11.31), 1,11x (13.01/11.69) > AIO1-CPU/ BASE : 1.07x (12.14/11.31), 1.08x (12.83/11.69) > > v4.4.0-21-generic > (Ubuntu 16.04 LTS): > > (current) SERIAL-SYS / BASE : 1.26x (13.73/10.87), 1.29x (14.69/11.32) > SERIAL-NODE / BASE : 1.19x (13.02/10.87), 1.23x (14.03/11.32) > SERIAL-CPU / BASE : 1.03x (11.21/10.87), 1.07x (12.18/11.32) > > AIO1-SYS/ BASE : 1.26x (13.73/10.87), 1.29x (14.69/11.32) > AIO1-NODE / BASE : 1.10x (12.04/10.87), 1.15x (13.03/11.32) > AIO1-CPU/ BASE : 1.12x (12.20/10.87), 1.15x (13.09/11.32) > > --- > Alexey Budankov (4): > perf record: allocate affinity masks > perf record: bind the AIO user space buffers to nodes > perf record: apply affinity masks when reading mmap buffers > perf record: implement --affinity=node|cpu option > > tools/perf/Documentation/perf-record.txt | 5 ++ > tools/perf/builtin-record.c | 45 +- > tools/perf/perf.h| 8 ++ > tools/perf/util/cpumap.c | 10 +++ > tools/perf/util/cpumap.h | 1 + > tools/perf/util/evlist.c | 6 +- > tools/perf/util/evlist.h | 2 +- > tools/perf/util/mmap.c | 105 ++- > tools/perf/util/mmap.h | 3 +- > 9 files changed, 175 insertions(+), 10 deletions(-) > > --- > Changes in v5: > - avoided multiple allocations of online cpu maps by > implementing it once in cpu_map__online() > - reduced indentation at record__parse_affinity() Are there any more comments on this patch set? Thanks, Alexey > > Changes in v4: > - fixed compilation issue converting pr_warn() to pr_warning() > - implemented stop if mbind() fails > - corrected mmap_params->cpu_map initialization to be based on > /sys/devices/system/cpu/online > - separated node cpu map generation into build_node_mask() > > Changes in v3: > - converted PERF_AFFINITY_EOF to PERF_AFFINITY_MAX > - corrected code style issues > - adjusted __aio_alloc,__aio_bind,__aio_free() implementation > - separated mask manipulations into __adjust_affinity() and > __setup_affinity_mask() > - implemented mapping of c index into online cpu index > - adjusted indentation at record__parse_affinity() > > Changes in v2: > - made debug affinity mode message user friendly > - converted affinity mode defines to enum values > - implemented perf_mmap__aio_alloc, perf_mmap__aio_free, perf_mmap__aio_bind > and put HAVE_LIBNUMA_SUPPORT #ifdefs in there > - separated AIO buffers binding to patch 2/4 > > --- > [1] https://en.wikipedia.org/wiki/Non-uniform_memory_access > [2] https://www.nas.nasa.gov/publications/npb.html > [3] http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html > [4] http://man7.org/linux/man-pages/man2/mbind.2.html > > --- >
[PATCH v2 4/4] perf report: support record trace file decompression
PERF_RECORD_COMPRESSED records are decompressed from trace file into
a linked list of mmaped memory regions using streaming Zstandard API.
After that the regions are loaded fetching uncompressed events. When
dumping raw trace (e.g., perf report -D --header) file offsets of
events from compressed records are set to zero.
Signed-off-by: Alexey Budankov
---
Changes in v2:
- moved compression/decompression code to session layer
---
tools/perf/builtin-report.c | 5 +-
tools/perf/util/session.c | 165 +++-
tools/perf/util/session.h | 11 +++
tools/perf/util/tool.h | 2 +
4 files changed, 181 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index c9ceaf88759c..c8b5686d1f6a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -1197,6 +1197,9 @@ int cmd_report(int argc, const char **argv)
if (session == NULL)
return -1;
+ if (perf_session__zstd_init(session, 0) < 0)
+ pr_warning("Decompression initialization failed. Reported data
may be incomplete.\n");
+
if (report.queue_size) {
ordered_events__set_alloc_size(>ordered_events,
report.queue_size);
@@ -1409,7 +1412,7 @@ int cmd_report(int argc, const char **argv)
error:
zfree(_range);
-
+ perf_session__zstd_fini(session);
perf_session__delete(session);
return ret;
}
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index b2bace785d9a..e35a5cc4d9a5 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -32,6 +32,21 @@ int perf_session__zstd_init(struct perf_session *session,
int level)
{
size_t ret;
+ session->zstd_dstream = ZSTD_createDStream();
+ if (session->zstd_dstream == NULL) {
+ pr_err("Couldn't create decompression stream.\n");
+ return -1;
+ }
+
+ ret = ZSTD_initDStream(session->zstd_dstream);
+ if (ZSTD_isError(ret)) {
+ pr_err("Failed to initialize decompression stream: %s\n",
ZSTD_getErrorName(ret));
+ return -1;
+ }
+
+ if (level == 0)
+ return 0;
+
session->header.env.comp_type = PERF_COMP_NONE;
session->header.env.comp_level = 0;
@@ -55,6 +70,22 @@ int perf_session__zstd_init(struct perf_session *session,
int level)
int perf_session__zstd_fini(struct perf_session *session)
{
+ struct decomp *next = session->decomp, *decomp;
+ size_t decomp_len = session->header.env.comp_mmap_len;
+
+ if (session->zstd_dstream) {
+ ZSTD_freeDStream(session->zstd_dstream);
+ session->zstd_dstream = NULL;
+ }
+
+ do {
+ decomp = next;
+ if (decomp == NULL)
+ break;
+ next = decomp->next;
+ munmap(decomp, decomp_len + sizeof(struct decomp));
+ } while (1);
+
if (session->zstd_cstream) {
ZSTD_freeCStream(session->zstd_cstream);
session->zstd_cstream = NULL;
@@ -106,6 +137,80 @@ size_t perf_session__zstd_compress(void *to, void *dst,
size_t dst_size,
return compressed;
}
+
+static size_t perf_session__zstd_decompress(struct perf_session *session,
+ void *src, size_t src_size,
+ void *dst, size_t dst_size)
+{
+ size_t ret;
+ ZSTD_inBuffer input = { src, src_size, 0 };
+ ZSTD_outBuffer output = { dst, dst_size, 0 };
+
+ while (input.pos < input.size) {
+ ret = ZSTD_decompressStream(session->zstd_dstream, ,
);
+ if (ZSTD_isError(ret)) {
+ pr_err("failed to decompress (B): %ld -> %ld : %s\n",
+ src_size, output.size, ZSTD_getErrorName(ret));
+ break;
+ }
+ output.dst = dst + output.pos;
+ output.size = dst_size - output.pos;
+ }
+
+ return output.pos;
+}
+
+static int perf_session__process_compressed_event(struct perf_session *session,
+ union perf_event *event, u64
file_offset)
+{
+ void *src;
+ size_t decomp_size, src_size;
+ u64 decomp_last_rem = 0;
+ size_t decomp_len = session->header.env.comp_mmap_len;
+ struct decomp *decomp, *decomp_last = session->decomp_last;
+
+ decomp = mmap(NULL, sizeof(struct decomp) + decomp_len,
PROT_READ|PROT_WRITE,
+ MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
+ if (decomp == MAP_FAILED) {
+ pr_err("Couldn't allocate memory for decompression\n");
+ return -1;
+ }
+
+ decomp->file_pos = file_offset;
+ decomp->head = 0;
+
+ if (decomp_last) {
+ decomp_last_rem = decomp_last->size -
Re: [PATCH] extcon: Fix build issues in ptn5150
On Mon, Jan 28, 2019 at 10:08:12AM +0530, Vijai Kumar K wrote: I was wondering, what is the normal procedure in the below case when the build fails because of the driver. Should I send a new patch as a whole [PATCH v3] for the driver or should I send a new patch to fix the issue like below. Thanks, Vijai Kumar K > - extcon-ptn5150 driver uses gpio libraries > - Add GPIOLIB in depends section of Kconfig > > Error: > - > > CC drivers/extcon/extcon-ptn5150.o > > ../drivers/extcon/extcon-ptn5150.c: In function ‘ptn5150_irq_work’: > > ../drivers/extcon/extcon-ptn5150.c:130:5: error: implicit declaration of > > function ‘gpiod_set_value’ [-Werror=implicit-function-declaration] > > gpiod_set_value(info->vbus_gpiod, 0); > > ^ > > ../drivers/extcon/extcon-ptn5150.c: In function ‘ptn5150_i2c_probe’: > > ../drivers/extcon/extcon-ptn5150.c:242:2: error: implicit declaration of > > function ‘devm_gpiod_get’ [-Werror=implicit-function-declaration] > > info->int_gpiod = devm_gpiod_get(>dev, "int", GPIOD_IN); > > ^ > > ../drivers/extcon/extcon-ptn5150.c:242:53: error: ‘GPIOD_IN’ undeclared > > (first use in this function) > > info->int_gpiod = devm_gpiod_get(>dev, "int", GPIOD_IN); > > ^ > > ../drivers/extcon/extcon-ptn5150.c:242:53: note: each undeclared identifier > > is reported only once for each function it appears in > > ../drivers/extcon/extcon-ptn5150.c:252:2: error: implicit declaration of > > function ‘gpiod_direction_output’ [-Werror=implicit-function-declaration] > > ret = gpiod_direction_output(info->vbus_gpiod, 0); > > ^ > > ../drivers/extcon/extcon-ptn5150.c:271:3: error: implicit declaration of > > function ‘gpiod_to_irq’ [-Werror=implicit-function-declaration] > >info->irq = gpiod_to_irq(info->int_gpiod); > - > > Signed-off-by: Vijai Kumar K > --- > drivers/extcon/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig > index b9cc027..330dd8b 100644 > --- a/drivers/extcon/Kconfig > +++ b/drivers/extcon/Kconfig > @@ -116,7 +116,7 @@ config EXTCON_PALMAS > > config EXTCON_PTN5150 > tristate "NXP PTN5150 CC LOGIC USB EXTCON support" > - depends on I2C > + depends on I2C && GPIOLIB > select REGMAP_I2C > help > Say Y here to enable support for USB peripheral and USB host > -- > 2.7.4 >
[PATCH v2 3/4] perf record: enable runtime trace compression
Compression is implemented using simple Zstd API and employs AIO data
buffer as the memory to operate on. If the API call fails for some
reason compression falls back to memcpy().
Data chunks are split and packed into PERF_RECORD_COMPRESSED records
by 64KB at max. mmap-flush option value can be used to avoid compression
of every single byte of data and increase compression ratio.
Signed-off-by: Alexey Budankov
---
Changes in v2:
- enabled trace compression for serial trace streaming
- moved compression/decompression code to session layer
---
tools/perf/builtin-record.c | 67 +++
tools/perf/util/mmap.c | 69 ---
tools/perf/util/mmap.h | 24 +---
tools/perf/util/session.c | 106
tools/perf/util/session.h | 13 +
5 files changed, 228 insertions(+), 51 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 2618d809675d..75dca9e5def4 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -107,8 +107,7 @@ static bool switch_output_time(struct record *rec)
trigger_is_ready(_output_trigger);
}
-static int record__write(struct record *rec, struct perf_mmap *map
__maybe_unused,
-void *bf, size_t size)
+static int record__write(struct record *rec, void *bf, size_t size)
{
struct perf_data_file *file = >session->data->file;
@@ -232,7 +231,7 @@ static int record__aio_sync(struct perf_mmap *md, bool
sync_all)
} while (1);
}
-static int record__aio_pushfn(void *to, struct aiocb *cblock, void *bf, size_t
size, off_t off)
+static int record__aio_pushfn(void *to, void *bf, size_t size, off_t off,
struct aiocb *cblock)
{
struct record *rec = to;
int ret, trace_fd = rec->session->data->file.fd;
@@ -259,13 +258,15 @@ static void record__aio_set_pos(int trace_fd, off_t pos)
lseek(trace_fd, pos, SEEK_SET);
}
+static int record__aio_enabled(struct record *rec);
+
static void record__aio_mmap_read_sync(struct record *rec)
{
int i;
struct perf_evlist *evlist = rec->evlist;
struct perf_mmap *maps = evlist->mmap;
- if (!rec->opts.nr_cblocks)
+ if (!record__aio_enabled(rec))
return;
for (i = 0; i < evlist->nr_mmaps; i++) {
@@ -306,8 +307,8 @@ static int record__aio_sync(struct perf_mmap *md
__maybe_unused, bool sync_all _
return -1;
}
-static int record__aio_pushfn(void *to __maybe_unused, struct aiocb *cblock
__maybe_unused,
- void *bf __maybe_unused, size_t size __maybe_unused, off_t off
__maybe_unused)
+static int record__aio_pushfn(void *to __maybe_unused, void *bf __maybe_unused,
+ size_t size __maybe_unused, off_t off __maybe_unused, struct aiocb
*cblock __maybe_unused)
{
return -1;
}
@@ -366,15 +367,15 @@ static int process_synthesized_event(struct perf_tool
*tool,
struct machine *machine __maybe_unused)
{
struct record *rec = container_of(tool, struct record, tool);
- return record__write(rec, NULL, event, event->header.size);
+ return record__write(rec, event, event->header.size);
}
-static int record__pushfn(struct perf_mmap *map, void *to, void *bf, size_t
size)
+static int record__pushfn(void *to, void *bf, size_t size)
{
struct record *rec = to;
rec->samples++;
- return record__write(rec, map, bf, size);
+ return record__write(rec, bf, size);
}
static volatile int done;
@@ -409,7 +410,7 @@ static void record__sig_exit(void)
#ifdef HAVE_AUXTRACE_SUPPORT
static int record__process_auxtrace(struct perf_tool *tool,
- struct perf_mmap *map,
+ struct perf_mmap *map __maybe_unused,
union perf_event *event, void *data1,
size_t len1, void *data2, size_t len2)
{
@@ -437,11 +438,11 @@ static int record__process_auxtrace(struct perf_tool
*tool,
if (padding)
padding = 8 - padding;
- record__write(rec, map, event, event->header.size);
- record__write(rec, map, data1, len1);
+ record__write(rec, event, event->header.size);
+ record__write(rec, data1, len1);
if (len2)
- record__write(rec, map, data2, len2);
- record__write(rec, map, , padding);
+ record__write(rec, data2, len2);
+ record__write(rec, , padding);
return 0;
}
@@ -764,6 +765,8 @@ static int record__mmap_read_evlist(struct record *rec,
struct perf_evlist *evli
struct perf_mmap *maps;
int trace_fd = rec->data.file.fd;
off_t off;
+ struct perf_session *session = rec->session;
+ perf_mmap__compress_fn_t compress_fn;
if (!evlist)
return 0;
@@ -775,6 +778,9 @@ static int record__mmap_read_evlist(struct
[PATCH v2 2/4] perf record: implement -z= and --mmap-flush= options
Implement -z,--compression_level= and --mmap-flush=
options as well as a special PERF_RECORD_COMPRESSED record that contains
compressed parts of kernel data buffer.
Because compression requires auxiliary memory to implement encoding of
kernel data record->opts.nr_cblocks == -1 signifies to allocate single
AIO data buffer aio.data[0] without accompanying AIO control blocks.
Signed-off-by: Alexey Budankov
---
Changes in v2:
- enabled allocation aio data buffers for compression
---
tools/perf/Documentation/perf-record.txt | 9 ++
tools/perf/builtin-record.c | 110 ++
tools/perf/perf.h| 2 +
tools/perf/util/env.h| 10 ++
tools/perf/util/event.c | 1 +
tools/perf/util/event.h | 7 ++
tools/perf/util/evlist.c | 6 +-
tools/perf/util/evlist.h | 2 +-
tools/perf/util/header.c | 45 -
tools/perf/util/header.h | 1 +
tools/perf/util/mmap.c | 112 ++-
tools/perf/util/mmap.h | 7 +-
tools/perf/util/session.h| 2 +
13 files changed, 246 insertions(+), 68 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index d232b13ea713..3ecd94ce8d7f 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -440,6 +440,15 @@ Use control blocks in asynchronous (Posix AIO) trace
writing mode (default:
Asynchronous mode is supported only when linking Perf tool with libc library
providing implementation for Posix AIO API.
+-z::
+--compression-level=n::
+Produce compressed trace file using specified level n to save storage space
(no compression: 0 - default,
+fastest compression: 1, smallest trace file: 22)
+
+--mmap-flush=n::
+Minimal number of bytes accumulated in kernel buffer that is flushed to trace
file (default: 1).
+Maximal allowed value is a quater of kernel buffer size.
+
--all-kernel::
Configure all used events to run in kernel space.
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 88ea11d57c6f..2618d809675d 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -287,18 +287,20 @@ static int record__aio_parse(const struct option *opt,
if (unset) {
opts->nr_cblocks = 0;
- } else {
- if (str)
- opts->nr_cblocks = strtol(str, NULL, 0);
- if (!opts->nr_cblocks)
- opts->nr_cblocks = nr_cblocks_default;
+ return 0;
}
+ if (str)
+ opts->nr_cblocks = strtol(str, NULL, 0);
+ if (!opts->nr_cblocks)
+ opts->nr_cblocks = nr_cblocks_default;
+
+ if (opts->nr_cblocks > nr_cblocks_max)
+ opts->nr_cblocks = nr_cblocks_max;
+
return 0;
}
#else /* HAVE_AIO_SUPPORT */
-static int nr_cblocks_max = 0;
-
static int record__aio_sync(struct perf_mmap *md __maybe_unused, bool sync_all
__maybe_unused)
{
return -1;
@@ -329,6 +331,35 @@ static int record__aio_enabled(struct record *rec)
return rec->opts.nr_cblocks > 0;
}
+#define MMAP_FLUSH_DEFAULT 1
+
+static int record__comp_enabled(struct record *rec)
+{
+ return rec->opts.comp_level > 0;
+}
+
+static int record__mmap_flush_parse(const struct option *opt,
+ const char *str,
+ int unset)
+{
+ int mmap_len;
+ struct record_opts *opts = (struct record_opts *)opt->value;
+
+ if (unset)
+ return 0;
+
+ if (str)
+ opts->mmap_flush = strtol(str, NULL, 0);
+ if (!opts->mmap_flush)
+ opts->mmap_flush = MMAP_FLUSH_DEFAULT;
+
+ mmap_len = perf_evlist__mmap_size(opts->mmap_pages);
+ if (opts->mmap_flush > mmap_len / 4)
+ opts->mmap_flush = mmap_len / 4;
+
+ return 0;
+}
+
static int process_synthesized_event(struct perf_tool *tool,
union perf_event *event,
struct perf_sample *sample __maybe_unused,
@@ -534,7 +565,8 @@ static int record__mmap_evlist(struct record *rec,
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
opts->auxtrace_mmap_pages,
-opts->auxtrace_snapshot_mode,
opts->nr_cblocks) < 0) {
+opts->auxtrace_snapshot_mode,
+opts->nr_cblocks, opts->mmap_flush) < 0) {
if (errno == EPERM) {
pr_err("Permission error mapping pages.\n"
"Consider increasing "
@@ -724,7 +756,7 @@ static struct perf_event_header finished_round_event = {
};
static int record__mmap_read_evlist(struct record *rec,
Re: [PATCH 3/5] phy: tegra: xusb: Parse dual-role mode property
Reviewed-by: JC Kuo
On 1/25/19 7:25 PM, Thierry Reding wrote:
From: Thierry Reding
The device tree bindings document the "mode" property of "ports"
subnodes, but the driver was not parsing the property. In preparation
for adding role switching, parse the property at probe time.
Based on work by JC Kuo .
Signed-off-by: Thierry Reding
---
drivers/phy/tegra/xusb.c | 21 +
drivers/phy/tegra/xusb.h | 3 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
index e3bc60cfe6a1..57a2d08ef6da 100644
--- a/drivers/phy/tegra/xusb.c
+++ b/drivers/phy/tegra/xusb.c
@@ -546,13 +546,34 @@ static void tegra_xusb_port_unregister(struct
tegra_xusb_port *port)
device_unregister(>dev);
}
+static const char *const modes[] = {
+ [USB_DR_MODE_UNKNOWN] = "",
+ [USB_DR_MODE_HOST] = "host",
+ [USB_DR_MODE_PERIPHERAL] = "peripheral",
+ [USB_DR_MODE_OTG] = "otg",
+};
+
static int tegra_xusb_usb2_port_parse_dt(struct tegra_xusb_usb2_port *usb2)
{
struct tegra_xusb_port *port = >base;
struct device_node *np = port->dev.of_node;
+ const char *mode;
usb2->internal = of_property_read_bool(np, "nvidia,internal");
+ if (!of_property_read_string(np, "mode", )) {
+ int err = match_string(modes, ARRAY_SIZE(modes), mode);
+ if (err < 0) {
+ dev_err(>dev, "invalid value %s for \"mode\"\n",
+ mode);
+ usb2->mode = USB_DR_MODE_UNKNOWN;
+ } else {
+ usb2->mode = err;
+ }
+ } else {
+ usb2->mode = USB_DR_MODE_HOST;
+ }
+
usb2->supply = devm_regulator_get(>dev, "vbus");
return PTR_ERR_OR_ZERO(usb2->supply);
}
diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
index b49dbc36efa3..bb60fc09c752 100644
--- a/drivers/phy/tegra/xusb.h
+++ b/drivers/phy/tegra/xusb.h
@@ -19,6 +19,8 @@
#include
#include
+#include
+
/* legacy entry points for backwards-compatibility */
int tegra_xusb_padctl_legacy_probe(struct platform_device *pdev);
int tegra_xusb_padctl_legacy_remove(struct platform_device *pdev);
@@ -271,6 +273,7 @@ struct tegra_xusb_usb2_port {
struct tegra_xusb_port base;
struct regulator *supply;
+ enum usb_dr_mode mode;
bool internal;
};
Re: [PATCH 2/5] phy: tegra: xusb: Skip single function lane programming
Reviewed-by: JC Kuo On 1/25/19 7:25 PM, Thierry Reding wrote: From: JC Kuo Tegra186 USB2 pads and USB3 pads do not have hardware mux for changing the pad function. For such "lanes", we can skip the lane mux register programming. Signed-off-by: JC Kuo Signed-off-by: Thierry Reding --- drivers/phy/tegra/xusb.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c index 5b3b8863363e..e3bc60cfe6a1 100644 --- a/drivers/phy/tegra/xusb.c +++ b/drivers/phy/tegra/xusb.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014-2015, NVIDIA CORPORATION. All rights reserved. + * Copyright (c) 2014-2016, NVIDIA CORPORATION. All rights reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License, @@ -313,6 +313,10 @@ static void tegra_xusb_lane_program(struct tegra_xusb_lane *lane) const struct tegra_xusb_lane_soc *soc = lane->soc; u32 value; + /* skip single function lanes */ + if (soc->num_funcs < 2) + return; + /* choose function */ value = padctl_readl(padctl, soc->offset); value &= ~(soc->mask << soc->shift);
[PATCH v2 1/4] feature: realize libzstd check, LIBZSTD_DIR and NO_LIBZSTD defines
Implement libzstd feature check, NO_LIBZSTD and LIBZSTD_DIR defines
to overrride Zstd library sources or disable the feature from the
command line:
$ make -C tools/perf LIBZSTD_DIR=/root/abudanko/zstd-1.3.7 clean all
$ make -C tools/perf NO_LIBZSTD=1 clean all
Signed-off-by: Alexey Budankov
---
tools/build/Makefile.feature | 6 --
tools/build/feature/Makefile | 6 +-
tools/build/feature/test-all.c | 5 +
tools/build/feature/test-libzstd.c | 12
tools/perf/Makefile.config | 20
tools/perf/Makefile.perf | 3 +++
6 files changed, 49 insertions(+), 3 deletions(-)
create mode 100644 tools/build/feature/test-libzstd.c
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 5467c6bf9ceb..25088c8f05b2 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -71,7 +71,8 @@ FEATURE_TESTS_BASIC := \
sdt\
setns \
libopencsd \
-libaio
+libaio \
+libzstd
# FEATURE_TESTS_BASIC + FEATURE_TESTS_EXTRA is the complete list
# of all feature tests
@@ -118,7 +119,8 @@ FEATURE_DISPLAY ?= \
lzma \
get_cpuid \
bpf \
- libaio
+ libaio\
+ libzstd
# Set FEATURE_CHECK_(C|LD)FLAGS-all for all FEATURE_TESTS features.
# If in the future we need per-feature checks/flags for features not
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 7ceb4441b627..4b8244ee65ce 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -62,7 +62,8 @@ FILES= \
test-clang.bin\
test-llvm.bin \
test-llvm-version.bin \
- test-libaio.bin
+ test-libaio.bin \
+ test-libzstd.bin
FILES := $(addprefix $(OUTPUT),$(FILES))
@@ -301,6 +302,9 @@ $(OUTPUT)test-clang.bin:
$(OUTPUT)test-libaio.bin:
$(BUILD) -lrt
+$(OUTPUT)test-libzstd.bin:
+ $(BUILD) -lzstd
+
###
clean:
diff --git a/tools/build/feature/test-all.c b/tools/build/feature/test-all.c
index 20cdaa4fc112..5af329b6ffef 100644
--- a/tools/build/feature/test-all.c
+++ b/tools/build/feature/test-all.c
@@ -178,6 +178,10 @@
# include "test-libaio.c"
#undef main
+#define main main_test_zstd
+# include "test-libzstd.c"
+#undef main
+
int main(int argc, char *argv[])
{
main_test_libpython();
@@ -219,6 +223,7 @@ int main(int argc, char *argv[])
main_test_setns();
main_test_libopencsd();
main_test_libaio();
+ main_test_libzstd();
return 0;
}
diff --git a/tools/build/feature/test-libzstd.c
b/tools/build/feature/test-libzstd.c
new file mode 100644
index ..55268c01b84d
--- /dev/null
+++ b/tools/build/feature/test-libzstd.c
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+
+int main(void)
+{
+ ZSTD_CStream*cstream;
+
+ cstream = ZSTD_createCStream();
+ ZSTD_freeCStream(cstream);
+
+ return 0;
+}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index b441c88cafa1..1dccd776a4aa 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -145,6 +145,13 @@ endif
FEATURE_CHECK_CFLAGS-libbabeltrace := $(LIBBABELTRACE_CFLAGS)
FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS)
-lbabeltrace-ctf
+ifdef LIBZSTD_DIR
+ LIBZSTD_CFLAGS := -I$(LIBZSTD_DIR)/lib
+ LIBZSTD_LDFLAGS := -L$(LIBZSTD_DIR)/lib
+endif
+FEATURE_CHECK_CFLAGS-libzstd := $(LIBZSTD_CFLAGS)
+FEATURE_CHECK_LDFLAGS-libzstd := $(LIBZSTD_LDFLAGS)
+
FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include
-I$(srctree)/tools/arch/$(SRCARCH)/include/uapi -I$(srctree)/tools/include/uapi
# include ARCH specific config
-include $(src-perf)/arch/$(SRCARCH)/Makefile
@@ -770,6 +777,19 @@ ifndef NO_LZMA
endif
endif
+ifndef NO_LIBZSTD
+ ifeq ($(feature-libzstd), 1)
+CFLAGS += -DHAVE_ZSTD_SUPPORT
+CFLAGS += $(LIBZSTD_CFLAGS)
+LDFLAGS += $(LIBZSTD_LDFLAGS)
+EXTLIBS += -lzstd
+$(call detected,CONFIG_ZSTD)
+ else
+msg := $(warning No libzstd found, disables trace compression, please
install libzstd-dev[el] and/or set LIBZSTD_DIR);
+NO_LIBZSTD := 1
+ endif
+endif
+
ifndef NO_BACKTRACE
ifeq ($(feature-backtrace), 1)
CFLAGS += -DHAVE_BACKTRACE_SUPPORT
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 09df1c8a4ec9..6e95e90a7b7b 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -108,6 +108,9 @@ include ../scripts/utilities.mak
# streaming for record mode. Currently Posix AIO trace streaming is
#
[PATCH net] vhost: fix OOB in get_rx_bufs()
After batched used ring updating was introduced in commit e2b3b35eb989
("vhost_net: batch used ring update in rx"). We tend to batch heads in
vq->heads for more than one packet. But the quota passed to
get_rx_bufs() was not correctly limited, which can result a OOB write
in vq->heads.
headcount = get_rx_bufs(vq, vq->heads + nvq->done_idx,
vhost_len, , vq_log, ,
likely(mergeable) ? UIO_MAXIOV : 1);
UIO_MAXIOV was still used which is wrong since we could have batched
used in vq->heads, this will cause OOB if the next buffer needs more
than 960 (1024 (UIO_MAXIOV) - 64 (VHOST_NET_BATCH)) heads after we've
batched 64 (VHOST_NET_BATCH) heads:
=
BUG kmalloc-8k (Tainted: GB): Redzone overwritten
-
INFO: 0xfd93b7a2-0xf0713384. First byte 0xa9 instead of 0xcc
INFO: Allocated in alloc_pd+0x22/0x60 age=3933677 cpu=2 pid=2674
kmem_cache_alloc_trace+0xbb/0x140
alloc_pd+0x22/0x60
gen8_ppgtt_create+0x11d/0x5f0
i915_ppgtt_create+0x16/0x80
i915_gem_create_context+0x248/0x390
i915_gem_context_create_ioctl+0x4b/0xe0
drm_ioctl_kernel+0xa5/0xf0
drm_ioctl+0x2ed/0x3a0
do_vfs_ioctl+0x9f/0x620
ksys_ioctl+0x6b/0x80
__x64_sys_ioctl+0x11/0x20
do_syscall_64+0x43/0xf0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
INFO: Slab 0xd13e87af objects=3 used=3 fp=0x (null)
flags=0x2010201
INFO: Object 0x03278802 @offset=17064 fp=0xe2e6652b
Fixing this by allocating UIO_MAXIOV + VHOST_NET_BATCH iovs for
vhost-net. This is done through set the limitation through
vhost_dev_init(), then set_owner can allocate the number of iov in a
per device manner.
This fixes CVE-2018-16880.
Fixes: e2b3b35eb989 ("vhost_net: batch used ring update in rx")
Signed-off-by: Jason Wang
---
drivers/vhost/net.c | 3 ++-
drivers/vhost/scsi.c | 2 +-
drivers/vhost/vhost.c | 7 ---
drivers/vhost/vhost.h | 4 +++-
drivers/vhost/vsock.c | 2 +-
5 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index bca86bf7189f..df51a35cf537 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1337,7 +1337,8 @@ static int vhost_net_open(struct inode *inode, struct
file *f)
n->vqs[i].rx_ring = NULL;
vhost_net_buf_init(>vqs[i].rxq);
}
- vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX);
+ vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX,
+ UIO_MAXIOV + VHOST_NET_BATCH);
vhost_poll_init(n->poll + VHOST_NET_VQ_TX, handle_tx_net, EPOLLOUT,
dev);
vhost_poll_init(n->poll + VHOST_NET_VQ_RX, handle_rx_net, EPOLLIN, dev);
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 344684f3e2e4..23593cb23dd0 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1627,7 +1627,7 @@ static int vhost_scsi_open(struct inode *inode, struct
file *f)
vqs[i] = >vqs[i].vq;
vs->vqs[i].vq.handle_kick = vhost_scsi_handle_kick;
}
- vhost_dev_init(>dev, vqs, VHOST_SCSI_MAX_VQ);
+ vhost_dev_init(>dev, vqs, VHOST_SCSI_MAX_VQ, UIO_MAXIOV);
vhost_scsi_init_inflight(vs, NULL);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 15a216cdd507..24a129fcdd61 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -390,9 +390,9 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev)
vq->indirect = kmalloc_array(UIO_MAXIOV,
sizeof(*vq->indirect),
GFP_KERNEL);
- vq->log = kmalloc_array(UIO_MAXIOV, sizeof(*vq->log),
+ vq->log = kmalloc_array(dev->iov_limit, sizeof(*vq->log),
GFP_KERNEL);
- vq->heads = kmalloc_array(UIO_MAXIOV, sizeof(*vq->heads),
+ vq->heads = kmalloc_array(dev->iov_limit, sizeof(*vq->heads),
GFP_KERNEL);
if (!vq->indirect || !vq->log || !vq->heads)
goto err_nomem;
@@ -414,7 +414,7 @@ static void vhost_dev_free_iovecs(struct vhost_dev *dev)
}
void vhost_dev_init(struct vhost_dev *dev,
- struct vhost_virtqueue **vqs, int nvqs)
+ struct vhost_virtqueue **vqs, int nvqs, int iov_limit)
{
struct vhost_virtqueue *vq;
int i;
@@ -427,6 +427,7 @@ void vhost_dev_init(struct vhost_dev *dev,
dev->iotlb = NULL;
dev->mm = NULL;
dev->worker = NULL;
+ dev->iov_limit = iov_limit;
init_llist_head(>work_list);
init_waitqueue_head(>wait);
INIT_LIST_HEAD(>read_list);
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 1b675dad5e05..9490e7ddb340 100644
---
Re: [PATCH 1/5] dt-bindings: phy: tegra: Add Tegra186 support
Reviewed-by: JC Kuo On 1/25/19 7:25 PM, Thierry Reding wrote: From: Thierry Reding Extend the bindings to cover the set of features found in Tegra186. Note that, technically, there are four more supplies connected to the XUSB pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL), but the power sequencing requirements of Tegra186 require these to be under the control of the PMIC. Signed-off-by: Thierry Reding --- .../bindings/phy/nvidia,tegra124-xusb-padctl.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt index 3742c152c467..daedb15f322e 100644 --- a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt @@ -36,11 +36,20 @@ Required properties: - Tegra124: "nvidia,tegra124-xusb-padctl" - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl" - Tegra210: "nvidia,tegra210-xusb-padctl" + - Tegra186: "nvidia,tegra186-xusb-padctl" - reg: Physical base address and length of the controller's registers. - resets: Must contain an entry for each entry in reset-names. - reset-names: Must include the following entries: - "padctl" +For Tegra186: +- avdd-pll-erefeut-supply: UPHY brick and reference clock as well as UTMI PHY + power supply. Must supply 1.8 V. +- avdd-usb-supply: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must supply + 3.3 V. +- vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V. +- vddio-hsic-supply: HSIC PHY power supply. Must supply 1.2 V. + Pad nodes: ==
Re: [PATCH] net: stmmac: dwmac-rk: fix error handling in rk_gmac_powerup()
From: Alexey Khoroshilov Date: Sat, 26 Jan 2019 22:48:57 +0300 > If phy_power_on() fails in rk_gmac_powerup(), clocks are left enabled. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Applied, thank you.
Re: use generic DMA mapping code in powerpc V4
On Sun, Jan 27, 2019 at 02:13:09PM +0100, Christian Zigotzky wrote: > Christoph, > > What shall I do next? I'll need to figure out what went wrong with the new zone selection on powerpc and give you another branch to test.
Re: [PATCH v4 4/6] arm64/kvm: enable pointer authentication cpufeature conditionally
Hi James,
On Fri, Jan 4, 2019 at 11:32 PM James Morse wrote:
>
> Hi Amit,
>
> On 18/12/2018 07:56, Amit Daniel Kachhap wrote:
> > According to userspace settings, pointer authentication cpufeature
> > is enabled/disabled from guests.
>
> This reads like the guest is changing something in the host. Isn't this hiding
> the id-register values from the guest?
I dropped this patch altogether in V5 series and now only key
registers are masked
if userspace disables it.
Thanks,
Amit Daniel
>
>
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index 6af6c7d..ce6144a 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -1066,6 +1066,15 @@ static u64 read_id_reg(struct sys_reg_desc const *r,
> > bool raz)
> > kvm_debug("SVE unsupported for guests,
> > suppressing\n");
> >
> > val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
> > + } else if (id == SYS_ID_AA64ISAR1_EL1) {
> > + const u64 ptrauth_mask = (0xfUL << ID_AA64ISAR1_APA_SHIFT) |
> > + (0xfUL << ID_AA64ISAR1_API_SHIFT) |
> > + (0xfUL << ID_AA64ISAR1_GPA_SHIFT) |
> > + (0xfUL << ID_AA64ISAR1_GPI_SHIFT);
> > + if (!kvm_arm_vcpu_ptrauth_allowed(vcpu)) {
> > + kvm_debug("ptrauth unsupported for guests,
> > suppressing\n");
> > + val &= ~ptrauth_mask;
> > + }
>
> I think this hunk should have been in the previous patch as otherwise its a
> bisection oddity.
>
> Could you merge this hunk with the previous patch, and move the mechanical
> bits
> that pass vcpu around to a prior preparatory patch.
>
> (I'm still unsure if we need to hide this as a user-controlled policy)
>
>
> Thanks,
>
> James
[PATCH v2 0/4] perf: enable compression of record mode trace to save storage space
The patch set implements runtime trace compression for record mode and
trace file decompression for report mode. Zstandard API [1] is used for
compression/decompression of data that come from perf_events kernel
data buffers.
Realized -z,--compression_level=n option provides ~3-5x avg. trace file
size reduction on variety of tested workloads what saves user storage
space on larger server systems where trace file size can easily reach
several tens or even hundreds of GiBs, especially when profiling with
stacks for later dwarf unwinding and context-switches tracing and etc.
$ tools/perf/perf record -z 1 -e cycles -- matrix.gcc
--mmap-flush option can be used to avoid compressing every single byte
of data and increase compression ratio at the same time lowering tool
runtime overhead.
The compression functionality can be disabled from the command line
using NO_LIBZSTD define and Zstandard sources can be overridden using
value of LIBZSTD_DIR define:
$ make -C tools/perf NO_LIBZSTD=1 clean all
$ make -C tools/perf LIBZSTD_DIR=/path/to/zstd-1.3.7 clean all
The patch set is for Arnaldo's perf/core repository.
---
Alexey Budankov (4):
feature: realize libzstd check, LIBZSTD_DIR and NO_LIBZSTD defines
perf record: implement -z= and --mmap-flush= options
perf record: enable runtime trace compression
perf report: support record trace file decompression
tools/build/Makefile.feature | 6 +-
tools/build/feature/Makefile | 6 +-
tools/build/feature/test-all.c | 5 +
tools/build/feature/test-libzstd.c | 12 +
tools/perf/Documentation/perf-record.txt | 9 +
tools/perf/Makefile.config | 20 ++
tools/perf/Makefile.perf | 3 +
tools/perf/builtin-record.c | 167 +++---
tools/perf/builtin-report.c | 5 +-
tools/perf/perf.h| 2 +
tools/perf/util/env.h| 10 +
tools/perf/util/event.c | 1 +
tools/perf/util/event.h | 7 +
tools/perf/util/evlist.c | 6 +-
tools/perf/util/evlist.h | 2 +-
tools/perf/util/header.c | 45 +++-
tools/perf/util/header.h | 1 +
tools/perf/util/mmap.c | 173 ++-
tools/perf/util/mmap.h | 31 ++-
tools/perf/util/session.c| 271 ++-
tools/perf/util/session.h| 26 +++
tools/perf/util/tool.h | 2 +
22 files changed, 695 insertions(+), 115 deletions(-)
create mode 100644 tools/build/feature/test-libzstd.c
---
Changes in v2:
- moved compression/decompression code to session layer
- enabled allocation aio data buffers for compression
- enabled trace compression for serial trace streaming
---
[1] https://github.com/facebook/zstd
---
Examples:
$ make -C tools/perf NO_LIBZSTD=1 clean all
$ make -C tools/perf LIBZSTD_DIR=/path/to/zstd-1.3.7 clean all
$ tools/perf/perf record -z 1 -e cycles -- matrix.gcc
Addr of buf1 = 0x7fc266d52010
Offs of buf1 = 0x7fc266d52180
Addr of buf2 = 0x7fc264d51010
Offs of buf2 = 0x7fc264d511c0
Addr of buf3 = 0x7fc262d50010
Offs of buf3 = 0x7fc262d50100
Addr of buf4 = 0x7fc260d4f010
Offs of buf4 = 0x7fc260d4f140
Threads #: 8 Pthreads
Matrix size: 2048
Using multiply kernel: multiply1
Execution time = 31.471 seconds
[ perf record: Woken up 120 times to write data ]
[ perf record: Compressed 38.118 MB to 7.084 MB, ratio is 5.381 ]
[ perf record: Captured and wrote 7.100 MB perf.data (999192 samples) ]
$ tools/perf/perf report -D --header
#
# captured on: Sat Jan 26 11:49:55 2019
# header version : 1
# data offset: 296
# data size : 7444119
# feat offset: 715
# hostname : nntvtune39
# os release : 4.19.15-300.fc29.x86_64
# perf version : 4.13.rc5.g3cfa299
# arch : x86_64
# nrcpus online : 8
# nrcpus avail : 8
# cpudesc : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
# cpuid : GenuineIntel,6,94,3
# total memory : 16153184 kB
# cmdline : /root/abudanko/kernel/acme/tools/perf/perf record -z 1 -e cycles
-- ../../matrix/linux/matrix.gcc
# event : name = cycles, , id = { 2171, 2172, 2173, 2174, 2175, 2176, 2177,
2178 }, size = 112, { sample_period, sample_freq } = 4000, sample_type =
IP|TID|TIME|PERIOD, read_format =>
# CPU_TOPOLOGY info available, use -I to display
# NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: intel_pt = 8, software = 1, power = 11, uprobe = 7,
uncore_imc = 12, cpu = 4, cstate_core = 18, uncore_cbox_2 = 15, breakpoint = 5,
uncore_cbox_0 = 13, tracepoint = 2>
# CACHE info available, use -I to display
# time of first sample : 230574.239204
# time of last sample : 230605.735403
# sample duration : 31496.200 ms
# MEM_TOPOLOGY info available, use -I to display
# compressed : Zstd, level = 1, ratio = 5
# missing
Re: [PATCH net 0/3] net: hns: code optimizations & bugfixes for HNS driver
From: Peng Li Date: Sat, 26 Jan 2019 17:18:24 +0800 > This patchset includes bugfixes and code optimizations for the HNS > ethernet controller driver Series applied, thank you. There are only bug fixes in here, so please do not use the word "optimizations" in such situations. Thanks.
[kvmtool PATCH v5 6/6] arm/kvm: arm64: Add a vcpu feature for pointer authentication
This is a runtime feature and can be enabled by --ptrauth option.
Signed-off-by: Amit Daniel Kachhap
Cc: Mark Rutland
Cc: Christoffer Dall
Cc: Marc Zyngier
Cc: Kristina Martsenko
Cc: kvm...@lists.cs.columbia.edu
Cc: Ramana Radhakrishnan
Cc: Will Deacon
---
arm/aarch32/include/kvm/kvm-cpu-arch.h| 2 ++
arm/aarch64/include/asm/kvm.h | 3 +++
arm/aarch64/include/kvm/kvm-arch.h| 1 +
arm/aarch64/include/kvm/kvm-config-arch.h | 4 +++-
arm/aarch64/include/kvm/kvm-cpu-arch.h| 2 ++
arm/aarch64/kvm-cpu.c | 5 +
arm/include/arm-common/kvm-config-arch.h | 1 +
arm/kvm-cpu.c | 7 +++
include/linux/kvm.h | 1 +
9 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/arm/aarch32/include/kvm/kvm-cpu-arch.h
b/arm/aarch32/include/kvm/kvm-cpu-arch.h
index d28ea67..5779767 100644
--- a/arm/aarch32/include/kvm/kvm-cpu-arch.h
+++ b/arm/aarch32/include/kvm/kvm-cpu-arch.h
@@ -13,4 +13,6 @@
#define ARM_CPU_ID 0, 0, 0
#define ARM_CPU_ID_MPIDR 5
+unsigned int kvm__cpu_ptrauth_get_feature(void) {}
+
#endif /* KVM__KVM_CPU_ARCH_H */
diff --git a/arm/aarch64/include/asm/kvm.h b/arm/aarch64/include/asm/kvm.h
index c286035..0fd183d 100644
--- a/arm/aarch64/include/asm/kvm.h
+++ b/arm/aarch64/include/asm/kvm.h
@@ -98,6 +98,9 @@ struct kvm_regs {
#define KVM_ARM_VCPU_PSCI_0_2 2 /* CPU uses PSCI v0.2 */
#define KVM_ARM_VCPU_PMU_V33 /* Support guest PMUv3 */
+/* CPU uses address authentication and A key */
+#define KVM_ARM_VCPU_PTRAUTH 4
+
struct kvm_vcpu_init {
__u32 target;
__u32 features[7];
diff --git a/arm/aarch64/include/kvm/kvm-arch.h
b/arm/aarch64/include/kvm/kvm-arch.h
index 9de623a..bd566cb 100644
--- a/arm/aarch64/include/kvm/kvm-arch.h
+++ b/arm/aarch64/include/kvm/kvm-arch.h
@@ -11,4 +11,5 @@
#include "arm-common/kvm-arch.h"
+
#endif /* KVM__KVM_ARCH_H */
diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h
b/arm/aarch64/include/kvm/kvm-config-arch.h
index 04be43d..2074684 100644
--- a/arm/aarch64/include/kvm/kvm-config-arch.h
+++ b/arm/aarch64/include/kvm/kvm-config-arch.h
@@ -8,7 +8,9 @@
"Create PMUv3 device"), \
OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed, \
"Specify random seed for Kernel Address Space " \
- "Layout Randomization (KASLR)"),
+ "Layout Randomization (KASLR)"),\
+ OPT_BOOLEAN('\0', "ptrauth", &(cfg)->has_ptrauth, \
+ "Enable address authentication"),
#include "arm-common/kvm-config-arch.h"
diff --git a/arm/aarch64/include/kvm/kvm-cpu-arch.h
b/arm/aarch64/include/kvm/kvm-cpu-arch.h
index a9d8563..f7b64b7 100644
--- a/arm/aarch64/include/kvm/kvm-cpu-arch.h
+++ b/arm/aarch64/include/kvm/kvm-cpu-arch.h
@@ -17,4 +17,6 @@
#define ARM_CPU_CTRL 3, 0, 1, 0
#define ARM_CPU_CTRL_SCTLR_EL1 0
+unsigned int kvm__cpu_ptrauth_get_feature(void);
+
#endif /* KVM__KVM_CPU_ARCH_H */
diff --git a/arm/aarch64/kvm-cpu.c b/arm/aarch64/kvm-cpu.c
index 1b29374..10da2cb 100644
--- a/arm/aarch64/kvm-cpu.c
+++ b/arm/aarch64/kvm-cpu.c
@@ -123,6 +123,11 @@ void kvm_cpu__reset_vcpu(struct kvm_cpu *vcpu)
return reset_vcpu_aarch64(vcpu);
}
+unsigned int kvm__cpu_ptrauth_get_feature(void)
+{
+ return (1UL << KVM_ARM_VCPU_PTRAUTH);
+}
+
int kvm_cpu__get_endianness(struct kvm_cpu *vcpu)
{
struct kvm_one_reg reg;
diff --git a/arm/include/arm-common/kvm-config-arch.h
b/arm/include/arm-common/kvm-config-arch.h
index 6a196f1..eb872db 100644
--- a/arm/include/arm-common/kvm-config-arch.h
+++ b/arm/include/arm-common/kvm-config-arch.h
@@ -10,6 +10,7 @@ struct kvm_config_arch {
boolaarch32_guest;
boolhas_pmuv3;
u64 kaslr_seed;
+ boolhas_ptrauth;
enum irqchip_type irqchip;
};
diff --git a/arm/kvm-cpu.c b/arm/kvm-cpu.c
index 7780251..5afd727 100644
--- a/arm/kvm-cpu.c
+++ b/arm/kvm-cpu.c
@@ -68,6 +68,13 @@ struct kvm_cpu *kvm_cpu__arch_init(struct kvm *kvm, unsigned
long cpu_id)
vcpu_init.features[0] |= (1UL << KVM_ARM_VCPU_PSCI_0_2);
}
+ /* Set KVM_ARM_VCPU_PTRAUTH_I_A if available */
+ if (kvm__supports_extension(kvm, KVM_CAP_ARM_PTRAUTH)) {
+ if (kvm->cfg.arch.has_ptrauth)
+ vcpu_init.features[0] |=
+ kvm__cpu_ptrauth_get_feature();
+ }
+
/*
* If the preferred target ioctl is successful then
* use preferred target else try each and every target type
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index f51d508..204315e 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -883,6 +883,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_PPC_MMU_RADIX
[PATCH v5 5/5] arm64/kvm: control accessibility of ptrauth key registers
According to userspace settings, ptrauth key registers are conditionally
present in guest system register list based on user specified flag
KVM_ARM_VCPU_PTRAUTH.
Signed-off-by: Amit Daniel Kachhap
Cc: Mark Rutland
Cc: Christoffer Dall
Cc: Marc Zyngier
Cc: Kristina Martsenko
Cc: kvm...@lists.cs.columbia.edu
Cc: Ramana Radhakrishnan
Cc: Will Deacon
---
Documentation/arm64/pointer-authentication.txt | 3 ++
arch/arm64/kvm/sys_regs.c | 42 +++---
2 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/Documentation/arm64/pointer-authentication.txt
b/Documentation/arm64/pointer-authentication.txt
index 0529a7d..3be4ee1 100644
--- a/Documentation/arm64/pointer-authentication.txt
+++ b/Documentation/arm64/pointer-authentication.txt
@@ -87,3 +87,6 @@ created by passing a flag (KVM_ARM_VCPU_PTRAUTH) requesting
this feature
to be enabled. Without this flag, pointer authentication is not enabled
in KVM guests and attempted use of the feature will result in an UNDEFINED
exception being injected into the guest.
+
+Additionally, when KVM_ARM_VCPU_PTRAUTH is not set then KVM will filter
+out the authentication key registers from userspace.
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 2546a65..b46a78e 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1334,12 +1334,6 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ SYS_DESC(SYS_TTBR1_EL1), access_vm_reg, reset_unknown, TTBR1_EL1 },
{ SYS_DESC(SYS_TCR_EL1), access_vm_reg, reset_val, TCR_EL1, 0 },
- PTRAUTH_KEY(APIA),
- PTRAUTH_KEY(APIB),
- PTRAUTH_KEY(APDA),
- PTRAUTH_KEY(APDB),
- PTRAUTH_KEY(APGA),
-
{ SYS_DESC(SYS_AFSR0_EL1), access_vm_reg, reset_unknown, AFSR0_EL1 },
{ SYS_DESC(SYS_AFSR1_EL1), access_vm_reg, reset_unknown, AFSR1_EL1 },
{ SYS_DESC(SYS_ESR_EL1), access_vm_reg, reset_unknown, ESR_EL1 },
@@ -1491,6 +1485,14 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ SYS_DESC(SYS_FPEXC32_EL2), NULL, reset_val, FPEXC32_EL2, 0x70 },
};
+static const struct sys_reg_desc ptrauth_reg_descs[] = {
+ PTRAUTH_KEY(APIA),
+ PTRAUTH_KEY(APIB),
+ PTRAUTH_KEY(APDA),
+ PTRAUTH_KEY(APDB),
+ PTRAUTH_KEY(APGA),
+};
+
static bool trap_dbgidr(struct kvm_vcpu *vcpu,
struct sys_reg_params *p,
const struct sys_reg_desc *r)
@@ -2093,6 +2095,8 @@ static int emulate_sys_reg(struct kvm_vcpu *vcpu,
r = find_reg(params, table, num);
if (!r)
r = find_reg(params, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
+ if (!r && kvm_arm_vcpu_ptrauth_allowed(vcpu))
+ r = find_reg(params, ptrauth_reg_descs,
ARRAY_SIZE(ptrauth_reg_descs));
if (likely(r)) {
perform_access(vcpu, params, r);
@@ -2206,6 +2210,8 @@ static const struct sys_reg_desc
*index_to_sys_reg_desc(struct kvm_vcpu *vcpu,
r = find_reg_by_id(id, , table, num);
if (!r)
r = find_reg(, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
+ if (!r && kvm_arm_vcpu_ptrauth_allowed(vcpu))
+ r = find_reg(, ptrauth_reg_descs,
ARRAY_SIZE(ptrauth_reg_descs));
/* Not saved in the sys_reg array and not otherwise accessible? */
if (r && !(r->reg || r->get_user))
@@ -2487,18 +2493,22 @@ static int walk_one_sys_reg(const struct sys_reg_desc
*rd,
}
/* Assumed ordered tables, see kvm_sys_reg_table_init. */
-static int walk_sys_regs(struct kvm_vcpu *vcpu, u64 __user *uind)
+static int walk_sys_regs(struct kvm_vcpu *vcpu, u64 __user *uind,
+ const struct sys_reg_desc *desc, unsigned int len)
{
const struct sys_reg_desc *i1, *i2, *end1, *end2;
unsigned int total = 0;
size_t num;
int err;
+ if (desc == ptrauth_reg_descs && !kvm_arm_vcpu_ptrauth_allowed(vcpu))
+ return total;
+
/* We check for duplicates here, to allow arch-specific overrides. */
i1 = get_target_table(vcpu->arch.target, true, );
end1 = i1 + num;
- i2 = sys_reg_descs;
- end2 = sys_reg_descs + ARRAY_SIZE(sys_reg_descs);
+ i2 = desc;
+ end2 = desc + len;
BUG_ON(i1 == end1 || i2 == end2);
@@ -2526,7 +2536,10 @@ unsigned long kvm_arm_num_sys_reg_descs(struct kvm_vcpu
*vcpu)
{
return ARRAY_SIZE(invariant_sys_regs)
+ num_demux_regs()
- + walk_sys_regs(vcpu, (u64 __user *)NULL);
+ + walk_sys_regs(vcpu, (u64 __user *)NULL, sys_reg_descs,
+ ARRAY_SIZE(sys_reg_descs))
+ + walk_sys_regs(vcpu, (u64 __user *)NULL, ptrauth_reg_descs,
+ ARRAY_SIZE(ptrauth_reg_descs));
}
int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
@@ -2541,7 +2554,12 @@ int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu
[PATCH v5 3/5] arm64/kvm: context-switch ptrauth registers
When pointer authentication is supported, a guest may wish to use it.
This patch adds the necessary KVM infrastructure for this to work, with
a semi-lazy context switch of the pointer auth state.
Pointer authentication feature is only enabled when VHE is built
into the kernel and present into CPU implementation so only VHE code
paths are modified.
When we schedule a vcpu, we disable guest usage of pointer
authentication instructions and accesses to the keys. While these are
disabled, we avoid context-switching the keys. When we trap the guest
trying to use pointer authentication functionality, we change to eagerly
context-switching the keys, and enable the feature. The next time the
vcpu is scheduled out/in, we start again.
Pointer authentication consists of address authentication and generic
authentication, and CPUs in a system might have varied support for
either. Where support for either feature is not uniform, it is hidden
from guests via ID register emulation, as a result of the cpufeature
framework in the host.
Unfortunately, address authentication and generic authentication cannot
be trapped separately, as the architecture provides a single EL2 trap
covering both. If we wish to expose one without the other, we cannot
prevent a (badly-written) guest from intermittently using a feature
which is not uniformly supported (when scheduled on a physical CPU which
supports the relevant feature). When the guest is scheduled on a
physical CPU lacking the feature, these attempts will result in an UNDEF
being taken by the guest.
Signed-off-by: Mark Rutland
Signed-off-by: Amit Daniel Kachhap
Cc: Marc Zyngier
Cc: Christoffer Dall
Cc: Kristina Martsenko
Cc: kvm...@lists.cs.columbia.edu
Cc: Ramana Radhakrishnan
Cc: Will Deacon
---
arch/arm/include/asm/kvm_host.h | 1 +
arch/arm64/include/asm/cpufeature.h | 5 +
arch/arm64/include/asm/kvm_host.h | 24
arch/arm64/include/asm/kvm_hyp.h| 7 ++
arch/arm64/kernel/traps.c | 1 +
arch/arm64/kvm/handle_exit.c| 23 +++
arch/arm64/kvm/hyp/Makefile | 1 +
arch/arm64/kvm/hyp/ptrauth-sr.c | 44 +
arch/arm64/kvm/hyp/switch.c | 4
arch/arm64/kvm/sys_regs.c | 40 ++---
virt/kvm/arm/arm.c | 2 ++
11 files changed, 135 insertions(+), 17 deletions(-)
create mode 100644 arch/arm64/kvm/hyp/ptrauth-sr.c
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 704667e..b200c14 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -345,6 +345,7 @@ static inline int kvm_arm_have_ssbd(void)
static inline void kvm_vcpu_load_sysregs(struct kvm_vcpu *vcpu) {}
static inline void kvm_vcpu_put_sysregs(struct kvm_vcpu *vcpu) {}
+static inline void kvm_arm_vcpu_ptrauth_reset(struct kvm_vcpu *vcpu) {}
#define __KVM_HAVE_ARCH_VM_ALLOC
struct kvm *kvm_arch_alloc_vm(void);
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index dfcfba7..e1bf2a5 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -612,6 +612,11 @@ static inline bool system_supports_generic_auth(void)
cpus_have_const_cap(ARM64_HAS_GENERIC_AUTH_IMP_DEF));
}
+static inline bool kvm_supports_ptrauth(void)
+{
+ return system_supports_address_auth() && system_supports_generic_auth();
+}
+
#define ARM64_SSBD_UNKNOWN -1
#define ARM64_SSBD_FORCE_DISABLE 0
#define ARM64_SSBD_KERNEL 1
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 1f2d237..c798d0c 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -146,6 +146,18 @@ enum vcpu_sysreg {
PMSWINC_EL0,/* Software Increment Register */
PMUSERENR_EL0, /* User Enable Register */
+ /* Pointer Authentication Registers */
+ APIAKEYLO_EL1,
+ APIAKEYHI_EL1,
+ APIBKEYLO_EL1,
+ APIBKEYHI_EL1,
+ APDAKEYLO_EL1,
+ APDAKEYHI_EL1,
+ APDBKEYLO_EL1,
+ APDBKEYHI_EL1,
+ APGAKEYLO_EL1,
+ APGAKEYHI_EL1,
+
/* 32bit specific registers. Keep them at the end of the range */
DACR32_EL2, /* Domain Access Control Register */
IFSR32_EL2, /* Instruction Fault Status Register */
@@ -439,6 +451,18 @@ static inline bool kvm_arch_requires_vhe(void)
return false;
}
+void kvm_arm_vcpu_ptrauth_enable(struct kvm_vcpu *vcpu);
+void kvm_arm_vcpu_ptrauth_disable(struct kvm_vcpu *vcpu);
+
+static inline void kvm_arm_vcpu_ptrauth_reset(struct kvm_vcpu *vcpu)
+{
+ /* Disable ptrauth and use it in a lazy context via traps */
+ if (has_vhe() && kvm_supports_ptrauth())
+ kvm_arm_vcpu_ptrauth_disable(vcpu);
+}
+
+void kvm_arm_vcpu_ptrauth_trap(struct kvm_vcpu *vcpu);
+
static inline void
[PATCH v5 4/5] arm64/kvm: add a userspace option to enable pointer authentication
This feature will allow the KVM guest to allow the handling of
pointer authentication instructions or to treat them as undefined
if not set. It uses the existing vcpu API KVM_ARM_VCPU_INIT to
supply this parameter instead of creating a new API.
A new register is not created to pass this parameter via
SET/GET_ONE_REG interface as just a flag (KVM_ARM_VCPU_PTRAUTH)
supplied is enough to enable this feature.
Signed-off-by: Amit Daniel Kachhap
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Christoffer Dall
Cc: Kristina Martsenko
Cc: kvm...@lists.cs.columbia.edu
Cc: Ramana Radhakrishnan
Cc: Will Deacon
---
Documentation/arm64/pointer-authentication.txt | 9 +
Documentation/virtual/kvm/api.txt | 4
arch/arm/include/asm/kvm_host.h| 4
arch/arm64/include/asm/kvm_host.h | 7 ---
arch/arm64/include/uapi/asm/kvm.h | 1 +
arch/arm64/kvm/handle_exit.c | 3 ++-
arch/arm64/kvm/hyp/ptrauth-sr.c| 13 +
arch/arm64/kvm/reset.c | 3 +++
include/uapi/linux/kvm.h | 1 +
9 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/Documentation/arm64/pointer-authentication.txt
b/Documentation/arm64/pointer-authentication.txt
index a25cd21..0529a7d 100644
--- a/Documentation/arm64/pointer-authentication.txt
+++ b/Documentation/arm64/pointer-authentication.txt
@@ -82,7 +82,8 @@ pointers).
Virtualization
--
-Pointer authentication is not currently supported in KVM guests. KVM
-will mask the feature bits from ID_AA64ISAR1_EL1, and attempted use of
-the feature will result in an UNDEFINED exception being injected into
-the guest.
+Pointer authentication is enabled in KVM guest when virtual machine is
+created by passing a flag (KVM_ARM_VCPU_PTRAUTH) requesting this feature
+to be enabled. Without this flag, pointer authentication is not enabled
+in KVM guests and attempted use of the feature will result in an UNDEFINED
+exception being injected into the guest.
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 356156f..1e646fb 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2642,6 +2642,10 @@ Possible features:
Depends on KVM_CAP_ARM_PSCI_0_2.
- KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU.
Depends on KVM_CAP_ARM_PMU_V3.
+ - KVM_ARM_VCPU_PTRAUTH: Emulate Pointer authentication for the CPU.
+ Depends on KVM_CAP_ARM_PTRAUTH and only on arm64 architecture. If
+ set, then the KVM guest allows the execution of pointer authentication
+ instructions or treats them as undefined if not set.
4.83 KVM_ARM_PREFERRED_TARGET
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index b200c14..b6950df 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -346,6 +346,10 @@ static inline int kvm_arm_have_ssbd(void)
static inline void kvm_vcpu_load_sysregs(struct kvm_vcpu *vcpu) {}
static inline void kvm_vcpu_put_sysregs(struct kvm_vcpu *vcpu) {}
static inline void kvm_arm_vcpu_ptrauth_reset(struct kvm_vcpu *vcpu) {}
+static inline bool kvm_arm_vcpu_ptrauth_allowed(struct kvm_vcpu *vcpu)
+{
+ return false;
+}
#define __KVM_HAVE_ARCH_VM_ALLOC
struct kvm *kvm_arch_alloc_vm(void);
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index c798d0c..4a6ec40 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -43,7 +43,7 @@
#define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
-#define KVM_VCPU_MAX_FEATURES 4
+#define KVM_VCPU_MAX_FEATURES 5
#define KVM_REQ_SLEEP \
KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
@@ -453,14 +453,15 @@ static inline bool kvm_arch_requires_vhe(void)
void kvm_arm_vcpu_ptrauth_enable(struct kvm_vcpu *vcpu);
void kvm_arm_vcpu_ptrauth_disable(struct kvm_vcpu *vcpu);
+bool kvm_arm_vcpu_ptrauth_allowed(struct kvm_vcpu *vcpu);
static inline void kvm_arm_vcpu_ptrauth_reset(struct kvm_vcpu *vcpu)
{
/* Disable ptrauth and use it in a lazy context via traps */
- if (has_vhe() && kvm_supports_ptrauth())
+ if (has_vhe() && kvm_supports_ptrauth()
+ && kvm_arm_vcpu_ptrauth_allowed(vcpu))
kvm_arm_vcpu_ptrauth_disable(vcpu);
}
-
void kvm_arm_vcpu_ptrauth_trap(struct kvm_vcpu *vcpu);
static inline void kvm_arch_hardware_unsetup(void) {}
diff --git a/arch/arm64/include/uapi/asm/kvm.h
b/arch/arm64/include/uapi/asm/kvm.h
index 97c3478..5f82ca1 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -102,6 +102,7 @@ struct kvm_regs {
#define KVM_ARM_VCPU_EL1_32BIT 1 /* CPU running a 32bit VM */
#define KVM_ARM_VCPU_PSCI_0_2 2 /* CPU uses PSCI v0.2 */
#define KVM_ARM_VCPU_PMU_V33 /* Support guest PMUv3 */
+#define
[PATCH v5 0/6] Add ARMv8.3 pointer authentication for kvm guest
Hi, This patch series adds pointer authentication support for KVM guest and is based on top of Linux 5.0-rc3. The basic patches in this series was originally posted by Mark Rutland earlier[1,2] and contains some history of this work. Extension Overview: = The ARMv8.3 pointer authentication extension adds functionality to detect modification of pointer values, mitigating certain classes of attack such as stack smashing, and making return oriented programming attacks harder. The extension introduces the concept of a pointer authentication code (PAC), which is stored in some upper bits of pointers. Each PAC is derived from the original pointer, another 64-bit value (e.g. the stack pointer), and a secret 128-bit key. New instructions are added which can be used to: * Insert a PAC into a pointer * Strip a PAC from a pointer * Authenticate and strip a PAC from a pointer The detailed description of ARMv8.3 pointer authentication support in userspace/kernel and can be found in Kristina's generic pointer authentication patch series[3]. KVM guest work: == If pointer authentication is enabled for KVM guests then the new PAC instructions will not trap to EL2. If not then they may be ignored if in HINT region or trapped in EL2 as illegal instruction. Since KVM guest vcpu runs as a thread so they have a key initialized which will be used by PAC. When world switch happens between host and guest then this key is exchanged. There were some review comments by Christoffer Dall in the original series [1,2,3] and this patch series tries to implement them. The original series enabled pointer authentication for both userspace and kvm userspace. However it is now bifurcated and this series contains only KVM guest support. The current v5 patch series contains most of the suggestion by James Morse. One of the suggestions was to do save/restore keys in asm during switch. However this series re-uses the arm64 core functions __ptrauth_key_install but called from C function using __no_ptrauth attribute. Changes since v4 [6]: Several suggestions from James Morse * Move host registers to be saved/restored inside struct kvm_cpu_context. * Similar to hcr_el2, save/restore mdcr_el2 register also. * Added save routines for ptrauth keys in generic arm core and use them during KVM context switch. * Defined a GCC attribute __no_ptrauth which discards generating ptrauth instructions in a function. This is taken from Kristina's earlier kernel pointer authentication support patches [4]. * Dropped a patch to mask cpufeature when not enabled from userspace and now only key registers are masked from register list. Changes since v3 [5]: * Use pointer authentication only when VHE is present as ARM8.3 implies ARM8.1 features to be present. * Added lazy context handling of ptrauth instructions from V2 version again. * Added more details in Documentation. Changes since v2 [1,2]: * Allow host and guest to have different HCR_EL2 settings and not just constant value HCR_HOST_VHE_FLAGS or HCR_HOST_NVHE_FLAGS. * Optimise the reading of HCR_EL2 in host/guest switch by fetching it once during KVM initialisation state and using it later. * Context switch pointer authentication keys when switching between guest and host. Pointer authentication was enabled in a lazy context earlier[2] and is removed now to make it simple. However it can be revisited later if there is significant performance issue. * Added a userspace option to choose pointer authentication. * Based on the userspace option, ptrauth cpufeature will be visible. * Based on the userspace option, ptrauth key registers will be accessible. * A small document is added on how to enable pointer authentication from userspace KVM API. Looking for feedback and comments. Thanks, Amit [1]: https://lore.kernel.org/lkml/20171127163806.31435-11-mark.rutl...@arm.com/ [2]: https://lore.kernel.org/lkml/20171127163806.31435-10-mark.rutl...@arm.com/ [3]: https://lkml.org/lkml/2018/12/7/666 [4]: https://lore.kernel.org/lkml/20181005084754.20950-1-kristina.martse...@arm.com/ [5]: https://lkml.org/lkml/2018/10/17/594 [6]: https://lkml.org/lkml/2018/12/18/80 Linux (5.0-rc3 based): Amit Daniel Kachhap (5): arm64: Add utilities to save restore pointer authentication keys arm64/kvm: preserve host HCR_EL2/MDCR_EL2 value arm64/kvm: context-switch ptrauth registers arm64/kvm: add a userspace option to enable pointer authentication arm64/kvm: control accessibility of ptrauth key registers Documentation/arm64/pointer-authentication.txt | 12 +++-- Documentation/virtual/kvm/api.txt | 4 ++ arch/arm/include/asm/kvm_host.h| 8 ++- arch/arm64/include/asm/cpufeature.h| 5 ++ arch/arm64/include/asm/kvm_asm.h | 2 + arch/arm64/include/asm/kvm_emulate.h | 22 arch/arm64/include/asm/kvm_host.h | 55
[PATCH] Bluetooth: Add NULL check for tiocmget() and tiocmset()
tiocmget() and tiocmset() operations are optional and some tty drivers
like pty miss the operations. We need NULL check before referencing
them.
Reported-by: syzbot+a950165cbb86bdd02...@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung
---
drivers/bluetooth/hci_ath.c | 13 -
drivers/bluetooth/hci_ldisc.c | 5 +
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
index d568fbd94d6c..076700a1e9a8 100644
--- a/drivers/bluetooth/hci_ath.c
+++ b/drivers/bluetooth/hci_ath.c
@@ -94,11 +94,14 @@ static void ath_hci_uart_work(struct work_struct *work)
hu = ath->hu;
tty = hu->tty;
- /* verify and wake up controller */
- if (ath->cur_sleep) {
- status = ath_wakeup_ar3k(tty);
- if (!(status & TIOCM_CTS))
- return;
+ /* tiocmget() and tiocmset() operations are optional */
+ if (tty->driver->ops->tiocmget && tty->driver->ops->tiocmset) {
+ /* verify and wake up controller */
+ if (ath->cur_sleep) {
+ status = ath_wakeup_ar3k(tty);
+ if (!(status & TIOCM_CTS))
+ return;
+ }
}
/* Ready to send Data */
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index fbf7b4df23ab..9f88a8563cf6 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -314,6 +314,11 @@ void hci_uart_set_flow_control(struct hci_uart *hu, bool
enable)
return;
}
+ /* tiocmget() and tiocmset() operations are optional */
+ if (!tty->driver->ops->tiocmget || !tty->driver->ops->tiocmset) {
+ return;
+ }
+
if (enable) {
/* Disable hardware flow control */
ktermios = tty->termios;
--
2.17.1
[PATCH v5 2/5] arm64/kvm: preserve host HCR_EL2/MDCR_EL2 value
When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
is a constant value. This works today, as the host HCR_EL2 value is
always the same, but this will get in the way of supporting extensions
that require HCR_EL2 bits to be set conditionally for the host.
To allow such features to work without KVM having to explicitly handle
every possible host feature combination, this patch has KVM save/restore
the host HCR when switching to/from a guest HCR. The saving of the
register is done once during cpu hypervisor initialization state and is
just restored after switch from guest.
For fetching HCR_EL2 during kvm initialisation, a hyp call is made using
kvm_call_hyp and is helpful in NHVE case.
For the hyp TLB maintenance code, __tlb_switch_to_host_vhe() is updated
to toggle the TGE bit with a RMW sequence, as we already do in
__tlb_switch_to_guest_vhe().
While at it, host MDCR_EL2 value is fetched in a similar way and restored
after every switch from host to guest. There should not be any change in
functionality due to this.
Signed-off-by: Mark Rutland
Signed-off-by: Amit Daniel Kachhap
Cc: Marc Zyngier
Cc: Christoffer Dall
Cc: Kristina Martsenko
Cc: kvm...@lists.cs.columbia.edu
Cc: Ramana Radhakrishnan
Cc: Will Deacon
---
arch/arm/include/asm/kvm_host.h | 3 ++-
arch/arm64/include/asm/kvm_asm.h | 2 ++
arch/arm64/include/asm/kvm_emulate.h | 22 ++--
arch/arm64/include/asm/kvm_host.h| 28 -
arch/arm64/include/asm/kvm_hyp.h | 2 +-
arch/arm64/kvm/debug.c | 28 ++---
arch/arm64/kvm/guest.c | 2 +-
arch/arm64/kvm/hyp/switch.c | 40 +++-
arch/arm64/kvm/hyp/sysreg-sr.c | 13 +++-
arch/arm64/kvm/hyp/tlb.c | 6 +-
virt/kvm/arm/arm.c | 4 ++--
11 files changed, 82 insertions(+), 68 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index ca56537..704667e 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -273,6 +273,8 @@ static inline void __cpu_init_stage2(void)
kvm_call_hyp(__init_stage2_translation);
}
+static inline void __cpu_copy_hyp_conf(void) {}
+
static inline int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, long ext)
{
return 0;
@@ -292,7 +294,6 @@ static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu
*vcpu) {}
static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
-static inline void kvm_arm_init_debug(void) {}
static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {}
static inline void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) {}
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index f5b79e9..2da6e43 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -80,6 +80,8 @@ extern void __vgic_v3_init_lrs(void);
extern u32 __kvm_get_mdcr_el2(void);
+extern u64 __kvm_get_hcr_el2(void);
+
/* Home-grown __this_cpu_{ptr,read} variants that always work at HYP */
#define __hyp_this_cpu_ptr(sym)
\
({ \
diff --git a/arch/arm64/include/asm/kvm_emulate.h
b/arch/arm64/include/asm/kvm_emulate.h
index 506386a..0dbe795 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -50,25 +50,25 @@ void kvm_inject_pabt32(struct kvm_vcpu *vcpu, unsigned long
addr);
static inline bool vcpu_el1_is_32bit(struct kvm_vcpu *vcpu)
{
- return !(vcpu->arch.hcr_el2 & HCR_RW);
+ return !(vcpu->arch.ctxt.hcr_el2 & HCR_RW);
}
static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
{
- vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
+ vcpu->arch.ctxt.hcr_el2 = HCR_GUEST_FLAGS;
if (is_kernel_in_hyp_mode())
- vcpu->arch.hcr_el2 |= HCR_E2H;
+ vcpu->arch.ctxt.hcr_el2 |= HCR_E2H;
if (cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) {
/* route synchronous external abort exceptions to EL2 */
- vcpu->arch.hcr_el2 |= HCR_TEA;
+ vcpu->arch.ctxt.hcr_el2 |= HCR_TEA;
/* trap error record accesses */
- vcpu->arch.hcr_el2 |= HCR_TERR;
+ vcpu->arch.ctxt.hcr_el2 |= HCR_TERR;
}
if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
- vcpu->arch.hcr_el2 |= HCR_FWB;
+ vcpu->arch.ctxt.hcr_el2 |= HCR_FWB;
if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
- vcpu->arch.hcr_el2 &= ~HCR_RW;
+ vcpu->arch.ctxt.hcr_el2 &= ~HCR_RW;
/*
* TID3: trap feature register accesses that we virtualise.
@@ -76,22 +76,22
[PATCH v5 1/5] arm64: Add utilities to save restore pointer authentication keys
The keys can be switched either inside an assembly or such
functions which do not have pointer authentication checks, so a GCC
attribute is added to enable it.
A function ptrauth_keys_store is added which is similar to existing
function ptrauth_keys_switch but saves the key values in memory.
This may be useful for save/restore scenarios when CPU changes
privilege levels, suspend/resume etc.
Signed-off-by: Amit Daniel Kachhap
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Christoffer Dall
Cc: Kristina Martsenko
Cc: kvm...@lists.cs.columbia.edu
Cc: Ramana Radhakrishnan
Cc: Will Deacon
---
arch/arm64/include/asm/pointer_auth.h | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/include/asm/pointer_auth.h
b/arch/arm64/include/asm/pointer_auth.h
index 15d4951..98441ce 100644
--- a/arch/arm64/include/asm/pointer_auth.h
+++ b/arch/arm64/include/asm/pointer_auth.h
@@ -11,6 +11,13 @@
#ifdef CONFIG_ARM64_PTR_AUTH
/*
+ * Compile the function without pointer authentication instructions. This
+ * allows pointer authentication to be enabled/disabled within the function
+ * (but leaves the function unprotected by pointer authentication).
+ */
+#define __no_ptrauth __attribute__((target("sign-return-address=none")))
+
+/*
* Each key is a 128-bit quantity which is split across a pair of 64-bit
* registers (Lo and Hi).
*/
@@ -50,6 +57,13 @@ do {
\
write_sysreg_s(__pki_v.hi, SYS_ ## k ## KEYHI_EL1); \
} while (0)
+#define __ptrauth_key_save(k, v) \
+do { \
+ struct ptrauth_key __pki_v = (v); \
+ __pki_v.lo = read_sysreg_s(SYS_ ## k ## KEYLO_EL1); \
+ __pki_v.hi = read_sysreg_s(SYS_ ## k ## KEYHI_EL1); \
+} while (0)
+
static inline void ptrauth_keys_switch(struct ptrauth_keys *keys)
{
if (system_supports_address_auth()) {
@@ -63,6 +77,19 @@ static inline void ptrauth_keys_switch(struct ptrauth_keys
*keys)
__ptrauth_key_install(APGA, keys->apga);
}
+static inline void ptrauth_keys_store(struct ptrauth_keys *keys)
+{
+ if (system_supports_address_auth()) {
+ __ptrauth_key_save(APIA, keys->apia);
+ __ptrauth_key_save(APIB, keys->apib);
+ __ptrauth_key_save(APDA, keys->apda);
+ __ptrauth_key_save(APDB, keys->apdb);
+ }
+
+ if (system_supports_generic_auth())
+ __ptrauth_key_save(APGA, keys->apga);
+}
+
extern int ptrauth_prctl_reset_keys(struct task_struct *tsk, unsigned long
arg);
/*
@@ -88,6 +115,7 @@ do {
\
ptrauth_keys_switch(&(tsk)->thread.keys_user)
#else /* CONFIG_ARM64_PTR_AUTH */
+#define __no_ptrauth
#define ptrauth_prctl_reset_keys(tsk, arg) (-EINVAL)
#define ptrauth_strip_insn_pac(lr) (lr)
#define ptrauth_thread_init_user(tsk)
--
2.7.4
[PATCH] Bluetooth: hci_uart: Switch pty driver to slave side in tty_set_termios()
tty_set_termios() should be called with slave side of pty driver. So, If
tty driver is pty master, it needs to be switched to ->link.
Reported-by: syzbot+a950165cbb86bdd02...@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung
---
drivers/bluetooth/hci_ldisc.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index fbf7b4df23ab..90c5ea8c399b 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -299,10 +299,18 @@ static int hci_uart_send_frame(struct hci_dev *hdev,
struct sk_buff *skb)
return 0;
}
+/* If driver is pty master, return slave side */
+static struct tty_struct *hci_uart_get_real_tty(struct tty_struct *tty)
+{
+ return (tty->driver->type == TTY_DRIVER_TYPE_PTY &&
+tty->driver->subtype == PTY_TYPE_MASTER) ? tty->link : tty;
+}
+
/* Flow control or un-flow control the device */
void hci_uart_set_flow_control(struct hci_uart *hu, bool enable)
{
struct tty_struct *tty = hu->tty;
+ struct tty_struct *real_tty;
struct ktermios ktermios;
int status;
unsigned int set = 0;
@@ -314,11 +322,12 @@ void hci_uart_set_flow_control(struct hci_uart *hu, bool
enable)
return;
}
+ real_tty = hci_uart_get_real_tty(tty);
if (enable) {
/* Disable hardware flow control */
- ktermios = tty->termios;
+ ktermios = real_tty->termios;
ktermios.c_cflag &= ~CRTSCTS;
- status = tty_set_termios(tty, );
+ status = tty_set_termios(real_tty, );
BT_DBG("Disabling hardware flow control: %s",
status ? "failed" : "success");
@@ -350,9 +359,9 @@ void hci_uart_set_flow_control(struct hci_uart *hu, bool
enable)
BT_DBG("Setting RTS: %s", status ? "failed" : "success");
/* Re-enable hardware flow control */
- ktermios = tty->termios;
+ ktermios = real_tty->termios;
ktermios.c_cflag |= CRTSCTS;
- status = tty_set_termios(tty, );
+ status = tty_set_termios(real_tty, );
BT_DBG("Enabling hardware flow control: %s",
status ? "failed" : "success");
}
@@ -367,9 +376,10 @@ void hci_uart_set_speeds(struct hci_uart *hu, unsigned int
init_speed,
void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed)
{
- struct tty_struct *tty = hu->tty;
+ struct tty_struct *tty;
struct ktermios ktermios;
+ tty = hci_uart_get_real_tty(hu->tty);
ktermios = tty->termios;
ktermios.c_cflag &= ~CBAUD;
tty_termios_encode_baud_rate(, speed, speed);
--
2.17.1
Re: [PATCH v3 1/3] mfd: cros_ec: Add commands to control codec
On Mon, 28 Jan 2019, Cheng-yi Chiang wrote: > Hi Lee, > Could you please give Mark a tag so he can merge ? > The later patch for cros_ec_codec driver is pending on it. Apologies for not getting back to you. I was waiting to see if my late PR would be merged. It was, which means the tag you were asking for is actually upstream. Any issues, let me know. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH 2/2] iwlwifi: Use struct_size() in kzalloc
Use struct_size() in kzalloc instead of the 'regd_to_copy' Signed-off-by: YueHaibing --- drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c index 569cc50..cb9e722 100644 --- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c +++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c @@ -1093,7 +1093,7 @@ iwl_parse_nvm_mcc_info(struct device *dev, const struct iwl_cfg *cfg, const u8 *nvm_chan = cfg->nvm_type == IWL_NVM_EXT ? iwl_ext_nvm_channels : iwl_nvm_channels; struct ieee80211_regdomain *regd, *copy_rd; - int size_of_regd, regd_to_copy; + int size_of_regd; struct ieee80211_reg_rule *rule; struct regdb_ptrs *regdb_ptrs; enum nl80211_band band; @@ -1193,10 +1193,8 @@ iwl_parse_nvm_mcc_info(struct device *dev, const struct iwl_cfg *cfg, * Narrow down regdom for unused regulatory rules to prevent hole * between reg rules to wmm rules. */ - regd_to_copy = sizeof(struct ieee80211_regdomain) + - valid_rules * sizeof(struct ieee80211_reg_rule); - - copy_rd = kmemdup(regd, regd_to_copy, GFP_KERNEL); + copy_rd = kmemdup(regd, struct_size(regd, reg_rules, valid_rules), + GFP_KERNEL); if (!copy_rd) copy_rd = ERR_PTR(-ENOMEM); -- 2.7.4
[PATCH 1/2] iwlwifi: Use kmemdup instead of duplicating its function
Use kmemdup rather than duplicating its implementation
Signed-off-by: YueHaibing
---
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
index d9afedc..569cc50 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
@@ -1196,13 +1196,9 @@ iwl_parse_nvm_mcc_info(struct device *dev, const struct
iwl_cfg *cfg,
regd_to_copy = sizeof(struct ieee80211_regdomain) +
valid_rules * sizeof(struct ieee80211_reg_rule);
- copy_rd = kzalloc(regd_to_copy, GFP_KERNEL);
- if (!copy_rd) {
+ copy_rd = kmemdup(regd, regd_to_copy, GFP_KERNEL);
+ if (!copy_rd)
copy_rd = ERR_PTR(-ENOMEM);
- goto out;
- }
-
- memcpy(copy_rd, regd, regd_to_copy);
out:
kfree(regdb_ptrs);
--
2.7.4
Re: [PATCH v4 0/9] cpufreq: Add flag to auto-register as cooling device
On 28-01-19, 12:11, Amit Kucheria wrote: > Add a flag for cpufreq drivers to tell cpufreq core to auto-register > themselves as a thermal cooling device. > > There series converts over all the drivers except arm_big_little.c. > Tested on SDM845 with the qcom-cpufreq-hw driver. Only compile-tested the > others. > > Things needing fixing (but not a blocker for the series): > - Look at how to detect that we're not in IKS mode in arm_big_little's >.ready callback. > > Chnages since v3: > - Got rid of wrapper function to register/unregister cooling devices. >Directly call the function in cpufreq.c Acked-by: Viresh Kumar -- viresh
[PATCH v4 6/9] cpufreq: mediatek: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
---
drivers/cpufreq/mediatek-cpufreq.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/mediatek-cpufreq.c
b/drivers/cpufreq/mediatek-cpufreq.c
index eb8920d39818..9a937f4c63e7 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -14,7 +14,6 @@
#include
#include
-#include
#include
#include
#include
@@ -48,7 +47,6 @@ struct mtk_cpu_dvfs_info {
struct regulator *sram_reg;
struct clk *cpu_clk;
struct clk *inter_clk;
- struct thermal_cooling_device *cdev;
struct list_head list_head;
int intermediate_voltage;
bool need_voltage_tracking;
@@ -307,13 +305,6 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy
*policy,
#define DYNAMIC_POWER "dynamic-power-coefficient"
-static void mtk_cpufreq_ready(struct cpufreq_policy *policy)
-{
- struct mtk_cpu_dvfs_info *info = policy->driver_data;
-
- info->cdev = of_cpufreq_cooling_register(policy);
-}
-
static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
{
struct device *cpu_dev;
@@ -472,7 +463,6 @@ static int mtk_cpufreq_exit(struct cpufreq_policy *policy)
{
struct mtk_cpu_dvfs_info *info = policy->driver_data;
- cpufreq_cooling_unregister(info->cdev);
dev_pm_opp_free_cpufreq_table(info->cpu_dev, >freq_table);
return 0;
@@ -480,13 +470,13 @@ static int mtk_cpufreq_exit(struct cpufreq_policy *policy)
static struct cpufreq_driver mtk_cpufreq_driver = {
.flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
-CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
+CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
+CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = mtk_cpufreq_set_target,
.get = cpufreq_generic_get,
.init = mtk_cpufreq_init,
.exit = mtk_cpufreq_exit,
- .ready = mtk_cpufreq_ready,
.name = "mtk-cpufreq",
.attr = cpufreq_generic_attr,
};
--
2.17.1
[PATCH v4 8/9] cpufreq: scmi: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
Acked-by: Sudeep Holla
---
drivers/cpufreq/scmi-cpufreq.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 242c3370544e..b19e9d129f8f 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -11,7 +11,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -22,7 +21,6 @@
struct scmi_data {
int domain_id;
struct device *cpu_dev;
- struct thermal_cooling_device *cdev;
};
static const struct scmi_handle *handle;
@@ -185,7 +183,6 @@ static int scmi_cpufreq_exit(struct cpufreq_policy *policy)
{
struct scmi_data *priv = policy->driver_data;
- cpufreq_cooling_unregister(priv->cdev);
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
kfree(priv);
dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
@@ -193,17 +190,11 @@ static int scmi_cpufreq_exit(struct cpufreq_policy
*policy)
return 0;
}
-static void scmi_cpufreq_ready(struct cpufreq_policy *policy)
-{
- struct scmi_data *priv = policy->driver_data;
-
- priv->cdev = of_cpufreq_cooling_register(policy);
-}
-
static struct cpufreq_driver scmi_cpufreq_driver = {
.name = "scmi",
.flags = CPUFREQ_STICKY | CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
- CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+ CPUFREQ_NEED_INITIAL_FREQ_CHECK |
+ CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.attr = cpufreq_generic_attr,
.target_index = scmi_cpufreq_set_target,
@@ -211,7 +202,6 @@ static struct cpufreq_driver scmi_cpufreq_driver = {
.get= scmi_cpufreq_get_rate,
.init = scmi_cpufreq_init,
.exit = scmi_cpufreq_exit,
- .ready = scmi_cpufreq_ready,
};
static int scmi_cpufreq_probe(struct scmi_device *sdev)
--
2.17.1
[PATCH v4 9/9] cpufreq: scpi: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
Acked-by: Sudeep Holla
---
drivers/cpufreq/scpi-cpufreq.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c
index 99449738faa4..82420e8e5f0d 100644
--- a/drivers/cpufreq/scpi-cpufreq.c
+++ b/drivers/cpufreq/scpi-cpufreq.c
@@ -22,7 +22,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -34,7 +33,6 @@
struct scpi_data {
struct clk *clk;
struct device *cpu_dev;
- struct thermal_cooling_device *cdev;
};
static struct scpi_ops *scpi_ops;
@@ -186,7 +184,6 @@ static int scpi_cpufreq_exit(struct cpufreq_policy *policy)
{
struct scpi_data *priv = policy->driver_data;
- cpufreq_cooling_unregister(priv->cdev);
clk_put(priv->clk);
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
kfree(priv);
@@ -195,23 +192,16 @@ static int scpi_cpufreq_exit(struct cpufreq_policy
*policy)
return 0;
}
-static void scpi_cpufreq_ready(struct cpufreq_policy *policy)
-{
- struct scpi_data *priv = policy->driver_data;
-
- priv->cdev = of_cpufreq_cooling_register(policy);
-}
-
static struct cpufreq_driver scpi_cpufreq_driver = {
.name = "scpi-cpufreq",
.flags = CPUFREQ_STICKY | CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
- CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+ CPUFREQ_NEED_INITIAL_FREQ_CHECK |
+ CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.attr = cpufreq_generic_attr,
.get= scpi_cpufreq_get_rate,
.init = scpi_cpufreq_init,
.exit = scpi_cpufreq_exit,
- .ready = scpi_cpufreq_ready,
.target_index = scpi_cpufreq_set_target,
};
--
2.17.1
[PATCH v4 4/9] cpufreq: imx6q: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
---
drivers/cpufreq/imx6q-cpufreq.c | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 9fedf627e000..9935df234fa1 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -52,7 +51,6 @@ static struct clk_bulk_data clks[] = {
};
static struct device *cpu_dev;
-static struct thermal_cooling_device *cdev;
static bool free_opp;
static struct cpufreq_frequency_table *freq_table;
static unsigned int max_freq;
@@ -193,16 +191,6 @@ static int imx6q_set_target(struct cpufreq_policy *policy,
unsigned int index)
return 0;
}
-static void imx6q_cpufreq_ready(struct cpufreq_policy *policy)
-{
- cdev = of_cpufreq_cooling_register(policy);
-
- if (!cdev)
- dev_err(cpu_dev,
- "running cpufreq without cooling device: %ld\n",
- PTR_ERR(cdev));
-}
-
static int imx6q_cpufreq_init(struct cpufreq_policy *policy)
{
int ret;
@@ -214,22 +202,14 @@ static int imx6q_cpufreq_init(struct cpufreq_policy
*policy)
return ret;
}
-static int imx6q_cpufreq_exit(struct cpufreq_policy *policy)
-{
- cpufreq_cooling_unregister(cdev);
-
- return 0;
-}
-
static struct cpufreq_driver imx6q_cpufreq_driver = {
- .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+ .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK |
+CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = imx6q_set_target,
.get = cpufreq_generic_get,
.init = imx6q_cpufreq_init,
- .exit = imx6q_cpufreq_exit,
.name = "imx6q-cpufreq",
- .ready = imx6q_cpufreq_ready,
.attr = cpufreq_generic_attr,
.suspend = cpufreq_generic_suspend,
};
--
2.17.1
[PATCH 0/2] cleanup for iwlwifi
YueHaibing (2): iwlwifi: Use kmemdup instead of duplicating its function iwlwifi: Use struct_size() in kzalloc drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) -- 2.7.4
[PATCH v4 7/9] cpufreq: qoriq: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
---
drivers/cpufreq/qoriq-cpufreq.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
index 3d773f64b4df..b206e6cb55f0 100644
--- a/drivers/cpufreq/qoriq-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -31,7 +30,6 @@
struct cpu_data {
struct clk **pclk;
struct cpufreq_frequency_table *table;
- struct thermal_cooling_device *cdev;
};
/*
@@ -239,7 +237,6 @@ static int qoriq_cpufreq_cpu_exit(struct cpufreq_policy
*policy)
{
struct cpu_data *data = policy->driver_data;
- cpufreq_cooling_unregister(data->cdev);
kfree(data->pclk);
kfree(data->table);
kfree(data);
@@ -258,23 +255,15 @@ static int qoriq_cpufreq_target(struct cpufreq_policy
*policy,
return clk_set_parent(policy->clk, parent);
}
-
-static void qoriq_cpufreq_ready(struct cpufreq_policy *policy)
-{
- struct cpu_data *cpud = policy->driver_data;
-
- cpud->cdev = of_cpufreq_cooling_register(policy);
-}
-
static struct cpufreq_driver qoriq_cpufreq_driver = {
.name = "qoriq_cpufreq",
- .flags = CPUFREQ_CONST_LOOPS,
+ .flags = CPUFREQ_CONST_LOOPS |
+ CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.init = qoriq_cpufreq_cpu_init,
.exit = qoriq_cpufreq_cpu_exit,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = qoriq_cpufreq_target,
.get= cpufreq_generic_get,
- .ready = qoriq_cpufreq_ready,
.attr = cpufreq_generic_attr,
};
--
2.17.1
[PATCH v4 5/9] cpufreq: cpufreq-dt: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
---
drivers/cpufreq/cpufreq-dt.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index e58bfcb1169e..2a4c4ea7980b 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -13,7 +13,6 @@
#include
#include
-#include
#include
#include
#include
@@ -30,7 +29,6 @@
struct private_data {
struct opp_table *opp_table;
struct device *cpu_dev;
- struct thermal_cooling_device *cdev;
const char *reg_name;
bool have_static_opps;
};
@@ -301,7 +299,6 @@ static int cpufreq_exit(struct cpufreq_policy *policy)
{
struct private_data *priv = policy->driver_data;
- cpufreq_cooling_unregister(priv->cdev);
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
if (priv->have_static_opps)
dev_pm_opp_of_cpumask_remove_table(policy->related_cpus);
@@ -314,21 +311,14 @@ static int cpufreq_exit(struct cpufreq_policy *policy)
return 0;
}
-static void cpufreq_ready(struct cpufreq_policy *policy)
-{
- struct private_data *priv = policy->driver_data;
-
- priv->cdev = of_cpufreq_cooling_register(policy);
-}
-
static struct cpufreq_driver dt_cpufreq_driver = {
- .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+ .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
+CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = set_target,
.get = cpufreq_generic_get,
.init = cpufreq_init,
.exit = cpufreq_exit,
- .ready = cpufreq_ready,
.name = "cpufreq-dt",
.attr = cpufreq_dt_attr,
.suspend = cpufreq_generic_suspend,
--
2.17.1
[PATCH v4 3/9] cpufreq: qcom-hw: Register as a cpufreq cooling device
Add the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow the cpufreq core
to auto-register the driver as a cooling device.
Signed-off-by: Amit Kucheria
Reviewed-by: Matthias Kaehlcke
Tested-by: Matthias Kaehlcke
Reviewed-by: Stephen Boyd
---
drivers/cpufreq/qcom-cpufreq-hw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
index d83939a1b3d4..ed32849a3d40 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -231,7 +231,8 @@ static struct freq_attr *qcom_cpufreq_hw_attr[] = {
static struct cpufreq_driver cpufreq_qcom_hw_driver = {
.flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
- CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
+ CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
+ CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = qcom_cpufreq_hw_target_index,
.get= qcom_cpufreq_hw_get,
--
2.17.1
[PATCH v4 2/9] cpufreq: Auto-register the driver as a thermal cooling device if asked
All cpufreq drivers do similar things to register as a cooling device.
Provide a cpufreq driver flag so drivers can just ask the cpufreq core
to register the cooling device on their behalf. This allows us to get
rid of duplicated code in the drivers.
In order to allow this, we add a struct thermal_cooling_device pointer
to struct cpufreq_policy so that drivers don't need to store it in a
private data structure.
Suggested-by: Stephen Boyd
Suggested-by: Viresh Kumar
Signed-off-by: Amit Kucheria
Reviewed-by: Matthias Kaehlcke
Tested-by: Matthias Kaehlcke
---
drivers/cpufreq/cpufreq.c | 9 +
include/linux/cpufreq.h | 9 +
2 files changed, 18 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e35a886e00bc..29ed78b0b77b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1318,6 +1319,9 @@ static int cpufreq_online(unsigned int cpu)
if (cpufreq_driver->ready)
cpufreq_driver->ready(policy);
+ if (cpufreq_driver->flags & CPUFREQ_AUTO_REGISTER_COOLING_DEV)
+ policy->cdev = of_cpufreq_cooling_register(policy);
+
pr_debug("initialization complete\n");
return 0;
@@ -1405,6 +1409,11 @@ static int cpufreq_offline(unsigned int cpu)
goto unlock;
}
+ if (cpufreq_driver->flags & CPUFREQ_AUTO_REGISTER_COOLING_DEV) {
+ cpufreq_cooling_unregister(policy->cdev);
+ policy->cdev = NULL;
+ }
+
if (cpufreq_driver->stop_cpu)
cpufreq_driver->stop_cpu(policy);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index bd7fbd6a4478..55ca61a64fc2 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -151,6 +151,9 @@ struct cpufreq_policy {
/* For cpufreq driver's internal use */
void*driver_data;
+
+ /* Pointer to the cooling device if used for thermal mitigation */
+ struct thermal_cooling_device *cdev;
};
/* Only for ACPI */
@@ -386,6 +389,12 @@ struct cpufreq_driver {
*/
#define CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING BIT(6)
+/*
+ * Set by drivers that want the core to automatically register the cpufreq
+ * driver as a thermal cooling device.
+ */
+#define CPUFREQ_AUTO_REGISTER_COOLING_DEV BIT(7)
+
int cpufreq_register_driver(struct cpufreq_driver *driver_data);
int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
--
2.17.1
[PATCH v4 1/9] thermal: cpu_cooling: Require thermal core to be compiled in
The CPU cooling driver (cpu_cooling.c) allows the platform's cpufreq driver to register as a cooling device and cool down the platform by throttling the CPU frequency. In order to be able to auto-register a cpufreq driver as a cooling device from the cpufreq core, we need access to code inside cpu_cooling.c which, in turn, accesses code inside thermal core. CPU_FREQ is a bool while THERMAL is tristate. In some configurations (e.g. allmodconfig), CONFIG_THERMAL ends up as a module while CONFIG_CPU_FREQ is compiled in. This leads to following error: drivers/cpufreq/cpufreq.o: In function `cpufreq_offline': cpufreq.c:(.text+0x407c): undefined reference to `cpufreq_cooling_unregister' drivers/cpufreq/cpufreq.o: In function `cpufreq_online': cpufreq.c:(.text+0x70c0): undefined reference to `of_cpufreq_cooling_register' Given that platforms using CPU_THERMAL usually want it compiled-in so it is available early in boot, make CPU_THERMAL depend on THERMAL being compiled-in instead of allowing it to be a module. As a result of this change, get rid of the ugly (!CPU_THERMAL || THERMAL) dependency in all cpufreq drivers using CPU_THERMAL. Suggested-by: Rafael J. Wysocki Signed-off-by: Amit Kucheria --- drivers/cpufreq/Kconfig | 3 --- drivers/cpufreq/Kconfig.arm | 5 - drivers/thermal/Kconfig | 1 + 3 files changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 608af20a3494..b22e6bba71f1 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -207,8 +207,6 @@ comment "CPU frequency scaling drivers" config CPUFREQ_DT tristate "Generic DT based cpufreq driver" depends on HAVE_CLK && OF - # if CPU_THERMAL is on and THERMAL=m, CPUFREQ_DT cannot be =y: - depends on !CPU_THERMAL || THERMAL select CPUFREQ_DT_PLATDEV select PM_OPP help @@ -327,7 +325,6 @@ endif config QORIQ_CPUFREQ tristate "CPU frequency scaling driver for Freescale QorIQ SoCs" depends on OF && COMMON_CLK && (PPC_E500MC || ARM || ARM64) - depends on !CPU_THERMAL || THERMAL select CLK_QORIQ help This adds the CPUFreq driver support for Freescale QorIQ SoCs diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 688f10227793..ca8567c3152c 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -29,8 +29,6 @@ config ARM_ARMADA_37XX_CPUFREQ config ARM_BIG_LITTLE_CPUFREQ tristate "Generic ARM big LITTLE CPUfreq driver" depends on ARM_CPU_TOPOLOGY && HAVE_CLK - # if CPU_THERMAL is on and THERMAL=m, ARM_BIT_LITTLE_CPUFREQ cannot be =y - depends on !CPU_THERMAL || THERMAL select PM_OPP help This enables the Generic CPUfreq driver for ARM big.LITTLE platforms. @@ -38,7 +36,6 @@ config ARM_BIG_LITTLE_CPUFREQ config ARM_SCPI_CPUFREQ tristate "SCPI based CPUfreq driver" depends on ARM_SCPI_PROTOCOL && COMMON_CLK_SCPI - depends on !CPU_THERMAL || THERMAL help This adds the CPUfreq driver support for ARM platforms using SCPI protocol for CPU power management. @@ -93,7 +90,6 @@ config ARM_KIRKWOOD_CPUFREQ config ARM_MEDIATEK_CPUFREQ tristate "CPU Frequency scaling support for MediaTek SoCs" depends on ARCH_MEDIATEK && REGULATOR - depends on !CPU_THERMAL || THERMAL select PM_OPP help This adds the CPUFreq driver support for MediaTek SoCs. @@ -233,7 +229,6 @@ config ARM_SA1110_CPUFREQ config ARM_SCMI_CPUFREQ tristate "SCMI based CPUfreq driver" depends on ARM_SCMI_PROTOCOL || COMPILE_TEST - depends on !CPU_THERMAL || THERMAL select PM_OPP help This adds the CPUfreq driver support for ARM platforms using SCMI diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 30323426902e..58bb7d72dc2b 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -152,6 +152,7 @@ config CPU_THERMAL bool "generic cpu cooling support" depends on CPU_FREQ depends on THERMAL_OF + depends on THERMAL=y help This implements the generic cpu cooling mechanism through frequency reduction. An ACPI version of this already exists -- 2.17.1
[PATCH v4 0/9] cpufreq: Add flag to auto-register as cooling device
Add a flag for cpufreq drivers to tell cpufreq core to auto-register themselves as a thermal cooling device. There series converts over all the drivers except arm_big_little.c. Tested on SDM845 with the qcom-cpufreq-hw driver. Only compile-tested the others. Things needing fixing (but not a blocker for the series): - Look at how to detect that we're not in IKS mode in arm_big_little's .ready callback. Chnages since v3: - Got rid of wrapper function to register/unregister cooling devices. Directly call the function in cpufreq.c Changes since v2: - Get rid of #ifdef'ery and let the pointer exist in all cases - Get rid of (!CPU_THERMAL || THERMAL) dependency in all cpufreq drivers' Kconfig Changes since v1: - Fix compilation failures with allmodconfig - Get rid of #ifdef in cpufreq.c - Removed miscellaneous patches and sent them separately - Merged patches 1 and 2 from v1 Amit Kucheria (9): thermal: cpu_cooling: Require thermal core to be compiled in cpufreq: Auto-register the driver as a thermal cooling device if asked cpufreq: qcom-hw: Register as a cpufreq cooling device cpufreq: imx6q: Use auto-registration of thermal cooling device cpufreq: cpufreq-dt: Use auto-registration of thermal cooling device cpufreq: mediatek: Use auto-registration of thermal cooling device cpufreq: qoriq: Use auto-registration of thermal cooling device cpufreq: scmi: Use auto-registration of thermal cooling device cpufreq: scpi: Use auto-registration of thermal cooling device drivers/cpufreq/Kconfig| 3 --- drivers/cpufreq/Kconfig.arm| 5 - drivers/cpufreq/cpufreq-dt.c | 14 ++ drivers/cpufreq/cpufreq.c | 9 + drivers/cpufreq/imx6q-cpufreq.c| 24 ++-- drivers/cpufreq/mediatek-cpufreq.c | 14 ++ drivers/cpufreq/qcom-cpufreq-hw.c | 3 ++- drivers/cpufreq/qoriq-cpufreq.c| 15 ++- drivers/cpufreq/scmi-cpufreq.c | 14 ++ drivers/cpufreq/scpi-cpufreq.c | 14 ++ drivers/thermal/Kconfig| 1 + include/linux/cpufreq.h| 9 + 12 files changed, 33 insertions(+), 92 deletions(-) -- 2.17.1
Re: kernel panic due to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2830bf6f05fb3e05bc4743274b806c821807a684
On Mon 28-01-19 11:37:00, Mikhail Gavrilov wrote:
> > Linus, could you take the revert please?
> >
> > From 817b18d3db36a6900ca9043af8c1416c56358be3 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko
> > Date: Fri, 25 Jan 2019 19:08:58 +0100
> > Subject: [PATCH] Revert "mm, memory_hotplug: initialize struct pages for the
> > full memory section"
> >
> > This reverts commit 2830bf6f05fb3e05bc4743274b806c821807a684.
> >
> > The underlying assumption that one sparse section belongs into a single
> > numa node doesn't hold really. Robert Shteynfeld has reported a boot
> > failure. The boot log was not captured but his memory layout is as
> > follows:
> > [0.286954] Early memory node ranges
> > [0.286955] node 1: [mem 0x1000-0x00090fff]
> > [0.286955] node 1: [mem 0x0010-0xdbdf8fff]
> > [0.286956] node 1: [mem 0x0001-0x001423ff]
> > [0.286956] node 0: [mem 0x00142400-0x002023ff]
> >
> > This means that node0 starts in the middle of a memory section which is
> > also in node1. memmap_init_zone tries to initialize padding of a section
> > even when it is outside of the given pfn range because there are code
> > paths (e.g. memory hotplug) which assume that the full worth of memory
> > section is always initialized. In this particular case, though, such a
> > range is already intialized and most likely already managed by the page
> > allocator. Scribbling over those pages corrupts the internal state and
> > likely blows up when any of those pages gets used.
> >
> > Reported-by: Robert Shteynfeld
> > Fixes: 2830bf6f05fb ("mm, memory_hotplug: initialize struct pages for the
> > full memory section")
> > Cc: stable
> > Signed-off-by: Michal Hocko
> > ---
> > mm/page_alloc.c | 12
> > 1 file changed, 12 deletions(-)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index d295c9bc01a8..35fdde041f5c 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -5701,18 +5701,6 @@ void __meminit memmap_init_zone(unsigned long size,
> > int nid, unsigned long zone,
> > cond_resched();
> > }
> > }
> > -#ifdef CONFIG_SPARSEMEM
> > - /*
> > -* If the zone does not span the rest of the section then
> > -* we should at least initialize those pages. Otherwise we
> > -* could blow up on a poisoned page in some paths which depend
> > -* on full sections being initialized (e.g. memory hotplug).
> > -*/
> > - while (end_pfn % PAGES_PER_SECTION) {
> > - __init_single_page(pfn_to_page(end_pfn), end_pfn, zone,
> > nid);
> > - end_pfn++;
> > - }
> > -#endif
> > }
> >
> > #ifdef CONFIG_ZONE_DEVICE
>
> Michal, I suppose that revert the commit
> 2830bf6f05fb3e05bc4743274b806c821807a68 are return my issue
> https://marc.info/?l=linux-mm=154499704718428
> Are any other better approach would be proposed for fixing my issue?
As I've said above. We will need to remove the hardcoded
PAGES_PER_SECTION assumption from the hotplug code. Mikhail had a patch
which was dealing with the two specific sysfs file handlers and I will
build on top of that.
--
Michal Hocko
SUSE Labs
Re: kernel panic due to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2830bf6f05fb3e05bc4743274b806c821807a684
> Linus, could you take the revert please?
>
> From 817b18d3db36a6900ca9043af8c1416c56358be3 Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Fri, 25 Jan 2019 19:08:58 +0100
> Subject: [PATCH] Revert "mm, memory_hotplug: initialize struct pages for the
> full memory section"
>
> This reverts commit 2830bf6f05fb3e05bc4743274b806c821807a684.
>
> The underlying assumption that one sparse section belongs into a single
> numa node doesn't hold really. Robert Shteynfeld has reported a boot
> failure. The boot log was not captured but his memory layout is as
> follows:
> [0.286954] Early memory node ranges
> [0.286955] node 1: [mem 0x1000-0x00090fff]
> [0.286955] node 1: [mem 0x0010-0xdbdf8fff]
> [0.286956] node 1: [mem 0x0001-0x001423ff]
> [0.286956] node 0: [mem 0x00142400-0x002023ff]
>
> This means that node0 starts in the middle of a memory section which is
> also in node1. memmap_init_zone tries to initialize padding of a section
> even when it is outside of the given pfn range because there are code
> paths (e.g. memory hotplug) which assume that the full worth of memory
> section is always initialized. In this particular case, though, such a
> range is already intialized and most likely already managed by the page
> allocator. Scribbling over those pages corrupts the internal state and
> likely blows up when any of those pages gets used.
>
> Reported-by: Robert Shteynfeld
> Fixes: 2830bf6f05fb ("mm, memory_hotplug: initialize struct pages for the
> full memory section")
> Cc: stable
> Signed-off-by: Michal Hocko
> ---
> mm/page_alloc.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d295c9bc01a8..35fdde041f5c 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5701,18 +5701,6 @@ void __meminit memmap_init_zone(unsigned long size,
> int nid, unsigned long zone,
> cond_resched();
> }
> }
> -#ifdef CONFIG_SPARSEMEM
> - /*
> -* If the zone does not span the rest of the section then
> -* we should at least initialize those pages. Otherwise we
> -* could blow up on a poisoned page in some paths which depend
> -* on full sections being initialized (e.g. memory hotplug).
> -*/
> - while (end_pfn % PAGES_PER_SECTION) {
> - __init_single_page(pfn_to_page(end_pfn), end_pfn, zone, nid);
> - end_pfn++;
> - }
> -#endif
> }
>
> #ifdef CONFIG_ZONE_DEVICE
Michal, I suppose that revert the commit
2830bf6f05fb3e05bc4743274b806c821807a68 are return my issue
https://marc.info/?l=linux-mm=154499704718428
Are any other better approach would be proposed for fixing my issue?
--
Best Regards,
Mike Gavrilov.
Re: [PATCH -next] drm/xen-front: Drop pointless static qualifier in fb_destroy()
On 1/26/19 2:05 PM, YueHaibing wrote:
> There is no need to have the 'struct drm_framebuffer *fb' variable
> static since new value always be assigned before use it.
>
> Signed-off-by: YueHaibing
Good catch, thank you!
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> index 860da05..c2955d3 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> @@ -54,7 +54,7 @@ static void fb_destroy(struct drm_framebuffer *fb)
> const struct drm_mode_fb_cmd2 *mode_cmd)
> {
> struct xen_drm_front_drm_info *drm_info = dev->dev_private;
> - static struct drm_framebuffer *fb;
> + struct drm_framebuffer *fb;
> struct drm_gem_object *gem_obj;
> int ret;
>
>
>
>
>
>
Re: [Xen-devel] [PATCH] arch/arm/xen: Remove duplicate header
On Mon, Jan 14, 2019 at 4:08 PM Oleksandr Andrushchenko wrote: > > On 1/7/19 7:37 PM, Souptick Joarder wrote: > > Remove duplicate header which is included twice. > > > > Signed-off-by: Souptick Joarder > Reviewed-by: Oleksandr Andrushchenko Can we get this patch in queue for 5.1 ? > > --- > > arch/arm/xen/mm.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c > > index cb44aa2..e1d44b9 100644 > > --- a/arch/arm/xen/mm.c > > +++ b/arch/arm/xen/mm.c > > @@ -7,7 +7,6 @@ > > #include > > #include > > #include > > -#include > > #include > > #include > > >
Re: [PATCH 6/9] iommu/dma-iommu.c: Convert to use vm_insert_range
On Fri, Jan 11, 2019 at 8:37 PM Souptick Joarder wrote:
>
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
Any comment on this patch ?
> ---
> drivers/iommu/dma-iommu.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index d1b0475..802de67 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -622,17 +622,7 @@ struct page **iommu_dma_alloc(struct device *dev, size_t
> size, gfp_t gfp,
>
> int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct
> *vma)
> {
> - unsigned long uaddr = vma->vm_start;
> - unsigned int i, count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> - int ret = -ENXIO;
> -
> - for (i = vma->vm_pgoff; i < count && uaddr < vma->vm_end; i++) {
> - ret = vm_insert_page(vma, uaddr, pages[i]);
> - if (ret)
> - break;
> - uaddr += PAGE_SIZE;
> - }
> - return ret;
> + return vm_insert_range(vma, pages, PAGE_ALIGN(size) >> PAGE_SHIFT);
> }
>
> static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
> --
> 1.9.1
>
Re: [PATCH 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
On Fri, Jan 11, 2019 at 8:35 PM Souptick Joarder wrote:
>
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
Any comment on this patch ?
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 ++---
> 1 file changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index a8db758..c9e207f 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -221,26 +221,13 @@ static int rockchip_drm_gem_object_mmap_iommu(struct
> drm_gem_object *obj,
> struct vm_area_struct *vma)
> {
> struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
> - unsigned int i, count = obj->size >> PAGE_SHIFT;
> + unsigned int count = obj->size >> PAGE_SHIFT;
> unsigned long user_count = vma_pages(vma);
> - unsigned long uaddr = vma->vm_start;
> - unsigned long offset = vma->vm_pgoff;
> - unsigned long end = user_count + offset;
> - int ret;
>
> if (user_count == 0)
> return -ENXIO;
> - if (end > count)
> - return -ENXIO;
>
> - for (i = offset; i < end; i++) {
> - ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
> - if (ret)
> - return ret;
> - uaddr += PAGE_SIZE;
> - }
> -
> - return 0;
> + return vm_insert_range(vma, rk_obj->pages, count);
> }
>
> static int rockchip_drm_gem_object_mmap_dma(struct drm_gem_object *obj,
> --
> 1.9.1
>
[PATCH v8 1/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver
Add a driver for Renesas R-Car Gen3 RPC-IF SPI controller. Signed-off-by: Mason Yang Signed-off-by: Sergei Shtylyov --- drivers/spi/Kconfig | 6 + drivers/spi/Makefile | 1 + drivers/spi/spi-renesas-rpc.c | 804 ++ 3 files changed, 811 insertions(+) create mode 100644 drivers/spi/spi-renesas-rpc.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 9f89cb1..6ad1782 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -544,6 +544,12 @@ config SPI_RSPI help SPI driver for Renesas RSPI and QSPI blocks. +config SPI_RENESAS_RPC + tristate "Renesas R-Car Gen3 RPC-IF controller" + depends on ARCH_RENESAS || COMPILE_TEST + help + SPI driver for Renesas R-Car Gen3 RPC-IF. + config SPI_QCOM_QSPI tristate "QTI QSPI controller" depends on ARCH_QCOM diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index f296270..9150732 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -84,6 +84,7 @@ obj-$(CONFIG_SPI_QUP) += spi-qup.o obj-$(CONFIG_SPI_ROCKCHIP) += spi-rockchip.o obj-$(CONFIG_SPI_RB4XX)+= spi-rb4xx.o obj-$(CONFIG_SPI_RSPI) += spi-rspi.o +obj-$(CONFIG_SPI_RENESAS_RPC) += spi-renesas-rpc.o obj-$(CONFIG_SPI_S3C24XX) += spi-s3c24xx-hw.o spi-s3c24xx-hw-y := spi-s3c24xx.o spi-s3c24xx-hw-$(CONFIG_SPI_S3C24XX_FIQ) += spi-s3c24xx-fiq.o diff --git a/drivers/spi/spi-renesas-rpc.c b/drivers/spi/spi-renesas-rpc.c new file mode 100644 index 000..ea12017 --- /dev/null +++ b/drivers/spi/spi-renesas-rpc.c @@ -0,0 +1,804 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2018 ~ 2019 Renesas Solutions Corp. +// Copyright (C) 2018 Macronix International Co., Ltd. +// +// R-Car Gen3 RPC-IF SPI/QSPI/Octa driver +// +// Authors: +// Mason Yang +// + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define RPC_CMNCR 0x // R/W +#define RPC_CMNCR_MD BIT(31) +#define RPC_CMNCR_SFDE BIT(24) // undocumented bit but must be set +#define RPC_CMNCR_MOIIO3(val) (((val) & 0x3) << 22) +#define RPC_CMNCR_MOIIO2(val) (((val) & 0x3) << 20) +#define RPC_CMNCR_MOIIO1(val) (((val) & 0x3) << 18) +#define RPC_CMNCR_MOIIO0(val) (((val) & 0x3) << 16) +#define RPC_CMNCR_MOIIO_HIZ(RPC_CMNCR_MOIIO0(3) | RPC_CMNCR_MOIIO1(3) | \ +RPC_CMNCR_MOIIO2(3) | RPC_CMNCR_MOIIO3(3)) +#define RPC_CMNCR_IO3FV(val) (((val) & 0x3) << 14) // undocumented +#define RPC_CMNCR_IO2FV(val) (((val) & 0x3) << 12) // undocumented +#define RPC_CMNCR_IO0FV(val) (((val) & 0x3) << 8) +#define RPC_CMNCR_IOFV_HIZ (RPC_CMNCR_IO0FV(3) | RPC_CMNCR_IO2FV(3) | \ +RPC_CMNCR_IO3FV(3)) +#define RPC_CMNCR_BSZ(val) (((val) & 0x3) << 0) + +#define RPC_SSLDR 0x0004 // R/W +#define RPC_SSLDR_SPNDL(d) (((d) & 0x7) << 16) +#define RPC_SSLDR_SLNDL(d) (((d) & 0x7) << 8) +#define RPC_SSLDR_SCKDL(d) (((d) & 0x7) << 0) + +#define RPC_DRCR 0x000C // R/W +#define RPC_DRCR_SSLN BIT(24) +#define RPC_DRCR_RBURST(v) v) - 1) & 0x1F) << 16) +#define RPC_DRCR_RCF BIT(9) +#define RPC_DRCR_RBE BIT(8) +#define RPC_DRCR_SSLE BIT(0) + +#define RPC_DRCMR 0x0010 // R/W +#define RPC_DRCMR_CMD(c) (((c) & 0xFF) << 16) +#define RPC_DRCMR_OCMD(c) (((c) & 0xFF) << 0) + +#define RPC_DREAR 0x0014 // R/W +#define RPC_DREAR_EAC(c) (((c) & 0x7) << 0) + +#define RPC_DROPR 0x0018 // R/W + +#define RPC_DRENR 0x001C // R/W +#define RPC_DRENR_CDB(o) (u32)o) & 0x3) << 30)) +#define RPC_DRENR_OCDB(o) (((o) & 0x3) << 28) +#define RPC_DRENR_ADB(o) (((o) & 0x3) << 24) +#define RPC_DRENR_OPDB(o) (((o) & 0x3) << 20) +#define RPC_DRENR_DRDB(o) (((o) & 0x3) << 16) +#define RPC_DRENR_DME BIT(15) +#define RPC_DRENR_CDE BIT(14) +#define RPC_DRENR_OCDE BIT(12) +#define RPC_DRENR_ADE(v) (((v) & 0xF) << 8) +#define RPC_DRENR_OPDE(v) (((v) & 0xF) << 4) + +#define RPC_SMCR 0x0020 // R/W +#define RPC_SMCR_SSLKP BIT(8) +#define RPC_SMCR_SPIRE BIT(2) +#define RPC_SMCR_SPIWE BIT(1) +#define RPC_SMCR_SPIE BIT(0) + +#define RPC_SMCMR 0x0024 // R/W +#define RPC_SMCMR_CMD(c) (((c) & 0xFF) << 16) +#define RPC_SMCMR_OCMD(c) (((c) & 0xFF) << 0) + +#define RPC_SMADR 0x0028 // R/W +#define RPC_SMOPR 0x002C // R/W +#define RPC_SMOPR_OPD3(o) (((o) & 0xFF) << 24) +#define RPC_SMOPR_OPD2(o) (((o) & 0xFF) << 16) +#define RPC_SMOPR_OPD1(o) (((o) & 0xFF) << 8) +#define RPC_SMOPR_OPD0(o) (((o) & 0xFF) << 0) + +#define
[PATCH v8 2/2] dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller bindings
Document the bindings used by the Renesas R-Car Gen3 RPC-IF controller.
Signed-off-by: Mason Yang
---
.../devicetree/bindings/spi/spi-renesas-rpc.txt| 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
new file mode 100644
index 000..7dff7e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
@@ -0,0 +1,40 @@
+Renesas R-Car Gen3 RPC-IF controller Device Tree Bindings
+
+
+Required properties:
+- compatible: should be an SoC-specific compatible value, followed by
+ "renesas,rcar-gen3-rpc" as a fallback.
+ supported SoC-specific values are:
+ "renesas,r8a77995-rpc" (R-Car D3)
+- reg: should contain three register areas:
+ first for the base address of rpc-if registers,
+ second for the direct mapping read mode and
+ third for the write buffer area.
+- reg-names: should contain "regs", "dirmap" and "wbuf"
+- clocks: should contain 1 entries for the module's clock
+- clock-names: should contain "rpc"
+- #address-cells: should be 1
+- #size-cells: should be 0
+
+Example:
+
+ rpc: rpc@ee20 {
+ compatible = "renesas,r8a77995-rpc", "renesas,rcar-gen3-rpc";
+ reg = <0 0xee20 0 0x200>, <0 0x0800 0 0x400>,
+ <0 0xee208000 0 0x100>;
+ reg-names = "regs", "dirmap", "wbuf";
+ clocks = < CPG_MOD 917>;
+ clock-names = "rpc";
+ power-domains = < R8A77995_PD_ALWAYS_ON>;
+ resets = < 917>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+ };
--
1.9.1
[PATCH v8 0/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI driver
Hi Mark, v8 patch including: 1) Supported SoC-specific values in DTS. 2) Rename device node name as flash. v7 patch is according to Geert and Sergei's comments: 1) Add all R-Car Gen3 model in dts. 2) patch rpc-if child node search. 3) minror coding style. v6 patch is accroding to Geert, Marek and Sergei's comments: 1) spi_controller for new code. 2) "renesas,rcar-gen3-rpc" instead of "renesas,r8a77995-rpc." 3) patch external address read mode w/o u64 readq(). 4) patch dts for write buffer & drop "renesas,rpc-mode". 5) coding style and so on. v5 patch is accroding to Sergei's comments: 1) Read 6 bytes ID from Sergei's patch. 2) regmap_update_bits(). 3) C++ style comment. v4 patch is according to Sergei's comments including: 1) Drop soc_device_match(). 2) Drop unused RPC registers. 3) Use ilog2() instead of fls(). 4) Patch read 6 bytes ID w/ one command. 5) Coding style and so on. v3 patch is according to Marek and Geert's comments including: 1) soc_device_mach() to set up RPC_PHYCNT_STRTIM. 2) get_unaligned(). 3) rpc-mode for rpi-spi-flash or rpc-hyperflash. 4) coding style and so on. v2 patch including: 1) remove RPC clock enable/dis-able control, 2) patch run time PM. 3) add RPC module software reset, 4) add regmap. 5) other coding style and so on. thanks for your review. best regards, Mason Mason Yang (2): spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller bindings .../devicetree/bindings/spi/spi-renesas-rpc.txt| 40 + drivers/spi/Kconfig| 6 + drivers/spi/Makefile | 1 + drivers/spi/spi-renesas-rpc.c | 804 + 4 files changed, 851 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt create mode 100644 drivers/spi/spi-renesas-rpc.c -- 1.9.1
[PATCH V3] sched/cpufreq: calculate util / cap in advance in map_util_freq()
From: "vincent.wang"
When a task that is in_iowait state is enqueued, cpufreq_update_util()
will be invoked with SCHED_CPUFREQ_IOWAIT flag. In this case,the value
of util and cap, which are parameters used in map_util_freq(), will be
cpu frequency, instead of cpu util and capactiy.
For some 32bit architectures, the size of unsigned long is 32. When
calculating freq, there may be an overflow error in this expression:
freq = (freq + (freq >> 2)) * util / cap;
This patch will fix this overflow risk by calulating util / cap in advance,
whether they be frequency or util.
Signed-off-by: Vincent Wang
Signed-off-by: Chunyan Zhang
---
Changes from v2:
* Fix for 32bit architectures only.
Changes from V1:
* Rebased onto v5.0-rc1;
* Addressed comments from Quentin Perret.
---
include/linux/sched/cpufreq.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/sched/cpufreq.h b/include/linux/sched/cpufreq.h
index afa940cd50dc..22128a6c9c91 100644
--- a/include/linux/sched/cpufreq.h
+++ b/include/linux/sched/cpufreq.h
@@ -24,7 +24,15 @@ void cpufreq_remove_update_util_hook(int cpu);
static inline unsigned long map_util_freq(unsigned long util,
unsigned long freq, unsigned long cap)
{
+#ifdef CONFIG_64BIT
return (freq + (freq >> 2)) * util / cap;
+#else
+ /*
+* calculate util / cap in advance to prevent an overflow error
+* on 32bit architectures
+*/
+ return ((freq + (freq >> 2)) * ((util << 10) / cap)) >> 10;
+#endif
}
#endif /* CONFIG_CPU_FREQ */
--
2.17.1
RE: [PATCH] KVM: x86: Sync the pending Posted-Interrupts
> > Some Posted-Interrupts from passthrough devices may be lost or
> > overwritten when the vCPU is in runnable state.
> >
> > The SN (Suppress Notification) of PID (Posted Interrupt Descriptor)
> > will be set when the vCPU is preempted (vCPU in KVM_MP_STATE_RUNNABLE
> > state but not running on physical CPU). If a posted interrupt coming
> > at this time, the irq remmaping facility will set the bit of PIR
> > (Posted Interrupt Requests) but ON (Outstanding Notification).
>
> s/but ON/and ON is set too/?
Sorry. If the interrupt remapping facility received a interrupt from device but
the current SN bit is 1, the remapping facility will not set ON and not send
notification event to CPU, just set the corresponding bit of PIR.
Thanks,
Luwei Kang
> > So this interrupt can't be sync to APIC virtualization register and
> > will not be handled by Guest because ON is zero.
> >
> > Signed-off-by: Luwei Kang
> > ---
> > arch/x86/kvm/vmx/vmx.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index
> > f6915f1..820a03b 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -6048,7 +6048,7 @@ static int vmx_sync_pir_to_irr(struct kvm_vcpu *vcpu)
> > bool max_irr_updated;
> >
> > WARN_ON(!vcpu->arch.apicv_active);
> > - if (pi_test_on(>pi_desc)) {
> > + if (!bitmap_empty((unsigned long *)vmx->pi_desc.pir, NR_VECTORS)) {
> > pi_clear_on(>pi_desc);
> > /*
> > * IOMMU can write to PIR.ON, so the barrier matters even on UP.
[PATCH v5 3/5] dt-bindings: dma: fsl-imx-sdma: add fsl,imx8mq to the accepted compatible node
Add an fsl,imx8mq compatible string Signed-off-by: Angus Ainslie (Purism) Reviewed-by: Lucas Stach --- Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt index 3c9a57a8443b..9d8bbac27d8b 100644 --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt @@ -9,6 +9,7 @@ Required properties: "fsl,imx53-sdma" "fsl,imx6q-sdma" "fsl,imx7d-sdma" + "fsl,imx8mq-sdma" The -to variants should be preferred since they allow to determine the correct ROM script addresses needed for the driver to work without additional firmware. -- 2.17.1
[PATCH v5 0/5] dmaengine: imx-sdma: add the sdma engine to the imx8mq
Add sdma support for the imx8mq Changes since V4 Builds against 5.0-rc4. Dropped device tree additions, will send a separate patch. Fixed sdma1 alignement. Dropped phandles in favour of of_nodes. Refactored SDMA_H_CONFIG register fix. Changes since V3 Builds against 5.0-rc3. Dropped sdma device index matching in favour of phandles. Corrected subsytem name to dmaengine Devicetree fixes. Fixed SDMA_H_CONFIG register bug. Changes since V2 Dropped device tree bindings and added clock ratio check. Fixed bug where incorrect sdma device was selected. Added new compatible string for "fsl,imx8mq-sdma" Changes since V1 Fixed to build against v5.0-rc2 Angus Ainslie (Purism) (5): dmaengine: imx-sdma: add clock ratio 1:1 check dmaengine: imx-sdma: add imx8mq sdma compatible parts dt-bindings: dma: fsl-imx-sdma: add fsl,imx8mq to the accepted compatible node dmaengine: imx-sdma: add a test for imx8mq multi sdma devices dmaengine: imx-sdma: fix consistent dma test failures .../devicetree/bindings/dma/fsl-imx-sdma.txt | 1 + drivers/dma/imx-sdma.c| 29 --- include/linux/platform_data/dma-imx.h | 1 + 3 files changed, 27 insertions(+), 4 deletions(-) -- 2.17.1
[PATCH v5 1/5] dmaengine: imx-sdma: add clock ratio 1:1 check
On i.mx8 mscale B0 chip, AHB/SDMA clock ratio 2:1 can't be supportted,
since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach
to 500Mhz, so use 1:1 instead.
Based on NXP commit MLK-16841-1 by Robin Gong
Signed-off-by: Angus Ainslie (Purism)
---
drivers/dma/imx-sdma.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 0b3a67ff8e82..757fad2fbfae 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -440,6 +440,8 @@ struct sdma_engine {
unsigned intirq;
dma_addr_t bd0_phys;
struct sdma_buffer_descriptor *bd0;
+ /* clock ratio for AHB:SDMA core. 1:1 is 1, 2:1 is 0*/
+ boolclk_ratio;
};
static int sdma_config_write(struct dma_chan *chan,
@@ -662,8 +664,11 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
dev_err(sdma->dev, "Timeout waiting for CH0 ready\n");
/* Set bits of CONFIG register with dynamic context switching */
- if (readl(sdma->regs + SDMA_H_CONFIG) == 0)
- writel_relaxed(SDMA_H_CONFIG_CSM, sdma->regs + SDMA_H_CONFIG);
+ reg = readl(sdma->regs + SDMA_H_CONFIG);
+ if ((reg & SDMA_H_CONFIG_CSM) == 0) {
+ reg |= SDMA_H_CONFIG_CSM;
+ writel_relaxed(reg, sdma->regs + SDMA_H_CONFIG);
+ }
return ret;
}
@@ -1840,6 +1845,9 @@ static int sdma_init(struct sdma_engine *sdma)
if (ret)
goto disable_clk_ipg;
+ if (clk_get_rate(sdma->clk_ahb) == clk_get_rate(sdma->clk_ipg))
+ sdma->clk_ratio = 1;
+
/* Be sure SDMA has not started yet */
writel_relaxed(0, sdma->regs + SDMA_H_C0PTR);
@@ -1880,8 +1888,10 @@ static int sdma_init(struct sdma_engine *sdma)
writel_relaxed(0x4050, sdma->regs + SDMA_CHN0ADDR);
/* Set bits of CONFIG register but with static context switching */
- /* FIXME: Check whether to set ACR bit depending on clock ratios */
- writel_relaxed(0, sdma->regs + SDMA_H_CONFIG);
+ if (sdma->clk_ratio)
+ writel_relaxed(SDMA_H_CONFIG_ACR, sdma->regs + SDMA_H_CONFIG);
+ else
+ writel_relaxed(0, sdma->regs + SDMA_H_CONFIG);
writel_relaxed(ccb_phys, sdma->regs + SDMA_H_C0PTR);
--
2.17.1
[PATCH v5 4/5] dmaengine: imx-sdma: add a test for imx8mq multi sdma devices
On i.mx8mq, there are two sdma instances, and the common dma framework
will get a channel dynamically from any available sdma instance whether
it's the first sdma device or the second sdma device. Some IPs like
SAI only work with sdma2 not sdma1. To make sure the sdma channel is from
the correct sdma device, use the node pointer to match.
Signed-off-by: Angus Ainslie (Purism)
---
drivers/dma/imx-sdma.c| 6 ++
include/linux/platform_data/dma-imx.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index c4db4fe6bcc9..d5f86becf59e 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1918,11 +1918,16 @@ static int sdma_init(struct sdma_engine *sdma)
static bool sdma_filter_fn(struct dma_chan *chan, void *fn_param)
{
struct sdma_channel *sdmac = to_sdma_chan(chan);
+ struct sdma_engine *sdma = sdmac->sdma;
struct imx_dma_data *data = fn_param;
if (!imx_dma_is_general_purpose(chan))
return false;
+ /* return false if it's not the right device */
+ if (sdma->dev->of_node != data->of_node)
+ return false;
+
sdmac->data = *data;
chan->private = >data;
@@ -1950,6 +1955,7 @@ static struct dma_chan *sdma_xlate(struct of_phandle_args
*dma_spec,
* be set to sdmac->event_id1.
*/
data.dma_request2 = 0;
+ data.of_node = ofdma->of_node;
return dma_request_channel(mask, sdma_filter_fn, );
}
diff --git a/include/linux/platform_data/dma-imx.h
b/include/linux/platform_data/dma-imx.h
index 7d964e787299..9daea8d42a10 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -55,6 +55,7 @@ struct imx_dma_data {
int dma_request2; /* secondary DMA request line */
enum sdma_peripheral_type peripheral_type;
int priority;
+ struct device_node *of_node;
};
static inline int imx_dma_is_ipu(struct dma_chan *chan)
--
2.17.1
[PATCH v5 2/5] dmaengine: imx-sdma: add imx8mq sdma compatible parts
This is identical to the imx7d.
Signed-off-by: Angus Ainslie (Purism)
---
drivers/dma/imx-sdma.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 757fad2fbfae..c4db4fe6bcc9 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -578,6 +578,9 @@ static const struct platform_device_id sdma_devtypes[] = {
}, {
.name = "imx7d-sdma",
.driver_data = (unsigned long)_imx7d,
+ }, {
+ .name = "imx8mq-sdma",
+ .driver_data = (unsigned long)_imx7d,
}, {
/* sentinel */
}
@@ -592,6 +595,7 @@ static const struct of_device_id sdma_dt_ids[] = {
{ .compatible = "fsl,imx31-sdma", .data = _imx31, },
{ .compatible = "fsl,imx25-sdma", .data = _imx25, },
{ .compatible = "fsl,imx7d-sdma", .data = _imx7d, },
+ { .compatible = "fsl,imx8mq-sdma", .data = _imx7d, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sdma_dt_ids);
--
2.17.1
[PATCH v5 5/5] dmaengine: imx-sdma: fix consistent dma test failures
Without the copy being aligned sdma1 fails ~10% of the time Signed-off-by: Angus Ainslie (Purism) --- drivers/dma/imx-sdma.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index d5f86becf59e..88910ec09568 100644 --- a/drivers/dma/imx-sdma.c +++ b/drivers/dma/imx-sdma.c @@ -2118,6 +2118,7 @@ static int sdma_probe(struct platform_device *pdev) sdma->dma_device.device_prep_dma_memcpy = sdma_prep_memcpy; sdma->dma_device.device_issue_pending = sdma_issue_pending; sdma->dma_device.dev->dma_parms = >dma_parms; + sdma->dma_device.copy_align = 2; dma_set_max_seg_size(sdma->dma_device.dev, SDMA_BD_MAX_CNT); platform_set_drvdata(pdev, sdma); -- 2.17.1
Re: [PATCH] ALSA: hda/tegra: enable clock during probe
On 1/25/2019 7:34 PM, Jon Hunter wrote:
On 25/01/2019 13:58, Takashi Iwai wrote:
On Fri, 25 Jan 2019 14:26:27 +0100,
Jon Hunter wrote:
On 25/01/2019 12:40, Takashi Iwai wrote:
On Fri, 25 Jan 2019 12:36:00 +0100,
Jon Hunter wrote:
On 24/01/2019 19:08, Takashi Iwai wrote:
On Thu, 24 Jan 2019 18:36:43 +0100,
Sameer Pujar wrote:
If CONFIG_PM is disabled or runtime PM calls are forbidden, the clocks
will not be ON. This could cause issue during probe, where hda init
setup is done. This patch checks whether runtime PM is enabled or not.
If disabled, clocks are enabled in probe() and disabled in remove()
This patch does following minor changes as cleanup,
* return code check for pm_runtime_get_sync() to take care of failure
and exit gracefully.
* In remove path runtime PM is disabled before calling snd_card_free().
* hda_tegra_disable_clocks() is moved out of CONFIG_PM_SLEEP check.
* runtime PM callbacks moved out of CONFIG_PM check
Signed-off-by: Sameer Pujar
Reviewed-by: Ravindra Lokhande
Reviewed-by: Jon Hunter
(snip)
@@ -555,6 +553,13 @@ static int hda_tegra_probe(struct platform_device *pdev)
if (!azx_has_pm_runtime(chip))
pm_runtime_forbid(hda->dev);
+ /* explicit resume if runtime PM is disabled */
+ if (!pm_runtime_enabled(hda->dev)) {
+ err = hda_tegra_runtime_resume(hda->dev);
+ if (err)
+ goto out_free;
+ }
+
schedule_work(>probe_work);
Calling runtime_resume here is really confusing...
Why? IMO it is better to have a single handler for resuming the device
and so if RPM is not enabled we call the handler directly. This is what
we have been advised to do in the past and do in other drivers. See ...
The point is that we're not "resuming" anything there. It's in the
early probe stage, and the device state is uninitialized, not really
suspended. It'd end up with just calling the same helper
(hda_tegra_enable_clocks()), though.
Yes and you can make the same argument for every driver that calls
pm_runtime_get_sync() during probe to turn on clocks, handle resets,
etc, because at the end of the day the very first call to
pm_runtime_get_sync() invokes the runtime_resume callback, when we have
never been suspended.
Although there are some magical pm_runtime_*() in some places, most of
such pm_runtime_get_sync() is for the actual runtime PM management (to
prevent the runtime suspend), while the code above is for explicitly
setting up something for non-PM cases.
And if pm_runtime_get_sync() is obviously superfluous, we should
remove such calls. Really.
Yes agree.
Yes at the end of the day it is the same and given that we have done
this elsewhere I think it is good to be consistent if/where we can.
The code becomes less readable, and that's a good reason against it :)
I don't its less readable. However, I do think it is less error prone :-)
Do we have a consensus here? Request others to provide opinions to help
close on this.
Thanks,
Sameer.
Jon
RE: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller
Hi Boris & Miquel, Could you please provide your thoughts on this driver to support HW-ECC? As I said previously, there is no way to detect errors beyond N bit. I am ok to update the driver based on your inputs. Thanks, Naga Sureshkumar Relli > -Original Message- > From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of > Naga > Sureshkumar Relli > Sent: Friday, December 21, 2018 1:06 PM > To: Miquel Raynal > Cc: r...@kernel.org; marek.va...@gmail.com; rich...@nod.at; > martin.lund@keep-it- > simple.com; linux-kernel@vger.kernel.org; Boris Brezillon > ; > linux-...@lists.infradead.org; nagasures...@gmail.com; Michal Simek > ; computersforpe...@gmail.com; dw...@infradead.org > Subject: RE: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for > Arasan > NAND Flash Controller > > Hi Miquel, > > > -Original Message- > > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] > > Sent: Wednesday, December 19, 2018 7:57 PM > > To: Naga Sureshkumar Relli > > Cc: Boris Brezillon ; r...@kernel.org; > > rich...@nod.at; linux-kernel@vger.kernel.org; marek.va...@gmail.com; > > linux-...@lists.infradead.org; nagasures...@gmail.com; Michal Simek > > ; computersforpe...@gmail.com; > > dw...@infradead.org; martin.l...@keep-it-simple.com > > Subject: Re: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support > > for Arasan NAND Flash Controller > > > > Hi Naga, > > > > + Martin > > > > Naga Sureshkumar Relli wrote on Tue, 18 Dec 2018 > > 05:33:53 +: > > > > > Hi Miquel, > > > > > > > -Original Message- > > > > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] > > > > Sent: Monday, December 17, 2018 10:11 PM > > > > To: Naga Sureshkumar Relli > > > > Cc: Boris Brezillon ; > > > > r...@kernel.org; rich...@nod.at; linux- ker...@vger.kernel.org; > > > > marek.va...@gmail.com; linux-...@lists.infradead.org; > > > > nagasures...@gmail.com; Michal Simek ; > > > > computersforpe...@gmail.com; dw...@infradead.org > > > > Subject: Re: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add > > > > support for Arasan NAND Flash Controller > > > > > > > > Hi Naga, > > > > > > > > [...] > > > > > > > > > Inserted biterror @ 48/7 > > > > > Successfully corrected 25 bit errors per subpage Inserted > > > > > biterror @ > > > > > 50/7 ECC failure, invalid data despite read success > > > > > root@xilinx-zc1751-dc2-2018_1:~# > > > > > > > > > > But even in this case also, driver is saying ECC failure but read > > > > > success. > > > > > That means controller is able to detect errors on read page up to 24 > > > > > bit only. > > > > > After that there is no way to say to the upper layers that the > > > > > page is bad because of the > > > > limitation in the controller. > > > > > > > > This is more than a "limitation", the design is broken. I am not > > > > sure how to support such controller, and I am not sure if we even want > > > > to. > > > > > > The number of errors that are correctable is limited by a parameter > > > 't'(total number of errors), If there is a condition that the number > > > of errors greater than 't', > > then the controller won't be able to detect that. > > > I guess this concept is same for other controllers as well. > > > In Arasan it is limited to 24-bit. > > > > > > Even, in case of Hamming, it is 1-bit error correction and 2-bit error > > > detection. > > > What will happen if there are multiple errors(greater than 2-bit)? > > > > Ok let's use the Hamming comparison in your ECC engine case. > > > > -> hamming: > > * 0 bf: everything is fine > > * 1 bf: will be detected, corrected, signaled > > * 2 bf: will be detected, not corrected, signaled > > * 3+ bf: don't care > > > > -> BCH: > > * 0 bf: everything is fine > > * 1-24 bf: will be detected, corrected, signaled > > * 25 bf: everything is fine > > * 26+ bf: don't care > > > > Do you see the problem? > No. > > > > In the 25 bf case, the controller is reporting that everything went > > fine while it should report that it detected an uncorrectable situation. > > > > Here are two leads to solve this issue, please investigate them both: > > 1/ Talk to your colleagues that developed the RTL, ask if there is a > >hidden/reserved bit for that purpose that is not documented. > I spoke to RTL guys, there is nothing hidden/reserved bit for this purpose. > I tried reading the status registers reserved bits, but they are raz(read as > zero) > > > 2/ Search for a status in the registers that might indicate that an > >error occurred, for instance "0 bf corrected" and "bf have been > >detected". > I tried reading status registers and other registers as well, but no luck. > > > > NB: I know that, with a BCH ECC engine, error detection at (strength + > > 1) is not 100% sure but statistically it will almost always be > > detected and in this case we need the controller to warn the user! > Ok, I understood now. > > Thanks, > Naga Sureshkumar Relli > > > > > > Thanks, > > Miquèl >
Re: [PATCH] iwlwifi: Use kmemdup instead of duplicating its function
On 2019/1/27 5:24, Joe Perches wrote:
> On Sat, 2019-01-26 at 20:42 +0800, YueHaibing wrote:
>> Use kmemdup rather than duplicating its implementation
> []
>> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
>> b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
> []
>> @@ -1196,13 +1196,9 @@ iwl_parse_nvm_mcc_info(struct device *dev, const
>> struct iwl_cfg *cfg,
>> regd_to_copy = sizeof(struct ieee80211_regdomain) +
>> valid_rules * sizeof(struct ieee80211_reg_rule);
>> -copy_rd = kzalloc(regd_to_copy, GFP_KERNEL);
>> -if (!copy_rd) {
>> +copy_rd = kmemdup(regd, regd_to_copy, GFP_KERNEL);
>
> This should probably be
>
> copy_rd = kmemdup(regd, struct_size(regd, reg_rules, valid_rules),
> GFP_KERNEL);
>
Yes, So also can remove 'regd_to_copy', I will do it in a new patch
Thanks!
>> +if (!copy_rd)
>> copy_rd = ERR_PTR(-ENOMEM);
>> -goto out;
>> -}
>> -
>> -memcpy(copy_rd, regd, regd_to_copy);
>>
>> out:
>> kfree(regdb_ptrs);
>
>
> .
>
[PATCH] USB: serial: cp210x: add GPIO support for CP2104
The CP2104 chips feature 4 controllable GPIO pins, which are similar to
the ones on CP2102N chip (output-only when push-pull, output or
simulated input mode when open-drain).
Add support for the GPIO pins for cp210x driver. The pin get/set routine
is shared with CP2102N, but the pinconf initialization code is not
shared because the acquisition of GPIO configuration in OTP ROM is
similar to CP2105, not CP2102N.
Signed-off-by: Icenowy Zheng
---
drivers/usb/serial/cp210x.c | 82 +++--
1 file changed, 78 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index c0777a374a88..b27cf9d00aec 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -443,10 +443,10 @@ struct cp210x_pin_mode {
#define CP210X_PIN_MODE_GPIO BIT(0)
/*
- * CP210X_VENDOR_SPECIFIC, CP210X_GET_PORTCONFIG call reads these 0xf bytes.
- * Structure needs padding due to unused/unspecified bytes.
+ * CP210X_VENDOR_SPECIFIC, CP210X_GET_PORTCONFIG call reads these 0xf bytes
+ * on a CP2105 chip. Structure needs padding due to unused/unspecified bytes.
*/
-struct cp210x_config {
+struct cp210x_dual_port_config {
__le16 gpio_mode;
u8 __pad0[2];
__le16 reset_state;
@@ -457,6 +457,19 @@ struct cp210x_config {
u8 device_cfg;
} __packed;
+/*
+ * CP210X_VENDOR_SPECIFIC, CP210X_GET_PORTCONFIG call reads these 0xd bytes
+ * on a CP2104 chip. Structure needs padding due to unused/unspecified bytes.
+ */
+struct cp210x_single_port_config {
+ __le16 gpio_mode;
+ u8 __pad0[2];
+ __le16 reset_state;
+ u8 __pad1[4];
+ __le16 suspend_state;
+ u8 device_cfg;
+} __packed;
+
/* GPIO modes */
#define CP210X_SCI_GPIO_MODE_OFFSET9
#define CP210X_SCI_GPIO_MODE_MASK GENMASK(11, 9)
@@ -464,11 +477,19 @@ struct cp210x_config {
#define CP210X_ECI_GPIO_MODE_OFFSET2
#define CP210X_ECI_GPIO_MODE_MASK GENMASK(3, 2)
+#define CP210X_GPIO_MODE_OFFSET8
+#define CP210X_GPIO_MODE_MASK GENMASK(11, 8)
+
/* CP2105 port configuration values */
#define CP2105_GPIO0_TXLED_MODEBIT(0)
#define CP2105_GPIO1_RXLED_MODEBIT(1)
#define CP2105_GPIO1_RS485_MODEBIT(2)
+/* CP2104 port configuration values */
+#define CP2104_GPIO0_TXLED_MODEBIT(0)
+#define CP2104_GPIO1_RXLED_MODEBIT(1)
+#define CP2104_GPIO2_RS485_MODEBIT(2)
+
/* CP2102N configuration array indices */
#define CP210X_2NCONFIG_CONFIG_VERSION_IDX 2
#define CP210X_2NCONFIG_GPIO_MODE_IDX 581
@@ -1470,7 +1491,7 @@ static int cp2105_gpioconf_init(struct usb_serial *serial)
{
struct cp210x_serial_private *priv = usb_get_serial_data(serial);
struct cp210x_pin_mode mode;
- struct cp210x_config config;
+ struct cp210x_dual_port_config config;
u8 intf_num = cp210x_interface_num(serial);
u8 iface_config;
int result;
@@ -1529,6 +1550,56 @@ static int cp2105_gpioconf_init(struct usb_serial
*serial)
return 0;
}
+static int cp2104_gpioconf_init(struct usb_serial *serial)
+{
+ struct cp210x_serial_private *priv = usb_get_serial_data(serial);
+ struct cp210x_single_port_config config;
+ u8 iface_config;
+ u8 gpio_latch;
+ int result;
+ u8 i;
+
+ result = cp210x_read_vendor_block(serial, REQTYPE_DEVICE_TO_HOST,
+ CP210X_GET_PORTCONFIG, ,
+ sizeof(config));
+ if (result < 0)
+ return result;
+
+ priv->gc.ngpio = 4;
+
+ iface_config = config.device_cfg;
+ priv->gpio_pushpull = (u8)((le16_to_cpu(config.gpio_mode) &
+ CP210X_GPIO_MODE_MASK) >>
+ CP210X_GPIO_MODE_OFFSET);
+ gpio_latch = (u8)((le16_to_cpu(config.reset_state) &
+ CP210X_GPIO_MODE_MASK) >>
+ CP210X_GPIO_MODE_OFFSET);
+
+ /* mark all pins which are not in GPIO mode */
+ if (iface_config & CP2104_GPIO0_TXLED_MODE) /* GPIO 0 */
+ priv->gpio_altfunc |= BIT(0);
+ if (iface_config & CP2104_GPIO1_RXLED_MODE) /* GPIO 1 */
+ priv->gpio_altfunc |= BIT(1);
+ if (iface_config & CP2104_GPIO2_RS485_MODE) /* GPIO 2 */
+ priv->gpio_altfunc |= BIT(2);
+
+ /*
+* Like CP2102N, CP2104 has also no strict input and output pin
+* modes.
+* Do the same input mode emulation as CP2102N.
+*/
+ for (i = 0; i < priv->gc.ngpio; ++i) {
+ /*
+* Set direction to "input" iff pin is open-drain and reset
+* value is 1.
+*/
+ if (!(priv->gpio_pushpull & BIT(i)) && (gpio_latch &
Re: [PATCH v2 1/2] media: uapi: Add H264 low-level decoder API compound controls.
On Thu, Nov 15, 2018 at 11:56 PM Maxime Ripard wrote: > > From: Pawel Osciak > > Stateless video codecs will require both the H264 metadata and slices in > order to be able to decode frames. > > This introduces the definitions for a new pixel format for H264 slices that > have been parsed, as well as the structures used to pass the metadata from > the userspace to the kernel. > > Co-Developed-by: Maxime Ripard > Signed-off-by: Pawel Osciak > Signed-off-by: Guenter Roeck > Signed-off-by: Maxime Ripard > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c > b/drivers/media/v4l2-core/v4l2-ctrls.c > index b854cceb19dc..e96c453208e8 100644 > --- a/drivers/media/v4l2-core/v4l2-ctrls.c > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c > @@ -825,6 +825,11 @@ const char *v4l2_ctrl_get_name(u32 id) > case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER:return "H264 > Number of HC Layers"; > case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP: > return "H264 > Set QP Value for HC Layers"; > + case V4L2_CID_MPEG_VIDEO_H264_SPS: return "H264 > SPS"; > + case V4L2_CID_MPEG_VIDEO_H264_PPS: return "H264 > PPS"; > + case V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX: return "H264 > Scaling Matrix"; > + case V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS: return "H264 > Slice Parameters"; > + case V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS:return "H264 > Decode Parameters"; > case V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP: return "MPEG4 > I-Frame QP Value"; > case V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP: return "MPEG4 > P-Frame QP Value"; > case V4L2_CID_MPEG_VIDEO_MPEG4_B_FRAME_QP: return "MPEG4 > B-Frame QP Value"; To make things future-proof I think it may be good to add a control specifying the granularity of data sent with each request (see https://lkml.org/lkml/2019/1/24/147). Right now we have a consensus that to make things simple, we request one frame of encoded data per request. But this will probably be relaxed in the future, since allowing to process things at lower granularity may improve latency. Moreover the granularity accepted by the encoder is hardware/firmware dependent, so it is probably a good idea to expose this from the beginning. How about a new V4L2_CID_MPEG_VIDEO_H264_GRANULARITY control with only one value at the moment, namely V4L2_MPEG_VIDEO_H264_GRANULARITY_FRAME? We could extend this in the future, and that way user-space will have no excuse for not checking that the codec supports the input granularity it will send. I'm wondering whether this could be made codec-independent, but I'm afraid this would add confusion.
[PATCH v5 0/2] cadence-quadspi: Add Octal mode support
This series adds support for OSPI version of Cadence QSPI controller IP. Tested with AM654 EVM with MT35x512 Octal flash Changes: v5: Fix comments from by on v4. v4: Fix comments on v3 by Tudor. Rebase on top latest linux-next(all dependencies are now part of -next) v3: Rebase on top of v7 of Yogesh's series[1] v2: spi-nor core patches dropped, are now part of Yogesh's series [1] Declare Octal mode capability based on compatible. Vignesh R (2): dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller .../bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 58 +++ 2 files changed, 47 insertions(+), 12 deletions(-) -- 2.20.1
[PATCH v5 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
Cadence OSPI controller IP supports Octal IO (x8 IO lines),
It also has an integrated PHY. IP register layout is very
similar to existing QSPI IP except for additional bits to support Octal
and Octal DDR mode. Therefore, extend current driver to support Octal
mode. Only Octal SDR read (1-1-8)mode is supported for now.
Tested with mt35xu512aba Octal flash on TI's AM654 EVM.
Signed-off-by: Vignesh R
Reviewed-by: Tudor Ambarus
---
v5:
s/cqsi_base_hwcaps_mask/CQSPI_BASE_HWCAPS_MASK/g
Add back cqspi_driver_platdata definition for base compatible.
v4: Fix comments by Tudor on v3
v3: No changes
v2: Declare Octal mode capability based on compatible.
drivers/mtd/spi-nor/cadence-quadspi.c | 58 +--
1 file changed, 46 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 04cedd3a2bf6..c8113ebe44fd 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -44,6 +44,12 @@
/* Quirks */
#define CQSPI_NEEDS_WR_DELAY BIT(0)
+/* Capabilities mask */
+#define CQSPI_BASE_HWCAPS_MASK \
+ (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
+ SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
+ SNOR_HWCAPS_PP)
+
struct cqspi_st;
struct cqspi_flash_pdata {
@@ -93,6 +99,11 @@ struct cqspi_st {
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
+struct cqspi_driver_platdata {
+ u32 hwcaps_mask;
+ u8 quirks;
+};
+
/* Operation timeout value */
#define CQSPI_TIMEOUT_MS 500
#define CQSPI_READ_TIMEOUT_MS 10
@@ -101,6 +112,7 @@ struct cqspi_st {
#define CQSPI_INST_TYPE_SINGLE 0
#define CQSPI_INST_TYPE_DUAL 1
#define CQSPI_INST_TYPE_QUAD 2
+#define CQSPI_INST_TYPE_OCTAL 3
#define CQSPI_DUMMY_CLKS_PER_BYTE 8
#define CQSPI_DUMMY_BYTES_MAX 4
@@ -911,6 +923,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const
int read)
case SNOR_PROTO_1_1_4:
f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
break;
+ case SNOR_PROTO_1_1_8:
+ f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
+ break;
default:
return -EINVAL;
}
@@ -1213,21 +1228,22 @@ static void cqspi_request_mmap_dma(struct cqspi_st
*cqspi)
static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
{
- const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ |
- SNOR_HWCAPS_READ_FAST |
- SNOR_HWCAPS_READ_1_1_2 |
- SNOR_HWCAPS_READ_1_1_4 |
- SNOR_HWCAPS_PP,
- };
struct platform_device *pdev = cqspi->pdev;
struct device *dev = >dev;
+ const struct cqspi_driver_platdata *ddata;
+ struct spi_nor_hwcaps hwcaps;
struct cqspi_flash_pdata *f_pdata;
struct spi_nor *nor;
struct mtd_info *mtd;
unsigned int cs;
int i, ret;
+ ddata = of_device_get_match_data(dev);
+ if (!ddata)
+ hwcaps.mask = CQSPI_BASE_HWCAPS_MASK;
+ else
+ hwcaps.mask = ddata->hwcaps_mask;
+
/* Get flash device data */
for_each_available_child_of_node(dev->of_node, np) {
ret = of_property_read_u32(np, "reg", );
@@ -1310,7 +1326,7 @@ static int cqspi_probe(struct platform_device *pdev)
struct cqspi_st *cqspi;
struct resource *res;
struct resource *res_ahb;
- unsigned long data;
+ const struct cqspi_driver_platdata *ddata;
int ret;
int irq;
@@ -1377,8 +1393,8 @@ static int cqspi_probe(struct platform_device *pdev)
}
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
- data = (unsigned long)of_device_get_match_data(dev);
- if (data & CQSPI_NEEDS_WR_DELAY)
+ ddata = of_device_get_match_data(dev);
+ if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
cqspi->master_ref_clk_hz);
@@ -1460,14 +1476,32 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
#define CQSPI_DEV_PM_OPS NULL
#endif
+static const struct cqspi_driver_platdata cdns_qspi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+};
+
+static const struct cqspi_driver_platdata k2g_qspi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
+static const struct cqspi_driver_platdata am654_ospi = {
+ .hwcaps_mask = CQSPI_BASE_HWCAPS_MASK | SNOR_HWCAPS_READ_1_1_8,
+ .quirks = CQSPI_NEEDS_WR_DELAY,
+};
+
static const struct of_device_id
[PATCH v5 1/2] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC
AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence QSPI controller but supports Octal IO(x8 data lines) and Double Data Rate(DDR) mode. Add new compatible to support OSPI controller on TI's AM654 SoCs. Signed-off-by: Vignesh R Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index bb2075df9b38..4345c3a6f530 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be one of the following: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". + For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.20.1
Re: [RFC PATCH] ALSA: core: Add DMA share buffer support
On Fri, 25 Jan 2019 at 21:04, Takashi Iwai wrote: > > > > > > Erm, obviously it's not enough. Each attach / detach needs to manage > > > the refcount, too, for covering the cases above. It can re-use the > > > PCM mmap_refount, though. > > > > But we've used the DMA buffer file's refcounting to manage the DMA > > buffer. So is this not enough? > > Unless you manage the PCM substream refcount (or block the state > change), the PCM stream itself can be released (or re-setup) freely. > OK. Thanks for your comments. -- Baolin Wang Best Regards
