[PATCH v3 0/5] staging: mt7621-pci: re-do reset boot process
Some time ago Greg Ungerer reported some random hangs using the staging mt7621-pci driver: See: * http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2019-June/134947.html Try to fix that is the main motivation of this patch series. Also in openwrt there is a driver for mt7621-pci which seems was rewritten from scratch (for kernel 4.14) by Ryder Lee and Weijie Gao from mediatek. There the approach for reset assert-deassert process is to set as 'gpio' the function for all the 'pcie' group for the pinctrl driver and use those gpio's as a reset for the end points. The driver I am talking about is still using legacy pci and legacy gpio kernel interfaces. IMHO, the correct thing to do is make this staging driver properly clean and functional and put it in its correct place in the mainline. See: * https://gist.github.com/dengqf6/7a9e9b4032d99f1a91dd9256c8a65c36 Because of all of this this patch series tries to avoid random hangs of boot trying to use the 'reset-gpios' approach. Changes are being tested by openwrt people and seems to work. Hope this helps. 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 (5): staging: mt7621-pci: use gpios for properly reset staging: mt7621-pci: change value for 'PERST_DELAY_US' 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 drivers/staging/mt7621-dts/mt7621.dtsi| 11 +- .../mt7621-pci/mediatek,mt7621-pci.txt| 7 +- drivers/staging/mt7621-pci/pci-mt7621.c | 107 +++--- 3 files changed, 80 insertions(+), 45 deletions(-) -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/5] staging: mt7621-pci: use gpios for properly reset
Original driver code was using three gpio's for reset
asserts and deasserts the pcis. Instead of using that
a general reset control with a perst gpio was introduced
and it seems it is partially working but sometimes there
are some unexpected hangs on boot. This commit make use of
the three original gpios using 'reset-gpios' property of
the device tree and removes the reset line and perst gpio.
According to the mediatek application note v0.1 there are
three gpios used for pcie ports reset control: gpio#19,
gpio#8 and gpio#7 for slots 0, 1 and 2 respectively.
This schema can be used separately for mt7621A but in some
boards due to pin share issue, if the PCM and I2S function
are enable at the same time, there are no enough GPIO to
control per-port PCIe reset. In those cases gpio#19 is enought
for reset the three ports together. Because of this we just
try to get the three gpios but if some of them fail we are not
failing in boot process, just prints a kernel notice and take
after into account if the descriptor is or not valid in order
to use it. All of them are set as GPIO output low configuration.
The gpio descriptor's API takes device tree property into account
and invert value if the pin is configured as active low.
So we also have to properly request pins from device tree
and set values correct in assert and deassert functions.
After this changes the order to make all assert and
deassert in the 'probe' process makes more sense:
* Parse device tree.
* make assert of the RC's and EP's before doing anything else.
* make deassert of the RC's before initializing the phy.
* Init the phy.
* make deassert of the EP's before initialize pci ports.
* Normal PCI initialization.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-pci/pci-mt7621.c | 82 +++--
1 file changed, 49 insertions(+), 33 deletions(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 770dabd3a70d..34f6bcd53fbf 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -95,6 +95,7 @@
* @pcie: pointer to PCIe host info
* @phy: pointer to PHY control block
* @pcie_rst: pointer to port reset control
+ * @gpio_rst: gpio reset
* @slot: port slot
* @enabled: indicates if port is enabled
*/
@@ -104,6 +105,7 @@ struct mt7621_pcie_port {
struct mt7621_pcie *pcie;
struct phy *phy;
struct reset_control *pcie_rst;
+ struct gpio_desc *gpio_rst;
u32 slot;
bool enabled;
};
@@ -117,8 +119,6 @@ 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
* @resets_inverted: depends on chip revision
* reset lines are inverted.
*/
@@ -133,8 +133,6 @@ struct mt7621_pcie {
resource_size_t io;
} offset;
struct list_head ports;
- struct gpio_desc *perst;
- struct reset_control *rst;
bool resets_inverted;
};
@@ -210,16 +208,16 @@ 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)
+static inline void mt7621_rst_gpio_pcie_assert(struct mt7621_pcie_port *port)
{
- gpiod_set_value(pcie->perst, 0);
- mdelay(PERST_DELAY_US);
+ if (port->gpio_rst)
+ gpiod_set_value(port->gpio_rst, 1);
}
-static inline void mt7621_perst_gpio_pcie_deassert(struct mt7621_pcie *pcie)
+static inline void mt7621_rst_gpio_pcie_deassert(struct mt7621_pcie_port *port)
{
- gpiod_set_value(pcie->perst, 1);
- mdelay(PERST_DELAY_US);
+ if (port->gpio_rst)
+ gpiod_set_value(port->gpio_rst, 0);
}
static inline bool mt7621_pcie_port_is_linkup(struct mt7621_pcie_port *port)
@@ -367,6 +365,11 @@ static int mt7621_pcie_parse_port(struct mt7621_pcie *pcie,
if (IS_ERR(port->phy))
return PTR_ERR(port->phy);
+ port->gpio_rst = devm_gpiod_get_index(dev, "reset", slot,
+ GPIOD_OUT_LOW);
+ if (IS_ERR(port->gpio_rst))
+ dev_notice(dev, "Failed to get GPIO for PCIe%d\n", slot);
+
port->slot = slot;
port->pcie = pcie;
@@ -383,12 +386,6 @@ 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");
@@ -399,12 +396,6 @@ static int mt7621_pcie_parse_dt(struct mt7621_pcie *pcie)
if (IS_ERR(pcie->base))
ret
[PATCH v3 2/5] staging: mt7621-pci: change value for 'PERST_DELAY_US'
Value of 'PERST_DELAY_US' is too high and it is ok just to set up to 100 us. Signed-off-by: Sergio Paracuellos --- drivers/staging/mt7621-pci/pci-mt7621.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c b/drivers/staging/mt7621-pci/pci-mt7621.c index 34f6bcd53fbf..5306a0dd769f 100644 --- a/drivers/staging/mt7621-pci/pci-mt7621.c +++ b/drivers/staging/mt7621-pci/pci-mt7621.c @@ -86,7 +86,7 @@ #define MEMORY_BASE0x0 #define PERST_MODE_MASKGENMASK(11, 10) #define PERST_MODE_GPIOBIT(10) -#define PERST_DELAY_US 1000 +#define PERST_DELAY_US 100 /** * struct mt7621_pcie_port - PCIe port information -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 4/5] staging: mt7621-pci: bindings: update doc accordly to last changes
Properly update bindings documentation with added 'reset-gpios'
property. Delete also 'perst-gpio' which is not being used anymore.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt
b/drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt
index 604ec813bd45..327a68267309 100644
--- a/drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt
+++ b/drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt
@@ -6,7 +6,6 @@ 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)
@@ -24,6 +23,7 @@ Required properties:
See ../clocks/clock-bindings.txt for details.
- clock-names: Must be "pcie0", "pcie1", "pcieN"... based on the number of
root ports.
+- reset-gpios: GPIO specs for the reset pins.
In addition, the device tree node must have sub-nodes describing each PCIe port
interface, having the following mandatory properties:
@@ -49,7 +49,6 @@ Example for MT7621:
#address-cells = <3>;
#size-cells = <2>;
- perst-gpio = <&gpio 19 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pcie_pins>;
@@ -74,6 +73,10 @@ Example for MT7621:
clocks = <&clkctrl 24 &clkctrl 25 &clkctrl 26>;
clock-names = "pcie0", "pcie1", "pcie2";
+ reset-gpios = <&gpio 19 GPIO_ACTIVE_LOW>,
+ <&gpio 8 GPIO_ACTIVE_LOW>,
+ <&gpio 7 GPIO_ACTIVE_LOW>;
+
pcie@0,0 {
reg = <0x 0 0 0 0>;
#address-cells = <3>;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 3/5] staging: mt7621-dts: make use of 'reset-gpios' property for pci
Properly set pins for group pcie as 'gpio' function and declare
gpio's in the pci node to make reset stuff properly functional.
Delete no more needed general reset and previous pers gpio which
is now being used in 'reset-gpios' property.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/mt7621.dtsi | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index d89d68ffa7bc..488474153535 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -286,7 +286,7 @@ mdio0 {
pcie_pins: pcie0 {
pcie0 {
groups = "pcie";
- function = "pcie rst";
+ function = "gpio";
};
};
@@ -512,7 +512,6 @@ pcie: pcie@1e14 {
#address-cells = <3>;
#size-cells = <2>;
- perst-gpio = <&gpio 19 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pcie_pins>;
@@ -532,13 +531,17 @@ pcie: pcie@1e14 {
status = "disabled";
- resets = <&rstctrl 23 &rstctrl 24 &rstctrl 25 &rstctrl 26>;
- reset-names = "pcie", "pcie0", "pcie1", "pcie2";
+ resets = <&rstctrl 24 &rstctrl 25 &rstctrl 26>;
+ reset-names = "pcie0", "pcie1", "pcie2";
clocks = <&clkctrl 24 &clkctrl 25 &clkctrl 26>;
clock-names = "pcie0", "pcie1", "pcie2";
phys = <&pcie0_phy 0>, <&pcie0_phy 1>, <&pcie1_phy 0>;
phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
+ reset-gpios = <&gpio 19 GPIO_ACTIVE_LOW>,
+ <&gpio 8 GPIO_ACTIVE_LOW>,
+ <&gpio 7 GPIO_ACTIVE_LOW>;
+
pcie@0,0 {
reg = <0x 0 0 0 0>;
#address-cells = <3>;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 5/5] staging: mt7621-pci: release gpios after pci initialization
R3G's LEDs fail to initialize because one of them uses GPIO8
Hence, release the GPIO resources after PCIe initialization
and properly release also in driver error path.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-pci/pci-mt7621.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 5306a0dd769f..6ea284942b6f 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -482,6 +482,15 @@ static void mt7621_pcie_reset_ep_deassert(struct
mt7621_pcie *pcie)
mdelay(PERST_DELAY_US);
}
+static void mt7621_pcie_release_gpios(struct mt7621_pcie *pcie)
+{
+ struct mt7621_pcie_port *port;
+
+ list_for_each_entry(port, &pcie->ports, list)
+ if (port->gpio_rst)
+ gpiod_put(port->gpio_rst);
+}
+
static void mt7621_pcie_init_ports(struct mt7621_pcie *pcie)
{
struct device *dev = pcie->dev;
@@ -681,7 +690,8 @@ static int mt7621_pci_probe(struct platform_device *pdev)
err = mt7621_pcie_init_virtual_bridges(pcie);
if (err) {
dev_err(dev, "Nothing is connected in virtual bridges.
Exiting...");
- return 0;
+ err = 0;
+ goto out_release_gpios;
}
mt7621_pcie_enable_ports(pcie);
@@ -689,7 +699,7 @@ static int mt7621_pci_probe(struct platform_device *pdev)
err = mt7621_pci_parse_request_of_pci_ranges(pcie);
if (err) {
dev_err(dev, "Error requesting pci resources from ranges");
- return err;
+ goto out_release_gpios;
}
setup_cm_memory_region(pcie);
@@ -697,16 +707,19 @@ static int mt7621_pci_probe(struct platform_device *pdev)
err = mt7621_pcie_request_resources(pcie, &res);
if (err) {
dev_err(dev, "Error requesting resources\n");
- return err;
+ goto out_release_gpios;
}
err = mt7621_pcie_register_host(bridge, &res);
if (err) {
dev_err(dev, "Error registering host\n");
- return err;
+ goto out_release_gpios;
}
- return 0;
+out_release_gpios:
+ mt7621_pcie_release_gpios(pcie);
+
+ return err;
}
static const struct of_device_id mt7621_pci_ids[] = {
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: Add device id for MERCUSYS MW150US v2
This device was added to the stand-alone driver on github.
Add it to the staging driver as well.
Link: https://github.com/lwfinger/rtl8188eu/commit/2141f244c3e7
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index b5d42f411dd8..845c8817281c 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -38,6 +38,7 @@ static const struct usb_device_id rtw_usb_id_tbl[] = {
{USB_DEVICE(0x2001, 0x331B)}, /* D-Link DWA-121 rev B1 */
{USB_DEVICE(0x2357, 0x010c)}, /* TP-Link TL-WN722N v2 */
{USB_DEVICE(0x2357, 0x0111)}, /* TP-Link TL-WN727N v5.21 */
+ {USB_DEVICE(0x2C4E, 0x0102)}, /* MERCUSYS MW150US v2 */
{USB_DEVICE(0x0df6, 0x0076)}, /* Sitecom N150 v2 */
{USB_DEVICE(USB_VENDER_ID_REALTEK, 0xffef)}, /* Rosewill RNX-N150NUB */
{} /* Terminating entry */
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] Staging: rtl8723bs: rtw_mlme: Remove unnecessary conditions
Hi Lakshmi, On Wed, 11 Mar 2020 19:42:06 -0700 Lakshmi Ramasubramanian wrote: > On 3/11/2020 6:58 AM, Shreeya Patel wrote: > > > Remove unnecessary if and else conditions since both are leading to the > > initialization of "phtpriv->ampdu_enable" with the same value. > > > > Signed-off-by: Shreeya Patel > > Stating this based on the patch descriptions I have seen. > Others, please advise\correct me if I am wrong. > > Patch description should state the problem first[1] and then describe > how that is fixed in the given patch. > > For example: > > In the function rtw_update_ht_cap(), phtpriv->ampdu_enable is set to the > same value in both if and else statements. > > This patch removes this unnecessary if-else statement. That's my general preference as well, but I can't find any point in the "Describe your changes" section of submitting-patches.rst actually defining the order. I wouldn't imply that from the sequence the steps are presented in. In case it's possible to say everything with a single statement as Shreeya did here, though, I guess that becomes rather a linguistic factor, and I personally prefer the concise version here. -- Stefano ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] Staging: rtl8723bs: rtw_mlme: Remove unnecessary conditions
On Thu, 12 Mar 2020, Stefano Brivio wrote: > Hi Lakshmi, > > On Wed, 11 Mar 2020 19:42:06 -0700 > Lakshmi Ramasubramanian wrote: > > > On 3/11/2020 6:58 AM, Shreeya Patel wrote: > > > > > Remove unnecessary if and else conditions since both are leading to the > > > initialization of "phtpriv->ampdu_enable" with the same value. > > > > > > Signed-off-by: Shreeya Patel > > > > Stating this based on the patch descriptions I have seen. > > Others, please advise\correct me if I am wrong. > > > > Patch description should state the problem first[1] and then describe > > how that is fixed in the given patch. > > > > For example: > > > > In the function rtw_update_ht_cap(), phtpriv->ampdu_enable is set to the > > same value in both if and else statements. > > > > This patch removes this unnecessary if-else statement. > > That's my general preference as well, but I can't find any point in the > "Describe your changes" section of submitting-patches.rst actually > defining the order. I wouldn't imply that from the sequence the steps > are presented in. > > In case it's possible to say everything with a single statement as > Shreeya did here, though, I guess that becomes rather a linguistic > factor, and I personally prefer the concise version here. https://kernelnewbies.org/PatchPhilosophy suggests: In patch descriptions and in the subject, it is common and preferable to use present-tense, imperative language. Write as if you are telling git what to do with your patch. It provides the following as an example of a good description: somedriver: fix sleep while atomic in send_a_packet() The send_a_packet() function is called in atomic context but takes a mutex, causing a sleeping while atomic warning. Change the skb_lock to be a spin lock instead of a mutex to fix. So this illustrates the order that Lakshmi suggests, even though I don't think that order is ever suggested explicitly. On the other hand it avoids "This patch...", which would add some clutter, in my opinion. julia > > -- > Stefano > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/20200312113416.23d3db5c%40elisabeth. > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] staging: greybus: loopback_test: fix poll-mask build breakage
A scripted conversion from userland POLL* to kernel EPOLL* constants
mistakingly replaced the poll flags in the loopback_test tool, which
therefore no longer builds.
Fixes: a9a08845e9ac ("vfs: do bulk POLL* -> EPOLL* replacement")
Cc: stable # 4.16
Signed-off-by: Johan Hovold
---
drivers/staging/greybus/tools/loopback_test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/tools/loopback_test.c
b/drivers/staging/greybus/tools/loopback_test.c
index ba6f905f26fa..41e1820d9ac9 100644
--- a/drivers/staging/greybus/tools/loopback_test.c
+++ b/drivers/staging/greybus/tools/loopback_test.c
@@ -655,7 +655,7 @@ static int open_poll_files(struct loopback_test *t)
goto err;
}
read(t->fds[fds_idx].fd, &dummy, 1);
- t->fds[fds_idx].events = EPOLLERR|EPOLLPRI;
+ t->fds[fds_idx].events = POLLERR | POLLPRI;
t->fds[fds_idx].revents = 0;
fds_idx++;
}
@@ -748,7 +748,7 @@ static int wait_for_complete(struct loopback_test *t)
}
for (i = 0; i < t->poll_count; i++) {
- if (t->fds[i].revents & EPOLLPRI) {
+ if (t->fds[i].revents & POLLPRI) {
/* Dummy read to clear the event */
read(t->fds[i].fd, &dummy, 1);
number_of_events++;
--
2.24.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/3] staging: greybus: loopback_test: fix build breakage
The loopback_test tool hasn't received much love lately. In fact, it has failed to build for the past two years after a scripted EPOLL* conversion. Newer GCC also started warning for potential string truncation of generated path names; the last two patches addresses that. Johan Johan Hovold (3): staging: greybus: loopback_test: fix poll-mask build breakage staging: greybus: loopback_test: fix potential path truncation staging: greybus: loopback_test: fix potential path truncations drivers/staging/greybus/tools/loopback_test.c | 21 ++- 1 file changed, 11 insertions(+), 10 deletions(-) -- 2.24.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] staging: greybus: loopback_test: fix potential path truncations
Newer GCC warns about possible truncations of two generated path names as
we're concatenating the configurable sysfs and debugfs path prefixes
with a filename and placing the results in buffers of the same size as
the maximum length of the prefixes.
snprintf(d->name, MAX_STR_LEN, "gb_loopback%u", dev_id);
snprintf(d->sysfs_entry, MAX_SYSFS_PATH, "%s%s/",
t->sysfs_prefix, d->name);
snprintf(d->debugfs_entry, MAX_SYSFS_PATH, "%sraw_latency_%s",
t->debugfs_prefix, d->name);
Fix this by separating the maximum path length from the maximum prefix
length and reducing the latter enough to fit the generated strings.
Note that we also need to reduce the device-name buffer size as GCC
isn't smart enough to figure out that we ever only used MAX_STR_LEN
bytes of it.
Fixes: 6b0658f68786 ("greybus: tools: Add tools directory to greybus repo and
add loopback")
Signed-off-by: Johan Hovold
---
drivers/staging/greybus/tools/loopback_test.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/greybus/tools/loopback_test.c
b/drivers/staging/greybus/tools/loopback_test.c
index d38bb4fbd6b9..69c6dce9be31 100644
--- a/drivers/staging/greybus/tools/loopback_test.c
+++ b/drivers/staging/greybus/tools/loopback_test.c
@@ -19,6 +19,7 @@
#include
#define MAX_NUM_DEVICES 10
+#define MAX_SYSFS_PREFIX 0x80
#define MAX_SYSFS_PATH 0x200
#define CSV_MAX_LINE 0x1000
#define SYSFS_MAX_INT 0x20
@@ -67,7 +68,7 @@ struct loopback_results {
};
struct loopback_device {
- char name[MAX_SYSFS_PATH];
+ char name[MAX_STR_LEN];
char sysfs_entry[MAX_SYSFS_PATH];
char debugfs_entry[MAX_SYSFS_PATH];
struct loopback_results results;
@@ -93,8 +94,8 @@ struct loopback_test {
int stop_all;
int poll_count;
char test_name[MAX_STR_LEN];
- char sysfs_prefix[MAX_SYSFS_PATH];
- char debugfs_prefix[MAX_SYSFS_PATH];
+ char sysfs_prefix[MAX_SYSFS_PREFIX];
+ char debugfs_prefix[MAX_SYSFS_PREFIX];
struct timespec poll_timeout;
struct loopback_device devices[MAX_NUM_DEVICES];
struct loopback_results aggregate_results;
@@ -907,10 +908,10 @@ int main(int argc, char *argv[])
t.iteration_max = atoi(optarg);
break;
case 'S':
- snprintf(t.sysfs_prefix, MAX_SYSFS_PATH, "%s", optarg);
+ snprintf(t.sysfs_prefix, MAX_SYSFS_PREFIX, "%s",
optarg);
break;
case 'D':
- snprintf(t.debugfs_prefix, MAX_SYSFS_PATH, "%s",
optarg);
+ snprintf(t.debugfs_prefix, MAX_SYSFS_PREFIX, "%s",
optarg);
break;
case 'm':
t.mask = atol(optarg);
@@ -961,10 +962,10 @@ int main(int argc, char *argv[])
}
if (!strcmp(t.sysfs_prefix, ""))
- snprintf(t.sysfs_prefix, MAX_SYSFS_PATH, "%s", sysfs_prefix);
+ snprintf(t.sysfs_prefix, MAX_SYSFS_PREFIX, "%s", sysfs_prefix);
if (!strcmp(t.debugfs_prefix, ""))
- snprintf(t.debugfs_prefix, MAX_SYSFS_PATH, "%s",
debugfs_prefix);
+ snprintf(t.debugfs_prefix, MAX_SYSFS_PREFIX, "%s",
debugfs_prefix);
ret = find_loopback_devices(&t);
if (ret)
--
2.24.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] staging: greybus: loopback_test: fix potential path truncation
Newer GCC warns about a possible truncation of a generated sysfs path
name as we're concatenating a directory path with a file name and
placing the result in a buffer that is half the size of the maximum
length of the directory path (which is user controlled).
loopback_test.c: In function 'open_poll_files':
loopback_test.c:651:31: warning: '%s' directive output may be truncated writing
up to 511 bytes into a region of size 255 [-Wformat-truncation=]
651 | snprintf(buf, sizeof(buf), "%s%s", dev->sysfs_entry,
"iteration_count");
| ^~
loopback_test.c:651:3: note: 'snprintf' output between 16 and 527 bytes into a
destination of size 255
651 | snprintf(buf, sizeof(buf), "%s%s", dev->sysfs_entry,
"iteration_count");
|
^~~
Fix this by making sure the buffer is large enough the concatenated
strings.
Fixes: 6b0658f68786 ("greybus: tools: Add tools directory to greybus repo and
add loopback")
Fixes: 9250c0ee2626 ("greybus: Loopback_test: use poll instead of inotify")
Signed-off-by: Johan Hovold
---
drivers/staging/greybus/tools/loopback_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/tools/loopback_test.c
b/drivers/staging/greybus/tools/loopback_test.c
index 41e1820d9ac9..d38bb4fbd6b9 100644
--- a/drivers/staging/greybus/tools/loopback_test.c
+++ b/drivers/staging/greybus/tools/loopback_test.c
@@ -637,7 +637,7 @@ int find_loopback_devices(struct loopback_test *t)
static int open_poll_files(struct loopback_test *t)
{
struct loopback_device *dev;
- char buf[MAX_STR_LEN];
+ char buf[MAX_SYSFS_PATH + MAX_STR_LEN];
char dummy;
int fds_idx = 0;
int i;
--
2.24.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/5] staging: wfx: fix lines ending with a comma instead of a semicolon
On Tue, Mar 10, 2020 at 11:13:53AM +0100, Jerome Pouiller wrote: > From: Jérôme Pouiller > > Obviously introduced by mistake. > I have a Smatch check for when people use a comma instead of semi-colon, but I have never published it because it seems totally harmless. I can't think of a reason why we should use semi-colons instead of commas. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Consulta Marzo 2020
Buenos días Os informamos que se encuentra abierto el plazo de inscripción para la presente Convocatoria de Cursos Bonificables para empleados (Marzo 2020) Todos los cursos son totalmente Bonificables con cargo al Crédito de Formación 2020 que disponen las empresas. Deseáis que os mandemos la información? Saludos. Alex Pons Director departamento formación. FOESCO Formación Estatal Continua. Entidad Organizadora: B171823AP www.foesco.com e-mail: cur...@foesco.net Tel: 910 323 794 (Horario de 9h a 15h y de 17h a 20h de Lunes a Viernes) FOESCO ofrece formación a empresas y trabajadores en activo a través de cursos bonificados por la Fundación Estatal para la Formación en el Empleo (antiguo FORCEM) que gestiona las acciones formativas de FORMACIÓN CONTINUA para trabajadores y se rige por la ley 30/2015 de 9 de Septiembre. Si no desea recibir mas información de FOESCO responda a este correo con la palabra BAJA en el asunto. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/5] staging: wfx: make warning about pending frame less scary
On Tue, Mar 10, 2020 at 11:13:54AM +0100, Jerome Pouiller wrote: > From: Jérôme Pouiller > > Removing station while some traffic is in progress may happen. > You're doing this in every commit where you start the commit message in the subject and then just keep writing. Take a look at your patch in this URL. Try to find the subject. https://marc.info/?l=linux-driver-devel&m=158383526527951&w=2 The subject is far separated from the body of the commit message. I normally read the patch first, then I read the commit message and I don't read the subject at all. Or sometimes I only read the subject. https://www.designershumor.com/2019/09/30/you-will-read-this-first-meme/ So it really helps me if the commit message restates the subject. The truth is that I don't really even like the advice that Josh wrote in the howto about patch descriptions. I normally start by explaining the problem then how I solved it. But I try not to be a pedant, so long as I can understand the problem and the patch that's fine. So how I would write this commit message is: The warning message about releasing a station while Tx is in progress will trigger a stack trace, possibly a reboot depending on the configuration, and a syzbot email. It's not necessarily a big deal that transmission is still in process so let's make the warning less scary. > Signed-off-by: Jérôme Pouiller > --- > drivers/staging/wfx/sta.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c > index 03d0f224ffdb..010e13bcd33e 100644 > --- a/drivers/staging/wfx/sta.c > +++ b/drivers/staging/wfx/sta.c > @@ -605,7 +605,9 @@ int wfx_sta_remove(struct ieee80211_hw *hw, struct > ieee80211_vif *vif, > int i; > > for (i = 0; i < ARRAY_SIZE(sta_priv->buffered); i++) > - WARN(sta_priv->buffered[i], "release station while Tx is in > progress"); > + if (sta_priv->buffered[i]) > + dev_warn(wvif->wdev->dev, "release station while %d > pending frame on queue %d", > + sta_priv->buffered[i], i); Why print a warning message at all if this is a normal situation? Just delete the whole thing. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: Use scnprintf() for avoiding potential buffer overflow
On Wed, Mar 11, 2020 at 10:58:14AM +0100, Johan Hovold wrote: > On Wed, Mar 11, 2020 at 10:19:06AM +0100, Takashi Iwai wrote: > > Since snprintf() returns the would-be-output size instead of the > > actual output size, the succeeding calls may go beyond the given > > buffer limit. Fix it by replacing with scnprintf(). > > > > Signed-off-by: Takashi Iwai > > --- > > drivers/staging/greybus/tools/loopback_test.c | 24 > > Thanks for the fix. > > Would you mind resending with a "staging: greybus: loopback_test:" > prefix since this is not a subsystem wide issue, bur rather a bug in a > specific user-space tool? I'm surprised that user-space even has scnprintf(). regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: Use scnprintf() for avoiding potential buffer overflow
On Thu, Mar 12, 2020 at 05:51:11PM +0300, Dan Carpenter wrote: > On Wed, Mar 11, 2020 at 10:58:14AM +0100, Johan Hovold wrote: > > On Wed, Mar 11, 2020 at 10:19:06AM +0100, Takashi Iwai wrote: > > > Since snprintf() returns the would-be-output size instead of the > > > actual output size, the succeeding calls may go beyond the given > > > buffer limit. Fix it by replacing with scnprintf(). > > > > > > Signed-off-by: Takashi Iwai > > > --- > > > drivers/staging/greybus/tools/loopback_test.c | 24 > > > > > > > Thanks for the fix. > > > > Would you mind resending with a "staging: greybus: loopback_test:" > > prefix since this is not a subsystem wide issue, bur rather a bug in a > > specific user-space tool? > > I'm surprised that user-space even has scnprintf(). Yeah, see the rest of the thread. Johan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] Staging: rtl8723bs: rtw_mlme: Remove unnecessary conditions
On 3/12/2020 3:49 AM, Julia Lawall wrote: Thanks for your input Julia and Stefano. That's my general preference as well, but I can't find any point in the "Describe your changes" section of submitting-patches.rst actually defining the order. I wouldn't imply that from the sequence the steps are presented in. In case it's possible to say everything with a single statement as Shreeya did here, though, I guess that becomes rather a linguistic factor, and I personally prefer the concise version here. https://kernelnewbies.org/PatchPhilosophy suggests: In patch descriptions and in the subject, it is common and preferable to use present-tense, imperative language. Write as if you are telling git what to do with your patch. Use of imperative language is the approach I was thinking as well. thanks, -lakshmi ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-linus] BUILD SUCCESS ac42c12dd752d315a7027dcb50421dbbd1af53bd
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-linus branch HEAD: ac42c12dd752d315a7027dcb50421dbbd1af53bd staging: wfx: fix RCU usage between hif_join() and ieee80211_bss_get_ie() elapsed time: 555m configs tested: 178 configs skipped: 0 The following configs have been built successfully. More configs may be tested in the coming days. arm allmodconfig arm allnoconfig arm allyesconfig arm64allmodconfig arm64 allnoconfig arm64allyesconfig arm at91_dt_defconfig arm efm32_defconfig arm exynos_defconfig armmulti_v5_defconfig armmulti_v7_defconfig armshmobile_defconfig arm sunxi_defconfig arm64 defconfig sparcallyesconfig powerpc defconfig mips allnoconfig nios2 10m50_defconfig riscv rv32_defconfig m68k m5475evb_defconfig s390 allmodconfig i386 allnoconfig i386 allyesconfig i386 alldefconfig i386defconfig ia64 alldefconfig ia64 allmodconfig ia64 allnoconfig ia64 allyesconfig ia64defconfig nios2 3c120_defconfig c6xevmc6678_defconfig xtensa iss_defconfig c6x allyesconfig xtensa common_defconfig openrisc simple_smp_defconfig openriscor1ksim_defconfig alpha defconfig cskydefconfig nds32 allnoconfig nds32 defconfig h8300 edosk2674_defconfig h8300h8300h-sim_defconfig h8300 h8s-sim_defconfig m68k allmodconfig m68k multi_defconfig m68k sun3_defconfig arc defconfig arc allyesconfig powerpc rhel-kconfig microblaze mmu_defconfig microblazenommu_defconfig powerpc allnoconfig powerpc ppc64_defconfig mips 32r2_defconfig mips 64r6el_defconfig mips allmodconfig mips allyesconfig mips fuloong2e_defconfig mips malta_kvm_defconfig pariscallnoconfig i386 randconfig-a003-20200312 i386 randconfig-a001-20200312 x86_64 randconfig-a001-20200312 i386 randconfig-a002-20200312 x86_64 randconfig-a003-20200312 x86_64 randconfig-a002-20200312 x86_64 randconfig-a001-20200311 x86_64 randconfig-a002-20200311 x86_64 randconfig-a003-20200311 i386 randconfig-a001-20200311 i386 randconfig-a002-20200311 i386 randconfig-a003-20200311 alpharandconfig-a001-20200312 m68k randconfig-a001-20200312 mips randconfig-a001-20200312 nds32randconfig-a001-20200312 parisc randconfig-a001-20200312 h8300randconfig-a001-20200312 sparc64 randconfig-a001-20200312 c6x randconfig-a001-20200312 nios2randconfig-a001-20200312 microblaze randconfig-a001-20200312 xtensa randconfig-a001-20200312 openrisc randconfig-a001-20200312 csky randconfig-a001-20200312 sh randconfig-a001-20200312 s390 randconfig-a001-20200312 x86_64 randconfig-b001-20200311 x86_64 randconfig-b002-20200311 x86_64 randconfig-b003-20200311 i386 randconfig-b001-20200311 i386 randconfig-b002-20200311 i386 randconfig-b003-20200311 x86_64 randconfig-c001-20200312 i386 randconfig-c001-20200312 x86_64 randconfig-c002-20200312 i386 randconfig-c002-20200312 i386 randconfig-c003-20200312 x86_64 randconfig-c003-20200312 x86_64
[staging:staging-testing] BUILD SUCCESS c15e7f072288bc6d19bbab065a8b60ca096529bf
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-testing branch HEAD: c15e7f072288bc6d19bbab065a8b60ca096529bf staging: rtl8712: Fixes for simple typos in C comments elapsed time: 485m configs tested: 182 configs skipped: 0 The following configs have been built successfully. More configs may be tested in the coming days. arm allmodconfig arm allnoconfig arm allyesconfig arm64allmodconfig arm64 allnoconfig arm64allyesconfig arm at91_dt_defconfig arm efm32_defconfig arm exynos_defconfig armmulti_v5_defconfig armmulti_v7_defconfig armshmobile_defconfig arm sunxi_defconfig arm64 defconfig sparcallyesconfig riscvallyesconfig s390 debug_defconfig sh rsk7269_defconfig i386defconfig mips fuloong2e_defconfig sparc64 allnoconfig um defconfig powerpc allnoconfig s390 zfcpdump_defconfig i386 allnoconfig i386 allyesconfig i386 alldefconfig ia64 alldefconfig ia64 allmodconfig ia64 allnoconfig ia64 allyesconfig ia64defconfig c6x allyesconfig c6xevmc6678_defconfig nios2 10m50_defconfig nios2 3c120_defconfig openriscor1ksim_defconfig openrisc simple_smp_defconfig xtensa common_defconfig xtensa iss_defconfig nds32 defconfig nds32 allnoconfig cskydefconfig alpha defconfig h8300 h8s-sim_defconfig h8300 edosk2674_defconfig m68k m5475evb_defconfig m68k allmodconfig h8300h8300h-sim_defconfig m68k sun3_defconfig m68k multi_defconfig powerpc defconfig arc defconfig arc allyesconfig powerpc ppc64_defconfig powerpc rhel-kconfig microblaze mmu_defconfig microblazenommu_defconfig mips 32r2_defconfig mips 64r6el_defconfig mips allmodconfig mips allnoconfig mips allyesconfig mips malta_kvm_defconfig pariscallnoconfig parisc allyesconfig pariscgeneric-32bit_defconfig pariscgeneric-64bit_defconfig x86_64 randconfig-a001-20200311 x86_64 randconfig-a002-20200311 x86_64 randconfig-a003-20200311 i386 randconfig-a001-20200311 i386 randconfig-a002-20200311 i386 randconfig-a003-20200311 x86_64 randconfig-a001-20200312 x86_64 randconfig-a002-20200312 x86_64 randconfig-a003-20200312 i386 randconfig-a001-20200312 i386 randconfig-a002-20200312 i386 randconfig-a003-20200312 alpharandconfig-a001-20200312 m68k randconfig-a001-20200312 mips randconfig-a001-20200312 nds32randconfig-a001-20200312 parisc randconfig-a001-20200312 riscvrandconfig-a001-20200312 c6x randconfig-a001-20200312 h8300randconfig-a001-20200312 microblaze randconfig-a001-20200312 nios2randconfig-a001-20200312 sparc64 randconfig-a001-20200312 xtensa randconfig-a001-20200312 openrisc randconfig-a001-20200312 csky randconfig-a001-20200312 sh randconfig-a001-20200312 s390 randconfig-a001-20200312 x86_64 randconfig-b001-20200311 x86_64 randconfig-b002-20200311 x86_64 randconfig-b003-20200311 i386 randconfig-b001-20200311 i386
Re: [Outreachy kernel] [PATCH] Staging: rtl8723bs: sdio_halinit: Remove unnecessary conditions
On Thu, 2020-03-12 at 03:58 +0530, Shreeya Patel wrote:
> Hey Joe,
>
> On March 11, 2020 10:56:29 PM GMT+05:30, Joe Perches wrote:
> > On Wed, 2020-03-11 at 19:08 +0530, Shreeya Patel wrote:
> > > Remove if and else conditions since both are leading to the
> > > initialization of "valueDMATimeout" and "valueDMAPageCount" with
> > > the same value.
> >
> > You might consider removing the
> > /* Timeout value is calculated by 34 / (2^n) */
> > comment entirely as it doesn't make much sense.
> >
>
> You want me to remove the other comments as well?
> Since Julia suggested in another email that the comments are not useful if we
> are removing the condition since they were applied to only one branch ( i.e.
> "if" branch )
It's not an either/or/both situation.
Code like:
if (test) {
[block 1]
} else {
[block 2]
}
where the contents of block 1 and block 2 are identical
exist for many reasons. All of them need situational
analysis to determine what the right thing to do is.
Sometimes it's a defect from a copy/paste where some other
code was intended on one of the blocks and so that one path
has a defect somewhere and actually needs to be changed.
Sometimes the blocks were originally different, but some
code was removed from one of the blocks that lead to the
blocks being identical. Those can be consolidated.
Sometimes test can be removed, sometimes not.
For hardware drivers like this, it's sometimes useful to
look at the latest code from the vendor and sometimes it's
better to ask the vendor what the right thing do is.
It does appear in this case that the branches should be
consolidated and comments in both branches removed.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging: bcm2835-camera: Use designators to init V4L2 controls
The initializer lists for the V4L2 controls are hard to read.
So improve this by using designators.
Signed-off-by: Stefan Wahren
---
.../vc04_services/bcm2835-camera/controls.c| 424 ++---
1 file changed, 277 insertions(+), 147 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c
b/drivers/staging/vc04_services/bcm2835-camera/controls.c
index 50f7c8b..5137fcf 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
@@ -920,210 +920,340 @@ static const struct v4l2_ctrl_ops bm2835_mmal_ctrl_ops
= {
static const struct bm2835_mmal_v4l2_ctrl v4l2_ctrls[V4L2_CTRL_COUNT] = {
{
- V4L2_CID_SATURATION, MMAL_CONTROL_TYPE_STD,
- -100, 100, 0, 1, NULL,
- MMAL_PARAMETER_SATURATION,
- ctrl_set_rational,
+ .id = V4L2_CID_SATURATION,
+ .type = MMAL_CONTROL_TYPE_STD,
+ .min = -100,
+ .max = 100,
+ .def = 0,
+ .step = 1,
+ .imenu = NULL,
+ .mmal_id = MMAL_PARAMETER_SATURATION,
+ .setter = ctrl_set_rational,
},
{
- V4L2_CID_SHARPNESS, MMAL_CONTROL_TYPE_STD,
- -100, 100, 0, 1, NULL,
- MMAL_PARAMETER_SHARPNESS,
- ctrl_set_rational,
+ .id = V4L2_CID_SHARPNESS,
+ .type = MMAL_CONTROL_TYPE_STD,
+ .min = -100,
+ .max = 100,
+ .def = 0,
+ .step = 1,
+ .imenu = NULL,
+ .mmal_id = MMAL_PARAMETER_SHARPNESS,
+ .setter = ctrl_set_rational,
},
{
- V4L2_CID_CONTRAST, MMAL_CONTROL_TYPE_STD,
- -100, 100, 0, 1, NULL,
- MMAL_PARAMETER_CONTRAST,
- ctrl_set_rational,
+ .id = V4L2_CID_CONTRAST,
+ .type = MMAL_CONTROL_TYPE_STD,
+ .min = -100,
+ .max = 100,
+ .def = 0,
+ .step = 1,
+ .imenu = NULL,
+ .mmal_id = MMAL_PARAMETER_CONTRAST,
+ .setter = ctrl_set_rational,
},
{
- V4L2_CID_BRIGHTNESS, MMAL_CONTROL_TYPE_STD,
- 0, 100, 50, 1, NULL,
- MMAL_PARAMETER_BRIGHTNESS,
- ctrl_set_rational,
+ .id = V4L2_CID_BRIGHTNESS,
+ .type = MMAL_CONTROL_TYPE_STD,
+ .min = 0,
+ .max = 100,
+ .def = 50,
+ .step = 1,
+ .imenu = NULL,
+ .mmal_id = MMAL_PARAMETER_BRIGHTNESS,
+ .setter = ctrl_set_rational,
},
{
- V4L2_CID_ISO_SENSITIVITY, MMAL_CONTROL_TYPE_INT_MENU,
- 0, ARRAY_SIZE(iso_qmenu) - 1, 0, 1, iso_qmenu,
- MMAL_PARAMETER_ISO,
- ctrl_set_iso,
+ .id = V4L2_CID_ISO_SENSITIVITY,
+ .type = MMAL_CONTROL_TYPE_INT_MENU,
+ .min = 0,
+ .max = ARRAY_SIZE(iso_qmenu) - 1,
+ .def = 0,
+ .step = 1,
+ .imenu = iso_qmenu,
+ .mmal_id = MMAL_PARAMETER_ISO,
+ .setter = ctrl_set_iso,
},
{
- V4L2_CID_ISO_SENSITIVITY_AUTO, MMAL_CONTROL_TYPE_STD_MENU,
- 0, V4L2_ISO_SENSITIVITY_AUTO, V4L2_ISO_SENSITIVITY_AUTO, 1,
- NULL, MMAL_PARAMETER_ISO,
- ctrl_set_iso,
+ .id = V4L2_CID_ISO_SENSITIVITY_AUTO,
+ .type = MMAL_CONTROL_TYPE_STD_MENU,
+ .min = 0,
+ .max = V4L2_ISO_SENSITIVITY_AUTO,
+ .def = V4L2_ISO_SENSITIVITY_AUTO,
+ .step = 1,
+ .imenu = NULL,
+ .mmal_id = MMAL_PARAMETER_ISO,
+ .setter = ctrl_set_iso,
},
{
- V4L2_CID_IMAGE_STABILIZATION, MMAL_CONTROL_TYPE_STD,
- 0, 1, 0, 1, NULL,
- MMAL_PARAMETER_VIDEO_STABILISATION,
- ctrl_set_value,
+ .id = V4L2_CID_IMAGE_STABILIZATION,
+ .type = MMAL_CONTROL_TYPE_STD,
+ .min = 0,
+ .max = 1,
+ .def = 0,
+ .step = 1,
+ .imenu = NULL,
+ .mmal_id = MMAL_PARAMETER_VIDEO_STABILISATION,
+ .setter = ctrl_set_value,
},
{
- V4L2_CID_EXPOSURE_AUTO, MMAL_CONTROL_TYPE_STD_MENU,
- ~0x03, V4L2_EXPOSURE_APERTURE_PRIORITY, V4L2_EXPOSURE_AUTO, 0,
- NULL, MMAL_PARAMETER_EXPOSURE_MODE,
- ctrl_set_exposure,
+ .id = V4L2_CID_EXPOSURE_AUTO,
+ .type = MMAL_CONTROL_TYPE_STD_MENU,
+ .min = ~0x03,
+ .max = V4L2_EXPOSURE_APERTURE_PRIORITY,
+ .def =
[PATCH 0/2] staging: bcm2835-camera: Improve bm2835_mmal_v4l2_ctrl
These 2 patches improves the V4L2 controls in the bcm2835 camera driver. Stefan Wahren (2): staging: bcm2835-camera: Drop unused ignore_errors flag staging: bcm2835-camera: Use designators to init V4L2 controls .../vc04_services/bcm2835-camera/controls.c| 458 + 1 file changed, 278 insertions(+), 180 deletions(-) -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: bcm2835-camera: Drop unused ignore_errors flag
The struct bm2835_mmal_v4l2_ctrl contains an ignore_errors flag which
was always set to false. So drop the unused flag.
Signed-off-by: Stefan Wahren
---
.../vc04_services/bcm2835-camera/controls.c| 34 +-
1 file changed, 1 insertion(+), 33 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/controls.c
b/drivers/staging/vc04_services/bcm2835-camera/controls.c
index 89786c2..50f7c8b 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/controls.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/controls.c
@@ -85,7 +85,6 @@ struct bm2835_mmal_v4l2_ctrl {
const s64 *imenu; /* integer menu array */
u32 mmal_id; /* mmal parameter id */
bm2835_mmal_v4l2_ctrl_cb *setter;
- bool ignore_errors;
};
struct v4l2_to_mmal_effects_setting {
@@ -912,8 +911,6 @@ static int bm2835_mmal_s_ctrl(struct v4l2_ctrl *ctrl)
if (ret)
pr_warn("ctrl id:%d/MMAL param %08X- returned ret %d\n",
ctrl->id, mmal_ctrl->mmal_id, ret);
- if (mmal_ctrl->ignore_errors)
- ret = 0;
return ret;
}
@@ -927,56 +924,48 @@ static const struct bm2835_mmal_v4l2_ctrl
v4l2_ctrls[V4L2_CTRL_COUNT] = {
-100, 100, 0, 1, NULL,
MMAL_PARAMETER_SATURATION,
ctrl_set_rational,
- false
},
{
V4L2_CID_SHARPNESS, MMAL_CONTROL_TYPE_STD,
-100, 100, 0, 1, NULL,
MMAL_PARAMETER_SHARPNESS,
ctrl_set_rational,
- false
},
{
V4L2_CID_CONTRAST, MMAL_CONTROL_TYPE_STD,
-100, 100, 0, 1, NULL,
MMAL_PARAMETER_CONTRAST,
ctrl_set_rational,
- false
},
{
V4L2_CID_BRIGHTNESS, MMAL_CONTROL_TYPE_STD,
0, 100, 50, 1, NULL,
MMAL_PARAMETER_BRIGHTNESS,
ctrl_set_rational,
- false
},
{
V4L2_CID_ISO_SENSITIVITY, MMAL_CONTROL_TYPE_INT_MENU,
0, ARRAY_SIZE(iso_qmenu) - 1, 0, 1, iso_qmenu,
MMAL_PARAMETER_ISO,
ctrl_set_iso,
- false
},
{
V4L2_CID_ISO_SENSITIVITY_AUTO, MMAL_CONTROL_TYPE_STD_MENU,
0, V4L2_ISO_SENSITIVITY_AUTO, V4L2_ISO_SENSITIVITY_AUTO, 1,
NULL, MMAL_PARAMETER_ISO,
ctrl_set_iso,
- false
},
{
V4L2_CID_IMAGE_STABILIZATION, MMAL_CONTROL_TYPE_STD,
0, 1, 0, 1, NULL,
MMAL_PARAMETER_VIDEO_STABILISATION,
ctrl_set_value,
- false
},
{
V4L2_CID_EXPOSURE_AUTO, MMAL_CONTROL_TYPE_STD_MENU,
~0x03, V4L2_EXPOSURE_APERTURE_PRIORITY, V4L2_EXPOSURE_AUTO, 0,
NULL, MMAL_PARAMETER_EXPOSURE_MODE,
ctrl_set_exposure,
- false
},
{
V4L2_CID_EXPOSURE_ABSOLUTE, MMAL_CONTROL_TYPE_STD,
@@ -984,7 +973,6 @@ static const struct bm2835_mmal_v4l2_ctrl
v4l2_ctrls[V4L2_CTRL_COUNT] = {
1, 1 * 1000 * 10, 100 * 10, 1, NULL,
MMAL_PARAMETER_SHUTTER_SPEED,
ctrl_set_exposure,
- false
},
{
V4L2_CID_AUTO_EXPOSURE_BIAS, MMAL_CONTROL_TYPE_INT_MENU,
@@ -992,7 +980,6 @@ static const struct bm2835_mmal_v4l2_ctrl
v4l2_ctrls[V4L2_CTRL_COUNT] = {
(ARRAY_SIZE(ev_bias_qmenu) + 1) / 2 - 1, 0, ev_bias_qmenu,
MMAL_PARAMETER_EXPOSURE_COMP,
ctrl_set_value_ev,
- false
},
{
V4L2_CID_EXPOSURE_AUTO_PRIORITY, MMAL_CONTROL_TYPE_STD,
@@ -1000,7 +987,6 @@ static const struct bm2835_mmal_v4l2_ctrl
v4l2_ctrls[V4L2_CTRL_COUNT] = {
0, 1, NULL,
0, /* Dummy MMAL ID as it gets mapped into FPS range*/
ctrl_set_exposure,
- false
},
{
V4L2_CID_EXPOSURE_METERING,
@@ -1009,7 +995,6 @@ static const struct bm2835_mmal_v4l2_ctrl
v4l2_ctrls[V4L2_CTRL_COUNT] = {
V4L2_EXPOSURE_METERING_AVERAGE, 0, NULL,
MMAL_PARAMETER_EXP_METERING_MODE,
ctrl_set_metering_mode,
- false
},
{
V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE,
@@ -1018,56 +1003,48 @@ static const struct bm2835_mmal_v4l2_ctrl
v4l2_ctrls[V4L2_CTRL_COUNT] = {
NULL,
MMAL_PARAMETER_AWB_MODE,
ctrl_set_awb_mode,
- false
},
{
V4L2_CID_RED_BALANCE, MMAL_CONTROL_TYPE_STD,
1, 7999, 1000, 1, NULL,
MMAL_PARAMETER_CUSTOM_AWB_GAINS,
ctrl_set_awb_gains,
- false
},
{
V4L2_CID_BL
Hello Friend,, 03/12/2020..
Good day, My name is Reem E. Hashimy, the Emirates Minister of State and Managing Director of the United Arab Emirates (Dubai) World Expo 2020 Committee. I am writing you to manage my funds I received as financial gratification from various foreign companies I assisted to receive participation slot in the incoming Dubai World Expo 2020. The amount is $44,762,906.00 United States dollars.The cumulative deposit were given as an expression of appreciation from the various foreign companies whose applications received approval to participate in the in-coming Dubai Expo 2020. But I could not receive the various gratifications to my personal account in my country because my social status as a married Muslim lady with limitations to certain investment opportunities. For this reason, an agreement was reached with a consulting firm to keep the funds in open beneficiary account with a financial institution where it will be possible to instruct transfer of the funds to a third party account for investment purpose which is the reason I am contacting you to receive and manage the funds as my investment partner. The detail will be discuss on your indication of interest with your information and capacity to manage the fund. However, if you are not ready to take up responsibility in this partnership, please do not reply. While looking forward to good partnership, I am wishing you the best of the year. my Regards Reem Hashimy. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: exfat: fixed coding style warning
Inverted comparison order on r8192U_wx.c:752 to place constant on the
right side.
Signed-off-by: Miguel Faggioni
---
drivers/staging/rtl8192u/r8192U_wx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/r8192U_wx.c
b/drivers/staging/rtl8192u/r8192U_wx.c
index 0118edb0b..40fb4165b 100644
--- a/drivers/staging/rtl8192u/r8192U_wx.c
+++ b/drivers/staging/rtl8192u/r8192U_wx.c
@@ -749,7 +749,7 @@ static int r8192_wx_set_enc_ext(struct net_device *dev,
idx--;
group = ext->ext_flags & IW_ENCODE_EXT_GROUP_KEY;
- if ((!group) || (IW_MODE_ADHOC == ieee->iw_mode) || (alg ==
KEY_TYPE_WEP40)) {
+ if ((!group) || (ieee->iw_mode == IW_MODE_ADHOC) || (alg ==
KEY_TYPE_WEP40)) {
if ((ext->key_len == 13) && (alg == KEY_TYPE_WEP40))
alg = KEY_TYPE_WEP104;
ieee->pairwise_key_type = alg;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: exfat: fixed coding style warning
On Thu, Mar 12, 2020 at 10:01:27PM +, Miguel Faggioni wrote: > Inverted comparison order on r8192U_wx.c:752 to place constant on the > right side. > > Signed-off-by: Miguel Faggioni > --- > drivers/staging/rtl8192u/r8192U_wx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) The subject does not match the file being modified :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: exfat: fixed coding style warning
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Thu, Mar 12, 2020 at 07:50:08PM -0300, Miguel wrote: > oh, sorry > > I had the file being modified on the second line in the commit. THe subject is still wrong :( > Should I amend the commit message and send another email? or amend the commit > message and send it on this same email thread? I can't take this patch as is, so you will have to do something in order to have it in acceptable shape. thanks, greg k-h ___ 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
Hi Sergio, On 12/3/20 7:00 pm, Sergio Paracuellos wrote: Some time ago Greg Ungerer reported some random hangs using the staging mt7621-pci driver: See: * http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2019-June/134947.html Try to fix that is the main motivation of this patch series. Also in openwrt there is a driver for mt7621-pci which seems was rewritten from scratch (for kernel 4.14) by Ryder Lee and Weijie Gao from mediatek. There the approach for reset assert-deassert process is to set as 'gpio' the function for all the 'pcie' group for the pinctrl driver and use those gpio's as a reset for the end points. The driver I am talking about is still using legacy pci and legacy gpio kernel interfaces. IMHO, the correct thing to do is make this staging driver properly clean and functional and put it in its correct place in the mainline. See: * https://gist.github.com/dengqf6/7a9e9b4032d99f1a91dd9256c8a65c36 Because of all of this this patch series tries to avoid random hangs of boot trying to use the 'reset-gpios' approach. Changes are being tested by openwrt people and seems to work. Thanks for the updated patch. 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) 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 (MIPS 1004Kc) Modules linked in: Process kworker/2:1 (pid: 107, threadinfo=(ptrval), task=(ptrval), tls=) Stack : 820e0250 809e2aa0 820d6380 820e0250 820d6980 804fe128 1e16 0001 6000
Re: [PATCH v3 0/5] staging: mt7621-pci: re-do reset boot process
Hi Greg,
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.
> 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 (MIPS 1004Kc)
> Modules linked in:
> Process kworker/2:1 (pid: 107, threadinfo=(ptrval), task=(ptrval),
> tls=)
> Stack : 820e0250 809e2aa0 820d6380 820e0250 820d6980 804fe128 1e16000
Re: [PATCH v3 0/5] staging: mt7621-pci: re-do reset boot process
Hi again Greg,
On Fri, Mar 13, 2020 at 6:45 AM Sergio Paracuellos
wrote:
>
> Hi Greg,
>
> 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.
Maybe just change devm_gpiod_get_index with
devm_gpiod_get_index_optional could be enough to get all of this
working as it is.
- port->gpio_rst = devm_gpiod_get_index(dev, "reset", slot,
- GPIOD_OUT_LOW);
+ port->gpio_rst = devm_gpiod_get_index_optional(dev, "reset", slot,
+ GPIOD_OUT_LOW);
if (IS_ERR(port->gpio_rst))
Regards,
Sergio Paracuellos
>
> > 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
> > $
