[PATCH] staging: rts5208: Remove function soft_reset_sd_card()
Remove function soft_reset_sd_card, as all it does is call reset_sd.
Modify call sites of the former to call the latter instead.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rts5208/sd.c | 7 +--
drivers/staging/rts5208/sd.h | 1 -
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index c256a2398651..b3f829ed1019 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -3580,11 +3580,6 @@ int sd_rw(struct scsi_cmnd *srb, struct rtsx_chip *chip,
u32 start_sector,
}
#ifdef SUPPORT_CPRM
-int soft_reset_sd_card(struct rtsx_chip *chip)
-{
- return reset_sd(chip);
-}
-
int ext_sd_send_cmd_get_rsp(struct rtsx_chip *chip, u8 cmd_idx, u32 arg,
u8 rsp_type, u8 *rsp, int rsp_len,
bool special_check)
@@ -4639,7 +4634,7 @@ int sd_hw_rst(struct scsi_cmnd *srb, struct rtsx_chip
*chip)
break;
case 1:
- retval = soft_reset_sd_card(chip);
+ retval = reset_sd(chip);
if (retval != STATUS_SUCCESS) {
set_sense_type(chip, lun, SENSE_TYPE_MEDIA_NOT_PRESENT);
sd_card->pre_cmd_err = 1;
diff --git a/drivers/staging/rts5208/sd.h b/drivers/staging/rts5208/sd.h
index e124526360b2..dc9e8cad7a74 100644
--- a/drivers/staging/rts5208/sd.h
+++ b/drivers/staging/rts5208/sd.h
@@ -273,7 +273,6 @@ void sd_cleanup_work(struct rtsx_chip *chip);
int sd_power_off_card3v3(struct rtsx_chip *chip);
int release_sd_card(struct rtsx_chip *chip);
#ifdef SUPPORT_CPRM
-int soft_reset_sd_card(struct rtsx_chip *chip);
int ext_sd_send_cmd_get_rsp(struct rtsx_chip *chip, u8 cmd_idx,
u32 arg, u8 rsp_type, u8 *rsp, int rsp_len,
bool special_check);
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] staging: mt7621-pci: Use gpio perst instead builtin behaviour
Some boards seems to ignore builtin perst configuration and use gpio instead. This approach seems to be more common. Hence, update the driver to properly use gpio perst via gpio descriptor's API. For more information refer to [1]. Even with this set of patches applied, there still seems to have some issues with a non stable pci link through the boot process. This will be resolved in nest patch series when the problem is find. Patches are only compile-tested. It would be good to test them before being applied. [1]: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2019-June/134947.html Sergio Paracuellos (4): staging: mt7621-pci: fix two messages in driver code staging: mt7621-pci: use gpio perst instead of builtin behaviour staging: mt7621-dts: add gpio perst to pcie bindings node staging: mt7621-pci: dt-bindings: add perst-gpio to sample bindings drivers/staging/mt7621-dts/mt7621.dtsi| 2 + .../mt7621-pci/mediatek,mt7621-pci.txt| 2 + drivers/staging/mt7621-pci/pci-mt7621.c | 108 ++ 3 files changed, 63 insertions(+), 49 deletions(-) -- 2.19.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] staging: mt7621-pci: dt-bindings: add perst-gpio to sample bindings
Both driver and device tree have been updated to use GPIO perst. Update bindings documentation also. Signed-off-by: Sergio Paracuellos --- drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt b/drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt index 5a6ee4103cd5..604ec813bd45 100644 --- a/drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt +++ b/drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt @@ -6,6 +6,7 @@ Required properties: - reg: Base addresses and lengths of the PCIe subsys and root ports. - bus-range: Range of bus numbers associated with this controller. - #address-cells: Address representation for root ports (must be 3) +- perst-gpio: PCIe reset signal line. - pinctrl-names : The pin control state names. - pinctrl-0: The "default" pinctrl state. - #size-cells: Size representation for root ports (must be 2) @@ -48,6 +49,7 @@ Example for MT7621: #address-cells = <3>; #size-cells = <2>; + perst-gpio = <&gpio 19 GPIO_ACTIVE_HIGH>; pinctrl-names = "default"; pinctrl-0 = <&pcie_pins>; -- 2.19.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging: mt7621-dts: add gpio perst to pcie bindings node
Driver has been changed to use perts gpio reset instead of
perst builtin behaviour. Update device tree accordly.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/mt7621.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 280ec33c8540..9c90cac82efc 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -1,4 +1,5 @@
#include
+#include
/ {
#address-cells = <1>;
@@ -468,6 +469,7 @@
#address-cells = <3>;
#size-cells = <2>;
+ perst-gpio = <&gpio 19 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pcie_pins>;
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging: mt7621-pci: fix two messages in driver code
There are two messages in driver code which are not correct.
Fix both of them to clarify boot runs.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-pci/pci-mt7621.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 03d919a94552..7ba6ec93ac0f 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -394,7 +394,7 @@ static int mt7621_pcie_init_port(struct mt7621_pcie_port
*port)
mt7621_reset_port(port);
val = read_config(pcie, slot, PCIE_FTS_NUM);
- dev_info(dev, "Port %d N_FTS = %x\n", (unsigned int)val, slot);
+ dev_info(dev, "Port %d N_FTS = %x\n", slot, (unsigned int)val);
err = phy_init(port->phy);
if (err) {
@@ -511,7 +511,7 @@ static void mt7621_pcie_enable_ports(struct mt7621_pcie
*pcie)
port->slot);
continue;
}
- dev_info(dev, "PCIE%d enabled\n", slot);
+ dev_info(dev, "PCIE%d enabled\n", num_slots_enabled);
num_slots_enabled++;
}
}
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] staging: mt7621-pci: use gpio perst instead of builtin behaviour
Some boards seems to ignore the PERST builtin behaviour to properly
perform a pcie line reset. Use gpio PERST behaviour instead which
seems to be more common.
Fixes: bd1a05bd87ad ("staging: mt7621-pci: use PERST_N instead of gpio control")
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-pci/pci-mt7621.c | 106 +---
1 file changed, 58 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 7ba6ec93ac0f..de09bda0b4cd 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -35,6 +36,7 @@
/* sysctl */
#define MT7621_CHIP_REV_ID 0x0c
+#define MT7621_GPIO_MODE 0x60
#define CHIP_REV_MT7621_E2 0x0101
/* MediaTek specific configuration registers */
@@ -81,7 +83,6 @@
#define PCIE_BAR_ENABLEBIT(0)
#define PCIE_PORT_INT_EN(x)BIT(20 + (x))
#define PCIE_PORT_CLK_EN(x)BIT(24 + (x))
-#define PCIE_PORT_PERST(x) BIT(1 + (x))
#define PCIE_PORT_LINKUP BIT(0)
#define PCIE_CLK_GEN_ENBIT(31)
@@ -89,6 +90,9 @@
#define PCIE_CLK_GEN1_DIS GENMASK(30, 24)
#define PCIE_CLK_GEN1_EN (BIT(27) | BIT(25))
#define MEMORY_BASE0x0
+#define PERST_MODE_MASKGENMASK(11, 10)
+#define PERST_MODE_GPIOBIT(10)
+#define PERST_DELAY_US 1000
/**
* struct mt7621_pcie_port - PCIe port information
@@ -119,6 +123,7 @@ struct mt7621_pcie_port {
* @offset: IO / Memory offset
* @dev: Pointer to PCIe device
* @ports: pointer to PCIe port information
+ * @perst: gpio reset
* @rst: pointer to pcie reset
*/
struct mt7621_pcie {
@@ -132,6 +137,7 @@ struct mt7621_pcie {
resource_size_t io;
} offset;
struct list_head ports;
+ struct gpio_desc *perst;
struct reset_control *rst;
};
@@ -198,6 +204,23 @@ static void write_config(struct mt7621_pcie *pcie,
unsigned int dev,
pcie_write(pcie, val, RALINK_PCI_CONFIG_DATA);
}
+static inline void mt7621_perst_gpio_pcie_assert(struct mt7621_pcie *pcie)
+{
+ gpiod_set_value(pcie->perst, 0);
+ mdelay(PERST_DELAY_US);
+}
+
+static inline void mt7621_perst_gpio_pcie_deassert(struct mt7621_pcie *pcie)
+{
+ gpiod_set_value(pcie->perst, 1);
+ mdelay(PERST_DELAY_US);
+}
+
+static inline bool mt7621_pcie_port_is_linkup(struct mt7621_pcie_port *port)
+{
+ return (pcie_port_read(port, RALINK_PCI_STATUS) & PCIE_PORT_LINKUP) !=
0;
+}
+
static inline void mt7621_control_assert(struct mt7621_pcie_port *port)
{
u32 chip_rev_id = rt_sysc_r32(MT7621_CHIP_REV_ID);
@@ -344,6 +367,12 @@ static int mt7621_pcie_parse_dt(struct mt7621_pcie *pcie)
struct resource regs;
int err;
+ pcie->perst = devm_gpiod_get(dev, "perst", GPIOD_OUT_HIGH);
+ if (IS_ERR(pcie->perst)) {
+ dev_err(dev, "failed to get gpio perst\n");
+ return PTR_ERR(pcie->perst);
+ }
+
err = of_address_to_resource(node, 0, ®s);
if (err) {
dev_err(dev, "missing \"reg\" property\n");
@@ -384,7 +413,6 @@ static int mt7621_pcie_init_port(struct mt7621_pcie_port
*port)
struct mt7621_pcie *pcie = port->pcie;
struct device *dev = pcie->dev;
u32 slot = port->slot;
- u32 val = 0;
int err;
/*
@@ -393,47 +421,34 @@ static int mt7621_pcie_init_port(struct mt7621_pcie_port
*port)
*/
mt7621_reset_port(port);
- val = read_config(pcie, slot, PCIE_FTS_NUM);
- dev_info(dev, "Port %d N_FTS = %x\n", slot, (unsigned int)val);
-
err = phy_init(port->phy);
if (err) {
dev_err(dev, "failed to initialize port%d phy\n", slot);
- goto err_phy_init;
+ return err;
}
err = phy_power_on(port->phy);
if (err) {
dev_err(dev, "failed to power on port%d phy\n", slot);
- goto err_phy_on;
- }
-
- if ((pcie_port_read(port, RALINK_PCI_STATUS) & PCIE_PORT_LINKUP) == 0) {
- dev_err(dev, "pcie%d no card, disable it (RST & CLK)\n", slot);
- mt7621_control_assert(port);
- port->enabled = false;
- err = -ENODEV;
- goto err_no_link_up;
+ return err;
}
port->enabled = true;
return 0;
-
-err_no_link_up:
- phy_power_off(port->phy);
-err_phy_on:
- phy_exit(port->phy);
-err_phy_init:
- return err;
}
static void mt7621_pcie_init_ports(struct mt7621_pcie *pcie)
{
struct device *dev = pcie->dev;
struct mt7621_pcie_port *port, *tmp;
+ u32 val = 0;
int err;
+ rt_
[PATCH] staging: rtl8188eu: remove unused code
Remove unused and/or commented code from rtw_wlan_util.c.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index f404370d6631..d1e99885c8f5 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -27,9 +27,6 @@ static const u8 EPIGRAM_OUI[] = {0x00, 0x90, 0x4c};
u8 REALTEK_96B_IE[] = {0x00, 0xe0, 0x4c, 0x02, 0x01, 0x20};
-#define R2T_PHY_DELAY (0)
-
-/* define WAIT_FOR_BCN_TO_M(3000) */
#define WAIT_FOR_BCN_TO_MIN(6000)
#define WAIT_FOR_BCN_TO_MAX(2)
@@ -1041,7 +1038,6 @@ void update_beacon_info(struct adapter *padapter, u8
*pframe, uint pkt_len, stru
switch (pIE->ElementID) {
case _HT_EXTRA_INFO_IE_:/* HT info */
- /* HT_info_handler(padapter, pIE); */
bwmode_update_check(padapter, pIE);
break;
case _ERPINFO_IE_:
@@ -1346,8 +1342,6 @@ void update_IOT_info(struct adapter *padapter)
false);
break;
case HT_IOT_PEER_REALTEK:
- /* rtw_write16(padapter, 0x4cc, 0x); */
- /* rtw_write16(padapter, 0x546, 0x01c0); */
/* disable high power */
Switch_DM_Func(padapter, (u32)(~DYNAMIC_BB_DYNAMIC_TXPWR),
false);
--
2.22.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] rts5208: Fix usleep_range is preferred over udelay
This patch fixes the issue reported by checkpatch:
CHECK: usleep_range is preferred over udelay;
see Documentation/timers/timers-howto.txt
It's save to sleep here instead of using busy waiting,
because we are not in an atomic context.
Signed-off-by: Lukas Schneider
Signed-off-by: Jannik Moritz
Cc:
---
drivers/staging/rts5208/ms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
index 1128eec3bd08..264887d8b3e6 100644
--- a/drivers/staging/rts5208/ms.c
+++ b/drivers/staging/rts5208/ms.c
@@ -3237,7 +3237,7 @@ static int ms_write_multiple_pages(struct rtsx_chip
*chip, u16 old_blk,
return STATUS_FAIL;
}
- udelay(30);
+ usleep_range(30, 40);
rtsx_init_cmd(chip);
@@ -4159,7 +4159,7 @@ int mg_set_ICV(struct scsi_cmnd *srb, struct rtsx_chip
*chip)
#ifdef MG_SET_ICV_SLOW
for (i = 0; i < 2; i++) {
- udelay(50);
+ usleep_range(50, 60);
rtsx_init_cmd(chip);
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] rts5208: Fix usleep_range is preferred over udelay
This patch fixes the issue reported by checkpatch:
CHECK: usleep_range is preferred over udelay;
see Documentation/timers/timers-howto.txt
It's save to sleep here instead of using busy waiting,
because we are not in an atomic context.
Signed-off-by: Lukas Schneider
Signed-off-by: Jannik Moritz
Cc:
---
drivers/staging/rts5208/rtsx_chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rts5208/rtsx_chip.c
b/drivers/staging/rts5208/rtsx_chip.c
index 76c35f3c0208..8cddfe542d56 100644
--- a/drivers/staging/rts5208/rtsx_chip.c
+++ b/drivers/staging/rts5208/rtsx_chip.c
@@ -1803,7 +1803,7 @@ void rtsx_exit_ss(struct rtsx_chip *chip)
if (chip->power_down_in_ss) {
rtsx_force_power_on(chip, SSC_PDCTL | OC_PDCTL);
- udelay(1000);
+ usleep_range(1000, 1010);
}
if (RTSX_TST_DELINK(chip)) {
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] rts5208: Fix usleep range is preferred over udelay
This patch fixes the issue reported by checkpatch: CHECK: usleep_range is preferred over udelay; see Doucmentation/timers/timers-howto.txt It's save to sleep here instead of using busy waiting, because we are not in an atomic context. Signed-off-by: Lukas Schneider Signed-off-by: Jannik Moritz Cc: --- drivers/staging/rts5208/sd.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c index c256a2398651..23a3499096ce 100644 --- a/drivers/staging/rts5208/sd.c +++ b/drivers/staging/rts5208/sd.c @@ -865,7 +865,7 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 sample_point, u8 tune_dir) PHASE_CHANGE); if (retval) return retval; - udelay(50); + usleep_range(50, 60); retval = rtsx_write_register(chip, SD_VP_CTL, 0xFF, PHASE_CHANGE | PHASE_NOT_RESET | @@ -877,14 +877,14 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 sample_point, u8 tune_dir) CHANGE_CLK, CHANGE_CLK); if (retval) return retval; - udelay(50); + usleep_range(50, 60); retval = rtsx_write_register(chip, SD_VP_CTL, 0xFF, PHASE_NOT_RESET | sample_point); if (retval) return retval; } - udelay(100); + usleep_range(100, 110); rtsx_init_cmd(chip); rtsx_add_cmd(chip, WRITE_REG_CMD, SD_DCMPS_CTL, DCMPS_CHANGE, @@ -918,7 +918,7 @@ static int sd_change_phase(struct rtsx_chip *chip, u8 sample_point, u8 tune_dir) return retval; } - udelay(50); + usleep_range(50, 60); } retval = rtsx_write_register(chip, SD_CFG1, SD_ASYNC_FIFO_NOT_RST, 0); @@ -1416,7 +1416,7 @@ static int sd_wait_data_idle(struct rtsx_chip *chip) retval = STATUS_SUCCESS; break; } - udelay(100); + usleep_range(100, 110); } dev_dbg(rtsx_dev(chip), "SD_DATA_STATE: 0x%02x\n", val); -- 2.19.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] rts5208: Fix usleep_range is preferred over udelay
This patch fixes the issue reported by checkpatch:
CHECK: usleep_range is preferred over udelay;
see Documentation/timers/timers-howto.txt
It's save to sleep here instead of using busy waiting,
because we are not in an atomic context.
Signed-off-by: Lukas Schneider
Signed-off-by: Jannik Moritz
Cc
---
drivers/staging/rts5208/rtsx_card.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_card.c
b/drivers/staging/rts5208/rtsx_card.c
index 294f381518fa..960e845133c3 100644
--- a/drivers/staging/rts5208/rtsx_card.c
+++ b/drivers/staging/rts5208/rtsx_card.c
@@ -679,7 +679,7 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
if (retval < 0)
return STATUS_ERROR;
- udelay(10);
+ usleep_range(10, 20);
retval = rtsx_write_register(chip, CLK_CTL, CLK_LOW_FREQ, 0);
if (retval)
return retval;
@@ -797,7 +797,7 @@ int switch_normal_clock(struct rtsx_chip *chip, int clk)
return retval;
if (sd_vpclk_phase_reset) {
- udelay(200);
+ usleep_range(200, 210);
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
if (retval)
@@ -806,7 +806,7 @@ int switch_normal_clock(struct rtsx_chip *chip, int clk)
PHASE_NOT_RESET, PHASE_NOT_RESET);
if (retval)
return retval;
- udelay(200);
+ usleep_range(200, 210);
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, 0);
if (retval)
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: use exact allocation for dma coherent memory
On Mon, Jun 17, 2019 at 10:33:42AM +0200, Christoph Hellwig wrote:
> > drivers/infiniband/hw/cxgb4/qp.c
> >129 static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
> >130 {
> >131 sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev),
> > sq->memsize,
> >132 &(sq->dma_addr), GFP_KERNEL);
> >133 if (!sq->queue)
> >134 return -ENOMEM;
> >135 sq->phys_addr = virt_to_phys(sq->queue);
> >136 dma_unmap_addr_set(sq, mapping, sq->dma_addr);
> >137 return 0;
> >138 }
> >
> > Is this a bug?
>
> Yes. This will blow up badly on many platforms, as sq->queue
> might be vmapped, ioremapped, come from a pool without page backing.
Gah, this addr gets fed into io_remap_pfn_range/remap_pfn_range too..
Potnuri, you should fix this..
You probably need to use dma_mmap_from_dev_coherent() in the mmap ?
Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/7] Hexdump Enhancements
On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote: > From: Alastair D'Silva > > Apologies for the large CC list, it's a heads up for those responsible > for subsystems where a prototype change in generic code causes a change > in those subsystems. > > This series enhances hexdump. Still not a fan of these patches. > These improve the readability of the dumped data in certain situations > (eg. wide terminals are available, many lines of empty bytes exist, etc). Changing hexdump's last argument from bool to int is odd. Perhaps a new function should be added instead of changing the existing hexdump. > The default behaviour of hexdump is unchanged, however, the prototype > for hex_dump_to_buffer() has changed, and print_hex_dump() has been > renamed to print_hex_dump_ext(), with a wrapper replacing it for > compatibility with existing code, which would have been too invasive to > change. > > Hexdump selftests have be run & confirmed passed. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: os_dep: fix indentation on break statement
From: Colin Ian King The break statement is indented one level too deep, fix this. Signed-off-by: Colin Ian King --- drivers/staging/rtl8723bs/os_dep/ioctl_linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c index ea50ec424e50..6ca896128b73 100644 --- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c +++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c @@ -1181,7 +1181,7 @@ static int rtw_wx_set_wap(struct net_device *dev, spin_unlock_bh(&queue->lock); goto exit; } - break; + break; } } -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vt6656: fix indentation on break statement
From: Colin Ian King
The break statement is indented one level too deep, fix this.
Signed-off-by: Colin Ian King
---
drivers/staging/vt6656/card.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6656/card.c b/drivers/staging/vt6656/card.c
index 08fc03d8740e..56cd77fd9ea0 100644
--- a/drivers/staging/vt6656/card.c
+++ b/drivers/staging/vt6656/card.c
@@ -166,7 +166,7 @@ static void vnt_calculate_ofdm_rate(u16 rate, u8 bb_type,
*tx_rate = 0x8b;
*rsv_time = 30;
}
- break;
+ break;
case RATE_9M:
if (bb_type == BB_TYPE_11A) {
*tx_rate = 0x9f;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: HalBtc8723b1Ant: fix Using comparison to true is error prone
This patch fixes below issue reported by checkpatch
CHECK: Using comparison to true is error prone
CHECK: Using comparison to false is error prone
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/HalBtc8723b1Ant.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/HalBtc8723b1Ant.c
b/drivers/staging/rtl8723bs/hal/HalBtc8723b1Ant.c
index eb6e07e..768ad53 100644
--- a/drivers/staging/rtl8723bs/hal/HalBtc8723b1Ant.c
+++ b/drivers/staging/rtl8723bs/hal/HalBtc8723b1Ant.c
@@ -1421,7 +1421,7 @@ static void halbtc8723b1ant_PsTdma(
if (bTurnOn) {
- if (pBtLinkInfo->bSlaveRole == true)
+ if (pBtLinkInfo->bSlaveRole)
psTdmaByte4Val = psTdmaByte4Val | 0x1; /* 0x778 = 0x1
at wifi slot (no blocking BT Low-Pri pkts) */
@@ -2337,9 +2337,9 @@ static void
halbtc8723b1ant_ActionWifiConnected(PBTC_COEXIST pBtCoexist)
);
}
} else if (
- (pCoexSta->bPanExist == false) &&
- (pCoexSta->bA2dpExist == false) &&
- (pCoexSta->bHidExist == false)
+ !pCoexSta->bPanExist &&
+ !pCoexSta->bA2dpExist &&
+ !pCoexSta->bHidExist
)
halbtc8723b1ant_PowerSaveState(pBtCoexist,
BTC_PS_WIFI_NATIVE, 0x0, 0x0);
else
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V5 00/16] use sg helper to operate scatterlist
On 6/18/19 5:29 PM, Martin K. Petersen wrote: I applied this series with a bunch of edits and clarifying comments. It was quite the nightmare to rebase 5.3/scsi-queue to satisfy the ordering requirements, locate the scattered fixes, tweak tags, etc. Hope I got everything right. Hi Martin, Do you perhaps plan to push out these patches at a later time? It seems like that branch has not been updated recently: $ git show --format=fuller mkp-scsi/5.3/scsi-queue | head -n7 commit f3e88ad00f58e9a05986be3028b2ed8654c601c9 Author: Suganath Prabu S AuthorDate: Fri May 31 08:14:43 2019 -0400 Commit: Martin K. Petersen CommitDate: Fri Jun 7 10:17:06 2019 -0400 scsi: mpt3sas: Update driver version to 29.100.00.00 Thanks, Bart. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V5 00/16] use sg helper to operate scatterlist
Bart, > Do you perhaps plan to push out these patches at a later time? It > seems like that branch has not been updated recently: I had a test failure on this end, that's why I didn't push. Appears to be hardware-related, though. Still looking into it. -- Martin K. Petersen Oracle Linux Engineering ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/7] Hexdump Enhancements
On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote: > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote: > > From: Alastair D'Silva > > > > Apologies for the large CC list, it's a heads up for those > > responsible > > for subsystems where a prototype change in generic code causes a > > change > > in those subsystems. > > > > This series enhances hexdump. > > Still not a fan of these patches. I'm afraid there's not too much action I can take on that, I'm happy to address specific issues though. > > > These improve the readability of the dumped data in certain > > situations > > (eg. wide terminals are available, many lines of empty bytes exist, > > etc). > > Changing hexdump's last argument from bool to int is odd. > Think of it as replacing a single boolean with many booleans. > Perhaps a new function should be added instead of changing > the existing hexdump. > There's only a handful of consumers, I don't think there is a value-add in creating more wrappers vs updating the existing callers. -- Alastair D'Silva mob: 0423 762 819 skype: alastair_dsilva Twitter: @EvilDeece blog: http://alastair.d-silva.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/4] staging: mt7621-pci: Use gpio perst instead builtin behaviour
Hi Sergio, On 19/6/19 5:44 pm, Sergio Paracuellos wrote: Some boards seems to ignore builtin perst configuration and use gpio instead. This approach seems to be more common. Hence, update the driver to properly use gpio perst via gpio descriptor's API. For more information refer to [1]. Even with this set of patches applied, there still seems to have some issues with a non stable pci link through the boot process. This will be resolved in nest patch series when the problem is find. Patches are only compile-tested. It would be good to test them before being applied. [1]: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2019-June/134947.html Sergio Paracuellos (4): staging: mt7621-pci: fix two messages in driver code staging: mt7621-pci: use gpio perst instead of builtin behaviour staging: mt7621-dts: add gpio perst to pcie bindings node staging: mt7621-pci: dt-bindings: add perst-gpio to sample bindings drivers/staging/mt7621-dts/mt7621.dtsi| 2 + .../mt7621-pci/mediatek,mt7621-pci.txt| 2 + drivers/staging/mt7621-pci/pci-mt7621.c | 108 ++ 3 files changed, 63 insertions(+), 49 deletions(-) Thanks for putting this together. I tried a quick test, applying this onto a linux-5.2.0-rc5 kernel and saw this in the boot trace: ... rt2880-pinmux pinctrl: pcie is already enabled mt7621-pci 1e14.pcie: Error applying setting, reverse things back ... The system went on to boot successfully, with PCI working. Testing across multiple boots, it sometimes hangs - but we know about that and it is what we are still looking into. Regards Greg ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/7] Hexdump Enhancements
On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote: > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote: > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote: > > > From: Alastair D'Silva > > > > > > Apologies for the large CC list, it's a heads up for those > > > responsible > > > for subsystems where a prototype change in generic code causes a > > > change > > > in those subsystems. > > > > > > This series enhances hexdump. > > > > Still not a fan of these patches. > > I'm afraid there's not too much action I can take on that, I'm happy to > address specific issues though. > > > > These improve the readability of the dumped data in certain > > > situations > > > (eg. wide terminals are available, many lines of empty bytes exist, > > > etc). I think it's generally overkill for the desired uses. > > Changing hexdump's last argument from bool to int is odd. > > > > Think of it as replacing a single boolean with many booleans. I understand it. It's odd. I would rather not have a mixture of true, false, and apparently random collections of bitfields like 0xd or 0b1011 or their equivalent or'd defines. > There's only a handful of consumers, I don't think there is a value-add > in creating more wrappers vs updating the existing callers. Perhaps more reason not to modify the existing api. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/7] Hexdump Enhancements
On Wed, 2019-06-19 at 17:35 -0700, Joe Perches wrote: > On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote: > > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote: > > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote: > > > > From: Alastair D'Silva > > > > > > > > Apologies for the large CC list, it's a heads up for those > > > > responsible > > > > for subsystems where a prototype change in generic code causes > > > > a > > > > change > > > > in those subsystems. > > > > > > > > This series enhances hexdump. > > > > > > Still not a fan of these patches. > > > > I'm afraid there's not too much action I can take on that, I'm > > happy to > > address specific issues though. > > > > > > These improve the readability of the dumped data in certain > > > > situations > > > > (eg. wide terminals are available, many lines of empty bytes > > > > exist, > > > > etc). > > I think it's generally overkill for the desired uses. I understand where you're coming from, however, these patches make it a lot easier to work with large chucks of binary data. I think it makes more sense to have these patches upstream, even though committed code may not necessarily have all the features enabled, as it means that devs won't have to apply out-of-tree patches during development to make larger dumps manageable. > > > > Changing hexdump's last argument from bool to int is odd. > > > > > > > Think of it as replacing a single boolean with many booleans. > > I understand it. It's odd. > > I would rather not have a mixture of true, false, and apparently > random collections of bitfields like 0xd or 0b1011 or their > equivalent or'd defines. > Where's the mixture? What would you propose instead? -- Alastair D'Silva mob: 0423 762 819 skype: alastair_dsilva Twitter: @EvilDeece blog: http://alastair.d-silva.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/7] Hexdump Enhancements
On Thu, 2019-06-20 at 11:14 +1000, Alastair D'Silva wrote:
> On Wed, 2019-06-19 at 17:35 -0700, Joe Perches wrote:
> > On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
> > > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> > > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> > > > > From: Alastair D'Silva
> > > > >
> > > > > Apologies for the large CC list, it's a heads up for those
> > > > > responsible
> > > > > for subsystems where a prototype change in generic code causes
> > > > > a
> > > > > change
> > > > > in those subsystems.
> > > > >
> > > > > This series enhances hexdump.
> > > >
> > > > Still not a fan of these patches.
> > >
> > > I'm afraid there's not too much action I can take on that, I'm
> > > happy to
> > > address specific issues though.
> > >
> > > > > These improve the readability of the dumped data in certain
> > > > > situations
> > > > > (eg. wide terminals are available, many lines of empty bytes
> > > > > exist,
> > > > > etc).
> >
> > I think it's generally overkill for the desired uses.
>
> I understand where you're coming from, however, these patches make it a
> lot easier to work with large chucks of binary data. I think it makes
> more sense to have these patches upstream, even though committed code
> may not necessarily have all the features enabled, as it means that
> devs won't have to apply out-of-tree patches during development to make
> larger dumps manageable.
>
> > > > Changing hexdump's last argument from bool to int is odd.
> > > >
> > >
> > > Think of it as replacing a single boolean with many booleans.
> >
> > I understand it. It's odd.
> >
> > I would rather not have a mixture of true, false, and apparently
> > random collections of bitfields like 0xd or 0b1011 or their
> > equivalent or'd defines.
> >
>
> Where's the mixture? What would you propose instead?
create a hex_dump_to_buffer_ext with a new argument
and a new static inline for the old hex_dump_to_buffer
without modifying the argument list that calls
hex_dump_to_buffer with whatever added argument content
you need.
Something like:
static inline
int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
int groupsize, char *linebuf, size_t linebuflen,
bool ascii)
{
return hex_dump_to_buffer_ext(buf, len, rowsize, groupsize,
linebuf, linebuflen, ascii, 0);
}
and remove EXPORT_SYMBOL(hex_dump_to_buffer)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: hal: hal_btcoex: Remove variables pHalData and pU1Tmp
Remove pHalData variable as it is set but unused in function.
Remove pU1Tmp and replace this with pu8
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/hal_btcoex.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
index fd0be52..e673319 100644
--- a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
+++ b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
@@ -560,18 +560,14 @@ static u8 halbtcoutsrc_Set(void *pBtcContext, u8 setType,
void *pInBuf)
{
PBTC_COEXIST pBtCoexist;
struct adapter *padapter;
- struct hal_com_data *pHalData;
u8 *pu8;
- u8 *pU1Tmp;
u32 *pU4Tmp;
u8 ret;
pBtCoexist = (PBTC_COEXIST)pBtcContext;
padapter = pBtCoexist->Adapter;
- pHalData = GET_HAL_DATA(padapter);
pu8 = pInBuf;
- pU1Tmp = pInBuf;
pU4Tmp = pInBuf;
ret = true;
@@ -614,11 +610,11 @@ static u8 halbtcoutsrc_Set(void *pBtcContext, u8 setType,
void *pInBuf)
/* set some u8 type variables. */
case BTC_SET_U1_RSSI_ADJ_VAL_FOR_AGC_TABLE_ON:
- pBtCoexist->btInfo.rssiAdjustForAgcTableOn = *pU1Tmp;
+ pBtCoexist->btInfo.rssiAdjustForAgcTableOn = *pu8;
break;
case BTC_SET_U1_AGG_BUF_SIZE:
- pBtCoexist->btInfo.aggBufSize = *pU1Tmp;
+ pBtCoexist->btInfo.aggBufSize = *pu8;
break;
/* the following are some action which will be triggered */
@@ -633,15 +629,15 @@ static u8 halbtcoutsrc_Set(void *pBtcContext, u8 setType,
void *pInBuf)
/* 1Ant === */
/* set some u8 type variables. */
case BTC_SET_U1_RSSI_ADJ_VAL_FOR_1ANT_COEX_TYPE:
- pBtCoexist->btInfo.rssiAdjustFor1AntCoexType = *pU1Tmp;
+ pBtCoexist->btInfo.rssiAdjustFor1AntCoexType = *pu8;
break;
case BTC_SET_U1_LPS_VAL:
- pBtCoexist->btInfo.lpsVal = *pU1Tmp;
+ pBtCoexist->btInfo.lpsVal = *pu8;
break;
case BTC_SET_U1_RPWM_VAL:
- pBtCoexist->btInfo.rpwmVal = *pU1Tmp;
+ pBtCoexist->btInfo.rpwmVal = *pu8;
break;
/* the following are some action which will be triggered */
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/4] staging: mt7621-pci: Use gpio perst instead builtin behaviour
Hi Greg, On Thu, Jun 20, 2019 at 2:40 AM Greg Ungerer wrote: > > Hi Sergio, > > On 19/6/19 5:44 pm, Sergio Paracuellos wrote: > > Some boards seems to ignore builtin perst configuration and use gpio > > instead. This approach seems to be more common. Hence, update the driver > > to properly use gpio perst via gpio descriptor's API. > > > > For more information refer to [1]. > > > > Even with this set of patches applied, there still seems to have some issues > > with a non stable pci link through the boot process. This will be resolved > > in nest patch series when the problem is find. > > > > Patches are only compile-tested. It would be good to test them before being > > applied. > > > > [1]: > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2019-June/134947.html > > > > Sergio Paracuellos (4): > >staging: mt7621-pci: fix two messages in driver code > >staging: mt7621-pci: use gpio perst instead of builtin behaviour > >staging: mt7621-dts: add gpio perst to pcie bindings node > >staging: mt7621-pci: dt-bindings: add perst-gpio to sample bindings > > > > drivers/staging/mt7621-dts/mt7621.dtsi| 2 + > > .../mt7621-pci/mediatek,mt7621-pci.txt| 2 + > > drivers/staging/mt7621-pci/pci-mt7621.c | 108 ++ > > 3 files changed, 63 insertions(+), 49 deletions(-) > > Thanks for putting this together. > > I tried a quick test, applying this onto a linux-5.2.0-rc5 kernel and > saw this in the boot trace: > >... >rt2880-pinmux pinctrl: pcie is already enabled >mt7621-pci 1e14.pcie: Error applying setting, reverse things back >... > > The system went on to boot successfully, with PCI working. > > Testing across multiple boots, it sometimes hangs - but we know about that > and it is what we are still looking into. Ok, thanks for testing this. Let's apply this patch series first. GregKH, can we also apply this for linux-stable? kernel 5.1. Should I sent anything else for that? > > Regards > Greg Best regards, Sergio Paracuellos > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
