Re: [PATCH] block: convert tasklets to use new tasklet_setup() API

[Allen Pais]

On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
 wrote:
>
> On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
> > > [...]
> > > > > Since both threads seem to have petered out, let me suggest in
> > > > > kernel.h:
> > > > >
> > > > > #define cast_out(ptr, container, member) \
> > > > > container_of(ptr, typeof(*container), member)
> > > > >
> > > > > It does what you want, the argument order is the same as
> > > > > container_of with the only difference being you name the
> > > > > containing structure instead of having to specify its type.
> > > >
> > > > Not to incessantly bike shed on the naming, but I don't like
> > > > cast_out, it's not very descriptive. And it has connotations of
> > > > getting rid of something, which isn't really true.
> > >
> > > Um, I thought it was exactly descriptive: you're casting to the
> > > outer container.  I thought about following the C++ dynamic casting
> > > style, so out_cast(), but that seemed a bit pejorative.  What about
> > > outer_cast()?
> > >
> > > > FWIW, I like the from_ part of the original naming, as it has
> > > > some clues as to what is being done here. Why not just
> > > > from_container()? That should immediately tell people what it
> > > > does without having to look up the implementation, even before
> > > > this becomes a part of the accepted coding norm.
> > >
> > > I'm not opposed to container_from() but it seems a little less
> > > descriptive than outer_cast() but I don't really care.  I always
> > > have to look up container_of() when I'm using it so this would just
> > > be another macro of that type ...
> > >
> >
> >  So far we have a few which have been suggested as replacement
> > for from_tasklet()
> >
> > - out_cast() or outer_cast()
> > - from_member().
> > - container_from() or from_container()
> >
> > from_container() sounds fine, would trimming it a bit work? like
> > from_cont().
>
> I'm fine with container_from().  It's the same form as container_of()
> and I think we need urgent agreement to not stall everything else so
> the most innocuous name is likely to get the widest acceptance.

Kees,

  Will you be  sending the newly proposed API to Linus? I have V2
which uses container_from()
ready to be sent out.

Thanks.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: qlge: fix build breakage with dumping enabled

[Benjamin Poirier]

On 2020-08-25 19:16 +0800, Coiby Xu wrote:
[...]
> > > @@ -1630,7 +1630,7 @@ void ql_dump_wqicb(struct wqicb *wqicb)
> > >  (unsigned long long)le64_to_cpu(wqicb->cnsmr_idx_addr));
> > >  }
> > > 
> > > -void ql_dump_tx_ring(struct tx_ring *tx_ring)
> > > +void ql_dump_tx_ring(struct ql_adapter *qdev, struct tx_ring *tx_ring)
> > >  {
> > 
> > This can be fixed without adding another argument:
> > struct ql_adapter *qdev;
> > 
> > if (!tx_ring)
> > return;
> > 
> > qdev = tx_ring->qdev;
> > 
> > ... similar comment for the other instances.
> 
> Thank you for the simpler solution!
> 
> For QL_OB_DUMP and QL_IB_DUMP, `struct ql_adapter *qdev` can't be
> obtained via container_of. So qdev are still directly passed to these
> functions.

That's right; sorry I didn't check those functions earlier.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: media-atomisp : fix "dubious: !x | !y" sparse warning

[Anant Thazhemadam]

Upon running sparse, "warning: dubious: !x | !y" is brought to notice
for this file. This patch fixes that warning.

If there's a specific reason that this change is considered undesirable, 
please do let me know why.
Thanks.

Signed-off-by: Anant Thazhemadam 
---
 .../media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c 
b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c
index 358cb7d2cd4c..3b850bb2d39d 100644
--- a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c
+++ b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c
@@ -58,7 +58,7 @@ sh_css_vf_downscale_log2(
unsigned int ds_log2 = 0;
unsigned int out_width;
 
-   if ((!out_info) | (!vf_info))
+   if ((!out_info) || (!vf_info))
return -EINVAL;
 
out_width = out_info->res.width;
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 00/49] DRM driver for Hikey 970

[Sam Ravnborg]

Hi Mauro.

Laurent and I discussed this driver a little on irc.
Some highlights:

This parts could use register names:
+   writel(0x2, noc_dss_base + 0xc);
+   writel(0x2, noc_dss_base + 0x8c);
+   writel(0x2, noc_dss_base + 0x10c);
+   writel(0x2, noc_dss_base + 0x18c);

The two nodes in the DT for DPE and DSI uses overlapping range for reg
entries. It looks like a syscon node or some iommu thing is needed to do
this properly.

The chain will lok like this:

DPE -> DSI -> video mux -> {adv7533, panel}

But drm_bridge has not yet support for such non-linear setup.
The recommendation is to focus on the HDMI prat. Then we can later
come up with support for a video mux.

The video mux should have a dedicated node with one input node and two
output nodes. Which is also where the gpio should be.

The DSI node references two DPHY instances - should it be PHY driver(s)?

Does the DSI part contain one or two instances. Clocks looks duplicated.

Does the DPE and DSI share a lot of register blocks - or does it just
look like this from a first point of view?

You can read though the logs here:
https://people.freedesktop.org/~cbrill/dri-log/index.php

Could you please try to get back on some of the points above so we can
help you move forward in the right direction.

Thanks,
Sam
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

[Jim Quinlan]

Hi Andy,


On Tue, Aug 25, 2020 at 5:54 AM Andy Shevchenko
 wrote:
>
> On Mon, Aug 24, 2020 at 03:30:20PM -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu addrs and
> > dma addrs.  It subsumes the role of "dev->dma_pfn_offset" which was only
> > capable of holding a single uniform offset and had no region bounds
> > checking.
> >
> > The function of_dma_get_range() has been modified so that it takes a single
> > argument -- the device node -- and returns a map, NULL, or an error code.
> > The map is an array that holds the information regarding the DMA regions.
> > Each range entry contains the address offset, the cpu_start address, the
> > dma_start address, and the size of the region.
> >
> > of_dma_configure() is the typical manner to set range offsets but there are
> > a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> > driver code.  These cases now invoke the function
> > dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
>
> ...
>
> > + /*
> > +  * Record all info in the generic DMA ranges array for struct device.
> > +  */
> > + *map = r;
> > + for_each_of_range(, ) {
> > + pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> > +  range.bus_addr, range.cpu_addr, range.size);
> > + r->cpu_start = range.cpu_addr;
> > + r->dma_start = range.bus_addr;
> > + r->size = range.size;
>
> > + r->offset = (u64)range.cpu_addr - (u64)range.bus_addr;
>
> What's the point in explicit castings to the same type?
No point.  If I have to send out another version I will fix this.

>
> > + r++;
> > + }
>
> ...
>
> > + phys_addr_t paddr;
> > + dma_addr_t  dma_addr;
> > + struct device   dev_bogus;
>
> >   unittest(paddr == expect_paddr,
> > -  "of_dma_get_range wrong phys addr (%llx) on node 
> > %pOF", paddr, np);
> > +  "of_dma_get_range: wrong phys addr %llx (expecting 
> > %llx) on node %pOF\n",
> > +  (u64)paddr, expect_paddr, np);
>
> %llx -> %pap
This was intentional -- I'm aware of %pap and %pad.  The problem is
that %pa[pd]  print out a zero-filled 16 character number regardless
of what the number is.  For example, 1 is "0x0001",
whereas using %llx yields "1".

>
> >   unittest(dma_addr == expect_dma_addr,
> > -  "of_dma_get_range wrong DMA addr (%llx) on node 
> > %pOF", dma_addr, np);
> > +  "of_dma_get_range: wrong DMA addr %llx (expecting 
> > %llx) on node %pOF\n",
> > +  (u64)dma_addr, expect_dma_addr, np);
>
> %llx -> %pad
>
> ...
>
> > + if (mem->use_dev_dma_pfn_offset) {
> > + u64 base_addr = PFN_PHYS((u64)mem->pfn_base);
>
> Do we need explicit casting here?
I don't think it is needed.  However, the "(u64)" is useless though
since the macro recasts it to a phys_addr_t.

If there is another version of this submission I will change this.
>
> > +
> > + return base_addr - dma_offset_from_phys_addr(dev, base_addr);
> > + }
>
> ...
>
> > +int dma_set_offset_range(struct device *dev, phys_addr_t cpu_start,
> > +  dma_addr_t dma_start, u64 size)
> > +{
> > + struct bus_dma_region *map;
> > + u64 offset = (u64)cpu_start - (u64)dma_start;
> > +
> > + if (dev->dma_range_map) {
> > + dev_err(dev, "attempt to add DMA range to existing map\n");
> > + return -EINVAL;
> > + }
>
> Wouldn't be better to do an assignment of offset here?
IIRC this was what Christoph requested.  It has actually gone back and
forth over the versions of this submission.
>
> > + if (!offset)
> > + return 0;
> > +
> > + map = kcalloc(2, sizeof(*map), GFP_KERNEL);
> > + if (!map)
> > + return -ENOMEM;
> > + map[0].cpu_start = cpu_start;
> > + map[0].dma_start = dma_start;
> > + map[0].offset = offset;
> > + map[0].size = size;
> > + dev->dma_range_map = map;
> > +
> > + return 0;
> > +}
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks again,
Jim
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 00/49] DRM driver for Hikey 970

[Sam Ravnborg]

Hi Mauro

> Before posting the big patch series again, let me send the new
> version folded into a single patch.
> 
> If you'd like to see the entire thing, I'm placing it here:
> 
>   
> https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/hikey970_v2/

Review 3/3

For next submission then to ease review it would be nice that the patch
is spilt up a little. Maybe something like:
- HW specific stuff in two patches (header fiels with register + setup
  code)
- Display driver files
- DSI driver files
- build stuff (Makefile, Kconfig fragments)
So all splits on file level - which should be easy to do.

This will make it easier for more people to give feedback. It is a bit
much to walk through 4k loc or what the full size is.
And then we can also provide a-b or r-b for fragments so the reviewed
parts can be ignored for later reviews.


For the DSI parts I may be hit by the old "when you have a hammer then
everything looks like a nail syndrome".
In my case the hammer is the bridge interface.

Suggestions:
- Move encoder to display driver
- Move connector creation to display driver (using
  drm_bridge_connector_init())
- Use drm_bridge interface for the DSI driver parts
- Maybe use the HDMI bridge driver as a chained driver - I did not look
  to close on this
- Use the standard bridge interface to find the bridge and drop use of
  the component framework

I hope that some other drm people chime in here.
Either to tell this is non-sense or confirm this is the way to go.

The above does not give any hint how to use the gpio_mux to shift
between the panel and HDMI. This logic needs to be in the display driver
as the bridge driver will only be used for HDMI - as I understand the
code. And I do not know how to do it.

Some details in the following that are not related to the above.

Sam

> diff --git a/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c 
> b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
> new file mode 100644
> index ..a2eed961b7d5
> --- /dev/null
> +++ b/drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
> @@ -0,0 +1,2126 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DesignWare MIPI DSI Host Controller v1.02 driver
> + *
> + * Copyright (c) 2016 Linaro Limited.
> + * Copyright (c) 2014-2016 Hisilicon Limited.
> + * Copyright (c) 2014-2020, Huawei Technologies Co., Ltd
> + *
> + * Author:
> + *   
> + *   
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
Sort

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
Sort

> +
> +#include "kirin9xx_dw_dsi_reg.h"
> +#include "kirin9xx_dpe.h"
> +#include "kirin9xx_drm_drv.h"
> +#include "kirin9xx_drm_dpe_utils.h"
Sort

> +
> +#define PHY_REF_CLK_RATE 1920
> +#define PHY_REF_CLK_PERIOD_PS(10 / (PHY_REF_CLK_RATE / 1000))
> +
> +#define encoder_to_dsi(encoder) \
> + container_of(encoder, struct dw_dsi, encoder)
> +#define host_to_dsi(host) \
> + container_of(host, struct dw_dsi, host)
> +#define connector_to_dsi(connector) \
> + container_of(connector, struct dw_dsi, connector)
Move the upcast next to the struct definition.


> +#define DSS_REDUCE(x)((x) > 0 ? ((x) - 1) : (x))
> +
> +enum dsi_output_client {
> + OUT_HDMI = 0,
> + OUT_PANEL,
> + OUT_MAX
> +};
> +
> +struct mipi_phy_params {
I did not check all fiels but I managed to find at least one unused
field. Cheack and delete what is unused.
> + u64 lane_byte_clk;
> + u32 clk_division;
> +
> + u32 clk_lane_lp2hs_time;
> + u32 clk_lane_hs2lp_time;
> + u32 data_lane_lp2hs_time;
> + u32 data_lane_hs2lp_time;
> + u32 clk2data_delay;
> + u32 data2clk_delay;
> +
> + u32 clk_pre_delay;
> + u32 clk_post_delay;
> + u32 clk_t_lpx;
> + u32 clk_t_hs_prepare;
> + u32 clk_t_hs_zero;
> + u32 clk_t_hs_trial;
> + u32 clk_t_wakeup;
> + u32 data_pre_delay;
> + u32 data_post_delay;
> + u32 data_t_lpx;
> + u32 data_t_hs_prepare;
> + u32 data_t_hs_zero;
> + u32 data_t_hs_trial;
> + u32 data_t_ta_go;
> + u32 data_t_ta_get;
> + u32 data_t_wakeup;
> +
> + u32 phy_stop_wait_time;
> +
> + u32 rg_vrefsel_vcm;
> + u32 rg_hstx_ckg_sel;
> + u32 rg_pll_fbd_div5f;
> + u32 rg_pll_fbd_div1f;
> + u32 rg_pll_fbd_2p;
> + u32 rg_pll_enbwt;
> + u32 rg_pll_fbd_p;
> + u32 rg_pll_fbd_s;
> + u32 rg_pll_pre_div1p;
> + u32 rg_pll_pre_p;
> + u32 rg_pll_vco_750m;
> + u32 rg_pll_lpf_rs;
> + u32 rg_pll_lpf_cs;
> + u32 rg_pll_enswc;
> + u32 rg_pll_chp;
> +
Some indent gone wrong here?
> + u32 pll_register_override;  /* 0x1E[0] */
> + u32 pll_power_down; /* 0x1E[1] */
> + u32 rg_band_sel;/* 0x1E[2] */
> + u32 rg_phase_gen_en;/* 0x1E[3] */
> + u32 reload_sel; 

Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips

[Florian Fainelli]

Hi,

On 8/24/2020 12:30 PM, Jim Quinlan wrote:


Patchset Summary:
   Enhance a PCIe host controller driver.  Because of its unusual design
   we are foced to change dev->dma_pfn_offset into a more general role
   allowing multiple offsets.  See the 'v1' notes below for more info.


We are version 11 and counting, and it is not clear to me whether there 
is any chance of getting these patches reviewed and hopefully merged for 
the 5.10 merge window.


There are a lot of different files being touched, so what would be the 
ideal way of routing those changes towards inclusion?


Thanks!
--
Florian
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/5] media: cedrus: Add support for R40

[Jernej Skrabec]

Video engine in R40 is very similar to that in A33 but it runs on lower
speed, at least according to OS images released by board designer.

Signed-off-by: Jernej Skrabec 
---
 drivers/staging/media/sunxi/cedrus/cedrus.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index bc27f9430eeb..83a654a618be 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -496,6 +496,11 @@ static const struct cedrus_variant sun8i_h3_cedrus_variant 
= {
.mod_rate   = 40200,
 };
 
+static const struct cedrus_variant sun8i_r40_cedrus_variant = {
+   .capabilities   = CEDRUS_CAPABILITY_UNTILED,
+   .mod_rate   = 29700,
+};
+
 static const struct cedrus_variant sun50i_a64_cedrus_variant = {
.capabilities   = CEDRUS_CAPABILITY_UNTILED |
  CEDRUS_CAPABILITY_H265_DEC,
@@ -536,6 +541,10 @@ static const struct of_device_id cedrus_dt_match[] = {
.compatible = "allwinner,sun8i-h3-video-engine",
.data = _h3_cedrus_variant,
},
+   {
+   .compatible = "allwinner,sun8i-r40-video-engine",
+   .data = _r40_cedrus_variant,
+   },
{
.compatible = "allwinner,sun50i-a64-video-engine",
.data = _a64_cedrus_variant,
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/5] ARM: dts: sun8i: r40: Enable video decoder

[Jernej Skrabec]

Allwinner R40 SoC contains video engine very similar to that in A33.

First two patches add system controller nodes and the rest of them
add support for Cedrus VPU.

Please take a look.

Best regards,
Jernej

Jernej Skrabec (5):
  dt-bindings: sram: allwinner,sun4i-a10-system-control: Add R40
compatibles
  ARM: dts: sun8i: r40: Add node for system controller
  dt-bindings: media: allwinner,sun4i-a10-video-engine: Add R40
compatible
  media: cedrus: Add support for R40
  ARM: dts: sun8i: r40: Add video engine node

 .../allwinner,sun4i-a10-video-engine.yaml |  1 +
 .../allwinner,sun4i-a10-system-control.yaml   |  6 
 arch/arm/boot/dts/sun8i-r40.dtsi  | 34 +++
 drivers/staging/media/sunxi/cedrus/cedrus.c   |  9 +
 4 files changed, 50 insertions(+)

-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/5] ARM: dts: sun8i: r40: Add node for system controller

[Jernej Skrabec]

Allwinner R40 has system controller and SRAM C1 region similar to that
in A10.

Add nodes for them.

Signed-off-by: Jernej Skrabec 
---
 arch/arm/boot/dts/sun8i-r40.dtsi | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index dff9a3dc1fba..0c7526365896 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -190,6 +190,29 @@ mixer1_out_tcon_top: endpoint {
};
};
 
+   syscon: system-control@1c0 {
+   compatible = "allwinner,sun8i-r40-system-control",
+"allwinner,sun4i-a10-system-control";
+   reg = <0x01c0 0x30>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   sram_c: sram@1d0 {
+   compatible = "mmio-sram";
+   reg = <0x01d0 0xd>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x01d0 0xd>;
+
+   ve_sram: sram-section@0 {
+   compatible = 
"allwinner,sun8i-r40-sram-c1",
+
"allwinner,sun4i-a10-sram-c1";
+   reg = <0x00 0x8>;
+   };
+   };
+   };
+
nmi_intc: interrupt-controller@1c00030 {
compatible = "allwinner,sun7i-a20-sc-nmi";
interrupt-controller;
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/5] dt-bindings: sram: allwinner, sun4i-a10-system-control: Add R40 compatibles

[Jernej Skrabec]

Allwinner R40 has system controller similar to that in A10.

Add compatibles for system controller and sram c1 region.

Signed-off-by: Jernej Skrabec 
---
 .../bindings/sram/allwinner,sun4i-a10-system-control.yaml   | 6 ++
 1 file changed, 6 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
 
b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
index f5825935fd22..6ebcbc153691 100644
--- 
a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
+++ 
b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
@@ -33,6 +33,9 @@ properties:
   - const: allwinner,sun4i-a10-system-control
   - const: allwinner,sun8i-a23-system-control
   - const: allwinner,sun8i-h3-system-control
+  - items:
+  - const: allwinner,sun8i-r40-system-control
+  - const: allwinner,sun4i-a10-system-control
   - const: allwinner,sun50i-a64-sram-controller
 deprecated: true
   - const: allwinner,sun50i-a64-system-control
@@ -86,6 +89,9 @@ patternProperties:
   - items:
   - const: allwinner,sun8i-h3-sram-c1
   - const: allwinner,sun4i-a10-sram-c1
+  - items:
+  - const: allwinner,sun8i-r40-sram-c1
+  - const: allwinner,sun4i-a10-sram-c1
   - items:
   - const: allwinner,sun50i-a64-sram-c1
   - const: allwinner,sun4i-a10-sram-c1
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 5/5] ARM: dts: sun8i: r40: Add video engine node

[Jernej Skrabec]

Allwinner R40 SoC has a video engine.

Add a node for it.

Signed-off-by: Jernej Skrabec 
---
 arch/arm/boot/dts/sun8i-r40.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 0c7526365896..7907569e7b5c 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -273,6 +273,17 @@ csi0: csi@1c09000 {
status = "disabled";
};
 
+   video-codec@1c0e000 {
+   compatible = "allwinner,sun8i-r40-video-engine";
+   reg = <0x01c0e000 0x1000>;
+   clocks = < CLK_BUS_VE>, < CLK_VE>,
+   < CLK_DRAM_VE>;
+   clock-names = "ahb", "mod", "ram";
+   resets = < RST_BUS_VE>;
+   interrupts = ;
+   allwinner,sram = <_sram 1>;
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun8i-r40-mmc",
 "allwinner,sun50i-a64-mmc";
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/5] dt-bindings: media: allwinner, sun4i-a10-video-engine: Add R40 compatible

[Jernej Skrabec]

Allwinner R40 SoC contains video engine. Add compatible for it.

Signed-off-by: Jernej Skrabec 
---
 .../bindings/media/allwinner,sun4i-a10-video-engine.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
index 4cc1a670c986..0d58bbcd24d3 100644
--- 
a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
+++ 
b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
@@ -18,6 +18,7 @@ properties:
   - allwinner,sun7i-a20-video-engine
   - allwinner,sun8i-a33-video-engine
   - allwinner,sun8i-h3-video-engine
+  - allwinner,sun8i-r40-video-engine
   - allwinner,sun50i-a64-video-engine
   - allwinner,sun50i-h5-video-engine
   - allwinner,sun50i-h6-video-engine
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 9/9] arm64: dts: renesas: salvator: add a connection from adv748x codec (HDMI input) to the R-Car SoC

[Kieran Bingham]

Hi Alex,

On 18/06/2020 17:32, Kieran Bingham wrote:
> Hi Alex,
> 
> On 02/04/2020 19:35, Alex Riesen wrote:
>> As all known variants of the Salvator board have the HDMI decoder
>> chip (the ADV7482) connected to the SSI4 on R-Car SoC, the ADV7482
>> endpoint and the connection definitions are placed in the common board
>> file.
>>
>> For the same reason, the CLK_C clock line and I2C configuration (similar
>> to the ak4613, on the same interface) are added into the common file.
>>
>> Signed-off-by: Alexander Riesen 
>>
>> --
>>
>> v5: Add dummy ssi4 node to the rcar sound card in r8a77961, as the
>> devices (Salvator-X 2nd version with R-Car M3 W+) also reference
>> salvator-common.dtsi.
>> Suggested-by: Geert Uytterhoeven 
>>
>> v2: Also add ssi4_ctrl pin group in the sound pins. The pins are
>> responsible for SCK4 (sample clock) WS4 and (word boundary input),
>> and are required for SSI audio input over I2S.
>>
>> The adv748x shall provide its own implementation of the output clock
>> (MCLK), connected to the audio_clk_c line of the R-Car SoC.
>>
>> If the frequency of the ADV748x MCLK were fixed, the clock
>> implementation were not necessary, but it does not seem so: the MCLK
>> depends on the value in a speed multiplier register and the input sample
>> rate (48kHz).
>>
>> Remove audio clock C from the clocks of adv7482.
>>
>> The clocks property of the video-receiver node lists the input
>> clocks of the device, which is quite the opposite from the
>> original intention: the adv7482 on Salvator X boards is a
>> provide of the MCLK clock for I2S audio output.
>>
>> Remove old definition of _card.dais and reduce size of changes
>> in the Salvator-X specific device tree source.
>>
>> Declare video-receiver a clock producer, as the adv748x driver
>> implements the master clock used I2S audio output.
>>
>> Suggested-by: Geert Uytterhoeven 
>>
>> v2: The driver provides only MCLK clock, not the SCLK and LRCLK,
>> which are part of the I2S protocol.
>>
>> Suggested-by: Laurent Pinchart 
>> ---
>>  .../boot/dts/renesas/r8a77950-salvator-x.dts  |  3 +-
>>  arch/arm64/boot/dts/renesas/r8a77961.dtsi |  1 +
>>  .../boot/dts/renesas/salvator-common.dtsi | 47 +--

Once again I'm back trying to test this series, and one issue I've had
is that the board I have (r8a77951-salvator-xs.dts) isn't included in
this DT update.

For v6, Should we include the relevant changes to all the following?

arch/arm64/boot/dts/renesas/r8a77950-salvator-x.dts
arch/arm64/boot/dts/renesas/r8a77951-salvator-x.dts
arch/arm64/boot/dts/renesas/r8a77960-salvator-x.dts
arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
arch/arm64/boot/dts/renesas/salvator-x.dtsi

And perhaps handle the salvator-xs in a second (yet very similar) patch?

arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dts
arch/arm64/boot/dts/renesas/r8a77960-salvator-xs.dts
arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts
arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
arch/arm64/boot/dts/renesas/salvator-xs.dtsi

I think I've added the relevant entries to my dtb, but I haven't
successfully captured audio yet.

I can see the device being listed through arecord:

kbingham@salvator-xs:~$ arecord -l
 List of CAPTURE Hardware Devices 
card 0: rcarsound [rcar-sound], device 0: rsnd-dai.0-ak4613-hifi
ak4613-hifi-0 []
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: rcarsound [rcar-sound], device 3: rsnd-dai.3-adv748x-i2s
adv748x.4-0070-3 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0


But as yet, everything I try to record fails or is empty silence.

Debugging ...

--
Regards

Kieran



>>  3 files changed, 45 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77950-salvator-x.dts 
>> b/arch/arm64/boot/dts/renesas/r8a77950-salvator-x.dts
>> index 2438825c9b22..e16c146808b6 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77950-salvator-x.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a77950-salvator-x.dts
>> @@ -146,7 +146,8 @@  {
>>  _card {
>>  dais = <_port0 /* ak4613 */
>>  _port1 /* HDMI0  */
>> -_port2>;   /* HDMI1  */
>> +_port2 /* HDMI1  */
>> +_port3>;   /* adv7482 hdmi-in  */
> 
> Ah - that was confusing at first... but HDMI0 and HDMI1 are *outputs*,
> where of course the adv7482 is an input ;-)
> 
> 
> Otherwise, I can't spot anything else yet so:
> 
> Reviewed-by: Kieran Bingham 
> 
> But I fear there may have been some churn around here, so it would be
> good to see a rebase too.
> 
> --
> Kieran
> 
> 
> 
>>  };
>>  
>>  _phy2 {
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi 
>> b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
>> index be3824bda632..b79907beaf31 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
>> @@ -861,6 +861,7 @@ rcar_sound,src {
>>  

Re: [PATCH 00/49] DRM driver for Hikey 970

[Daniel Stone]

Hi Mauro,

On Tue, 25 Aug 2020 at 12:30, Mauro Carvalho Chehab
 wrote:
> Sorry, but I can't agree that review is more important than to be able
> to properly indicate copyrights in a valid way at the legal systems that
> it would apply ;-)

The way to properly indicate copyright coverage is to insert a
copyright statement in the file. This has been the accepted way of
communicating copyright notices since approximately the dawn of time.
The value of the 'author' field within a chain of git commits does not
have privileged legal value.

If what you were saying is true, it would be impossible for any
project to copy code from any other project, unless they did git
filter-branch and made sure to follow renames too. As others have
noted, it would also be impossible for any patches to be developed
collaboratively by different copyright holders, or for maintainers to
apply changes.

This is accepted community practice and has passed signoffs from a
million different lawyers and copyright holders. If you wish to break
with this and do something different, the onus is on you to provide
the community with _specific_ legal advice; if this is accepted, the
development model would have to drastically change in the presence of
single pieces of code developed by multiple distinct copyright
holders.

Cheers,
Daniel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 00/49] DRM driver for Hikey 970

[Laurent Pinchart]

Hi Mauro,

On Tue, Aug 25, 2020 at 01:30:25PM +0200, Mauro Carvalho Chehab wrote:
> Em Tue, 25 Aug 2020 05:29:29 +1000
> Dave Airlie  escreveu:
> 
> > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart
> >  wrote:
> > >
> > > Hi Mauro,
> > >
> > > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote:  
> > > > Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu:  
> > > > > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote:  
> > > > > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:  
> > > > > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab 
> > > > > > > wrote:  
> > > > > > > > This patch series port the out-of-tree driver for Hikey 970 
> > > > > > > > (which
> > > > > > > > should also support Hikey 960) from the official 96boards tree:
> > > > > > > >
> > > > > > > >https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
> > > > > > > >
> > > > > > > > Based on his history, this driver seems to be originally written
> > > > > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original
> > > > > > > > driver used to depend on ION (from Kernel 4.4) and had its own
> > > > > > > > implementation for FB dev API.
> > > > > > > >
> > > > > > > > As I need to preserve the original history (with has patches 
> > > > > > > > from
> > > > > > > > both HiSilicon and from Linaro),  I'm starting from the original
> > > > > > > > patch applied there. The remaining patches are incremental,
> > > > > > > > and port this driver to work with upstream Kernel.
> > > > > > > >  
> > > > > ...  
> > > > > > > > - Due to legal reasons, I need to preserve the authorship of
> > > > > > > >   each one responsbile for each patch. So, I need to start from
> > > > > > > >   the original patch from Kernel 4.4;  
> > > > > ...  
> > > > > > > I do acknowledge you need to preserve history and all -
> > > > > > > but this patchset is not easy to review.  
> > > > > >
> > > > > > Why do we need to preserve history ? Adding relevant Signed-off-by 
> > > > > > and
> > > > > > Co-developed-by should be enough, shouldn't it ? Having a public 
> > > > > > branch
> > > > > > that contains the history is useful if anyone is interested, but I 
> > > > > > don't
> > > > > > think it's required in mainline.  
> > > > >
> > > > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you
> > > > > have on this but preserving the "absolute" history here is actively
> > > > > detrimental for review and understanding of the patch set.
> > > > >
> > > > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by
> > > > > lines should be sufficient to provide both atribution credit and DCO
> > > > > history.  
> > > >
> > > > I'm not convinced that, from legal standpoint, folding things would
> > > > be enough. See, there are at least 3 legal systems involved here
> > > > among the different patch authors:
> > > >
> > > >   - civil law;
> > > >   - common law;
> > > >   - customary law + common law.
> > > >
> > > > Merging stuff altogether from different law systems can be problematic,
> > > > and trying to discuss this with experienced IP property lawyers will
> > > > for sure take a lot of time and efforts. I also bet that different
> > > > lawyers will have different opinions, because laws are subject to
> > > > interpretation. With that matter I'm not aware of any court rules
> > > > with regards to folded patches. So, it sounds to me that folding
> > > > patches is something that has yet to be proofed in courts around
> > > > the globe.
> > > >
> > > > At least for US legal system, it sounds that the Country of
> > > > origin of a patch is relevant, as they have a concept of
> > > > "national technology" that can be subject to export regulations.
> > > >
> > > > From my side, I really prefer to play safe and stay out of any such
> > > > legal discussions.  
> > >
> > > Let's be serious for a moment. If you think there are legal issues in
> > > taking GPL-v2.0-only patches and squashing them while retaining
> > > authorship information through tags, the Linux kernel if *full* of that.
> > > You also routinely modify patches that you commit to the media subsystem
> > > to fix "small issues".
> > >
> > > The country of origin argument makes no sense either, the kernel code
> > > base if full of code coming from pretty much all country on the planet.
> > >
> > > Keeping the patches separate make this hard to review. Please squash
> > > them.  
> > 
> > I'm inclined to agree with Laurent here.
> > 
> > Patches submitted as GPL-v2 with DCO lines and author names/companies
> > should be fine to be squashed and rearranged,
> > as long as the DCO and Authorship is kept somewhere in the new patch
> > that is applied.
> > 
> > Review is more important here.
> 
> Sorry, but I can't agree that review is more important than to be able
> to properly indicate copyrights in a valid way at the legal systems that
> it would apply ;-)
> 
> In any case, 

Re: [PATCH 00/49] DRM driver for Hikey 970

[Mauro Carvalho Chehab]

Em Tue, 25 Aug 2020 05:29:29 +1000
Dave Airlie  escreveu:

> On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart
>  wrote:
> >
> > Hi Mauro,
> >
> > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote:  
> > > Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu:  
> > > > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote:  
> > > > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:  
> > > > > > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab 
> > > > > > wrote:  
> > > > > > > This patch series port the out-of-tree driver for Hikey 970 (which
> > > > > > > should also support Hikey 960) from the official 96boards tree:
> > > > > > >
> > > > > > >https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
> > > > > > >
> > > > > > > Based on his history, this driver seems to be originally written
> > > > > > > for Kernel 4.4, and was later ported to Kernel 4.9. The original
> > > > > > > driver used to depend on ION (from Kernel 4.4) and had its own
> > > > > > > implementation for FB dev API.
> > > > > > >
> > > > > > > As I need to preserve the original history (with has patches from
> > > > > > > both HiSilicon and from Linaro),  I'm starting from the original
> > > > > > > patch applied there. The remaining patches are incremental,
> > > > > > > and port this driver to work with upstream Kernel.
> > > > > > >  
> > > > ...  
> > > > > > > - Due to legal reasons, I need to preserve the authorship of
> > > > > > >   each one responsbile for each patch. So, I need to start from
> > > > > > >   the original patch from Kernel 4.4;  
> > > > ...  
> > > > > > I do acknowledge you need to preserve history and all -
> > > > > > but this patchset is not easy to review.  
> > > > >
> > > > > Why do we need to preserve history ? Adding relevant Signed-off-by and
> > > > > Co-developed-by should be enough, shouldn't it ? Having a public 
> > > > > branch
> > > > > that contains the history is useful if anyone is interested, but I 
> > > > > don't
> > > > > think it's required in mainline.  
> > > >
> > > > Yea. I concur with Laurent here. I'm not sure what legal reasoning you
> > > > have on this but preserving the "absolute" history here is actively
> > > > detrimental for review and understanding of the patch set.
> > > >
> > > > Preserving Authorship, Signed-off-by lines and adding Co-developed-by
> > > > lines should be sufficient to provide both atribution credit and DCO
> > > > history.  
> > >
> > > I'm not convinced that, from legal standpoint, folding things would
> > > be enough. See, there are at least 3 legal systems involved here
> > > among the different patch authors:
> > >
> > >   - civil law;
> > >   - common law;
> > >   - customary law + common law.
> > >
> > > Merging stuff altogether from different law systems can be problematic,
> > > and trying to discuss this with experienced IP property lawyers will
> > > for sure take a lot of time and efforts. I also bet that different
> > > lawyers will have different opinions, because laws are subject to
> > > interpretation. With that matter I'm not aware of any court rules
> > > with regards to folded patches. So, it sounds to me that folding
> > > patches is something that has yet to be proofed in courts around
> > > the globe.
> > >
> > > At least for US legal system, it sounds that the Country of
> > > origin of a patch is relevant, as they have a concept of
> > > "national technology" that can be subject to export regulations.
> > >
> > > From my side, I really prefer to play safe and stay out of any such
> > > legal discussions.  
> >
> > Let's be serious for a moment. If you think there are legal issues in
> > taking GPL-v2.0-only patches and squashing them while retaining
> > authorship information through tags, the Linux kernel if *full* of that.
> > You also routinely modify patches that you commit to the media subsystem
> > to fix "small issues".
> >
> > The country of origin argument makes no sense either, the kernel code
> > base if full of code coming from pretty much all country on the planet.
> >
> > Keeping the patches separate make this hard to review. Please squash
> > them.  
> 
> I'm inclined to agree with Laurent here.
> 
> Patches submitted as GPL-v2 with DCO lines and author names/companies
> should be fine to be squashed and rearranged,
> as long as the DCO and Authorship is kept somewhere in the new patch
> that is applied.
> 
> Review is more important here.

Sorry, but I can't agree that review is more important than to be able
to properly indicate copyrights in a valid way at the legal systems that
it would apply ;-)

In any case, there's an easy way to make the code easy to review:
I can write the patches against staging (where it is OK to submit
preserving the history) and then add a final patch moving it out
of staging.

You can then just review the last patch, as it will contain the
entire code on it.

Another alternative, as I'm already doing with Sam, 

Re: [PATCH] staging: qlge: fix build breakage with dumping enabled

[Coiby Xu]

On Fri, Aug 21, 2020 at 05:31:59PM +0900, Benjamin Poirier wrote:

On 2020-08-21 15:03 +0800, Coiby Xu wrote:

This fixes commit 0107635e15ac
("staging: qlge: replace pr_err with netdev_err") which introduced an
build breakage with dumping enabled, i.e.,

$ QL_ALL_DUMP=1 QL_OB_DUMP=1 QL_CB_DUMP=1 QL_REG_DUMP=1 \
  QL_IB_DUMP=1 QL_DEV_DUMP=1 make M=drivers/staging/qlge

Fixes: 0107635e15ac ("taging: qlge: replace pr_err with netdev_err")

^ staging


Thank you for reminding me of the typo!


Reported-by: Benjamin Poirier 
Signed-off-by: Coiby Xu 
---
 drivers/staging/qlge/qlge.h  | 42 
 drivers/staging/qlge/qlge_dbg.c  | 36 +--
 drivers/staging/qlge/qlge_main.c |  4 +--
 3 files changed, 41 insertions(+), 41 deletions(-)


[...]

@@ -1615,7 +1615,7 @@ void ql_dump_qdev(struct ql_adapter *qdev)
 #endif

 #ifdef QL_CB_DUMP
-void ql_dump_wqicb(struct wqicb *wqicb)
+void ql_dump_wqicb(struct ql_adapter *qdev, struct wqicb *wqicb)
 {


This can be fixed without adding another argument:

struct tx_ring *tx_ring = container_of(wqicb, struct tx_ring, wqicb);
struct ql_adapter *qdev = tx_ring->qdev;


netdev_err(qdev->ndev, "Dumping wqicb stuff...\n");
netdev_err(qdev->ndev, "wqicb->len = 0x%x\n", le16_to_cpu(wqicb->len));
@@ -1630,7 +1630,7 @@ void ql_dump_wqicb(struct wqicb *wqicb)
   (unsigned long long)le64_to_cpu(wqicb->cnsmr_idx_addr));
 }

-void ql_dump_tx_ring(struct tx_ring *tx_ring)
+void ql_dump_tx_ring(struct ql_adapter *qdev, struct tx_ring *tx_ring)
 {


This can be fixed without adding another argument:
struct ql_adapter *qdev;

if (!tx_ring)
return;

qdev = tx_ring->qdev;

... similar comment for the other instances.


Thank you for the simpler solution!

For QL_OB_DUMP and QL_IB_DUMP, `struct ql_adapter *qdev` can't be
obtained via container_of. So qdev are still directly passed to these
functions.

--
Best regards,
Coiby
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

[Andy Shevchenko]

On Mon, Aug 24, 2020 at 03:30:20PM -0400, Jim Quinlan wrote:
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs.  It subsumes the role of "dev->dma_pfn_offset" which was only
> capable of holding a single uniform offset and had no region bounds
> checking.
> 
> The function of_dma_get_range() has been modified so that it takes a single
> argument -- the device node -- and returns a map, NULL, or an error code.
> The map is an array that holds the information regarding the DMA regions.
> Each range entry contains the address offset, the cpu_start address, the
> dma_start address, and the size of the region.
> 
> of_dma_configure() is the typical manner to set range offsets but there are
> a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> driver code.  These cases now invoke the function
> dma_attach_offset_range(dev, cpu_addr, dma_addr, size).

...

> + /*
> +  * Record all info in the generic DMA ranges array for struct device.
> +  */
> + *map = r;
> + for_each_of_range(, ) {
> + pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> +  range.bus_addr, range.cpu_addr, range.size);
> + r->cpu_start = range.cpu_addr;
> + r->dma_start = range.bus_addr;
> + r->size = range.size;

> + r->offset = (u64)range.cpu_addr - (u64)range.bus_addr;

What's the point in explicit castings to the same type?

> + r++;
> + }

...

> + phys_addr_t paddr;
> + dma_addr_t  dma_addr;
> + struct device   dev_bogus;

>   unittest(paddr == expect_paddr,
> -  "of_dma_get_range wrong phys addr (%llx) on node 
> %pOF", paddr, np);
> +  "of_dma_get_range: wrong phys addr %llx (expecting 
> %llx) on node %pOF\n",
> +  (u64)paddr, expect_paddr, np);

%llx -> %pap

>   unittest(dma_addr == expect_dma_addr,
> -  "of_dma_get_range wrong DMA addr (%llx) on node %pOF", 
> dma_addr, np);
> +  "of_dma_get_range: wrong DMA addr %llx (expecting 
> %llx) on node %pOF\n",
> +  (u64)dma_addr, expect_dma_addr, np);

%llx -> %pad

...

> + if (mem->use_dev_dma_pfn_offset) {
> + u64 base_addr = PFN_PHYS((u64)mem->pfn_base);

Do we need explicit casting here?

> +
> + return base_addr - dma_offset_from_phys_addr(dev, base_addr);
> + }

...

> +int dma_set_offset_range(struct device *dev, phys_addr_t cpu_start,
> +  dma_addr_t dma_start, u64 size)
> +{
> + struct bus_dma_region *map;
> + u64 offset = (u64)cpu_start - (u64)dma_start;
> +
> + if (dev->dma_range_map) {
> + dev_err(dev, "attempt to add DMA range to existing map\n");
> + return -EINVAL;
> + }

Wouldn't be better to do an assignment of offset here?

> + if (!offset)
> + return 0;
> +
> + map = kcalloc(2, sizeof(*map), GFP_KERNEL);
> + if (!map)
> + return -ENOMEM;
> + map[0].cpu_start = cpu_start;
> + map[0].dma_start = dma_start;
> + map[0].offset = offset;
> + map[0].size = size;
> + dev->dma_range_map = map;
> +
> + return 0;
> +}

-- 
With Best Regards,
Andy Shevchenko


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] staging: emxx_udc: Fix passing of NULL to dma_alloc_coherent()

[Alex Dewar]

In nbu2ss_eq_queue() memory is allocated with dma_alloc_coherent(),
though, strangely, NULL is passed as the struct device* argument. Pass
the UDC's device instead. Fix up the corresponding call to
dma_free_coherent() in the same way.

Build-tested on x86 only.

Fixes: 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile USB Gadget driver")
Reported-by: Dan Carpenter 
Signed-off-by: Alex Dewar 
---
v2: also fix call to dma_free_coherent() (Dan)

@Magnus: I noticed you contributed this code back in 2014... I don't
suppose you happen to have the hardware lying around to test this so we
can get a Tested-by? :)
---
 drivers/staging/emxx_udc/emxx_udc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index 03929b9d3a8bc..d0725bc8b48a4 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -2593,7 +2593,7 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
 
if (req->unaligned) {
if (!ep->virt_buf)
-   ep->virt_buf = dma_alloc_coherent(NULL, PAGE_SIZE,
+   ep->virt_buf = dma_alloc_coherent(udc->dev, PAGE_SIZE,
  >phys_buf,
  GFP_ATOMIC | GFP_DMA);
if (ep->epnum > 0)  {
@@ -3148,7 +3148,7 @@ static int nbu2ss_drv_remove(struct platform_device *pdev)
for (i = 0; i < NUM_ENDPOINTS; i++) {
ep = >ep[i];
if (ep->virt_buf)
-   dma_free_coherent(NULL, PAGE_SIZE, (void *)ep->virt_buf,
+   dma_free_coherent(udc->dev, PAGE_SIZE, (void 
*)ep->virt_buf,
  ep->phys_buf);
}
 
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH][next] staging: spmi: hisi-spmi-controller: fix spelling mistake "controlller" -> "controller"

[Mauro Carvalho Chehab]

Em Thu, 20 Aug 2020 08:51:36 +0100
Colin King  escreveu:

> From: Colin Ian King 
> 
> There is a spelling mistake in the MODULE_ALIAS, fix it.
> 
> Signed-off-by: Colin Ian King 
Reviewed-by: Mauro Carvalho Chehab 

> ---
>  drivers/staging/hikey9xx/hisi-spmi-controller.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/hikey9xx/hisi-spmi-controller.c 
> b/drivers/staging/hikey9xx/hisi-spmi-controller.c
> index 66a0b296e06f..b132b2a5d939 100644
> --- a/drivers/staging/hikey9xx/hisi-spmi-controller.c
> +++ b/drivers/staging/hikey9xx/hisi-spmi-controller.c
> @@ -354,4 +354,4 @@ module_exit(spmi_controller_exit);
>  
>  MODULE_LICENSE("GPL v2");
>  MODULE_VERSION("1.0");
> -MODULE_ALIAS("platform:spmi_controlller");
> +MODULE_ALIAS("platform:spmi_controller");



Thanks,
Mauro
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 01/12] staging: wfx: fix BA when device is AP and MFP is enabled

[Jerome Pouiller]

From: Jérôme Pouiller 

The protection of the management frames is mainly done by mac80211.
However, frames for the management of the BlockAck sessions are directly
sent by the device. These frames have to be protected if MFP is in use.
So the driver has to pass the MFP configuration to the device.

Until now, the BlockAck management frames were completely unprotected
whatever the status of the MFP negotiation. So, some devices dropped
these frames.

The device has two knobs to control the MFP. One global and one per
station. Normally, the driver should always enable global MFP. Then it
should enable MFP on every station with which MFP was successfully
negotiated. Unfortunately, the older firmwares only provide the
global control.

So, this patch enable global MFP as it is exposed in the beacon. Then it
marks every station with which the MFP is effective.

Thus, the support for the old firmwares is not so bad. It may only
encounter some difficulties to negotiate BA sessions when the local
device (the AP) is MFP capable (ieee80211w=1) but the station is not.
The only solution for this case is to upgrade the firmware.

Signed-off-by: Jérôme Pouiller 
---
v2:
  - Check that ptr does not point out of bounds of skb.

 drivers/staging/wfx/sta.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c
index ad63332f690c..c31e302d05c9 100644
--- a/drivers/staging/wfx/sta.c
+++ b/drivers/staging/wfx/sta.c
@@ -434,7 +434,7 @@ int wfx_sta_add(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
wvif->link_id_map |= BIT(sta_priv->link_id);
WARN_ON(!sta_priv->link_id);
WARN_ON(sta_priv->link_id >= HIF_LINK_ID_MAX);
-   hif_map_link(wvif, sta->addr, 0, sta_priv->link_id);
+   hif_map_link(wvif, sta->addr, sta->mfp ? 2 : 0, sta_priv->link_id);
 
return 0;
 }
@@ -474,6 +474,31 @@ static int wfx_upload_ap_templates(struct wfx_vif *wvif)
return 0;
 }
 
+static void wfx_set_mfp_ap(struct wfx_vif *wvif)
+{
+   struct sk_buff *skb = ieee80211_beacon_get(wvif->wdev->hw, wvif->vif);
+   const int ieoffset = offsetof(struct ieee80211_mgmt, u.beacon.variable);
+   const u16 *ptr = (u16 *)cfg80211_find_ie(WLAN_EID_RSN,
+skb->data + ieoffset,
+skb->len - ieoffset);
+   const int pairwise_cipher_suite_count_offset = 8 / sizeof(u16);
+   const int pairwise_cipher_suite_size = 4 / sizeof(u16);
+   const int akm_suite_size = 4 / sizeof(u16);
+
+   if (ptr) {
+   ptr += pairwise_cipher_suite_count_offset;
+   if (WARN_ON(ptr > (u16 *)skb_tail_pointer(skb)))
+   return;
+   ptr += 1 + pairwise_cipher_suite_size * *ptr;
+   if (WARN_ON(ptr > (u16 *)skb_tail_pointer(skb)))
+   return;
+   ptr += 1 + akm_suite_size * *ptr;
+   if (WARN_ON(ptr > (u16 *)skb_tail_pointer(skb)))
+   return;
+   hif_set_mfp(wvif, *ptr & BIT(7), *ptr & BIT(6));
+   }
+}
+
 int wfx_start_ap(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
 {
struct wfx_vif *wvif = (struct wfx_vif *)vif->drv_priv;
@@ -488,6 +513,7 @@ int wfx_start_ap(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif)
ret = hif_start(wvif, >bss_conf, wvif->channel);
if (ret > 0)
return -EIO;
+   wfx_set_mfp_ap(wvif);
return ret;
 }
 
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 03/12] staging: wfx: fix BA when MFP is disabled but BSS is MFP capable

[Jerome Pouiller]

From: Jérôme Pouiller 

The protection of the management frames is mainly done by mac80211.
However, frames for the management of the BlockAck sessions are directly
sent by the device. These frames have to be protected if MFP is in use.
So the driver has to pass the MFP configuration to the device.

Until now, the driver directly read the RSN IE of the BSS. However, it
didn't work when the BSS was MFP capable (ieee80211w=1) and the local
device has disabled MFP (ieee80211w=0).

This patch read the MFP information directly from the struct
ieee80211_sta. This information take into account the MFP negotiated
during the association. In addition, the code is far simpler.

Signed-off-by: Jérôme Pouiller 
---
 drivers/staging/wfx/sta.c | 34 +++---
 1 file changed, 3 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c
index b6ccb04f308a..2b848b8985df 100644
--- a/drivers/staging/wfx/sta.c
+++ b/drivers/staging/wfx/sta.c
@@ -323,36 +323,6 @@ void wfx_set_default_unicast_key(struct ieee80211_hw *hw,
hif_wep_default_key_id(wvif, idx);
 }
 
-static void wfx_set_mfp(struct wfx_vif *wvif,
-   struct cfg80211_bss *bss)
-{
-   const int pairwise_cipher_suite_count_offset = 8 / sizeof(u16);
-   const int pairwise_cipher_suite_size = 4 / sizeof(u16);
-   const int akm_suite_size = 4 / sizeof(u16);
-   const u16 *ptr = NULL;
-   bool mfpc = false;
-   bool mfpr = false;
-
-   /* 802.11w protected mgmt frames */
-
-   /* retrieve MFPC and MFPR flags from beacon or PBRSP */
-
-   rcu_read_lock();
-   if (bss)
-   ptr = (const u16 *)ieee80211_bss_get_ie(bss, WLAN_EID_RSN);
-
-   if (ptr) {
-   ptr += pairwise_cipher_suite_count_offset;
-   ptr += 1 + pairwise_cipher_suite_size * *ptr;
-   ptr += 1 + akm_suite_size * *ptr;
-   mfpr = *ptr & BIT(6);
-   mfpc = *ptr & BIT(7);
-   }
-   rcu_read_unlock();
-
-   hif_set_mfp(wvif, mfpc, mfpr);
-}
-
 void wfx_reset(struct wfx_vif *wvif)
 {
struct wfx_dev *wdev = wvif->wdev;
@@ -400,7 +370,6 @@ static void wfx_do_join(struct wfx_vif *wvif)
}
rcu_read_unlock();
 
-   wfx_set_mfp(wvif, bss);
cfg80211_put_bss(wvif->wdev->hw->wiphy, bss);
 
wvif->join_in_progress = true;
@@ -427,6 +396,9 @@ int wfx_sta_add(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
 
sta_priv->vif_id = wvif->id;
 
+   if (vif->type == NL80211_IFTYPE_STATION)
+   hif_set_mfp(wvif, sta->mfp, sta->mfp);
+
// In station mode, the firmware interprets new link-id as a TDLS peer.
if (vif->type == NL80211_IFTYPE_STATION && !sta->tdls)
return 0;
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 12/12] staging: wfx: add workaround for 'timeout while wake up chip'

[Jerome Pouiller]

From: Jérôme Pouiller 

The host and the device can be connected with a called Wake-Up GPIO.
When the host fall down this GPIO, it allows the device to enter in deep
sleep and no communication with the device is no more possible (the
device wakes up automatically on DTIM and fetch data if necessary).

So, before to communicate with the device, the driver have to raise the
Wake-up GPIO and then wait for an IRQ from the device.

Unfortunately, old firmwares have a race in sleep/wake-up process and
the device may never wake up. In this case, the IRQ is not sent and
driver complains with "timeout while wake up chip". Then, the driver
tries anyway to access the bus and an other error is raised by the bus.

Fortunately, when the bug occurs, it is possible to fall down the IRQ
and the device will eventually finish the sleep process. Then the driver
can wake it up normally.

The patch implements that workaround and add a retry limit in case
something goes very wrong.

Signed-off-by: Jérôme Pouiller 
---
 drivers/staging/wfx/bh.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wfx/bh.c b/drivers/staging/wfx/bh.c
index 07304a80c29b..f07bcee50e3f 100644
--- a/drivers/staging/wfx/bh.c
+++ b/drivers/staging/wfx/bh.c
@@ -18,25 +18,40 @@
 
 static void device_wakeup(struct wfx_dev *wdev)
 {
+   int max_retry = 3;
+
if (!wdev->pdata.gpio_wakeup)
return;
if (gpiod_get_value_cansleep(wdev->pdata.gpio_wakeup))
return;
 
-   gpiod_set_value_cansleep(wdev->pdata.gpio_wakeup, 1);
if (wfx_api_older_than(wdev, 1, 4)) {
+   gpiod_set_value_cansleep(wdev->pdata.gpio_wakeup, 1);
if (!completion_done(>hif.ctrl_ready))
usleep_range(2000, 2500);
-   } else {
+   return;
+   }
+   for (;;) {
+   gpiod_set_value_cansleep(wdev->pdata.gpio_wakeup, 1);
// completion.h does not provide any function to wait
// completion without consume it (a kind of
// wait_for_completion_done_timeout()). So we have to emulate
// it.
if (wait_for_completion_timeout(>hif.ctrl_ready,
-   msecs_to_jiffies(2)))
+   msecs_to_jiffies(2))) {
complete(>hif.ctrl_ready);
-   else
+   return;
+   } else if (max_retry-- > 0) {
+   // Older firmwares have a race in sleep/wake-up process.
+   // Redo the process is sufficient to unfreeze the
+   // chip.
dev_err(wdev->dev, "timeout while wake up chip\n");
+   gpiod_set_value_cansleep(wdev->pdata.gpio_wakeup, 0);
+   usleep_range(2000, 2500);
+   } else {
+   dev_err(wdev->dev, "max wake-up retries reached\n");
+   return;
+   }
}
 }
 
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 02/12] staging: wfx: improve usage of hif_map_link()

[Jerome Pouiller]

From: Jérôme Pouiller 

Until now, hif_map_link() get as argument the raw value for
map_link_flags when map_link_flags is defined as a bitfield. It was
error prone.

Now hif_map_link() takes explicit value for every flags of the
struct map_link_flags.

Signed-off-by: Jérôme Pouiller 
---
 drivers/staging/wfx/hif_tx.c | 5 +++--
 drivers/staging/wfx/hif_tx.h | 3 ++-
 drivers/staging/wfx/sta.c| 4 ++--
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/wfx/hif_tx.c b/drivers/staging/wfx/hif_tx.c
index 3b5f4dcc469c..6b89e55f03f4 100644
--- a/drivers/staging/wfx/hif_tx.c
+++ b/drivers/staging/wfx/hif_tx.c
@@ -499,7 +499,7 @@ int hif_beacon_transmit(struct wfx_vif *wvif, bool enable)
return ret;
 }
 
-int hif_map_link(struct wfx_vif *wvif, u8 *mac_addr, int flags, int sta_id)
+int hif_map_link(struct wfx_vif *wvif, bool unmap, u8 *mac_addr, int sta_id, 
bool mfp)
 {
int ret;
struct hif_msg *hif;
@@ -509,7 +509,8 @@ int hif_map_link(struct wfx_vif *wvif, u8 *mac_addr, int 
flags, int sta_id)
return -ENOMEM;
if (mac_addr)
ether_addr_copy(body->mac_addr, mac_addr);
-   body->map_link_flags = *(struct hif_map_link_flags *)
+   body->map_link_flags.mfpc = mfp ? 1 : 0;
+   body->map_link_flags.map_direction = unmap ? 1 : 0;
body->peer_sta_id = sta_id;
wfx_fill_header(hif, wvif->id, HIF_REQ_ID_MAP_LINK, sizeof(*body));
ret = wfx_cmd_send(wvif->wdev, hif, NULL, 0, false);
diff --git a/drivers/staging/wfx/hif_tx.h b/drivers/staging/wfx/hif_tx.h
index e1da28aef706..b371b3777a31 100644
--- a/drivers/staging/wfx/hif_tx.h
+++ b/drivers/staging/wfx/hif_tx.h
@@ -55,7 +55,8 @@ int hif_set_edca_queue_params(struct wfx_vif *wvif, u16 queue,
 int hif_start(struct wfx_vif *wvif, const struct ieee80211_bss_conf *conf,
  const struct ieee80211_channel *channel);
 int hif_beacon_transmit(struct wfx_vif *wvif, bool enable);
-int hif_map_link(struct wfx_vif *wvif, u8 *mac_addr, int flags, int sta_id);
+int hif_map_link(struct wfx_vif *wvif,
+bool unmap, u8 *mac_addr, int sta_id, bool mfp);
 int hif_update_ie_beacon(struct wfx_vif *wvif, const u8 *ies, size_t ies_len);
 int hif_sl_set_mac_key(struct wfx_dev *wdev,
   const u8 *slk_key, int destination);
diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c
index c31e302d05c9..b6ccb04f308a 100644
--- a/drivers/staging/wfx/sta.c
+++ b/drivers/staging/wfx/sta.c
@@ -434,7 +434,7 @@ int wfx_sta_add(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
wvif->link_id_map |= BIT(sta_priv->link_id);
WARN_ON(!sta_priv->link_id);
WARN_ON(sta_priv->link_id >= HIF_LINK_ID_MAX);
-   hif_map_link(wvif, sta->addr, sta->mfp ? 2 : 0, sta_priv->link_id);
+   hif_map_link(wvif, false, sta->addr, sta_priv->link_id, sta->mfp);
 
return 0;
 }
@@ -449,7 +449,7 @@ int wfx_sta_remove(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
if (!sta_priv->link_id)
return 0;
// FIXME add a mutex?
-   hif_map_link(wvif, sta->addr, 1, sta_priv->link_id);
+   hif_map_link(wvif, true, sta->addr, sta_priv->link_id, false);
wvif->link_id_map &= ~BIT(sta_priv->link_id);
return 0;
 }
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 10/12] staging: wfx: enable powersave on probe

[Jerome Pouiller]

From: Jérôme Pouiller 

In the old days, ieee80211 powersave has some impact on the Rx speed.
These problems are solved for a long time now. There is no more reason
to not enabling it.

Signed-off-by: Jérôme Pouiller 
---
 drivers/staging/wfx/main.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/wfx/main.c b/drivers/staging/wfx/main.c
index 5a3018e14445..5e2b82499004 100644
--- a/drivers/staging/wfx/main.c
+++ b/drivers/staging/wfx/main.c
@@ -285,7 +285,6 @@ struct wfx_dev *wfx_init_common(struct device *dev,
hw->wiphy->features |= NL80211_FEATURE_AP_SCAN;
hw->wiphy->flags |= WIPHY_FLAG_AP_PROBE_RESP_OFFLOAD;
hw->wiphy->flags |= WIPHY_FLAG_AP_UAPSD;
-   hw->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
hw->wiphy->max_ap_assoc_sta = HIF_LINK_ID_MAX;
hw->wiphy->max_scan_ssids = 2;
hw->wiphy->max_scan_ie_len = IEEE80211_MAX_DATA_LEN;
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 06/12] staging: wfx: drop useless field from struct wfx_tx_priv

[Jerome Pouiller]

From: Jérôme Pouiller 

The device need to receive a skb with necessary space for the ICV. So,
the driver adds this space before to send the frame.

Currently, once the frame is sent, the driver restore the original
content of the skb. However, this step is useless. Mac80211 don't do it
when software encryption is enabled.

Once we have removed this step, it appears that it is no more necessary
to keep hw_key in tx_priv. Then, it is possible to simplify a bunch of
code in the Tx path.

Signed-off-by: Jérôme Pouiller 
---
 drivers/staging/wfx/data_tx.c | 16 
 drivers/staging/wfx/data_tx.h |  3 +--
 2 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c
index d16b516ad7cf..485907b0faa2 100644
--- a/drivers/staging/wfx/data_tx.c
+++ b/drivers/staging/wfx/data_tx.c
@@ -336,7 +336,6 @@ static int wfx_tx_inner(struct wfx_vif *wvif, struct 
ieee80211_sta *sta,
 {
struct hif_msg *hif_msg;
struct hif_req_tx *req;
-   struct wfx_tx_priv *tx_priv;
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ieee80211_key_conf *hw_key = tx_info->control.hw_key;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
@@ -350,14 +349,11 @@ static int wfx_tx_inner(struct wfx_vif *wvif, struct 
ieee80211_sta *sta,
 
// From now tx_info->control is unusable
memset(tx_info->rate_driver_data, 0, sizeof(struct wfx_tx_priv));
-   // Fill tx_priv
-   tx_priv = (struct wfx_tx_priv *)tx_info->rate_driver_data;
-   tx_priv->hw_key = hw_key;
 
// Fill hif_msg
WARN(skb_headroom(skb) < wmsg_len, "not enough space in skb");
WARN(offset & 1, "attempt to transmit an unaligned frame");
-   skb_put(skb, wfx_tx_get_icv_len(tx_priv->hw_key));
+   skb_put(skb, wfx_tx_get_icv_len(hw_key));
skb_push(skb, wmsg_len);
memset(skb->data, 0, wmsg_len);
hif_msg = (struct hif_msg *)skb->data;
@@ -489,7 +485,6 @@ static void wfx_tx_fill_rates(struct wfx_dev *wdev,
 void wfx_tx_confirm_cb(struct wfx_dev *wdev, const struct hif_cnf_tx *arg)
 {
struct ieee80211_tx_info *tx_info;
-   const struct wfx_tx_priv *tx_priv;
struct wfx_vif *wvif;
struct sk_buff *skb;
 
@@ -499,18 +494,15 @@ void wfx_tx_confirm_cb(struct wfx_dev *wdev, const struct 
hif_cnf_tx *arg)
 arg->packet_id);
return;
}
+   tx_info = IEEE80211_SKB_CB(skb);
wvif = wdev_to_wvif(wdev, ((struct hif_msg *)skb->data)->interface);
WARN_ON(!wvif);
if (!wvif)
return;
-   tx_info = IEEE80211_SKB_CB(skb);
-   tx_priv = wfx_skb_tx_priv(skb);
+
+   // Note that wfx_pending_get_pkt_us_delay() get data from tx_info
_trace_tx_stats(arg, skb, wfx_pending_get_pkt_us_delay(wdev, skb));
-
-   // You can touch to tx_priv, but don't touch to tx_info->status.
wfx_tx_fill_rates(wdev, tx_info, arg);
-   skb_trim(skb, skb->len - wfx_tx_get_icv_len(tx_priv->hw_key));
-
// From now, you can touch to tx_info->status, but do not touch to
// tx_priv anymore
// FIXME: use ieee80211_tx_info_clear_status()
diff --git a/drivers/staging/wfx/data_tx.h b/drivers/staging/wfx/data_tx.h
index cff7b9ff99a9..87e1b9b62dbb 100644
--- a/drivers/staging/wfx/data_tx.h
+++ b/drivers/staging/wfx/data_tx.h
@@ -35,8 +35,7 @@ struct tx_policy_cache {
 
 struct wfx_tx_priv {
ktime_t xmit_timestamp;
-   struct ieee80211_key_conf *hw_key;
-} __packed;
+};
 
 void wfx_tx_policy_init(struct wfx_vif *wvif);
 void wfx_tx_policy_upload_work(struct work_struct *work);
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 11/12] staging: wfx: remove useless extra jiffy

[Jerome Pouiller]

From: Jérôme Pouiller 

The initial developer has feared msecs_to_jiffies() could round down the
result. However, the documentation of msecs_to_jiffies() says that the
result is rounded upward. So the increment of the result of
msecs_to_jiffies() is not necessary.

Signed-off-by: Jérôme Pouiller 
---
 drivers/staging/wfx/bh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wfx/bh.c b/drivers/staging/wfx/bh.c
index 53ae0b5abcdd..07304a80c29b 100644
--- a/drivers/staging/wfx/bh.c
+++ b/drivers/staging/wfx/bh.c
@@ -33,7 +33,7 @@ static void device_wakeup(struct wfx_dev *wdev)
// wait_for_completion_done_timeout()). So we have to emulate
// it.
if (wait_for_completion_timeout(>hif.ctrl_ready,
-   msecs_to_jiffies(2) + 1))
+   msecs_to_jiffies(2)))
complete(>hif.ctrl_ready);
else
dev_err(wdev->dev, "timeout while wake up chip\n");
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 09/12] staging: wfx: scan while AP is supported

[Jerome Pouiller]

From: Jérôme Pouiller 

The device is able to scan while running an Access Point. Just declare
it.

Signed-off-by: Jérôme Pouiller 
---
 drivers/staging/wfx/main.c | 1 +
 drivers/staging/wfx/scan.c | 4 
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/staging/wfx/main.c b/drivers/staging/wfx/main.c
index 4263f912760b..5a3018e14445 100644
--- a/drivers/staging/wfx/main.c
+++ b/drivers/staging/wfx/main.c
@@ -282,6 +282,7 @@ struct wfx_dev *wfx_init_common(struct device *dev,
NL80211_PROBE_RESP_OFFLOAD_SUPPORT_WPS2 
|
NL80211_PROBE_RESP_OFFLOAD_SUPPORT_P2P |

NL80211_PROBE_RESP_OFFLOAD_SUPPORT_80211U;
+   hw->wiphy->features |= NL80211_FEATURE_AP_SCAN;
hw->wiphy->flags |= WIPHY_FLAG_AP_PROBE_RESP_OFFLOAD;
hw->wiphy->flags |= WIPHY_FLAG_AP_UAPSD;
hw->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
diff --git a/drivers/staging/wfx/scan.c b/drivers/staging/wfx/scan.c
index e9de19784865..02d4e653d594 100644
--- a/drivers/staging/wfx/scan.c
+++ b/drivers/staging/wfx/scan.c
@@ -113,10 +113,6 @@ int wfx_hw_scan(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
struct wfx_vif *wvif = (struct wfx_vif *)vif->drv_priv;
 
WARN_ON(hw_req->req.n_channels > HIF_API_MAX_NB_CHANNELS);
-
-   if (vif->type == NL80211_IFTYPE_AP)
-   return -EOPNOTSUPP;
-
wvif->scan_req = hw_req;
schedule_work(>scan_work);
return 0;
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 08/12] staging: wfx: fix potential use before init

[Jerome Pouiller]

From: Jérôme Pouiller 

The trace below can appear:

[83613.832200] INFO: trying to register non-static key.
[83613.837248] the code is fine but needs lockdep annotation.
[83613.842808] turning off the locking correctness validator.
[83613.848375] CPU: 3 PID: 141 Comm: kworker/3:2H Tainted: G   O
  5.6.13-silabs15 #2
[83613.857019] Hardware name: BCM2835
[83613.860605] Workqueue: events_highpri bh_work [wfx]
[83613.865552] Backtrace:
[83613.868041] [] (dump_backtrace) from [] 
(show_stack+0x20/0x24)
[83613.881463] [] (show_stack) from [] 
(dump_stack+0xe8/0x114)
[83613.82] [] (dump_stack) from [] 
(register_lock_class+0x748/0x768)
[83613.905035] [] (register_lock_class) from [] 
(__lock_acquire+0x88/0x13dc)
[83613.924192] [] (__lock_acquire) from [] 
(lock_acquire+0xe8/0x274)
[83613.942644] [] (lock_acquire) from [] 
(_raw_spin_lock_irqsave+0x58/0x6c)
[83613.961714] [] (_raw_spin_lock_irqsave) from [] 
(skb_dequeue+0x24/0x78)
[83613.974967] [] (skb_dequeue) from [] 
(wfx_tx_queues_get+0x96c/0x1294 [wfx])
[83613.989728] [] (wfx_tx_queues_get [wfx]) from [] 
(bh_work+0x454/0x26d8 [wfx])
[83614.009337] [] (bh_work [wfx]) from [] 
(process_one_work+0x23c/0x7ec)
[83614.028141] [] (process_one_work) from [] 
(worker_thread+0x4c/0x55c)
[83614.046861] [] (worker_thread) from [] 
(kthread+0x138/0x168)
[83614.064876] [] (kthread) from [] 
(ret_from_fork+0x14/0x20)
[83614.072200] Exception stack(0xecad3fb0 to 0xecad3ff8)
[83614.077323] 3fa0:   
 
[83614.085620] 3fc0:       
 
[83614.093914] 3fe0:     0013 

Indeed, the code of wfx_add_interface() shows that the interface is
enabled to early. So, the spinlock associated with some skb_queue may
not yet initialized when wfx_tx_queues_get() is called.

Signed-off-by: Jérôme Pouiller 
---
 drivers/staging/wfx/sta.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c
index 7a4c9f63c4a2..a890fe32161c 100644
--- a/drivers/staging/wfx/sta.c
+++ b/drivers/staging/wfx/sta.c
@@ -759,17 +759,6 @@ int wfx_add_interface(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif)
return -EOPNOTSUPP;
}
 
-   for (i = 0; i < ARRAY_SIZE(wdev->vif); i++) {
-   if (!wdev->vif[i]) {
-   wdev->vif[i] = vif;
-   wvif->id = i;
-   break;
-   }
-   }
-   if (i == ARRAY_SIZE(wdev->vif)) {
-   mutex_unlock(>conf_mutex);
-   return -EOPNOTSUPP;
-   }
// FIXME: prefer use of container_of() to get vif
wvif->vif = vif;
wvif->wdev = wdev;
@@ -786,12 +775,22 @@ int wfx_add_interface(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif)
init_completion(>scan_complete);
INIT_WORK(>scan_work, wfx_hw_scan_work);
 
-   mutex_unlock(>conf_mutex);
-
-   hif_set_macaddr(wvif, vif->addr);
-
wfx_tx_queues_init(wvif);
wfx_tx_policy_init(wvif);
+
+   for (i = 0; i < ARRAY_SIZE(wdev->vif); i++) {
+   if (!wdev->vif[i]) {
+   wdev->vif[i] = vif;
+   wvif->id = i;
+   break;
+   }
+   }
+   WARN(i == ARRAY_SIZE(wdev->vif), "try to instantiate more vif than 
supported");
+
+   hif_set_macaddr(wvif, vif->addr);
+
+   mutex_unlock(>conf_mutex);
+
wvif = NULL;
while ((wvif = wvif_iterate(wdev, wvif)) != NULL) {
// Combo mode does not support Block Acks. We can re-enable them
@@ -823,6 +822,7 @@ void wfx_remove_interface(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif)
wvif->vif = NULL;
 
mutex_unlock(>conf_mutex);
+
wvif = NULL;
while ((wvif = wvif_iterate(wdev, wvif)) != NULL) {
// Combo mode does not support Block Acks. We can re-enable them
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 05/12] staging: wfx: fix support for cipher AES_CMAC (multicast PMF)

[Jerome Pouiller]

From: Jérôme Pouiller 

When MFP is enabled, the multicast management frames are not protected,
in fact. Instead, but they should include an IE containing the MMIC of
the frames (i.e. a cryptographic signature).

Until now, the driver didn't correctly detect this kind of frames (they
are not marked protected but they are associated to a key) and didn't
ask to the device to encrypt them.

In add, the device is not able to generate the IE itself. Mac80211 has
to generate the IE and let the device compute the MMIC.

Signed-off-by: Jérôme Pouiller 
---
 drivers/staging/wfx/data_tx.c | 5 +++--
 drivers/staging/wfx/key.c | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c
index 41f9afd41e14..d16b516ad7cf 100644
--- a/drivers/staging/wfx/data_tx.c
+++ b/drivers/staging/wfx/data_tx.c
@@ -325,6 +325,8 @@ static int wfx_tx_get_icv_len(struct ieee80211_key_conf 
*hw_key)
 
if (!hw_key)
return 0;
+   if (hw_key->cipher == WLAN_CIPHER_SUITE_AES_CMAC)
+   return 0;
mic_space = (hw_key->cipher == WLAN_CIPHER_SUITE_TKIP) ? 8 : 0;
return hw_key->icv_len + mic_space;
 }
@@ -350,8 +352,7 @@ static int wfx_tx_inner(struct wfx_vif *wvif, struct 
ieee80211_sta *sta,
memset(tx_info->rate_driver_data, 0, sizeof(struct wfx_tx_priv));
// Fill tx_priv
tx_priv = (struct wfx_tx_priv *)tx_info->rate_driver_data;
-   if (ieee80211_has_protected(hdr->frame_control))
-   tx_priv->hw_key = hw_key;
+   tx_priv->hw_key = hw_key;
 
// Fill hif_msg
WARN(skb_headroom(skb) < wmsg_len, "not enough space in skb");
diff --git a/drivers/staging/wfx/key.c b/drivers/staging/wfx/key.c
index 6165df59ecf9..728e5f8d3b7c 100644
--- a/drivers/staging/wfx/key.c
+++ b/drivers/staging/wfx/key.c
@@ -198,8 +198,8 @@ static int wfx_add_key(struct wfx_vif *wvif, struct 
ieee80211_sta *sta,
else
k.type = fill_sms4_group(_group_key, key);
} else if (key->cipher == WLAN_CIPHER_SUITE_AES_CMAC) {
-   k.type = fill_aes_cmac_group(_group_key, key,
-);
+   k.type = fill_aes_cmac_group(_group_key, key, );
+   key->flags |= IEEE80211_KEY_FLAG_GENERATE_MMIE;
} else {
dev_warn(wdev->dev, "unsupported key type %d\n", key->cipher);
wfx_free_key(wdev, idx);
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 07/12] staging: wfx: fix frame reordering

[Jerome Pouiller]

From: Jérôme Pouiller 

When mac80211 debug is enabled, the trace below appears:

[60744.340037] wlan0: Rx A-MPDU request on aa:bb:cc:97:60:24 tid 0 result 
-524

This imply that ___ieee80211_start_rx_ba_session will prematurely exit
and frame reordering won't be enabled.

Fixes: e5da5fbd77411 ("staging: wfx: fix CCMP/TKIP replay protection")
Signed-off-by: Jérôme Pouiller 
---
 drivers/staging/wfx/sta.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c
index 2b848b8985df..7a4c9f63c4a2 100644
--- a/drivers/staging/wfx/sta.c
+++ b/drivers/staging/wfx/sta.c
@@ -680,15 +680,16 @@ int wfx_ampdu_action(struct ieee80211_hw *hw,
 struct ieee80211_vif *vif,
 struct ieee80211_ampdu_params *params)
 {
-   /* Aggregation is implemented fully in firmware,
-* including block ack negotiation. Do not allow
-* mac80211 stack to do anything: it interferes with
-* the firmware.
-*/
-
-   /* Note that we still need this function stubbed. */
-
-   return -ENOTSUPP;
+   // Aggregation is implemented fully in firmware
+   switch (params->action) {
+   case IEEE80211_AMPDU_RX_START:
+   case IEEE80211_AMPDU_RX_STOP:
+   // Just acknowledge it to enable frame re-ordering
+   return 0;
+   default:
+   // Leave the firmware doing its business for tx aggregation
+   return -ENOTSUPP;
+   }
 }
 
 int wfx_add_chanctx(struct ieee80211_hw *hw,
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 04/12] staging: wfx: fix spaces around binary operators

[Jerome Pouiller]

From: Jérôme Pouiller 

A binary operator should be followed by exactly one space.

Signed-off-by: Jérôme Pouiller 
---
 drivers/staging/wfx/key.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wfx/key.c b/drivers/staging/wfx/key.c
index 5ee2ffc5f935..6165df59ecf9 100644
--- a/drivers/staging/wfx/key.c
+++ b/drivers/staging/wfx/key.c
@@ -171,7 +171,7 @@ static int wfx_add_key(struct wfx_vif *wvif, struct 
ieee80211_sta *sta,
k.int_id = wvif->id;
k.entry_index = idx;
if (key->cipher == WLAN_CIPHER_SUITE_WEP40 ||
-   key->cipher ==  WLAN_CIPHER_SUITE_WEP104) {
+   key->cipher == WLAN_CIPHER_SUITE_WEP104) {
if (pairwise)
k.type = fill_wep_pair(_pairwise_key, key,
   sta->addr);
@@ -191,13 +191,13 @@ static int wfx_add_key(struct wfx_vif *wvif, struct 
ieee80211_sta *sta,
else
k.type = fill_ccmp_group(_group_key, key,
 );
-   } else if (key->cipher ==  WLAN_CIPHER_SUITE_SMS4) {
+   } else if (key->cipher == WLAN_CIPHER_SUITE_SMS4) {
if (pairwise)
k.type = fill_sms4_pair(_pairwise_key, key,
sta->addr);
else
k.type = fill_sms4_group(_group_key, key);
-   } else if (key->cipher ==  WLAN_CIPHER_SUITE_AES_CMAC) {
+   } else if (key->cipher == WLAN_CIPHER_SUITE_AES_CMAC) {
k.type = fill_aes_cmac_group(_group_key, key,
 );
} else {
-- 
2.28.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: emxx_udc: Fix passing of NULL to dma_alloc_coherent()

[Dan Carpenter]

On Tue, Aug 25, 2020 at 09:14:59AM +0100, Alex Dewar wrote:
> On Tue, Aug 25, 2020 at 10:37:13AM +0300, Dan Carpenter wrote:
> > On Mon, Aug 24, 2020 at 04:57:12PM +0100, Alex Dewar wrote:
> > > On Mon, Aug 24, 2020 at 04:19:17PM +0100, Alex Dewar wrote:
> > > > In nbu2ss_eq_queue() memory is allocated with dma_alloc_coherent(),
> > > > though, strangely, NULL is passed as the struct device* argument. Pass
> > > > the UDC's device instead.
> > 
> > I think passing NULL was always wrong, but it used to not cause an Oops.
> > This was changed a year or two ago.
> > 
> > > > 
> > > > Build-tested on x86 only.
> > > > 
> > > > Fixes: 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile USB Gadget 
> > > > driver")
> > > > Signed-off-by: Alex Dewar 
> > > > ---
> > > > 
> > > > So I *think* this is the right fix, but I don't have the hardware so
> > > > I've only been able to build-test it. My worry is that I could be
> > > > passing in the wrong struct device* here, which would squelch the
> > > > warning without fixing the breakage.
> > > > 
> > > > Can someone cleverer than me tell me if this makes sense?
> > > > 
> > > > - Alex
> > > 
> > > PS -- I meant to put an RFC in the subject line and an extra tag:
> > > Reported-by: Dan Carpenter 
> > > 
> > 
> > I don't know which dev pointer we're supposed to pass...  It would be
> > good to find someone to test the patch but if not then applying your
> > patch is reasonable.
> > 
> > But could you search through the file and update the rest as well.
> > The dma_free_coherent() needs to be updated and there was a second
> > dma_alloc_coherent() in the bug report.
> > 
> > regards,
> > dan carpenter
> > 
> 
> I can only find the one instance of dma_alloc_coherent(). Was it by any
> chance a different warning about the same call?

Ah  It was warning about the dma_free_coherent().

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: emxx_udc: Fix passing of NULL to dma_alloc_coherent()

[Alex Dewar]

On Tue, Aug 25, 2020 at 10:37:13AM +0300, Dan Carpenter wrote:
> On Mon, Aug 24, 2020 at 04:57:12PM +0100, Alex Dewar wrote:
> > On Mon, Aug 24, 2020 at 04:19:17PM +0100, Alex Dewar wrote:
> > > In nbu2ss_eq_queue() memory is allocated with dma_alloc_coherent(),
> > > though, strangely, NULL is passed as the struct device* argument. Pass
> > > the UDC's device instead.
> 
> I think passing NULL was always wrong, but it used to not cause an Oops.
> This was changed a year or two ago.
> 
> > > 
> > > Build-tested on x86 only.
> > > 
> > > Fixes: 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile USB Gadget 
> > > driver")
> > > Signed-off-by: Alex Dewar 
> > > ---
> > > 
> > > So I *think* this is the right fix, but I don't have the hardware so
> > > I've only been able to build-test it. My worry is that I could be
> > > passing in the wrong struct device* here, which would squelch the
> > > warning without fixing the breakage.
> > > 
> > > Can someone cleverer than me tell me if this makes sense?
> > > 
> > > - Alex
> > 
> > PS -- I meant to put an RFC in the subject line and an extra tag:
> > Reported-by: Dan Carpenter 
> > 
> 
> I don't know which dev pointer we're supposed to pass...  It would be
> good to find someone to test the patch but if not then applying your
> patch is reasonable.
> 
> But could you search through the file and update the rest as well.
> The dma_free_coherent() needs to be updated and there was a second
> dma_alloc_coherent() in the bug report.
> 
> regards,
> dan carpenter
> 

I can only find the one instance of dma_alloc_coherent(). Was it by any
chance a different warning about the same call?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: emxx_udc: Fix passing of NULL to dma_alloc_coherent()

[Dan Carpenter]

On Mon, Aug 24, 2020 at 04:57:12PM +0100, Alex Dewar wrote:
> On Mon, Aug 24, 2020 at 04:19:17PM +0100, Alex Dewar wrote:
> > In nbu2ss_eq_queue() memory is allocated with dma_alloc_coherent(),
> > though, strangely, NULL is passed as the struct device* argument. Pass
> > the UDC's device instead.

I think passing NULL was always wrong, but it used to not cause an Oops.
This was changed a year or two ago.

> > 
> > Build-tested on x86 only.
> > 
> > Fixes: 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile USB Gadget driver")
> > Signed-off-by: Alex Dewar 
> > ---
> > 
> > So I *think* this is the right fix, but I don't have the hardware so
> > I've only been able to build-test it. My worry is that I could be
> > passing in the wrong struct device* here, which would squelch the
> > warning without fixing the breakage.
> > 
> > Can someone cleverer than me tell me if this makes sense?
> > 
> > - Alex
> 
> PS -- I meant to put an RFC in the subject line and an extra tag:
> Reported-by: Dan Carpenter 
> 

I don't know which dev pointer we're supposed to pass...  It would be
good to find someone to test the patch but if not then applying your
patch is reasonable.

But could you search through the file and update the rest as well.
The dma_free_coherent() needs to be updated and there was a second
dma_alloc_coherent() in the bug report.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

kindly respond to my mail

[Sgt Vivian Robert]

Good Day, I am glad to contact you through this medium I’m Sgt Vivian Robert am 
from united state, 28 years old single I am the only surviving child of my late 
parents, I am America female soldier presently in Afghanistan for the training, 
advising the Afghan forces and also helping in stabilizing the country against 
security challenges, am Actually seeking your assistance to evacuate the sum of 
$3.5 million, This money I got it as my reward in service by Afghanistan 
government to support me for my Good job in their land. Right now, I want you 
to stand as my beneficiary and receive the fund my certificate of deposit from 
the Bank where this fund deposited and my authorization letter is with me 
now.My contact with you is not by my power but it is divinely made for God's 
purpose to be fulfilled in our lives. I want you to be rest assured that this 
transaction is legitimate and a 100% risk free involvement, all you have to do 
is to keep it secret and confidential to yourself , this transaction will not 
take more than 7 working banking days for the money to get into your account 
based on your sincerity and cooperation. i want you to take 40% Percent of the 
total money for your personal use While 20% Percent of the money will go to 
charity, people in the street and helping the orphanage the remaining 40% 
percent of the total money .you will assist me to invest it in a good 
profitable Venture or you keep it for me until I arrive your country. If you’re 
willing to assist me contact me through my email address “sgtviva...@gmail.com.

Sgt Vivian Robert
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 0/2] staging: android: Remove BUG/BUG_ON from ion

[Greg Kroah-Hartman]

On Tue, Aug 25, 2020 at 07:47:29AM +0100, Christoph Hellwig wrote:
> On Fri, Aug 21, 2020 at 06:27:04PM +0300, Tomer Samara wrote:
> > Remove BUG/BUG_ON from androind/ion
> 
> Please just remove ion.  It has been rejected and we have developed
> proper kernel subsystens to replace it.  Don't waste your time on it.

It is going to be removed at the end of this year.  Why we keep it
around until then, I really don't know, but John and Laura have this as
the plan.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 0/2] staging: android: Remove BUG/BUG_ON from ion

[Christoph Hellwig]

On Fri, Aug 21, 2020 at 06:27:04PM +0300, Tomer Samara wrote:
> Remove BUG/BUG_ON from androind/ion

Please just remove ion.  It has been rejected and we have developed
proper kernel subsystens to replace it.  Don't waste your time on it.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel