[PATCH] Staging: comedi: Return -EFAULT if copy_to_user() fails
Return -EFAULT on error instead of the number of bytes remaining to be
copied.
Fixes: bac42fb21259 ("comedi: get rid of compat_alloc_user_space() mess in
COMEDI_CMD{,TEST} compat")
Signed-off-by: Dan Carpenter
---
Hi Al, this goes through your tree.
drivers/staging/comedi/comedi_fops.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index d99231c737fb..80d74cce2a01 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2987,7 +2987,9 @@ static int put_compat_cmd(struct comedi32_cmd_struct
__user *cmd32,
v32.chanlist_len = cmd->chanlist_len;
v32.data = ptr_to_compat(cmd->data);
v32.data_len = cmd->data_len;
- return copy_to_user(cmd32, , sizeof(v32));
+ if (copy_to_user(cmd32, , sizeof(v32)))
+ return -EFAULT;
+ return 0;
}
/* Handle 32-bit COMEDI_CMD ioctl. */
--
2.29.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 08/11] input: raspberrypi-ts: Release firmware handle when not needed
Hi Nicolas,
On Mon, Nov 23, 2020 at 07:38:29PM +0100, Nicolas Saenz Julienne wrote:
> Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
> interface when unbinding the device.
I do not believe this comment is correct any longer. Otherwise:
Acked-by: Dmitry Torokhov
>
> Signed-off-by: Nicolas Saenz Julienne
>
> ---
>
> Changes since v3:
> - Release firmware handle in probe function
>
> Changes since v2:
> - Use devm_rpi_firmware_get(), instead of remove function
>
> drivers/input/touchscreen/raspberrypi-ts.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/raspberrypi-ts.c
> b/drivers/input/touchscreen/raspberrypi-ts.c
> index ef6aaed217cf..5000f5fd9ec3 100644
> --- a/drivers/input/touchscreen/raspberrypi-ts.c
> +++ b/drivers/input/touchscreen/raspberrypi-ts.c
> @@ -160,7 +160,7 @@ static int rpi_ts_probe(struct platform_device *pdev)
> touchbuf = (u32)ts->fw_regs_phys;
> error = rpi_firmware_property(fw, RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF,
> , sizeof(touchbuf));
> -
> + rpi_firmware_put(fw);
> if (error || touchbuf != 0) {
> dev_warn(dev, "Failed to set touchbuf, %d\n", error);
> return error;
> --
> 2.29.2
>
--
Dmitry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 5/6] dt-bindings: media: cedrus: Add V3s compatible
On Mon, 16 Nov 2020 13:56:16 +0100, Martin Cerveny wrote: > Allwinner V3s SoC contains video engine. Add compatible for it. > > Signed-off-by: Martin Cerveny > --- > .../bindings/media/allwinner,sun4i-a10-video-engine.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 2/6] dt-bindings: sram: allwinner, sun4i-a10-system-control: Add V3s compatibles
On Mon, 16 Nov 2020 13:56:13 +0100, Martin Cerveny wrote: > Allwinner V3s has system control similar to that in H3. > Add compatibles for system control with SRAM C1 region. > > Signed-off-by: Martin Cerveny > --- > .../bindings/sram/allwinner,sun4i-a10-system-control.yaml | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
01.12.2020 17:34, Mark Brown пишет: > On Tue, Dec 01, 2020 at 05:17:20PM +0300, Dmitry Osipenko wrote: >> 01.12.2020 16:57, Mark Brown пишет: > >>> [1/1] regulator: Allow skipping disabled regulators in >>> regulator_check_consumers() >>> (no commit info) > >> Could you please hold on this patch? It won't be needed in a v2, which >> will use power domains. > >> Also, I'm not sure whether the "sound" tree is suitable for any of the >> patches in this series. > > It didn't actually get applied (note the "no commit info") - it looks > like b4's matching code got confused and decided to generate mails for > anything that I've ever downloaded and not posted. > Alright, thank you for the clarification. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
On Tue, Dec 01, 2020 at 05:17:20PM +0300, Dmitry Osipenko wrote: > 01.12.2020 16:57, Mark Brown пишет: > > [1/1] regulator: Allow skipping disabled regulators in > > regulator_check_consumers() > > (no commit info) > Could you please hold on this patch? It won't be needed in a v2, which > will use power domains. > Also, I'm not sure whether the "sound" tree is suitable for any of the > patches in this series. It didn't actually get applied (note the "no commit info") - it looks like b4's matching code got confused and decided to generate mails for anything that I've ever downloaded and not posted. signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
01.12.2020 16:57, Mark Brown пишет: > On Thu, 5 Nov 2020 02:43:57 +0300, Dmitry Osipenko wrote: >> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces >> power consumption and heating of the Tegra chips. Tegra SoC has multiple >> hardware units which belong to a core power domain of the SoC and share >> the core voltage. The voltage must be selected in accordance to a minimum >> requirement of every core hardware unit. >> >> The minimum core voltage requirement depends on: >> >> [...] > > Applied to > >https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next > > Thanks! > > [1/1] regulator: Allow skipping disabled regulators in > regulator_check_consumers() > (no commit info) > > All being well this means that it will be integrated into the linux-next > tree (usually sometime in the next 24 hours) and sent to Linus during > the next merge window (or sooner if it is a bug fix), however if > problems are discovered then the patch may be dropped or reverted. > > You may get further e-mails resulting from automated or manual testing > and review of the tree, please engage with people reporting problems and > send followup patches addressing any issues that are reported if needed. > > If any updates are required or you are submitting further changes they > should be sent as incremental updates against current git, existing > patches will not be replaced. > > Please add any relevant lists and maintainers to the CCs when replying > to this mail. Hello Mark, Could you please hold on this patch? It won't be needed in a v2, which will use power domains. Also, I'm not sure whether the "sound" tree is suitable for any of the patches in this series. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/
>
> So looks like the bulk of these are:
> switch (x) {
> case 0:
> ++x;
> default:
> break;
> }
This should not generate a warning.
>
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895
>
> There's 3 other cases that don't quite match between GCC and Clang I
> observe in the kernel:
> switch (x) {
> case 0:
> ++x;
> default:
> goto y;
> }
> y:;
This should generate a warning.
>
> switch (x) {
> case 0:
> ++x;
> default:
> return;
> }
Warn for this.
>
> switch (x) {
> case 0:
> ++x;
> default:
> ;
> }
Don't warn for this.
If adding a break statement changes the flow of the code then warn about
potentially missing break statements, but if it doesn't change anything
then don't warn about it.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Sun, Nov 22, 2020 at 08:17:03AM -0800, Kees Cook wrote: > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote: > > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote: > > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > > > > > This series aims to fix almost all remaining fall-through warnings in > > > > > order to enable -Wimplicit-fallthrough for Clang. > > > > > > > > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > > > > > add multiple break/goto/return/fallthrough statements instead of just > > > > > letting the code fall through to the next case. > > > > > > > > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this > > > > > change[1] is meant to be reverted at some point. So, this patch helps > > > > > to move in that direction. > > > > > > > > > > Something important to mention is that there is currently a > > > > > discrepancy > > > > > between GCC and Clang when dealing with switch fall-through to empty > > > > > case > > > > > statements or to cases that only contain a break/continue/return > > > > > statement[2][3][4]. > > > > > > > > Are we sure we want to make this change? Was it discussed before? > > > > > > > > Are there any bugs Clangs puritanical definition of fallthrough helped > > > > find? > > > > > > > > IMVHO compiler warnings are supposed to warn about issues that could > > > > be bugs. Falling through to default: break; can hardly be a bug?! > > > > > > It's certainly a place where the intent is not always clear. I think > > > this makes all the cases unambiguous, and doesn't impact the machine > > > code, since the compiler will happily optimize away any behavioral > > > redundancy. > > > > If none of the 140 patches here fix a real bug, and there is no change > > to machine code then it sounds to me like a W=2 kind of a warning. > > FWIW, this series has found at least one bug so far: > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/ This is a fallthrough to a return and not to a break. That should trigger a warning. The fallthrough to a break should not generate a warning. The bug we're trying to fix is "missing break statement" but if the result of the bug is "we hit a break statement" then now we're just talking about style. GCC should limit itself to warning about potentially buggy code. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
On Thu, 5 Nov 2020 02:43:57 +0300, Dmitry Osipenko wrote: > Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces > power consumption and heating of the Tegra chips. Tegra SoC has multiple > hardware units which belong to a core power domain of the SoC and share > the core voltage. The voltage must be selected in accordance to a minimum > requirement of every core hardware unit. > > The minimum core voltage requirement depends on: > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] regulator: Allow skipping disabled regulators in regulator_check_consumers() (no commit info) All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 13/19] media: sunxi: Add support for the A31 MIPI CSI-2 controller
Hi,
On Sat, Nov 28, 2020 at 03:28:33PM +0100, Paul Kocialkowski wrote:
> The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
> found on Allwinner SoCs such as the A31 and V3/V3s.
>
> It is a standalone block, connected to the CSI controller on one side
> and to the MIPI D-PHY block on the other. It has a dedicated address
> space, interrupt line and clock.
>
> It is represented as a V4L2 subdev to the CSI controller and takes a
> MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
> media controller API.
>
> Only 8-bit and 10-bit Bayer formats are currently supported.
> While up to 4 internal channels to the CSI controller exist, only one
> is currently supported by this implementation.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/media/platform/sunxi/Kconfig | 1 +
> drivers/media/platform/sunxi/Makefile | 1 +
> .../platform/sunxi/sun6i-mipi-csi2/Kconfig| 12 +
> .../platform/sunxi/sun6i-mipi-csi2/Makefile | 4 +
> .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c | 591 ++
> .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h | 117
> 6 files changed, 726 insertions(+)
> create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> create mode 100644
> drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> create mode 100644
> drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h
>
> diff --git a/drivers/media/platform/sunxi/Kconfig
> b/drivers/media/platform/sunxi/Kconfig
> index 7151cc249afa..9684e07454ad 100644
> --- a/drivers/media/platform/sunxi/Kconfig
> +++ b/drivers/media/platform/sunxi/Kconfig
> @@ -2,3 +2,4 @@
>
> source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
> source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
> +source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
> diff --git a/drivers/media/platform/sunxi/Makefile
> b/drivers/media/platform/sunxi/Makefile
> index fc537c9f5ca9..887a7cae8fca 100644
> --- a/drivers/media/platform/sunxi/Makefile
> +++ b/drivers/media/platform/sunxi/Makefile
> @@ -2,5 +2,6 @@
>
> obj-y+= sun4i-csi/
> obj-y+= sun6i-csi/
> +obj-y+= sun6i-mipi-csi2/
I'm not sure we need a new folder here, it's only ever tied to sun6i-csi
so it would make more sense to have it in the same folder.
> obj-y+= sun8i-di/
> obj-y+= sun8i-rotate/
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> new file mode 100644
> index ..3260591ed5c0
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> @@ -0,0 +1,12 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config VIDEO_SUN6I_MIPI_CSI2
> + tristate "Allwinner A31 MIPI CSI-2 Controller Driver"
> + depends on VIDEO_V4L2 && COMMON_CLK
> + depends on ARCH_SUNXI || COMPILE_TEST
> + select PHY_SUN6I_MIPI_DPHY
> + select MEDIA_CONTROLLER
> + select VIDEO_V4L2_SUBDEV_API
> + select REGMAP_MMIO
> + select V4L2_FWNODE
> + help
> +Support for the Allwinner A31 MIPI CSI-2 Controller.
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> new file mode 100644
> index ..14e4e03818b5
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +sun6i-mipi-csi2-y += sun6i_mipi_csi2.o
> +
> +obj-$(CONFIG_VIDEO_SUN6I_MIPI_CSI2) += sun6i-mipi-csi2.o
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> new file mode 100644
> index ..a6567ef82fb4
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> @@ -0,0 +1,591 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 Bootlin
> + * Author: Paul Kocialkowski
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "sun6i_mipi_csi2.h"
> +
> +#define MODULE_NAME "sun6i-mipi-csi2"
> +
> +static const u32 sun6i_mipi_csi2_mbus_codes[] = {
> + MEDIA_BUS_FMT_SBGGR8_1X8,
> + MEDIA_BUS_FMT_SGBRG8_1X8,
> + MEDIA_BUS_FMT_SGRBG8_1X8,
> + MEDIA_BUS_FMT_SRGGB8_1X8,
> + MEDIA_BUS_FMT_SBGGR10_1X10,
> + MEDIA_BUS_FMT_SGBRG10_1X10,
> + MEDIA_BUS_FMT_SGRBG10_1X10,
> + MEDIA_BUS_FMT_SRGGB10_1X10,
> +};
> +
> +/* Video */
> +
> +static int sun6i_mipi_csi2_s_stream(struct v4l2_subdev *subdev, int on)
> +{
> + struct sun6i_mipi_csi2_video *video =
> + sun6i_mipi_csi2_subdev_video(subdev);
> + struct sun6i_mipi_csi2_dev *cdev = sun6i_mipi_csi2_video_dev(video);
> +
Re: [PATCH v2 12/19] dt-bindings: media: Add A31 MIPI CSI-2 bindings documentation
On Sat, Nov 28, 2020 at 03:28:32PM +0100, Paul Kocialkowski wrote: > This introduces YAML bindings documentation for the A31 MIPI CSI-2 > controller. > > Signed-off-by: Paul Kocialkowski > --- > .../media/allwinner,sun6i-a31-mipi-csi2.yaml | 151 ++ > 1 file changed, 151 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml > > diff --git > a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml > b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml > new file mode 100644 > index ..917cd09d6fda > --- /dev/null > +++ > b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml > @@ -0,0 +1,151 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/allwinner,sun6i-a31-mipi-csi2.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Allwinner A31 MIPI CSI-2 Device Tree Bindings > + > +maintainers: > + - Paul Kocialkowski > + > +properties: > + compatible: > +oneOf: > + - const: allwinner,sun6i-a31-mipi-csi2 > + - items: > + - const: allwinner,sun8i-v3s-mipi-csi2 > + - const: allwinner,sun6i-a31-mipi-csi2 > + > + reg: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + > + clocks: > +items: > + - description: Bus Clock > + - description: Module Clock > + > + clock-names: > +items: > + - const: bus > + - const: mod > + > + phys: > +items: > + - description: MIPI D-PHY > + > + phy-names: > +items: > + - const: dphy If there's a single item, you don't need the items: in phys and phy-names > + resets: > +maxItems: 1 > + > + # See ./video-interfaces.txt for details > + ports: > +type: object > + > +properties: > + port@0: > +type: object > +description: Input port, connect to a MIPI CSI-2 sensor > + > +properties: > + reg: > +const: 0 > + > + endpoint: > +type: object > + > +properties: > + remote-endpoint: true > + > + data-lanes: > +minItems: 1 > +maxItems: 4 > + > +required: > + - data-lanes > + - remote-endpoint > + > +required: > + - endpoint > + > +additionalProperties: false > + > + port@1: > +type: object > +description: Output port, connect to a CSI controller > + > +properties: > + reg: > +const: 1 > + > + endpoint: > +type: object > + > +properties: > + remote-endpoint: true > + > +required: > + - endpoint > + > +additionalProperties: false Same thing than for the other dt binding patch, there's a schema for it now Maxime signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 09/19] ARM: dts: sunxi: h3/h5: Add CSI controller port for parallel input
On Sat, Nov 28, 2020 at 03:28:29PM +0100, Paul Kocialkowski wrote:
> Since the CSI controller binding is getting a bit more complex due
> to the addition of MIPI CSI-2 bridge support, make the ports node
> explicit with the parallel port.
>
> This way, it's clear that the controller only supports parallel
> interface input and there's no confusion about the port number.
>
> Signed-off-by: Paul Kocialkowski
> ---
> arch/arm/boot/dts/sunxi-h3-h5.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index 9be13378d4df..02b698cace6a 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -803,6 +803,15 @@ csi: camera@1cb {
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + csi_in_parallel: port@0 {
> + reg = <0>;
> + };
> + };
> };
This will create a DTC warning, since port@0 is the only node, and is
equivalent to port
Maxime
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 07/19] media: sun6i-csi: Add support for MIPI CSI-2 bridge input
Hi, On Sat, Nov 28, 2020 at 03:28:27PM +0100, Paul Kocialkowski wrote: > The A31 CSI controller supports a MIPI CSI-2 bridge input, which has > its own dedicated port in the fwnode graph. > > Support for this input is added with this change: > - two pads are defined for the media entity instead of one > and only one needs to be connected at a time; > - the pads currently match the fwnode graph representation; > - links are created between our pads and the subdevs for each > interface and are no longer immutable so that userspace can select > which interface to use in case both are bound to a subdev; > - fwnode endpoints are parsed and stored for each interface; > - the active subdev (and fwnode endpoint) is retrieved when validating > the media link at stream on time and cleared at stream off; > - an error is raised if both links are active at the same time; > - the MIPI interface bit is set if the MIPI CSI-2 bridge endpoint is > active. > > In the future, the media entity representation might evolve to: > - distinguish the internal parallel bridge and data formatter; > - represent each of the 4 internal channels that can exist between > the parallel bridge (for BT656 time-multiplex) and MIPI CSI-2 > (internal channels can be mapped to virtual channels); > - connect the controller's output to the ISP instead of its > DMA engine. > > Finally note that the MIPI CSI-2 bridges should not be linked in > the fwnode graph unless they have a sensor subdev attached. I'll leave most of the review to Laurent and Sakari, but I'm not quite sure what you meant in the last paragraph. Did you mean that the MIPI-CSI controller in the Allwinner SoC should only be linked if it has a sensor attached, or did you mean that any MIPI-CSI2 bridge cannot be attached to the controller? Also, having somewhere (like your cover letter) the media-ctl setup you tested with would be great. Maxime signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 06/19] dt-bindings: media: sun6i-a31-csi: Add MIPI CSI-2 input port
On Sat, Nov 28, 2020 at 03:28:26PM +0100, Paul Kocialkowski wrote: > The A31 CSI controller supports two distinct input interfaces: > parallel and an external MIPI CSI-2 bridge. The parallel interface > is often connected to a set of hardware pins while the MIPI CSI-2 > bridge is an internal FIFO-ish link. As a result, these two inputs > are distinguished as two different ports. > > Note that only one of the two may be present on a controller instance. > For example, the V3s has one controller dedicated to MIPI-CSI2 and one > dedicated to parallel. > > Update the binding with an explicit ports node that holds two distinct > port nodes: one for parallel input and one for MIPI CSI-2. > > This is backward-compatible with the single-port approach that was > previously taken for representing the parallel interface port, which > stays enumerated as fwnode port 0. However, it is now marked as > deprecated and the multi-port approach should be preferred. > > Note that additional ports may be added in the future, especially to > support feeding the CSI controller's output to the ISP. > > Signed-off-by: Paul Kocialkowski > --- > .../media/allwinner,sun6i-a31-csi.yaml| 86 --- > 1 file changed, 73 insertions(+), 13 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml > b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml > index 1fd9b5532a21..3bcee2d44f3c 100644 > --- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml > +++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml > @@ -43,6 +43,7 @@ properties: ># See ./video-interfaces.txt for details >port: > type: object > +deprecated: true I'm not sure we want to deprecate it. There's some SoCs with the same controller but without the MIPI-CSI block where this would be completely valid > properties: >endpoint: > @@ -67,6 +68,59 @@ properties: > > additionalProperties: false > > + ports: > +type: object > + > +properties: > + port@0: > +type: object > +description: Parallel input port, connect to a parallel sensor > + > +properties: > + reg: > +const: 0 > + > + endpoint: > +type: object > + > +properties: > + remote-endpoint: true > + > + bus-width: > +enum: [ 8, 10, 12, 16 ] > + > + pclk-sample: true > + hsync-active: true > + vsync-active: true > + > +required: > + - bus-width > + - remote-endpoint > + > +required: > + - endpoint > + > +additionalProperties: false > + > + port@1: > +type: object > +description: MIPI CSI-2 bridge input port > + > +properties: > + reg: > +const: 1 > + > + endpoint: > +type: object > + > +properties: > + remote-endpoint: true > + > +required: > + - remote-endpoint > + > +additionalProperties: false There's a schema for the OF-graph now, you'll want to use it. Maxime signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 04/19] media: sun6i-csi: Use common V4L2 format info for storage bpp
On Sat, Nov 28, 2020 at 03:28:24PM +0100, Paul Kocialkowski wrote:
> V4L2 has a common helper which can be used for calculating the number
> of stored bits per pixels of a given (stored) image format.
>
> Use the helper-returned structure instead of our own switch/case list.
> Note that a few formats are not in that list so we keep them as
> special cases.
>
> The custom switch/case was also wrong concerning 10/12-bit Bayer
> formats, which are aligned to 16 bits in memory. Using the common
> helper fixes it.
>
> Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
> Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 03/19] phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI CSI-2
On Sat, Nov 28, 2020 at 03:28:23PM +0100, Paul Kocialkowski wrote: > The Allwinner A31 D-PHY supports both Rx and Tx modes. While the latter > is already supported and used for MIPI DSI this adds support for the > former, to be used with MIPI CSI-2. > > This implementation is inspired by Allwinner's V3s Linux SDK > implementation, which was used as a documentation base. > > Signed-off-by: Paul Kocialkowski Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 01/19] docs: phy: Add a part about PHY mode and submode
On Sat, Nov 28, 2020 at 03:28:21PM +0100, Paul Kocialkowski wrote: > Besides giving pointers to the relevant functions for PHY mode and > submode configuration, this clarifies the need to set them before > powering on the PHY. > > Signed-off-by: Paul Kocialkowski Reviewed-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Tue, Dec 01, 2020 at 12:52:27AM -0500, Martin K. Petersen wrote: > > Gustavo, > > > This series aims to fix almost all remaining fall-through warnings in > > order to enable -Wimplicit-fallthrough for Clang. > > Applied 20-22,54,120-124 to 5.11/scsi-staging, thanks. Awesome! :) Thanks, Martin. -- Gustavo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
