Re: [PATCH 02/14] phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI CSI-2
Hi,
On Mon 26 Oct 20, 16:38, Maxime Ripard wrote:
> On Fri, Oct 23, 2020 at 07:45:34PM +0200, 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 the Allwinner BSP implementation.
>
> Mentionning which BSP you took this from would be helpful
Sure! It's from the Github repo linked from https://linux-sunxi.org/V3s.
Would you like that I mention this URL explicitly or would it be enough to
mention "Allwinner's V3s Linux SDK" as they seem to call it?
> > Signed-off-by: Paul Kocialkowski
> > ---
> > drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 164 +++-
> > 1 file changed, 160 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> > b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> > index 1fa761ba6cbb..8bcd4bb79f60 100644
> > --- a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> > +++ b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> > @@ -24,6 +24,14 @@
> > #define SUN6I_DPHY_TX_CTL_REG 0x04
> > #define SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT BIT(28)
> >
> > +#define SUN6I_DPHY_RX_CTL_REG 0x08
> > +#define SUN6I_DPHY_RX_CTL_EN_DBC BIT(31)
> > +#define SUN6I_DPHY_RX_CTL_RX_CLK_FORCE BIT(24)
> > +#define SUN6I_DPHY_RX_CTL_RX_D3_FORCE BIT(23)
> > +#define SUN6I_DPHY_RX_CTL_RX_D2_FORCE BIT(22)
> > +#define SUN6I_DPHY_RX_CTL_RX_D1_FORCE BIT(21)
> > +#define SUN6I_DPHY_RX_CTL_RX_D0_FORCE BIT(20)
> > +
>
> It's hard to tell from the diff, but it looks like you aligned the
> BIT(..) with the register?
That's correct, yes.
> If so, you should follow the what the rest of this driver (ie, one more
> indentation for register values).
I'll fix it in the next revision!
> > #define SUN6I_DPHY_TX_TIME0_REG0x10
> > #define SUN6I_DPHY_TX_TIME0_HS_TRAIL(n)(((n) & 0xff) << 24)
> > #define SUN6I_DPHY_TX_TIME0_HS_PREPARE(n) (((n) & 0xff) << 16)
> > @@ -44,12 +52,29 @@
> > #define SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(n) (((n) & 0xff) << 8)
> > #define SUN6I_DPHY_TX_TIME4_HS_TX_ANA0(n) ((n) & 0xff)
> >
> > +#define SUN6I_DPHY_RX_TIME0_REG0x30
> > +#define SUN6I_DPHY_RX_TIME0_HS_RX_SYNC(n) (((n) & 0xff) << 24)
> > +#define SUN6I_DPHY_RX_TIME0_HS_RX_CLK_MISS(n) (((n) & 0xff) << 16)
> > +#define SUN6I_DPHY_RX_TIME0_LP_RX(n) (((n) & 0xff) << 8)
> > +
> > +#define SUN6I_DPHY_RX_TIME1_REG0x34
> > +#define SUN6I_DPHY_RX_TIME1_RX_DLY(n) (((n) & 0xfff) << 20)
> > +#define SUN6I_DPHY_RX_TIME1_LP_RX_ULPS_WP(n) ((n) & 0xf)
> > +
> > +#define SUN6I_DPHY_RX_TIME2_REG0x38
> > +#define SUN6I_DPHY_RX_TIME2_HS_RX_ANA1(n) (((n) & 0xff) << 8)
> > +#define SUN6I_DPHY_RX_TIME2_HS_RX_ANA0(n) ((n) & 0xff)
> > +
> > +#define SUN6I_DPHY_RX_TIME3_REG0x40
> > +#define SUN6I_DPHY_RX_TIME3_LPRST_DLY(n) (((n) & 0x) << 16)
> > +
> > #define SUN6I_DPHY_ANA0_REG0x4c
> > #define SUN6I_DPHY_ANA0_REG_PWSBIT(31)
> > #define SUN6I_DPHY_ANA0_REG_DMPC BIT(28)
> > #define SUN6I_DPHY_ANA0_REG_DMPD(n)(((n) & 0xf) << 24)
> > #define SUN6I_DPHY_ANA0_REG_SLV(n) (((n) & 7) << 12)
> > #define SUN6I_DPHY_ANA0_REG_DEN(n) (((n) & 0xf) << 8)
> > +#define SUN6I_DPHY_ANA0_REG_SFB(n) (((n) & 3) << 2)
> >
> > #define SUN6I_DPHY_ANA1_REG0x50
> > #define SUN6I_DPHY_ANA1_REG_VTTMODEBIT(31)
> > @@ -92,6 +117,8 @@ struct sun6i_dphy {
> >
> > struct phy *phy;
> > struct phy_configure_opts_mipi_dphy config;
> > +
> > + int submode;
> > };
> >
> > static int sun6i_dphy_init(struct phy *phy)
> > @@ -105,6 +132,18 @@ static int sun6i_dphy_init(struct phy *phy)
> > return 0;
> > }
> >
> > +static int sun6i_dphy_set_mode(struct phy *phy, enum phy_mode mode, int
> > submode)
> > +{
> > + struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> > +
> > + if (mode != PHY_MODE_MIPI_DPHY)
> > + return -EINVAL;
> > +
> > + dphy->submode = submode;
> > +
> > + return 0;
> > +}
> > +
> > static int sun6i_dphy_configure(struct phy *phy, union phy_configure_opts
> > *opts)
> > {
> > struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> > @@ -119,9 +158,8 @@ static int sun6i_dphy_configure(struct phy *phy, union
> > phy_configure_opts *opts)
> > return 0;
> > }
> >
> > -static int sun6i_dphy_power_on(struct phy *phy)
> > +static int sun6i_dphy_tx_power_on(struct sun6i_dphy *dphy)
> > {
> > - struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> > u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
> >
> > regmap_write(dphy->regs, SUN6I_DPHY_TX_CTL_REG,
> > @@ -211,12 +249,129 @@ static int sun6i_dphy_power_on(struct phy *p
Re: [PATCH 03/14] media: sun6i-csi: Support an optional dedicated memory pool
Hi,
On Mon 26 Oct 20, 16:41, Maxime Ripard wrote:
> On Fri, Oct 23, 2020 at 07:45:35PM +0200, Paul Kocialkowski wrote:
> > This allows selecting a dedicated CMA memory pool (specified via
> > device-tree) instead of the default one.
> >
> > Signed-off-by: Paul Kocialkowski
>
> Why would that be needed?
Sorry for the confusion, this is indeed unrelated to the current series and
it is not needed for MIPI CSI-2 support.
However, I think it's a worthwhile addition to the driver.
I will take it out of the series and re-submit it separately then.
> > ---
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > index 28e89340fed9..5d2389a5cd17 100644
> > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -849,6 +850,12 @@ static int sun6i_csi_resource_request(struct
> > sun6i_csi_dev *sdev,
> > return PTR_ERR(sdev->regmap);
> > }
> >
> > + ret = of_reserved_mem_device_init(&pdev->dev);
> > + if (ret && ret != -ENODEV) {
> > + dev_err(&pdev->dev, "Unable to init reserved memory\n");
> > + return ret;
> > + }
> > +
> > sdev->clk_mod = devm_clk_get(&pdev->dev, "mod");
>
> If that clk_get or any subsequent function fail you'll end up leaking
> whatever the initialization of the reserved memory has allocated
Right, there's a missing of_reserved_mem_device_release in the error path here.
Thanks!
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 05/14] media: sun6i-csi: Only configure the interface data width for parallel
Hi,
On Mon 26 Oct 20, 17:00, Maxime Ripard wrote:
> On Fri, Oct 23, 2020 at 07:45:37PM +0200, Paul Kocialkowski wrote:
> > Bits related to the interface data width do not have any effect when
> > the CSI controller is taking input from the MIPI CSI-2 controller.
>
> I guess it would be clearer to mention that the data width is only
> applicable for parallel here.
Understood, will change the wording in the next version.
> > In prevision of adding support for this case, set these bits
> > conditionally so there is no ambiguity.
> >
> > Co-developed-by: Kévin L'hôpital
> > Signed-off-by: Kévin L'hôpital
> > Signed-off-by: Paul Kocialkowski
> > ---
> > .../platform/sunxi/sun6i-csi/sun6i_csi.c | 42 +++
> > 1 file changed, 25 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > index 5d2389a5cd17..a876a05ea3c7 100644
> > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > @@ -378,8 +378,13 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev
> > *sdev)
> > unsigned char bus_width;
> > u32 flags;
> > u32 cfg;
> > + bool input_parallel = false;
> > bool input_interlaced = false;
> >
> > + if (endpoint->bus_type == V4L2_MBUS_PARALLEL ||
> > + endpoint->bus_type == V4L2_MBUS_BT656)
> > + input_parallel = true;
> > +
> > if (csi->config.field == V4L2_FIELD_INTERLACED
> > || csi->config.field == V4L2_FIELD_INTERLACED_TB
> > || csi->config.field == V4L2_FIELD_INTERLACED_BT)
> > @@ -395,6 +400,26 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev
> > *sdev)
> > CSI_IF_CFG_HREF_POL_MASK | CSI_IF_CFG_FIELD_MASK |
> > CSI_IF_CFG_SRC_TYPE_MASK);
> >
> > + if (input_parallel) {
> > + switch (bus_width) {
> > + case 8:
> > + cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
> > + break;
> > + case 10:
> > + cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
> > + break;
> > + case 12:
> > + cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
> > + break;
> > + case 16: /* No need to configure DATA_WIDTH for 16bit */
> > + break;
> > + default:
> > + dev_warn(sdev->dev, "Unsupported bus width: %u\n",
> > +bus_width);
> > + break;
> > + }
> > + }
> > +
> > if (input_interlaced)
> > cfg |= CSI_IF_CFG_SRC_TYPE_INTERLACED;
> > else
> > @@ -440,23 +465,6 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev
> > *sdev)
> > break;
> > }
> >
> > - switch (bus_width) {
> > - case 8:
> > - cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
> > - break;
> > - case 10:
> > - cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
> > - break;
> > - case 12:
> > - cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
> > - break;
> > - case 16: /* No need to configure DATA_WIDTH for 16bit */
> > - break;
> > - default:
> > - dev_warn(sdev->dev, "Unsupported bus width: %u\n", bus_width);
> > - break;
> > - }
> > -
>
> Is there any reason to move it around?
The main reason is cosmetics: input_parallel is introduced to match the already
existing input_interlaced variable, so it made sense to me to have both of these
conditionals one after the other instead of spreading them randomly.
I can mention this in the commit log if you prefer.
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 17/32] MAINTAINERS: fix broken doc refs due to yaml conversion
Several *.txt files got converted to yaml. Update their references at MAINTAINERS file accordingly. Acked-by: Stephen Boyd Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/clock/hi6220-clock.txt | 2 +- MAINTAINERS | 9 - .../devicetree/bindings/net/wireless/silabs,wfx.yaml | 2 +- 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/hi6220-clock.txt b/Documentation/devicetree/bindings/clock/hi6220-clock.txt index ef3deb7b86ea..17ac4a3dd26a 100644 --- a/Documentation/devicetree/bindings/clock/hi6220-clock.txt +++ b/Documentation/devicetree/bindings/clock/hi6220-clock.txt @@ -4,7 +4,7 @@ Clock control registers reside in different Hi6220 system controllers, please refer the following document to know more about the binding rules for these system controllers: -Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml Required Properties: diff --git a/MAINTAINERS b/MAINTAINERS index e73636b75f29..4511501cd59c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -978,7 +978,7 @@ M: Michael Hennerich L: linux-...@vger.kernel.org S: Supported W: http://ez.analog.com/community/linux-device-drivers -F: Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.txt +F: Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml F: drivers/iio/adc/ad7768-1.c ANALOG DEVICES INC AD7780 DRIVER @@ -3860,7 +3860,7 @@ M:Roger Quadros L: linux-...@vger.kernel.org S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git -F: Documentation/devicetree/bindings/usb/cdns-usb3.txt +F: Documentation/devicetree/bindings/usb/cdns,usb3.yaml F: drivers/usb/cdns3/ CADET FM/AM RADIO RECEIVER DRIVER @@ -7920,7 +7920,7 @@ HISILICON LPC BUS DRIVER M: john.ga...@huawei.com S: Maintained W: http://www.hisilicon.com -F: Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt +F: Documentation/devicetree/bindings/arm/hisilicon/low-pin-count.yaml F: drivers/bus/hisi_lpc.c HISILICON NETWORK SUBSYSTEM 3 DRIVER (HNS3) @@ -14902,7 +14902,6 @@ RENESAS ETHERNET DRIVERS R: Sergei Shtylyov L: net...@vger.kernel.org L: linux-renesas-...@vger.kernel.org -F: Documentation/devicetree/bindings/net/renesas,*.txt F: Documentation/devicetree/bindings/net/renesas,*.yaml F: drivers/net/ethernet/renesas/ F: include/linux/sh_eth.h @@ -18106,7 +18105,7 @@ M: Yu Chen M: Binghui Wang L: linux-...@vger.kernel.org S: Maintained -F: Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt +F: Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml F: drivers/phy/hisilicon/phy-hi3660-usb3.c USB ISP116X DRIVER diff --git a/drivers/staging/wfx/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml b/drivers/staging/wfx/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml index 43b5630c0407..510edd12ed19 100644 --- a/drivers/staging/wfx/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml +++ b/drivers/staging/wfx/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml @@ -24,7 +24,7 @@ description: In addition, it is recommended to declare a mmc-pwrseq on SDIO host above WFx. Without it, you may encounter issues with warm boot. The mmc-pwrseq should be compatible with mmc-pwrseq-simple. Please consult -Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt for more +Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml for more information. For SPI':' -- 2.26.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/14] dt-bindings: media: i2c: Add A31 MIPI CSI-2 bindings documentation
Hi,
On Mon 26 Oct 20, 17:14, Maxime Ripard wrote:
> i2c? :)
Oops, good catch!
> On Fri, Oct 23, 2020 at 07:45:39PM +0200, 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 | 168 ++
> > 1 file changed, 168 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 ..9adc0bc27033
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
> > @@ -0,0 +1,168 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%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
> > +
> > + 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
> > +
> > + bus-type:
> > +const: 4
> > +
> > + clock-lanes:
> > +maxItems: 1
> > +
> > + data-lanes:
> > +minItems: 1
> > +maxItems: 4
> > +
> > +required:
> > + - bus-type
> > + - data-lanes
> > + - remote-endpoint
> > +
> > +additionalProperties: false
> > +
> > +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
> > +
> > + bus-type:
> > +const: 4
>
> That one seems a bit weird. If the input and output ports are using the
> same format, what is that "bridge" supposed to be doing?
Fair enough. What this represents is the internal link (likely a FIFO) between
the two controllers. It is definitely not a MIPI CSI-2 bus but there's no
mbus type for an internal link (probably because it's not a bus after all).
Note that on the CSI controller side, we need the bus-type to be set to 4 for it
to properly select the MIPI CSI-2 input. So it just felt more logical to have
the same on the other side of the endpoint. On the other hand, we can just
remove it on the MIPI CSI-2 controller side since it won't check it and have it
fallback to the unknown mbus type.
But that would make the types inconsistent on the two sides of the link.
I don't think V4L2 will complain about it at the moment, but it would also make
sense that it does eventually.
What do you think?
> > +additionalProperties: false
> > +
> > +required:
> > + - endpoint
> > +
> > +additionalProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - clock-names
> > + - resets
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +#include
> > +
> > +mipi_csi2: mipi-csi2@1cb1000 {
>
> The unit name should be pretty standard, with the list here:
>
> https://github.com/devicetree-org/devicetree-specification/blob/master/source/chapter2-devicetree-basics.rst#generic-names-recommendation
>
> there's nothing really standing out for us in that list, but given that
> there's dsi, we should stick with csi
Then what really s
Low-Cost Loans for SMEs & Investment Funding.
Dear My name is Nicholas Toms, an investment portfolio manager with ACLL . We offer the right loan Investment funding with low interest to finance your business or project ranging from US$1M to US$2BIllion. Kindly contact me for more details as I am open to questions. Sincerely, Nicholas Toms ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e, rtl8192u: use correct notation to define pointer
On Mon, Oct 26, 2020 at 05:14:35PM +0500, Muhammad Usama Anjum wrote:
> Use pointer notation instead of using array notation as info_element is
> a pointer not array.
>
> Warnings from sparse:
> drivers/staging/rtl8192u/ieee80211/ieee80211.h:1013:51: warning: array of
> flexible structures
> drivers/staging/rtl8192u/ieee80211/ieee80211.h:985:51: warning: array of
> flexible structures
> drivers/staging/rtl8192u/ieee80211/ieee80211.h:963:51: warning: array of
> flexible structures
> drivers/staging/rtl8192u/ieee80211/ieee80211.h:996:51: warning: array of
> flexible structures
> drivers/staging/rtl8192u/ieee80211/ieee80211.h:974:51: warning: array of
> flexible structures
>
> drivers/staging/rtl8192e/rtllib.h:832:48: warning: array of flexible
> structures
> drivers/staging/rtl8192e/rtllib.h:851:48: warning: array of flexible
> structures
> drivers/staging/rtl8192e/rtllib.h:805:48: warning: array of flexible
> structures
> drivers/staging/rtl8192e/rtllib.h:843:48: warning: array of flexible
> structures
> drivers/staging/rtl8192e/rtllib.h:821:48: warning: array of flexible
> structures
>
> Signed-off-by: Muhammad Usama Anjum
> ---
> drivers/staging/rtl8192e/rtllib.h | 10 +-
> drivers/staging/rtl8192u/ieee80211/ieee80211.h | 12 ++--
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtllib.h
> b/drivers/staging/rtl8192e/rtllib.h
> index b84f00b8d18b..1dab9c3d08a8 100644
> --- a/drivers/staging/rtl8192e/rtllib.h
> +++ b/drivers/staging/rtl8192e/rtllib.h
> @@ -802,7 +802,7 @@ struct rtllib_authentication {
> __le16 transaction;
> __le16 status;
> /*challenge*/
> - struct rtllib_info_element info_element[];
> + struct rtllib_info_element *info_element;
> } __packed;
Are you sure these changes are correct? This isn't just a list of
structures after this at the end of the structure?
Please look at commit 5979afa2c4d1 ("staging: Replace zero-length array
with flexible-array member") which made most of these flexible arrays.
This is not a pointer, it really is an array, I think sparse is really
wrong here, be careful.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Fixed issues with alignment to open parenthesis.
On Mon, Oct 19, 2020 at 04:24:51PM +0100, Tabot Kevin wrote: > This patch fixes the following: > - Made sure alignment matched open parenthesis. > > Signed-off-by: Tabot Kevin > --- > drivers/staging/greybus/audio_codec.c | 9 - > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/drivers/staging/greybus/audio_codec.c > b/drivers/staging/greybus/audio_codec.c > index 494aa82..d61e79f 100644 > --- a/drivers/staging/greybus/audio_codec.c > +++ b/drivers/staging/greybus/audio_codec.c > @@ -71,7 +71,7 @@ static int gbaudio_module_enable_tx(struct > gbaudio_codec_info *codec, > i2s_port = 0; /* fixed for now */ > cportid = data->connection->hd_cport_id; > ret = gb_audio_apbridgea_register_cport(data->connection, > - i2s_port, cportid, > + i2s_port, cportid, > AUDIO_APBRIDGEA_DIRECTION_TX); This just looks weird now. Please, just leave it as-is. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/rtl8192u/ieee80211: fix line length exceeds 100 columns
On Tue, Oct 20, 2020 at 08:11:11AM -0700, Elena Afanasova wrote: > Reported by checkpatch.pl. The commit message should be considered like an separate thing from the subject. On my email client, I normally read either just the subject or just the commit message. It looks something like this: https://lore.kernel.org/driverdev-devel/20201020151748.35937-1-eafanas...@gmail.com/T/#t Do you see the subject? It's far away from the commit message. Here is how I would write this commit message: Subject: [PATCH] Staging: rtl8192u: split up long lines Checkpatch complains that these lines are over 100 characters so let's split them up. Some people care about verb tenses or whatever but most maintainers don't. I don't. I only care about if I can basically see what you are changing and why. This patch doesn't affect runtime, but if it did, then I would like some comments about what the bug looks like to the user. Basically if I can understand the commit message then it's fine, and obviously "Reported by checkpatch.pl" is not sufficient to understand what's going on. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: remove commented defines
Remove commented defines from ioctl_linux.c. They are included from include/uapi/linux/wireless.h. Also clears a checkpatch warning. WARNING: Block comments use * on subsequent lines Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c index 6ac904ceb95e..6f42f13a71fa 100644 --- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c +++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c @@ -906,17 +906,6 @@ static int rtw_wx_get_range(struct net_device *dev, /* If the driver doesn't provide this capability to network manager, */ /* the WPA/WPA2 routers can't be chosen in the network manager. */ -/* -#define IW_SCAN_CAPA_NONE 0x00 -#define IW_SCAN_CAPA_ESSID 0x01 -#define IW_SCAN_CAPA_BSSID 0x02 -#define IW_SCAN_CAPA_CHANNEL 0x04 -#define IW_SCAN_CAPA_MODE 0x08 -#define IW_SCAN_CAPA_RATE 0x10 -#define IW_SCAN_CAPA_TYPE 0x20 -#define IW_SCAN_CAPA_TIME 0x40 -*/ - range->enc_capa = IW_ENC_CAPA_WPA | IW_ENC_CAPA_WPA2 | IW_ENC_CAPA_CIPHER_TKIP | IW_ENC_CAPA_CIPHER_CCMP; -- 2.29.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: avoid uninitialized variable use
On Mon, Oct 26, 2020 at 05:11:11PM +0100, Jérôme Pouiller wrote:
> On Monday 26 October 2020 17:02:22 CET Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > Move the added check of the 'band' variable after the
> > initialization. Pointed out by clang with
> >
> > drivers/staging/wfx/data_tx.c:34:19: warning: variable 'band' is
> > uninitialized when used here [-Wuninitialized]
> > if (rate->idx >= band->n_bitrates) {
>
> Hello Arnd,
>
> This patch has already been submitted[1]. I think it is going to be
> applied to staging very soon.
>
> Sorry for the disturbing.
>
> [1]
> https://lore.kernel.org/driverdev-devel/20201019160604.1609180-1-jerome.pouil...@silabs.com/
Sorry for the delay, had to wait until -rc1 was out.
Now queued up in my tree.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/rtl8188eu: fix line length exceeds 100 columns
On Tue, Oct 20, 2020 at 08:17:48AM -0700, Elena Afanasova wrote:
> Reported by checkpatch.pl
>
If I were trying to clean up this driver I would probably take a
different approach.
Just send a patch that introduces line breaks for RT_TRACE() printks.
The RT_TRACE() printks are super ugly, and if you add newlines to them,
it can't make it worse than it already is. Do not change the RT_TRACE()
output.
-("=== curfragnum=%d, pframe = 0x%.2x,
0x%.2x, 0x%.2x, 0x%.2x, 0x%.2x, 0x%.2x, 0x%.2x, 0x%.2x,!!!\n",
+("curfrnum=%d:
%.2x-%.2x-%.2x-%.2x-%.2x-%.2x-%.2x-%.2x\n",
Your change here is an improvement but it requires thinking and
reviewers don't want to look at RT_TRACE(). Make your patches as
uncontroversial as possible.
Then for the other things there are some changes which are good, but in
other places the correct thing is to introduce new functions. So what
I would want instead is a series of patches which do small clean ups
which make the code obviously better, and are not just to make checkpatch
happy.
> Signed-off-by: Elena Afanasova
> ---
> drivers/staging/rtl8188eu/core/rtw_xmit.c | 118 +++---
> 1 file changed, 81 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c
> b/drivers/staging/rtl8188eu/core/rtw_xmit.c
> index 317355f830cb..51769f2ca910 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
> @@ -44,7 +44,9 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct
> adapter *padapter)
> u32 max_xmit_extbuf_size = MAX_XMIT_EXTBUF_SZ;
> u32 num_xmit_extbuf = NR_XMIT_EXTBUFF;
>
> - /* We don't need to memset padapter->XXX to zero, because adapter is
> allocated by vzalloc(). */
> + /* We don't need to memset padapter->XXX to zero,
> + * because adapter is allocated by vzalloc().
> + */
This comment is totally pointless. Kernel devs are expected to
understand what the "z" in vzalloc() means. Just delete it.
>
> spin_lock_init(&pxmitpriv->lock);
>
> @@ -127,7 +129,8 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv,
> struct adapter *padapter)
> res = rtw_os_xmit_resource_alloc(pxmitbuf, (MAX_XMITBUF_SZ +
> XMITBUF_ALIGN_SZ));
> if (res == _FAIL) {
> msleep(10);
> - res = rtw_os_xmit_resource_alloc(pxmitbuf,
> (MAX_XMITBUF_SZ + XMITBUF_ALIGN_SZ));
> + res = rtw_os_xmit_resource_alloc(pxmitbuf,
> (MAX_XMITBUF_SZ +
> +
> XMITBUF_ALIGN_SZ));
Align it like this:
res = rtw_os_xmit_resource_alloc(pxmitbuf,
MAX_XMITBUF_SZ +
XMITBUF_ALIGN_SZ);
The rtw_os_xmit_resource_alloc() function is poorly named.
> if (res == _FAIL)
> goto exit;
> }
> @@ -441,7 +444,9 @@ static s32 update_attrib(struct adapter *padapter, struct
> sk_buff *pkt, struct p
> ((tmp[21] == 67) && (tmp[23] == 68))) {
> /* 68 : UDP BOOTP client */
> /* 67 : UDP BOOTP server */
> - RT_TRACE(_module_rtl871x_xmit_c_,
> _drv_err_, ("== %s: get DHCP Packet\n", __func__));
> + RT_TRACE(_module_rtl871x_xmit_c_,
> _drv_err_,
> + ("== %s:
> get DHCP Packet\n",
> + __func__));
What does this message really mean? The "===" characters don't add
anything. It's probably better to just delete this printk.
> /* Use low rate to send DHCP packet. */
> pattrib->dhcp_pkt = 1;
> }
> @@ -455,7 +460,9 @@ static s32 update_attrib(struct adapter *padapter, struct
> sk_buff *pkt, struct p
> rtw_set_scan_deny(padapter, 3000);
>
> /* If EAPOL , ARP , OR DHCP packet, driver must be in active mode. */
> - if ((pattrib->ether_type == ETH_P_ARP) || (pattrib->ether_type ==
> ETH_P_PAE) || (pattrib->dhcp_pkt == 1))
> + if ((pattrib->ether_type == ETH_P_ARP) ||
> + (pattrib->ether_type == ETH_P_PAE) ||
> + (pattrib->dhcp_pkt == 1))
This change is good.
> rtw_lps_ctrl_wk_cmd(padapter, LPS_CTRL_SPECIAL_PACKET, 1);
>
> mcast = is_multicast_ether_addr(pattrib->ra);
> @@ -466,7 +473,9 @@ static s32 update_attrib(struct adapter *padapter, struct
> sk_buff *pkt, struct p
> } else {
> psta = rtw_get_stainfo(pstapriv, pattrib->ra);
> if (!psta) { /* if we cannot get psta => drrp the pkt */
> -
Re: [PATCH -next] binder: change error code from postive to negative in binder_transaction
Thanks!
On Mon, Oct 26, 2020 at 11:52 AM Zhang Qilong wrote:
>
> Depending on the context, the error return value
> here (extra_buffers_size < added_size) should be
> negative.
>
> Signed-off-by: Zhang Qilong
Acked-by: Martijn Coenen
> ---
> drivers/android/binder.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index b5117576792b..8bbfb9124fa2 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -3103,7 +3103,7 @@ static void binder_transaction(struct binder_proc *proc,
> if (extra_buffers_size < added_size) {
> /* integer overflow of extra_buffers_size */
> return_error = BR_FAILED_REPLY;
> - return_error_param = EINVAL;
> + return_error_param = -EINVAL;
> return_error_line = __LINE__;
> goto err_bad_extra_size;
> }
> --
> 2.17.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH 3/3] staging/rtl8712: use BIT macro
On Tue, Oct 20, 2020 at 07:44:04PM +0100, Matthew Wilcox wrote: > On Tue, Oct 20, 2020 at 11:24:39AM -0700, Elena Afanasova wrote: > > Reported by checkpatch.pl > > Checkpatch is wrong. > > > +++ b/drivers/staging/rtl8712/rtl871x_recv.h > > @@ -8,7 +8,7 @@ > > #define NR_RECVFRAME 256 > > > > #define RXFRAME_ALIGN 8 > > -#define RXFRAME_ALIGN_SZ (1 << RXFRAME_ALIGN) > > +#define RXFRAME_ALIGN_SZ BIT(RXFRAME_ALIGN) Yeah. It's weird to talk about size as a BIT() flag. The RXFRAME_ALIGN is not needed. Just say: -#define RXFRAME_ALIGN 8 -#define RXFRAME_ALIGN_SZ (1 << RXFRAME_ALIGN) +#define RXFRAME_ALIGN_SZ 256 This is literally used for aligning the RX frame. It seems like a crazy thing to me that to aligned at 256 bytes. I would have expected 64 bit alignment or page alignment but not 256 byte alignment... Weird. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: kpc2000: kpc_dma: rearrange lines exceeding 100 columns
On Mon, Oct 26, 2020 at 09:34:53AM +0530, Deepak R Varma wrote: > On Wed, Oct 21, 2020 at 01:01:07PM +0530, Deepak R Varma wrote: > > Hello, > Requesting a review / ack of this patch. > Wait a couple weeks before you ask for feed back. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e, rtl8192u: use correct notation to define pointer
On Tue, Oct 27, 2020 at 12:23:03PM +0100, Greg KH wrote:
> On Mon, Oct 26, 2020 at 05:14:35PM +0500, Muhammad Usama Anjum wrote:
> > Use pointer notation instead of using array notation as info_element is
> > a pointer not array.
> >
> > Warnings from sparse:
> > drivers/staging/rtl8192u/ieee80211/ieee80211.h:1013:51: warning: array of
> > flexible structures
> > drivers/staging/rtl8192u/ieee80211/ieee80211.h:985:51: warning: array of
> > flexible structures
> > drivers/staging/rtl8192u/ieee80211/ieee80211.h:963:51: warning: array of
> > flexible structures
> > drivers/staging/rtl8192u/ieee80211/ieee80211.h:996:51: warning: array of
> > flexible structures
> > drivers/staging/rtl8192u/ieee80211/ieee80211.h:974:51: warning: array of
> > flexible structures
> >
> > drivers/staging/rtl8192e/rtllib.h:832:48: warning: array of flexible
> > structures
> > drivers/staging/rtl8192e/rtllib.h:851:48: warning: array of flexible
> > structures
> > drivers/staging/rtl8192e/rtllib.h:805:48: warning: array of flexible
> > structures
> > drivers/staging/rtl8192e/rtllib.h:843:48: warning: array of flexible
> > structures
> > drivers/staging/rtl8192e/rtllib.h:821:48: warning: array of flexible
> > structures
> >
> > Signed-off-by: Muhammad Usama Anjum
> > ---
> > drivers/staging/rtl8192e/rtllib.h | 10 +-
> > drivers/staging/rtl8192u/ieee80211/ieee80211.h | 12 ++--
> > 2 files changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8192e/rtllib.h
> > b/drivers/staging/rtl8192e/rtllib.h
> > index b84f00b8d18b..1dab9c3d08a8 100644
> > --- a/drivers/staging/rtl8192e/rtllib.h
> > +++ b/drivers/staging/rtl8192e/rtllib.h
> > @@ -802,7 +802,7 @@ struct rtllib_authentication {
> > __le16 transaction;
> > __le16 status;
> > /*challenge*/
> > - struct rtllib_info_element info_element[];
> > + struct rtllib_info_element *info_element;
> > } __packed;
>
> Are you sure these changes are correct? This isn't just a list of
> structures after this at the end of the structure?
Definitely the patch will break things at runtime. I was surprised that
it compiles, but it does.
>
> Please look at commit 5979afa2c4d1 ("staging: Replace zero-length array
> with flexible-array member") which made most of these flexible arrays.
>
> This is not a pointer, it really is an array, I think sparse is really
> wrong here, be careful.
It's an interesting warning message. Sparse is correct that the code
looks strange. If there were ever two or more elements in the array
then the code would break. But since the code only uses a max of one
element then it's fine.
I guess the question is does this warning ever catch bugs in real life?
It seems like that the kind of bug which would be caught in testing so
static analysis is not going to be useful.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 02/14] phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI CSI-2
Hi,
On Tue, Oct 27, 2020 at 10:23:26AM +0100, Paul Kocialkowski wrote:
> On Mon 26 Oct 20, 16:38, Maxime Ripard wrote:
> > On Fri, Oct 23, 2020 at 07:45:34PM +0200, 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 the Allwinner BSP implementation.
> >
> > Mentionning which BSP you took this from would be helpful
>
> Sure! It's from the Github repo linked from https://linux-sunxi.org/V3s.
> Would you like that I mention this URL explicitly or would it be enough to
> mention "Allwinner's V3s Linux SDK" as they seem to call it?
Yeah, that would be great
> > > +static int sun6i_dphy_rx_power_on(struct sun6i_dphy *dphy)
> > > +{
> > > + /* Physical clock rate is actually half of symbol rate with DDR. */
> > > + unsigned long mipi_symbol_rate = dphy->config.hs_clk_rate;
> > > + unsigned long dphy_clk_rate;
> > > + unsigned int rx_dly;
> > > + unsigned int lprst_dly;
> > > + u32 value;
> > > +
> > > + dphy_clk_rate = clk_get_rate(dphy->mod_clk);
> > > + if (!dphy_clk_rate)
> > > + return -1;
> >
> > Returning -1 is weird here?
>
> What do you think would be a more appropriate error code to return?
> It looks like some other drivers return -EINVAL when that happens (but many
> don't do the check).
Yeah, EINVAL at least is better than ENOPERM
> > > +
> > > + /* Hardcoded timing parameters from the Allwinner BSP. */
> > > + regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME0_REG,
> > > + SUN6I_DPHY_RX_TIME0_HS_RX_SYNC(255) |
> > > + SUN6I_DPHY_RX_TIME0_HS_RX_CLK_MISS(255) |
> > > + SUN6I_DPHY_RX_TIME0_LP_RX(255));
> > > +
> > > + /*
> > > + * Formula from the Allwinner BSP, with hardcoded coefficients
> > > + * (probably internal divider/multiplier).
> > > + */
> > > + rx_dly = 8 * (unsigned int)(dphy_clk_rate / (mipi_symbol_rate / 8));
> > > +
> > > + /*
> > > + * The Allwinner BSP has an alternative formula for LP_RX_ULPS_WP:
> > > + * lp_ulps_wp_cnt = lp_ulps_wp_ms * lp_clk / 1000
> > > + * but does not use it and hardcodes 255 instead.
> > > + */
> > > + regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME1_REG,
> > > + SUN6I_DPHY_RX_TIME1_RX_DLY(rx_dly) |
> > > + SUN6I_DPHY_RX_TIME1_LP_RX_ULPS_WP(255));
> > > +
> > > + /* HS_RX_ANA0 value is hardcoded in the Allwinner BSP. */
> > > + regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME2_REG,
> > > + SUN6I_DPHY_RX_TIME2_HS_RX_ANA0(4));
> > > +
> > > + /*
> > > + * Formula from the Allwinner BSP, with hardcoded coefficients
> > > + * (probably internal divider/multiplier).
> > > + */
> > > + lprst_dly = 4 * (unsigned int)(dphy_clk_rate / (mipi_symbol_rate / 2));
> > > +
> > > + regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME3_REG,
> > > + SUN6I_DPHY_RX_TIME3_LPRST_DLY(lprst_dly));
> > > +
> > > + /* Analog parameters are hardcoded in the Allwinner BSP. */
> > > + regmap_write(dphy->regs, SUN6I_DPHY_ANA0_REG,
> > > + SUN6I_DPHY_ANA0_REG_PWS |
> > > + SUN6I_DPHY_ANA0_REG_SLV(7) |
> > > + SUN6I_DPHY_ANA0_REG_SFB(2));
> > > +
> > > + regmap_write(dphy->regs, SUN6I_DPHY_ANA1_REG,
> > > + SUN6I_DPHY_ANA1_REG_SVTT(4));
> > > +
> > > + regmap_write(dphy->regs, SUN6I_DPHY_ANA4_REG,
> > > + SUN6I_DPHY_ANA4_REG_DMPLVC |
> > > + SUN6I_DPHY_ANA4_REG_DMPLVD(1));
> > > +
> > > + regmap_write(dphy->regs, SUN6I_DPHY_ANA2_REG,
> > > + SUN6I_DPHY_ANA2_REG_ENIB);
> > > +
> > > + regmap_write(dphy->regs, SUN6I_DPHY_ANA3_REG,
> > > + SUN6I_DPHY_ANA3_EN_LDOR |
> > > + SUN6I_DPHY_ANA3_EN_LDOC |
> > > + SUN6I_DPHY_ANA3_EN_LDOD);
> > > +
> > > + /*
> > > + * Delay comes from the Allwinner BSP, likely for internal regulator
> > > + * ramp-up.
> > > + */
> > > + udelay(3);
> > > +
> > > + value = SUN6I_DPHY_RX_CTL_EN_DBC | SUN6I_DPHY_RX_CTL_RX_CLK_FORCE;
> > > +
> > > + /*
> > > + * Rx data lane force-enable bits are used as regular RX enable by the
> > > + * Allwinner BSP.
> > > + */
> > > + if (dphy->config.lanes >= 1)
> > > + value |= SUN6I_DPHY_RX_CTL_RX_D0_FORCE;
> > > + if (dphy->config.lanes >= 2)
> > > + value |= SUN6I_DPHY_RX_CTL_RX_D1_FORCE;
> > > + if (dphy->config.lanes >= 3)
> > > + value |= SUN6I_DPHY_RX_CTL_RX_D2_FORCE;
> > > + if (dphy->config.lanes == 4)
> > > + value |= SUN6I_DPHY_RX_CTL_RX_D3_FORCE;
> > > +
> > > + regmap_write(dphy->regs, SUN6I_DPHY_RX_CTL_REG, value);
> > > +
> > > + regmap_write(dphy->regs, SUN6I_DPHY_GCTL_REG,
> > > + SUN6I_DPHY_GCTL_LANE_NUM(dphy->config.lanes) |
> > > + SUN6I_DPHY_GCTL_EN);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int sun6i_dphy_power_on(struct phy *phy)
> > > +{
> > > + struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> > >
Re: [PATCH 05/14] media: sun6i-csi: Only configure the interface data width for parallel
On Tue, Oct 27, 2020 at 10:31:19AM +0100, Paul Kocialkowski wrote:
> Hi,
>
> On Mon 26 Oct 20, 17:00, Maxime Ripard wrote:
> > On Fri, Oct 23, 2020 at 07:45:37PM +0200, Paul Kocialkowski wrote:
> > > Bits related to the interface data width do not have any effect when
> > > the CSI controller is taking input from the MIPI CSI-2 controller.
> >
> > I guess it would be clearer to mention that the data width is only
> > applicable for parallel here.
>
> Understood, will change the wording in the next version.
>
> > > In prevision of adding support for this case, set these bits
> > > conditionally so there is no ambiguity.
> > >
> > > Co-developed-by: Kévin L'hôpital
> > > Signed-off-by: Kévin L'hôpital
> > > Signed-off-by: Paul Kocialkowski
> > > ---
> > > .../platform/sunxi/sun6i-csi/sun6i_csi.c | 42 +++
> > > 1 file changed, 25 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > index 5d2389a5cd17..a876a05ea3c7 100644
> > > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > @@ -378,8 +378,13 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev
> > > *sdev)
> > > unsigned char bus_width;
> > > u32 flags;
> > > u32 cfg;
> > > + bool input_parallel = false;
> > > bool input_interlaced = false;
> > >
> > > + if (endpoint->bus_type == V4L2_MBUS_PARALLEL ||
> > > + endpoint->bus_type == V4L2_MBUS_BT656)
> > > + input_parallel = true;
> > > +
> > > if (csi->config.field == V4L2_FIELD_INTERLACED
> > > || csi->config.field == V4L2_FIELD_INTERLACED_TB
> > > || csi->config.field == V4L2_FIELD_INTERLACED_BT)
> > > @@ -395,6 +400,26 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev
> > > *sdev)
> > >CSI_IF_CFG_HREF_POL_MASK | CSI_IF_CFG_FIELD_MASK |
> > >CSI_IF_CFG_SRC_TYPE_MASK);
> > >
> > > + if (input_parallel) {
> > > + switch (bus_width) {
> > > + case 8:
> > > + cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
> > > + break;
> > > + case 10:
> > > + cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
> > > + break;
> > > + case 12:
> > > + cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
> > > + break;
> > > + case 16: /* No need to configure DATA_WIDTH for 16bit */
> > > + break;
> > > + default:
> > > + dev_warn(sdev->dev, "Unsupported bus width: %u\n",
> > > + bus_width);
> > > + break;
> > > + }
> > > + }
> > > +
> > > if (input_interlaced)
> > > cfg |= CSI_IF_CFG_SRC_TYPE_INTERLACED;
> > > else
> > > @@ -440,23 +465,6 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev
> > > *sdev)
> > > break;
> > > }
> > >
> > > - switch (bus_width) {
> > > - case 8:
> > > - cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
> > > - break;
> > > - case 10:
> > > - cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
> > > - break;
> > > - case 12:
> > > - cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
> > > - break;
> > > - case 16: /* No need to configure DATA_WIDTH for 16bit */
> > > - break;
> > > - default:
> > > - dev_warn(sdev->dev, "Unsupported bus width: %u\n", bus_width);
> > > - break;
> > > - }
> > > -
> >
> > Is there any reason to move it around?
>
> The main reason is cosmetics: input_parallel is introduced to match the
> already
> existing input_interlaced variable, so it made sense to me to have both of
> these
> conditionals one after the other instead of spreading them randomly.
>
> I can mention this in the commit log if you prefer.
Yeah, that would great
Maxime
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: fieldbus: Use %pM format specifier for MAC addresses
Convert to %pM instead of using custom code. Signed-off-by: Andy Shevchenko --- v2: dropped struct removal (Sven), rebased on top of v5.10-rc1 drivers/staging/fieldbus/anybuss/hms-profinet.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/staging/fieldbus/anybuss/hms-profinet.c b/drivers/staging/fieldbus/anybuss/hms-profinet.c index 31c43a0a5776..eca7d97b8e85 100644 --- a/drivers/staging/fieldbus/anybuss/hms-profinet.c +++ b/drivers/staging/fieldbus/anybuss/hms-profinet.c @@ -66,10 +66,7 @@ static int profi_id_get(struct fieldbus_dev *fbdev, char *buf, sizeof(response)); if (ret < 0) return ret; - return snprintf(buf, max_size, "%02X:%02X:%02X:%02X:%02X:%02X\n", - response.addr[0], response.addr[1], - response.addr[2], response.addr[3], - response.addr[4], response.addr[5]); + return snprintf(buf, max_size, "%pM\n", response.addr); } static bool profi_enable_get(struct fieldbus_dev *fbdev) -- 2.28.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/14] dt-bindings: media: i2c: Add A31 MIPI CSI-2 bindings documentation
On Tue, Oct 27, 2020 at 10:52:21AM +0100, Paul Kocialkowski wrote: > Hi, > > On Mon 26 Oct 20, 17:14, Maxime Ripard wrote: > > i2c? :) > > Oops, good catch! > > > On Fri, Oct 23, 2020 at 07:45:39PM +0200, 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 | 168 ++ > > > 1 file changed, 168 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 ..9adc0bc27033 > > > --- /dev/null > > > +++ > > > b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml > > > @@ -0,0 +1,168 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%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 > > > + > > > + 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 > > > + > > > + bus-type: > > > +const: 4 > > > + > > > + clock-lanes: > > > +maxItems: 1 > > > + > > > + data-lanes: > > > +minItems: 1 > > > +maxItems: 4 > > > + > > > +required: > > > + - bus-type > > > + - data-lanes > > > + - remote-endpoint > > > + > > > +additionalProperties: false > > > + > > > +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 > > > + > > > + bus-type: > > > +const: 4 > > > > That one seems a bit weird. If the input and output ports are using the > > same format, what is that "bridge" supposed to be doing? > > Fair enough. What this represents is the internal link (likely a FIFO) between > the two controllers. It is definitely not a MIPI CSI-2 bus but there's no > mbus type for an internal link (probably because it's not a bus after all). > > Note that on the CSI controller side, we need the bus-type to be set to 4 for > it > to properly select the MIPI CSI-2 input. So it just felt more logical to have > the same on the other side of the endpoint. On the other hand, we can just > remove it on the MIPI CSI-2 controller side since it won't check it and have > it > fallback to the unknown mbus type. > > But that would make the types inconsistent on the two sides of the link. > I don't think V4L2 will complain about it at the moment, but it would also > make > sense that it does eventually. > > What do you think? There's still the same issue though, it doesn't make any sense that a bridge doesn't change the bus type. If it really did, we wouldn't need that in the first place. What you want to check in your driver is whether the subdev you're connected to has a sink pad that uses MIPI-CSI Maxime > > > +additionalProperties: false > > > + > > > +required: > > > + - endpoint > > > + > > > +
[RFC] wimax: move out to staging
From: Arnd Bergmann
There are no known users of this driver as of October 2020, and it will
be removed unless someone turns out to still need it in future releases.
According to https://en.wikipedia.org/wiki/List_of_WiMAX_networks, there
have been many public wimax networks, but it appears that these entries
are all stale, after everyone has migrated to LTE or discontinued their
service altogether.
NetworkManager appears to have dropped userspace support in 2015
https://bugzilla.gnome.org/show_bug.cgi?id=747846, the
www.linuxwimax.org
site had already shut down earlier.
WiMax is apparently still being deployed on airport campus networks
("AeroMACS"), but in a frequency band that was not supported by the old
Intel 2400m (used in Sandy Bridge laptops and earlier), which is the
only driver using the kernel's wimax stack.
Move all files into drivers/staging/wimax, including the uapi header
files and documentation, to make it easier to remove it when it gets
to that. Only minimal changes are made to the source files, in order
to make it possible to port patches across the move.
Also remove the MAINTAINERS entry that refers to a broken mailing
list and website.
Suggested-by: Inaky Perez-Gonzalez
Signed-off-by: Arnd Bergmann
---
Documentation/admin-guide/index.rst | 1 -
Documentation/networking/kapi.rst | 21 --
.../translations/zh_CN/admin-guide/index.rst | 1 -
MAINTAINERS | 22 ---
drivers/net/Kconfig | 2 --
drivers/net/wimax/Kconfig | 18 ---
drivers/net/wimax/Makefile| 2 --
drivers/staging/Kconfig | 2 ++
drivers/staging/Makefile | 1 +
.../staging/wimax/Documentation}/i2400m.rst | 0
.../staging/wimax/Documentation}/index.rst| 0
.../staging/wimax/Documentation}/wimax.rst| 0
{net => drivers/staging}/wimax/Kconfig| 6 +
{net => drivers/staging}/wimax/Makefile | 2 ++
drivers/staging/wimax/TODO| 16 ++
{net => drivers/staging}/wimax/debug-levels.h | 2 +-
{net => drivers/staging}/wimax/debugfs.c | 2 +-
drivers/{net => staging}/wimax/i2400m/Kconfig | 0
.../{net => staging}/wimax/i2400m/Makefile| 0
.../{net => staging}/wimax/i2400m/control.c | 2 +-
.../wimax/i2400m/debug-levels.h | 2 +-
.../{net => staging}/wimax/i2400m/debugfs.c | 0
.../{net => staging}/wimax/i2400m/driver.c| 2 +-
drivers/{net => staging}/wimax/i2400m/fw.c| 0
.../wimax/i2400m/i2400m-usb.h | 0
.../{net => staging}/wimax/i2400m/i2400m.h| 4 ++--
.../staging/wimax/i2400m/linux-wimax-i2400m.h | 0
.../{net => staging}/wimax/i2400m/netdev.c| 0
.../{net => staging}/wimax/i2400m/op-rfkill.c | 2 +-
drivers/{net => staging}/wimax/i2400m/rx.c| 0
drivers/{net => staging}/wimax/i2400m/sysfs.c | 0
drivers/{net => staging}/wimax/i2400m/tx.c| 0
.../wimax/i2400m/usb-debug-levels.h | 2 +-
.../{net => staging}/wimax/i2400m/usb-fw.c| 0
.../{net => staging}/wimax/i2400m/usb-notif.c | 0
.../{net => staging}/wimax/i2400m/usb-rx.c| 0
.../{net => staging}/wimax/i2400m/usb-tx.c| 0
drivers/{net => staging}/wimax/i2400m/usb.c | 2 +-
{net => drivers/staging}/wimax/id-table.c | 2 +-
.../staging/wimax/linux-wimax-debug.h | 2 +-
.../staging/wimax/linux-wimax.h | 0
.../staging/wimax/net-wimax.h | 2 +-
{net => drivers/staging}/wimax/op-msg.c | 2 +-
{net => drivers/staging}/wimax/op-reset.c | 4 ++--
{net => drivers/staging}/wimax/op-rfkill.c| 4 ++--
{net => drivers/staging}/wimax/op-state-get.c | 4 ++--
{net => drivers/staging}/wimax/stack.c| 2 +-
.../staging}/wimax/wimax-internal.h | 2 +-
net/Kconfig | 2 --
net/Makefile | 1 -
50 files changed, 49 insertions(+), 92 deletions(-)
delete mode 100644 drivers/net/wimax/Kconfig
delete mode 100644 drivers/net/wimax/Makefile
rename {Documentation/admin-guide/wimax =>
drivers/staging/wimax/Documentation}/i2400m.rst (100%)
rename {Documentation/admin-guide/wimax =>
drivers/staging/wimax/Documentation}/index.rst (100%)
rename {Documentation/admin-guide/wimax =>
drivers/staging/wimax/Documentation}/wimax.rst (100%)
rename {net => drivers/staging}/wimax/Kconfig (94%)
rename {net => drivers/staging}/wimax/Makefile (83%)
create mode 100644 drivers/staging/wimax/TODO
rename {net => drivers/staging}/wimax/debug-levels.h (96%)
rename {net => drivers/staging}/wimax/debugfs.c (97%)
rename drivers/{net => staging}/wimax/i2400m/Kconfig (100%)
rename drivers/{net => staging}/wimax/i2400m/Makefile (100%)
rename drivers/{net => staging}/wimax/i2400m/control.c (99%)
rename drivers/{net => staging}/wimax/i2400m/debug-levels.h (96%)
rename drivers/{net
Benachrichtigung der Gewinner !!!.
Benachrichtigung der Gewinner !!!. Ihre E-Mail-ID hat Ђ 150.000,00 Euro (ein hundertfьnfzigtausend Euro) in LottoMax International Charity program.Ref Well Sp gewonnen /179/0-39/44/4-07/ES.Lucky No.9 / 44/15/27 / 49.For Weitere Informationen und Antragsverfahren , benutzen Sie bitte unser Agent unten in Verbindung; National Post-Code Agency.S.L Mr.Jaime Sanchez E-mail: infocod...@aol.com Mit Ihren vollstдndigen Namen, Adresse, Alter, Beruf, Telefonnummern Senden Sie Ihre Antwort auf diese E-Mail: infocod...@aol.com Hinweis: Dies ist eine internationale Lotterie-Programm. Dieser Eintrag wurde automatisch aus dem Englischen ins Deutschland ьbersetzt. Herzlichen Glьckwunsch ! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Android: binder: added a missing blank line after declaration
Fixed a coding style issue.
Signed-off-by: Andrew Bridges
---
drivers/android/binder.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index b5117576792b..3241d233a12d 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -3614,6 +3614,7 @@ static int binder_thread_write(struct binder_proc *proc,
ret = -1;
if (increment && !target) {
struct binder_node *ctx_mgr_node;
+
mutex_lock(&context->context_mgr_node_lock);
ctx_mgr_node = context->binder_context_mgr_node;
if (ctx_mgr_node) {
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-linus] BUILD SUCCESS 7e97e4cbf30026b49b0145c3bfe06087958382c5
mpc8313_rdb_defconfig ia64generic_defconfig m68k m5275evb_defconfig m68km5272c3_defconfig arm moxart_defconfig arm footbridge_defconfig arm colibri_pxa270_defconfig powerpc motionpro_defconfig mips gcw0_defconfig powerpc mpc8272_ads_defconfig sh r7780mp_defconfig mipsar7_defconfig s390 zfcpdump_defconfig sh se7705_defconfig mipsqi_lb60_defconfig h8300 h8s-sim_defconfig powerpc pasemi_defconfig mips bigsur_defconfig xtensasmp_lx200_defconfig arm exynos_defconfig mipsmalta_kvm_guest_defconfig sh se7750_defconfig powerpc bluestone_defconfig powerpc lite5200b_defconfig arm mv78xx0_defconfig xtensa defconfig sh rsk7264_defconfig nds32 allnoconfig arm vf610m4_defconfig mips fuloong2e_defconfig mips mtx1_defconfig m68kmac_defconfig shdreamcast_defconfig powerpc ppa8548_defconfig powerpc mpc836x_mds_defconfig arm imx_v6_v7_defconfig arm u8500_defconfig mips allmodconfig powerpc allnoconfig powerpc chrp32_defconfig mipsmaltaup_defconfig mips mpc30x_defconfig sh lboxre2_defconfig mips ip28_defconfig mips allyesconfig arm spitz_defconfig mips rb532_defconfig ia64 allmodconfig ia64defconfig m68k allmodconfig m68k allyesconfig nios2 defconfig arc allyesconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig arc defconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparc defconfig i386defconfig powerpc allyesconfig powerpc allmodconfig i386 randconfig-a002-20201026 i386 randconfig-a003-20201026 i386 randconfig-a005-20201026 i386 randconfig-a001-20201026 i386 randconfig-a006-20201026 i386 randconfig-a004-20201026 i386 randconfig-a002-20201027 i386 randconfig-a003-20201027 i386 randconfig-a005-20201027 i386 randconfig-a001-20201027 i386 randconfig-a006-20201027 i386 randconfig-a004-20201027 x86_64 randconfig-a011-20201026 x86_64 randconfig-a013-20201026 x86_64 randconfig-a016-20201026 x86_64 randconfig-a015-20201026 x86_64 randconfig-a012-20201026 x86_64 randconfig-a014-20201026 i386 randconfig-a016-20201027 i386 randconfig-a015-20201027 i386 randconfig-a014-20201027 i386 randconfig-a012-20201027 i386 randconfig-a013-20201027 i386 randconfig-a011-20201027 i386 randconfig-a016-20201026 i386 randconfig-a015-20201026 i386 randconfig-a014-20201026 i386 randconfig-a012-20201026 i386 randconfig-a013-20201026 i386 randconfig-a011-20201026 x86_64 randconfig-a001-20201027 x86_64 randconfig-a003-20201027 x86_64 randconfig-a002-20201027 x86_64 randconfig-a006-20201027 x86_64 randconfig-a004-20201027 x86_64 randconfig-a005-20201027 riscvnommu_k210_defconfig riscvallyesconfig riscv allnoconfig riscv
[staging:staging-testing] BUILD SUCCESS af702094a63e8d56f125f473461fe3b620fba1fd
mpc837x_rdb_defconfig arm imx_v6_v7_defconfig arm u8500_defconfig mips allmodconfig powerpc allnoconfig ia64 allmodconfig ia64defconfig m68k allmodconfig m68k allyesconfig nios2 defconfig arc allyesconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig h8300allyesconfig arc defconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparc defconfig i386defconfig mips allyesconfig powerpc allyesconfig powerpc allmodconfig i386 randconfig-a002-20201026 i386 randconfig-a003-20201026 i386 randconfig-a005-20201026 i386 randconfig-a001-20201026 i386 randconfig-a006-20201026 i386 randconfig-a004-20201026 i386 randconfig-a002-20201027 i386 randconfig-a003-20201027 i386 randconfig-a005-20201027 i386 randconfig-a001-20201027 i386 randconfig-a006-20201027 i386 randconfig-a004-20201027 x86_64 randconfig-a011-20201026 x86_64 randconfig-a013-20201026 x86_64 randconfig-a016-20201026 x86_64 randconfig-a015-20201026 x86_64 randconfig-a012-20201026 x86_64 randconfig-a014-20201026 i386 randconfig-a016-20201027 i386 randconfig-a015-20201027 i386 randconfig-a014-20201027 i386 randconfig-a012-20201027 i386 randconfig-a013-20201027 i386 randconfig-a011-20201027 i386 randconfig-a016-20201026 i386 randconfig-a015-20201026 i386 randconfig-a014-20201026 i386 randconfig-a012-20201026 i386 randconfig-a013-20201026 i386 randconfig-a011-20201026 riscvnommu_k210_defconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a001-20201026 x86_64 randconfig-a003-20201026 x86_64 randconfig-a002-20201026 x86_64 randconfig-a006-20201026 x86_64 randconfig-a004-20201026 x86_64 randconfig-a005-20201026 x86_64 randconfig-a011-20201027 x86_64 randconfig-a013-20201027 x86_64 randconfig-a016-20201027 x86_64 randconfig-a015-20201027 x86_64 randconfig-a012-20201027 x86_64 randconfig-a014-20201027 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: rtl8723bs: core: rtw_cmd: Fixed multiple brace coding style issues
Fixed multiple brace coding style issues in rtw_cmd.c
Signed-off-by: Manuel Palenzuela
---
drivers/staging/rtl8723bs/core/rtw_cmd.c | 27
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c
b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index 3ac286bbfc4e..4cf09d947d32 100644
--- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c
@@ -229,9 +229,8 @@ void _rtw_free_evt_priv(struct evt_priv *pevtpriv)
while (!rtw_cbuf_empty(pevtpriv->c2h_queue)) {
void *c2h = rtw_cbuf_pop(pevtpriv->c2h_queue);
- if (c2h && c2h != (void *)pevtpriv) {
+ if (c2h && c2h != (void *)pevtpriv)
kfree(c2h);
- }
}
kfree(pevtpriv->c2h_queue);
@@ -339,9 +338,8 @@ int rtw_enqueue_cmd(struct cmd_priv *pcmdpriv, struct
cmd_obj *cmd_obj)
int res = _FAIL;
struct adapter *padapter = pcmdpriv->padapter;
- if (cmd_obj == NULL) {
+ if (cmd_obj == NULL)
goto exit;
- }
cmd_obj->padapter = padapter;
@@ -543,9 +541,8 @@ int rtw_cmd_thread(void *context)
if (pcmd->cmdcode == GEN_CMD_CODE(_Set_Drv_Extra)) {
extra_parm = (struct drvextra_cmd_parm *)pcmd->parmbuf;
- if (extra_parm->pbuf && extra_parm->size > 0) {
+ if (extra_parm->pbuf && extra_parm->size > 0)
kfree(extra_parm->pbuf);
- }
}
rtw_free_cmd_obj(pcmd);
@@ -571,9 +568,8 @@ u8 rtw_sitesurvey_cmd(struct adapter *padapter, struct
ndis_802_11_ssid *ssid,
struct cmd_priv *pcmdpriv = &padapter->cmdpriv;
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
- if (check_fwstate(pmlmepriv, _FW_LINKED) == true) {
+ if (check_fwstate(pmlmepriv, _FW_LINKED) == true)
rtw_lps_ctrl_wk_cmd(padapter, LPS_CTRL_SCAN, 1);
- }
ph2c = rtw_zmalloc(sizeof(struct cmd_obj));
if (ph2c == NULL)
@@ -826,9 +822,8 @@ u8 rtw_joinbss_cmd(struct adapter *padapter, struct
wlan_network *pnetwork)
/* If not, we have to copy the connecting AP's MAC address to it so
that */
/* the driver just has the bssid information for PMKIDList searching.
*/
- if (pmlmepriv->assoc_by_bssid == false) {
+ if (pmlmepriv->assoc_by_bssid == false)
memcpy(&pmlmepriv->assoc_bssid[0],
&pnetwork->network.MacAddress[0], ETH_ALEN);
- }
psecnetwork->IELength = rtw_restruct_sec_ie(padapter,
&pnetwork->network.IEs[0], &psecnetwork->IEs[0], pnetwork->network.IELength);
@@ -1349,9 +1344,8 @@ u8 traffic_status_watchdog(struct adapter *padapter, u8
from_timer)
/* DBG_871X("Set TrafficTransitionCount to
%d\n", pmlmepriv->LinkDetectInfo.TrafficTransitionCount); */
- if
(pmlmepriv->LinkDetectInfo.TrafficTransitionCount >
30/*TrafficTransitionLevel*/) {
+ if
(pmlmepriv->LinkDetectInfo.TrafficTransitionCount >
30/*TrafficTransitionLevel*/)
pmlmepriv->LinkDetectInfo.TrafficTransitionCount = 30;
- }
}
} else {
/* DBG_871X("(+)Tx = %d, Rx = %d\n",
pmlmepriv->LinkDetectInfo.NumTxOkInPeriod,
pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod); */
@@ -1405,9 +1399,8 @@ static void dynamic_chk_wk_hdl(struct adapter *padapter)
struct mlme_priv *pmlmepriv;
pmlmepriv = &(padapter->mlmepriv);
- if (check_fwstate(pmlmepriv, WIFI_AP_STATE) == true) {
+ if (check_fwstate(pmlmepriv, WIFI_AP_STATE) == true)
expire_timeout_chk(padapter);
- }
/* for debug purpose */
_linked_info_dump(padapter);
@@ -1606,9 +1599,8 @@ static void rtw_lps_change_dtim_hdl(struct adapter
*padapter, u8 dtim)
static void rtw_dm_ra_mask_hdl(struct adapter *padapter, struct sta_info *psta)
{
- if (psta) {
+ if (psta)
set_sta_rate(padapter, psta);
- }
}
u8 rtw_dm_ra_mask_wk_cmd(struct adapter *padapter, u8 *psta)
@@ -1977,9 +1969,8 @@ u8 rtw_drvextra_cmd_hdl(struct adapter *padapter,
unsigned char *pbuf)
break;
}
- if (pdrvextra_cmd->pbuf && pdrvextra_cmd->size > 0) {
+ if (pdrvextra_cmd->pbuf && pdrvextra_cmd->size > 0)
kfree(pdrvextra_cmd->pbuf);
- }
return H2C_SUCCESS;
}
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
From Raden Mas.,
Peace Be Unto You I am Ichwan Raden Mas, the project Engineer with Al Shafar General Contracting (ASGC) a Construction Company here in Abu Dhabi U.A.E, some years back my organization awarded contracts to some foreign firms and this contract was over inflated over a period of years to the tune of eight million five hundred thousand America dollars in order for me to benefit from this contract. However the original contractors have been paid their contract sum and the accrued balance which is eight million five hundred thousand America dollars have been lying in a suspense account in one of the Bank in awaiting remittance. I wish to have a deal with you as regards to this unpaid fund as all datas are correct and it is my duty to recommend the transfer of these funds to the company's contract review board therefore I use this opportunity to write you based on the instructions received three days ago from the to submit the list of payment the company's reports/expenditures and audited reports of revenues before the end of next week. If you AGREE with my offer, I want you to send to me now your FULL NAME: FULL ADDRESS : and a DIRECT TELEPHONE NUMBER: and this business will commence without delay as I will proceed to fix your name on the payment list instantly for approval before the end of next week. I hope you do not reject this offer as I await your reply soon. Thank You Ichwan Raden Mas ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e, rtl8192u: use correct notation to define pointer
On Tue, Oct 27, 2020 at 12:23:03PM +0100, Greg KH wrote:
>
> Are you sure these changes are correct? This isn't just a list of
> structures after this at the end of the structure?
>
> Please look at commit 5979afa2c4d1 ("staging: Replace zero-length array
> with flexible-array member") which made most of these flexible arrays.
>
> This is not a pointer, it really is an array, I think sparse is really
> wrong here, be careful.
Sparse's warning is not about changing the definition of this member
as if it was the argument of a function. It's about how can you use
an array of structure when this structure has a flexible member.
It's a recent warning, added purposely to catch this.
See
https://lore.kernel.org/r/CAHk-=wgjz05ap8vqdzwdwjvwvtzioytc6cnnb8gneqzenfm...@mail.gmail.com
-- Luc
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] wimax: move out to staging
On Tue, Oct 27, 2020 at 10:20:13PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> There are no known users of this driver as of October 2020, and it will
> be removed unless someone turns out to still need it in future releases.
>
> According to https://en.wikipedia.org/wiki/List_of_WiMAX_networks, there
> have been many public wimax networks, but it appears that these entries
> are all stale, after everyone has migrated to LTE or discontinued their
> service altogether.
>
> NetworkManager appears to have dropped userspace support in 2015
> https://bugzilla.gnome.org/show_bug.cgi?id=747846, the
> www.linuxwimax.org
> site had already shut down earlier.
>
> WiMax is apparently still being deployed on airport campus networks
> ("AeroMACS"), but in a frequency band that was not supported by the old
> Intel 2400m (used in Sandy Bridge laptops and earlier), which is the
> only driver using the kernel's wimax stack.
>
> Move all files into drivers/staging/wimax, including the uapi header
> files and documentation, to make it easier to remove it when it gets
> to that. Only minimal changes are made to the source files, in order
> to make it possible to port patches across the move.
>
> Also remove the MAINTAINERS entry that refers to a broken mailing
> list and website.
>
> Suggested-by: Inaky Perez-Gonzalez
> Signed-off-by: Arnd Bergmann
Is this ok for me to take through the staging tree? If so, I need an
ack from the networking maintainers.
If not, feel free to send it through the networking tree and add:
Acked-by: Greg Kroah-Hartman
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
