[PATCH] media: cedrus: h264: Fix 4K decoding on H6

2020-03-15 Thread Jernej Skrabec
Due to unknown reason, H6 needs larger intraprediction buffer for 4K
videos than other SoCs. This was discovered by playing 4096x2304 video,
which is maximum what H6 VPU is supposed to support.

Fixes: 03e612e701a6 ("media: cedrus: Fix H264 4k support")
Signed-off-by: Jernej Skrabec 
---
 drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
index bfb4a4820a67..54ee2aa423e2 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
@@ -610,8 +610,12 @@ static int cedrus_h264_start(struct cedrus_ctx *ctx)
goto err_mv_col_buf;
}
 
+   /*
+* NOTE: Multiplying by two deviates from CedarX logic, but it
+* is for some unknown reason needed for H264 4K decoding on H6.
+*/
ctx->codec.h264.intra_pred_buf_size =
-   ALIGN(ctx->src_fmt.width, 64) * 5;
+   ALIGN(ctx->src_fmt.width, 64) * 5 * 2;
ctx->codec.h264.intra_pred_buf =
dma_alloc_coherent(dev->dev,
   ctx->codec.h264.intra_pred_buf_size,
-- 
2.25.1

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


Re: [PATCH v4 0/6] staging: mt7621-pci: re-do reset boot process

2020-03-15 Thread Sergio Paracuellos
Hi,

On Sat, Mar 14, 2020 at 11:42 AM Sergio Paracuellos
 wrote:
[snip]

> >
> > Changes in v4:
> > * Make use of 'devm_gpiod_get_index_optional' instead of 
> > 'devm_gpiod_get_index'.
> > * Use 'dev_err' instead of 'dev_notice' and return ERR_PTR if
> > 'devm_gpiod_get_index_optional' fails.
> > * Rename pers dealy macro to PERST_DELAY_MS.
> > * Add new patch 6 which removes function 'mt7621_reset_port' not needed 
> > anymore.
>
> It seems this series work but due to an unknow bug set / clear gpio
> registers are not properly working.
> So maybe this patch is also necessary:
> https://github.com/openwrt/openwrt/pull/2798/commits/823d41e28b4e15734560508b29df726b16c51dab

An update on this. It seems gpio-mmio driver upstream is broken for
this arch because bgpio_dir_out sets pin value before specifying pin
mode and set/clear register only works when pin is at output mode.

The following patches have been sent to linux-gpio mail list by Chuanhong Guo:

https://marc.info/?l=linux-gpio&m=158427446906895&w=2

This issue does not affect this pcie driver.

Best regards,
 Sergio Paracuellos
>
> Should this patch be also properly added to the tree? Added Linus
> Walleij and René van Dorst in order to get feedback about this issue.
>
> I also add all the thread to get openwrt working with 5.4 in where
> this patches and the gpio one have been added (just in case is
> interesting for anyone):
> https://github.com/openwrt/openwrt/pull/2798
>
> Best regards,
> Sergio Paracuellos
> >
> > Changes in v3:
> > * Avoid to fail if gpio descriptor fails on get.
> > * re-do PATCH 1 commit message.
> > * Take into account gpio low polarity on request and assert and deassert.
> > * Review error path of driver to properly release gpio's resources.
> >
> > Changes in v2:
> > * restore configuration for pers mode to GPIO.
> > * Avoid to read FTS_NUM register in reset state.
> > * Release gpio's patch added
> >
> > Best regards,
> > Sergio Paracuellos
> >
> >
> > Sergio Paracuellos (6):
> >   staging: mt7621-pci: use gpios for properly reset
> >   staging: mt7621-pci: change value for 'PERST_DELAY_MS'
> >   staging: mt7621-dts: make use of 'reset-gpios' property for pci
> >   staging: mt7621-pci: bindings: update doc accordly to last changes
> >   staging: mt7621-pci: release gpios after pci initialization
> >   staging: mt7621-pci: delete no more needed 'mt7621_reset_port'
> >
> >  drivers/staging/mt7621-dts/mt7621.dtsi|  11 +-
> >  .../mt7621-pci/mediatek,mt7621-pci.txt|   7 +-
> >  drivers/staging/mt7621-pci/pci-mt7621.c   | 122 ++
> >  3 files changed, 82 insertions(+), 58 deletions(-)
> >
> > --
> > 2.25.1
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v3 0/5] staging: mt7621-pci: re-do reset boot process

2020-03-15 Thread Sergio Paracuellos
Hi Greg,

On Sun, Mar 15, 2020 at 1:32 PM Greg Ungerer  wrote:
>
> Hi Sergio,
>
> On 13/3/20 3:45 pm, Sergio Paracuellos wrote:
> > On Fri, Mar 13, 2020 at 4:51 AM Greg Ungerer  wrote:
> > [snip]
> >>
> >> I applied the patches to the staging git tree for testing.
> >> I have seen a couple of different problems on boot up:
> >>
> >> ...
> >> rt2880-pinmux pinctrl: pcie is already enabled
> >> mt7621-pci 1e14.pcie: Error applying setting, reverse things back
> >> mt7621-pci 1e14.pcie: Failed to get GPIO for PCIe1
> >> mt7621-pci 1e14.pcie: Failed to get GPIO for PCIe2
> >> gpiod_set_value: invalid GPIO (errorpointer)
> >> gpiod_set_value: invalid GPIO (errorpointer)
> >
> > So the not grabbed gpio's are error pointers instead of NULL. What
> > happen if you just
> > set them to NULL? Something like:
> >
> > diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
> > b/drivers/staging/mt7621-pci/pci-mt7621.c
> > index 6ea284942b6f..03c1f057b29f 100644
> > --- a/drivers/staging/mt7621-pci/pci-mt7621.c
> > +++ b/drivers/staging/mt7621-pci/pci-mt7621.c
> > @@ -367,8 +367,10 @@ static int mt7621_pcie_parse_port(struct mt7621_pcie 
> > *pcie,
> >
> >  port->gpio_rst = devm_gpiod_get_index(dev, "reset", slot,
> >GPIOD_OUT_LOW);
> > -   if (IS_ERR(port->gpio_rst))
> > +   if (IS_ERR(port->gpio_rst)) {
> > +   port->gpio_rst = NULL;
> >  dev_notice(dev, "Failed to get GPIO for PCIe%d\n", slot);
> > +   }
> >
> > Another possibility would be to use 'gpio_is_valid' getting int gpio
> > value from descriptor using 'gpio_to_desc' but I think we were mixing
> > legacy gpio APIS with the descriptor interface one which sound not
> > good.
>
> I will try this and let you know. (It looks like in v4 you did this
> differently though?).

v4 uses 'devm_gpiod_get_index_optional' instead of
'devm_gpiod_get_index' to avoid the error pointer and explicitely set
it to NULL. It should work for you also, AFAICT.

Regards,
Sergio Paracuellos
>
> FWIW, on my hardware platform GPIO 7 and 8 are not used for PCI resets.
> They are wired out as serial port signals (DCD and DTR), and they are
> defined in my device tree as that.
>
> Regards
> Greg
>
>
>
> >> mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
> >> mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
> >> mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
> >> gpiod_set_value: invalid GPIO (errorpointer)
> >> gpiod_set_value: invalid GPIO (errorpointer)
> >> mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & CLK)
> >> mt7621-pci 1e14.pcie: pcie2 no card, disable it (RST & CLK)
> >> mt7621-pci 1e14.pcie: PCIE0 enabled
> >> mt7621-pci 1e14.pcie: PCI coherence region base: 0x6000, 
> >> mask/settings: 0xf002
> >> mt7621-pci 1e14.pcie: PCI host bridge to bus :00
> >> pci_bus :00: root bus resource [io  0x]
> >> pci_bus :00: root bus resource [mem 0x6000-0x6fff]
> >> pci_bus :00: root bus resource [bus 00-ff]
> >> pci :00:00.0: [0e8d:0801] type 01 class 0x060400
> >> pci :00:00.0: reg 0x10: [mem 0x-0x7fff]
> >> pci :00:00.0: reg 0x14: [mem 0x-0x]
> >> pci :00:00.0: supports D1
> >> pci :00:00.0: PME# supported from D0 D1 D3hot
> >> pci :00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> >> pci :01:00.0: [168c:003c] type 00 class 0x028000
> >> pci :01:00.0: reg 0x10: [mem 0x-0x001f 64bit]
> >> pci :01:00.0: reg 0x30: [mem 0x-0x pref]
> >> pci :01:00.0: supports D1 D2
> >> pci :00:00.0: PCI bridge to [bus 01-ff]
> >> pci :00:00.0:   bridge window [io  0x-0x0fff]
> >> pci :00:00.0:   bridge window [mem 0x-0x000f]
> >> pci :00:00.0:   bridge window [mem 0x-0x000f pref]
> >> pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
> >> pci :00:00.0: BAR 0: no space for [mem size 0x8000]
> >> pci :00:00.0: BAR 0: failed to assign [mem size 0x8000]
> >> pci :00:00.0: BAR 8: assigned [mem 0x6000-0x601f]
> >> pci :00:00.0: BAR 9: assigned [mem 0x6020-0x602f pref]
> >> pci :00:00.0: BAR 1: assigned [mem 0x6030-0x6030]
> >> pci :00:00.0: BAR 7: no space for [io  size 0x1000]
> >> pci :00:00.0: BAR 7: failed to assign [io  size 0x1000]
> >> pci :01:00.0: BAR 0: assigned [mem 0x6000-0x601f 64bit]
> >> pci :01:00.0: BAR 6: assigned [mem 0x6020-0x6020 pref]
> >> pci :00:00.0: PCI bridge to [bus 01]
> >> pci :00:00.0:   bridge window [mem 0x6000-0x601f]
> >> pci :00:00.0:   bridge window [mem 0x6020-0x602f pref]
> >> pcieport :00:00.0: of_irq_parse_pci: failed with rc=-22
> >> pcieport :00:00.0: enabling device (0004 -> 0006)
> >> CPU 2 Unable to handle kernel paging request at virtual address fff0, 
> >> epc == 8039c7b0, ra == 804fe128
> >> Oops[#1]:
> >> CP

Re: [PATCH v3 0/5] staging: mt7621-pci: re-do reset boot process

2020-03-15 Thread Greg Ungerer

Hi Sergio,

On 13/3/20 3:45 pm, Sergio Paracuellos wrote:

On Fri, Mar 13, 2020 at 4:51 AM Greg Ungerer  wrote:
[snip]


I applied the patches to the staging git tree for testing.
I have seen a couple of different problems on boot up:

...
rt2880-pinmux pinctrl: pcie is already enabled
mt7621-pci 1e14.pcie: Error applying setting, reverse things back
mt7621-pci 1e14.pcie: Failed to get GPIO for PCIe1
mt7621-pci 1e14.pcie: Failed to get GPIO for PCIe2
gpiod_set_value: invalid GPIO (errorpointer)
gpiod_set_value: invalid GPIO (errorpointer)


So the not grabbed gpio's are error pointers instead of NULL. What
happen if you just
set them to NULL? Something like:

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 6ea284942b6f..03c1f057b29f 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -367,8 +367,10 @@ static int mt7621_pcie_parse_port(struct mt7621_pcie *pcie,

 port->gpio_rst = devm_gpiod_get_index(dev, "reset", slot,
   GPIOD_OUT_LOW);
-   if (IS_ERR(port->gpio_rst))
+   if (IS_ERR(port->gpio_rst)) {
+   port->gpio_rst = NULL;
 dev_notice(dev, "Failed to get GPIO for PCIe%d\n", slot);
+   }

Another possibility would be to use 'gpio_is_valid' getting int gpio
value from descriptor using 'gpio_to_desc' but I think we were mixing
legacy gpio APIS with the descriptor interface one which sound not
good.


I will try this and let you know. (It looks like in v4 you did this
differently though?).

FWIW, on my hardware platform GPIO 7 and 8 are not used for PCI resets.
They are wired out as serial port signals (DCD and DTR), and they are
defined in my device tree as that.

Regards
Greg




mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
gpiod_set_value: invalid GPIO (errorpointer)
gpiod_set_value: invalid GPIO (errorpointer)
mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & CLK)
mt7621-pci 1e14.pcie: pcie2 no card, disable it (RST & CLK)
mt7621-pci 1e14.pcie: PCIE0 enabled
mt7621-pci 1e14.pcie: PCI coherence region base: 0x6000, mask/settings: 
0xf002
mt7621-pci 1e14.pcie: PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x]
pci_bus :00: root bus resource [mem 0x6000-0x6fff]
pci_bus :00: root bus resource [bus 00-ff]
pci :00:00.0: [0e8d:0801] type 01 class 0x060400
pci :00:00.0: reg 0x10: [mem 0x-0x7fff]
pci :00:00.0: reg 0x14: [mem 0x-0x]
pci :00:00.0: supports D1
pci :00:00.0: PME# supported from D0 D1 D3hot
pci :00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci :01:00.0: [168c:003c] type 00 class 0x028000
pci :01:00.0: reg 0x10: [mem 0x-0x001f 64bit]
pci :01:00.0: reg 0x30: [mem 0x-0x pref]
pci :01:00.0: supports D1 D2
pci :00:00.0: PCI bridge to [bus 01-ff]
pci :00:00.0:   bridge window [io  0x-0x0fff]
pci :00:00.0:   bridge window [mem 0x-0x000f]
pci :00:00.0:   bridge window [mem 0x-0x000f pref]
pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
pci :00:00.0: BAR 0: no space for [mem size 0x8000]
pci :00:00.0: BAR 0: failed to assign [mem size 0x8000]
pci :00:00.0: BAR 8: assigned [mem 0x6000-0x601f]
pci :00:00.0: BAR 9: assigned [mem 0x6020-0x602f pref]
pci :00:00.0: BAR 1: assigned [mem 0x6030-0x6030]
pci :00:00.0: BAR 7: no space for [io  size 0x1000]
pci :00:00.0: BAR 7: failed to assign [io  size 0x1000]
pci :01:00.0: BAR 0: assigned [mem 0x6000-0x601f 64bit]
pci :01:00.0: BAR 6: assigned [mem 0x6020-0x6020 pref]
pci :00:00.0: PCI bridge to [bus 01]
pci :00:00.0:   bridge window [mem 0x6000-0x601f]
pci :00:00.0:   bridge window [mem 0x6020-0x602f pref]
pcieport :00:00.0: of_irq_parse_pci: failed with rc=-22
pcieport :00:00.0: enabling device (0004 -> 0006)
CPU 2 Unable to handle kernel paging request at virtual address fff0, epc 
== 8039c7b0, ra == 804fe128
Oops[#1]:
CPU: 2 PID: 107 Comm: kworker/2:1 Not tainted 
5.6.0-rc3-00180-gc15e7f072288-dirty #2
Workqueue: events deferred_probe_work_func
$ 0   :  0001 820d6984 0001
$ 4   : fff0 0001  803a
$ 8   : 0024  0001 302e3030
$12   :  8e26fbd8  0020
$16   : 820d6980 820e0250  8e26fcd0
$20   : 820e01e0 809a 820e0228 8fd47e10
$24   :  0020
$28   : 8e26e000 8e26fc70 8e26fcf8 804fe128
Hi: 0125
Lo: 122f2000
epc   : 8039c7b0 gpiod_free+0x14/0x6c
ra: 804fe128 mt7621_pci_probe+0x700/0xcd8
Status: 1100fc03KERNEL EXL IE
Cause : 0088 (ExcCode 02)
BadVA : fff0
PrId  : 0001992f 

Re: [Outreachy kernel] [PATCH v2] Staging: rtl8723bs: rtw_mlme: Remove unnecessary conditions

2020-03-15 Thread Joe Perches
On Sat, 2020-03-14 at 16:58 +0530, Shreeya Patel wrote:
> This could be:
> > if ((!(phtpriv->ampdu_enable) && pregistrypriv->ampdu_enable ==
> > 1)) ||
> > pregistrypriv->ampdu_enable == 2)
> > phtpriv->ampdu_enable = true;
> > 
> > Though it is probably more sensible to just set
> > phtpriv->ampdu_enable without testing whether or
> > not it's already set:
> > 
> > if (pregistrypriv->ampdu_enable == 1 ||
> > pregistrypriv->ampdu_enable == 2)
> > phtpriv->ampdu_enable = true;
> 
> But the else-if block which I removed in v2 of this patch had nothing
> in the block.
> It was not assigning any value to "phtpriv->ampdu_enable". ( basically
> it was empty and useless)

Right, I misread the deletions from patch.


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


[PATCH] staging: mt7621-pci-phy: add 'mt7621_phy_rmw' to simplify code

2020-03-15 Thread Sergio Paracuellos
In order to simplify driver code and decrease a bit LOC add new
function 'mt7621_phy_rmw' where clear and set bits are passed as
arguments.

Signed-off-by: Sergio Paracuellos 
---
 .../staging/mt7621-pci-phy/pci-mt7621-phy.c   | 158 --
 1 file changed, 71 insertions(+), 87 deletions(-)

diff --git a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c 
b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
index d2a07f145143..648f0c8df003 100644
--- a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
+++ b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
@@ -120,17 +120,25 @@ static inline void phy_write(struct mt7621_pci_phy *phy, 
u32 val, u32 reg)
regmap_write(phy->regmap, reg, val);
 }
 
+static inline void mt7621_phy_rmw(struct mt7621_pci_phy *phy,
+ u32 reg, u32 clr, u32 set)
+{
+   u32 val = phy_read(phy, reg);
+
+   val &= ~clr;
+   val |= set;
+   phy_write(phy, val, reg);
+}
+
 static void mt7621_bypass_pipe_rst(struct mt7621_pci_phy *phy,
   struct mt7621_pci_phy_instance *instance)
 {
u32 offset = (instance->index != 1) ?
RG_PE1_PIPE_REG : RG_PE1_PIPE_REG + RG_P0_TO_P1_WIDTH;
-   u32 reg;
 
-   reg = phy_read(phy, offset);
-   reg &= ~(RG_PE1_PIPE_RST | RG_PE1_PIPE_CMD_FRC);
-   reg |= (RG_PE1_PIPE_RST | RG_PE1_PIPE_CMD_FRC);
-   phy_write(phy, reg, offset);
+   mt7621_phy_rmw(phy, offset,
+  RG_PE1_PIPE_RST | RG_PE1_PIPE_CMD_FRC,
+  RG_PE1_PIPE_RST | RG_PE1_PIPE_CMD_FRC);
 }
 
 static void mt7621_set_phy_for_ssc(struct mt7621_pci_phy *phy,
@@ -139,97 +147,77 @@ static void mt7621_set_phy_for_ssc(struct mt7621_pci_phy 
*phy,
struct device *dev = phy->dev;
u32 reg = rt_sysc_r32(SYSC_REG_SYSTEM_CONFIG0);
u32 offset;
-   u32 val;
 
reg = (reg >> 6) & 0x7;
/* Set PCIe Port PHY to disable SSC */
/* Debug Xtal Type */
-   val = phy_read(phy, RG_PE1_FRC_H_XTAL_REG);
-   val &= ~(RG_PE1_FRC_H_XTAL_TYPE | RG_PE1_H_XTAL_TYPE);
-   val |= RG_PE1_FRC_H_XTAL_TYPE;
-   val |= RG_PE1_H_XTAL_TYPE_VAL(0x00);
-   phy_write(phy, val, RG_PE1_FRC_H_XTAL_REG);
+   mt7621_phy_rmw(phy, RG_PE1_FRC_H_XTAL_REG,
+  RG_PE1_FRC_H_XTAL_TYPE | RG_PE1_H_XTAL_TYPE,
+  RG_PE1_FRC_H_XTAL_TYPE | RG_PE1_H_XTAL_TYPE_VAL(0x00));
 
/* disable port */
offset = (instance->index != 1) ?
RG_PE1_FRC_PHY_REG : RG_PE1_FRC_PHY_REG + RG_P0_TO_P1_WIDTH;
-   val = phy_read(phy, offset);
-   val &= ~(RG_PE1_FRC_PHY_EN | RG_PE1_PHY_EN);
-   val |= RG_PE1_FRC_PHY_EN;
-   phy_write(phy, val, offset);
-
-   /* Set Pre-divider ratio (for host mode) */
-   val = phy_read(phy, RG_PE1_H_PLL_REG);
-   val &= ~(RG_PE1_H_PLL_PREDIV);
+   mt7621_phy_rmw(phy, offset,
+  RG_PE1_FRC_PHY_EN | RG_PE1_PHY_EN, RG_PE1_FRC_PHY_EN);
 
if (reg <= 5 && reg >= 3) { /* 40MHz Xtal */
-   val |= RG_PE1_H_PLL_PREDIV_VAL(0x01);
-   phy_write(phy, val, RG_PE1_H_PLL_REG);
+   /* Set Pre-divider ratio (for host mode) */
+   mt7621_phy_rmw(phy, RG_PE1_H_PLL_REG,
+  RG_PE1_H_PLL_PREDIV,
+  RG_PE1_H_PLL_PREDIV_VAL(0x01));
dev_info(dev, "Xtal is 40MHz\n");
-   } else { /* 25MHz | 20MHz Xtal */
-   val |= RG_PE1_H_PLL_PREDIV_VAL(0x00);
-   phy_write(phy, val, RG_PE1_H_PLL_REG);
-   if (reg >= 6) {
-   dev_info(dev, "Xtal is 25MHz\n");
-
-   /* Select feedback clock */
-   val = phy_read(phy, RG_PE1_H_PLL_FBKSEL_REG);
-   val &= ~(RG_PE1_H_PLL_FBKSEL);
-   val |= RG_PE1_H_PLL_FBKSEL_VAL(0x01);
-   phy_write(phy, val, RG_PE1_H_PLL_FBKSEL_REG);
-
-   /* DDS NCPO PCW (for host mode) */
-   val = phy_read(phy, RG_PE1_H_LCDDS_SSC_PRD_REG);
-   val &= ~(RG_PE1_H_LCDDS_SSC_PRD);
-   val |= RG_PE1_H_LCDDS_SSC_PRD_VAL(0x1800);
-   phy_write(phy, val, RG_PE1_H_LCDDS_SSC_PRD_REG);
-
-   /* DDS SSC dither period control */
-   val = phy_read(phy, RG_PE1_H_LCDDS_SSC_PRD_REG);
-   val &= ~(RG_PE1_H_LCDDS_SSC_PRD);
-   val |= RG_PE1_H_LCDDS_SSC_PRD_VAL(0x18d);
-   phy_write(phy, val, RG_PE1_H_LCDDS_SSC_PRD_REG);
-
-   /* DDS SSC dither amplitude control */
-   val = phy_read(phy, RG_PE1_H_LCDDS_SSC_DELTA_REG);
-   val &= ~(RG_PE1_H_LCDDS_SSC_DELTA |
-RG_PE1_H_LCDDS_SSC_DELTA1);
-   val |= RG_PE1_H_LCDDS_SSC_DELTA_VAL(0x4a);
-  

Re: [Outreachy kernel] [PATCH v2] Staging: rtl8723bs: rtw_mlme: Remove unnecessary conditions

2020-03-15 Thread Stefano Brivio
On Fri, 13 Mar 2020 15:59:12 +0530
Shreeya Patel  wrote:

> Remove unnecessary if and else conditions since both are leading to the
> initialization of "phtpriv->ampdu_enable" with the same value.
> Also, remove the unnecessary else-if condition since it does nothing.
> 
> Signed-off-by: Shreeya Patel 
> ---
> 
> Changes in v2
>   - Remove unnecessary comments
>   - Remove unnecessary else-if condition which does nothing.
> 
>  drivers/staging/rtl8723bs/core/rtw_mlme.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c 
> b/drivers/staging/rtl8723bs/core/rtw_mlme.c
> index 71fcb466019a..d7a58af76ea0 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
> @@ -2772,16 +2772,7 @@ void rtw_update_ht_cap(struct adapter *padapter, u8 
> *pie, uint ie_len, u8 channe
>  
>   /* maybe needs check if ap supports rx ampdu. */
>   if (!(phtpriv->ampdu_enable) && pregistrypriv->ampdu_enable == 1) {
> - if (pregistrypriv->wifi_spec == 1) {
> - /* remove this part because testbed AP should disable 
> RX AMPDU */
> - /* phtpriv->ampdu_enable = false; */
> - phtpriv->ampdu_enable = true;
> - } else {
> - phtpriv->ampdu_enable = true;
> - }
> - } else if (pregistrypriv->ampdu_enable == 2) {
> - /* remove this part because testbed AP should disable RX AMPDU 
> */
> - /* phtpriv->ampdu_enable = true; */
> + phtpriv->ampdu_enable = true;

I suspect this is actually a bug, that is:

os_dep/os_intfs.c:74:static int rtw_ampdu_enable = 1;/* for enable tx_ampdu ,0: 
disable, 0x1:enable (but wifi_spec should be 0), 0x2: force enable (don't care 
wifi_spec) */

and that seems to actually map to the ampdu_enable field in
pregistrypriv.

However, I wouldn't change this without testing it on the actual
hardware, change looks good to me and doesn't affect functionality,

Reviewed-by: Stefano Brivio 

-- 
Stefano

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


Re: [Outreachy kernel] [PATCH] Staging: wilc1000: cfg80211: Use kmemdup instead of kmalloc and memcpy

2020-03-15 Thread Stefano Brivio
On Fri, 13 Mar 2020 16:54:51 +0530
Shreeya Patel  wrote:

> Replace calls to kmalloc followed by a memcpy with a direct call to
> kmemdup.
> 
> The Coccinelle semantic patch used to make this change is as follows:
> @@
> expression from,to,size,flag;
> statement S;
> @@
> 
> -  to = \(kmalloc\|kzalloc\)(size,flag);
> +  to = kmemdup(from,size,flag);
>if (to==NULL || ...) S
> -  memcpy(to, from, size);
> 
> Signed-off-by: Shreeya Patel 

Reviewed-by: Stefano Brivio 

-- 
Stefano

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