[PATCH] staging: fwserial: Fix error handling in fwserial_create
When fw_core_add_address_handler() fails, we need to destroy
the port by tty_port_destroy(). Also we need to unregister
the address handler by fw_core_remove_address_handler() on
failure.
Signed-off-by: Dinghao Liu
---
drivers/staging/fwserial/fwserial.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/fwserial/fwserial.c
b/drivers/staging/fwserial/fwserial.c
index db83d34cd677..c368082aae1a 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -2189,6 +2189,7 @@ static int fwserial_create(struct fw_unit *unit)
err = fw_core_add_address_handler(&port->rx_handler,
&fw_high_memory_region);
if (err) {
+ tty_port_destroy(&port->port);
kfree(port);
goto free_ports;
}
@@ -2271,6 +2272,7 @@ static int fwserial_create(struct fw_unit *unit)
free_ports:
for (--i; i >= 0; --i) {
+ fw_core_remove_address_handler(&serial->ports[i]->rx_handler);
tty_port_destroy(&serial->ports[i]->port);
kfree(serial->ports[i]);
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: octeon-usb: octeon-hcd: fixed indent and ending with brace coding style issue
On Mon, Dec 21, 2020 at 09:15:57AM +, Anjandev Momi wrote: > Fixed coding style issues > > Signed-off-by: Anjandev Momi > --- > drivers/staging/octeon-usb/octeon-hcd.c | 96 - > 1 file changed, 46 insertions(+), 50 deletions(-) > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch did many different things all at once, making it difficult to review. All Linux kernel patches need to only do one thing at a time. If you need to do multiple things (such as clean up all coding style issues in a file/driver), do it in a sequence of patches, each one doing only one thing. This will make it easier to review the patches to ensure that they are correct, and to help alleviate any merge issues that larger patches can cause. - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH -next] greybus/audio_helper: Add missing unlock to avoid mismatched lock
Fix a missing unlock in the error branch.
Signed-off-by: Zheng Yongjun
---
drivers/staging/greybus/audio_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/greybus/audio_helper.c
b/drivers/staging/greybus/audio_helper.c
index 237531ba60f3..293675dbea10 100644
--- a/drivers/staging/greybus/audio_helper.c
+++ b/drivers/staging/greybus/audio_helper.c
@@ -135,6 +135,7 @@ int gbaudio_dapm_free_controls(struct snd_soc_dapm_context
*dapm,
if (!w) {
dev_err(dapm->dev, "%s: widget not found\n",
widget->name);
+ mutex_unlock(&dapm->card->dapm_mutex);
return -EINVAL;
}
widget++;
--
2.22.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: octeon-usb: octeon-hcd: fixed indent and ending with brace coding style issue
Fixed coding style issues
Signed-off-by: Anjandev Momi
---
drivers/staging/octeon-usb/octeon-hcd.c | 96 -
1 file changed, 46 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
b/drivers/staging/octeon-usb/octeon-hcd.c
index e2f8b6b67f75..d8b099f8b83a 100644
--- a/drivers/staging/octeon-usb/octeon-hcd.c
+++ b/drivers/staging/octeon-usb/octeon-hcd.c
@@ -1258,7 +1258,7 @@ static void cvmx_usb_poll_tx_fifo(struct octeon_hcd *usb)
union cvmx_usbcx_hptxsts tx_status;
tx_status.u32 = cvmx_usb_read_csr32(usb,
- CVMX_USBCX_HPTXSTS(usb->index));
+
CVMX_USBCX_HPTXSTS(usb->index));
if (cvmx_usb_fill_tx_hw(usb, &usb->periodic,
tx_status.s.ptxfspcavail))
USB_SET_FIELD32(CVMX_USBCX_GINTMSK(usb->index),
@@ -1272,7 +1272,7 @@ static void cvmx_usb_poll_tx_fifo(struct octeon_hcd *usb)
union cvmx_usbcx_gnptxsts tx_status;
tx_status.u32 = cvmx_usb_read_csr32(usb,
- CVMX_USBCX_GNPTXSTS(usb->index));
+
CVMX_USBCX_GNPTXSTS(usb->index));
if (cvmx_usb_fill_tx_hw(usb, &usb->nonperiodic,
tx_status.s.nptxfspcavail))
USB_SET_FIELD32(CVMX_USBCX_GINTMSK(usb->index),
@@ -1298,13 +1298,13 @@ static void cvmx_usb_fill_tx_fifo(struct octeon_hcd
*usb, int channel)
/* We only need to fill data on outbound channels */
hcchar.u32 = cvmx_usb_read_csr32(usb,
- CVMX_USBCX_HCCHARX(channel, usb->index));
+CVMX_USBCX_HCCHARX(channel,
usb->index));
if (hcchar.s.epdir != CVMX_USB_DIRECTION_OUT)
return;
/* OUT Splits only have data on the start and not the complete */
usbc_hcsplt.u32 = cvmx_usb_read_csr32(usb,
- CVMX_USBCX_HCSPLTX(channel, usb->index));
+ CVMX_USBCX_HCSPLTX(channel,
usb->index));
if (usbc_hcsplt.s.spltena && usbc_hcsplt.s.compsplt)
return;
@@ -1313,7 +1313,7 @@ static void cvmx_usb_fill_tx_fifo(struct octeon_hcd *usb,
int channel)
* words.
*/
usbc_hctsiz.u32 = cvmx_usb_read_csr32(usb,
- CVMX_USBCX_HCTSIZX(channel, usb->index));
+ CVMX_USBCX_HCTSIZX(channel,
usb->index));
if (!usbc_hctsiz.s.xfersize)
return;
@@ -1360,7 +1360,7 @@ static void cvmx_usb_start_channel_control(struct
octeon_hcd *usb,
union cvmx_usbcx_hctsizx usbc_hctsiz;
usbc_hctsiz.u32 = cvmx_usb_read_csr32(usb,
- CVMX_USBCX_HCTSIZX(channel, usb->index));
+ CVMX_USBCX_HCTSIZX(channel,
usb->index));
switch (transaction->stage) {
case CVMX_USB_STAGE_NON_CONTROL:
@@ -1517,7 +1517,7 @@ static void cvmx_usb_start_channel(struct octeon_hcd
*usb, int channel,
/* Clear all channel status bits */
usbc_hcint.u32 = cvmx_usb_read_csr32(usb,
- CVMX_USBCX_HCINTX(channel, usb->index));
+CVMX_USBCX_HCINTX(channel,
usb->index));
cvmx_usb_write_csr32(usb,
CVMX_USBCX_HCINTX(channel, usb->index),
@@ -1552,7 +1552,7 @@ static void cvmx_usb_start_channel(struct octeon_hcd
*usb, int channel,
/* Enable the channel interrupt to propagate */
usbc_haintmsk.u32 = cvmx_usb_read_csr32(usb,
- CVMX_USBCX_HAINTMSK(usb->index));
+
CVMX_USBCX_HAINTMSK(usb->index));
usbc_haintmsk.s.haintmsk |= 1 << channel;
cvmx_usb_write_csr32(usb, CVMX_USBCX_HAINTMSK(usb->index),
usbc_haintmsk.u32);
@@ -1797,15 +1797,13 @@ static void cvmx_usb_start_channel(struct octeon_hcd
*usb, int channel,
*/
if (pipe->transfer_dir == CVMX_USB_DIRECTION_OUT) {
if (pipe->multi_count < 2) /* Need DATA0 */
- USB_SET_FIELD32(
- CVMX_USBCX_HCTSIZX(channel,
- usb->index),
- cvmx_usbcx_hctsizx, pid, 0);
+
USB_SET_FIELD32(CVMX_USBCX_HCTSIZX(channel,
+
usb->index),
+
Re: [PATCH -next] greybus/audio_helper: Add missing unlock to avoid mismatched lock
On Mon, Dec 21, 2020 at 09:02:46PM +0800, Zheng Yongjun wrote:
> Fix a missing unlock in the error branch.
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/staging/greybus/audio_helper.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/greybus/audio_helper.c
> b/drivers/staging/greybus/audio_helper.c
> index 237531ba60f3..293675dbea10 100644
> --- a/drivers/staging/greybus/audio_helper.c
> +++ b/drivers/staging/greybus/audio_helper.c
> @@ -135,6 +135,7 @@ int gbaudio_dapm_free_controls(struct
> snd_soc_dapm_context *dapm,
> if (!w) {
> dev_err(dapm->dev, "%s: widget not found\n",
> widget->name);
> + mutex_unlock(&dapm->card->dapm_mutex);
> return -EINVAL;
> }
> widget++;
This has already been fixed in mainline by your colleague:
e77b259f67ab ("staging: greybus: audio: Fix possible leak free widgets
in gbaudio_dapm_free_controls")
It seems you're all working on reports from your "Hulk Robot" so perhaps
you can try to coordinate that internally.
Johan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 01/48] dt-bindings: memory: tegra20: emc: Replace core regulator with power domain
On Thu, 17 Dec 2020 21:05:51 +0300, Dmitry Osipenko wrote: > Power domain fits much better than a voltage regulator in regards to > a proper hardware description and from a software perspective as well. > Hence replace the core regulator with the power domain. Note that this > doesn't affect any existing DTBs because we haven't started to use the > regulator yet, and thus, it's okay to change it. > > Signed-off-by: Dmitry Osipenko > --- > .../bindings/memory-controllers/nvidia,tegra20-emc.txt| 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 02/48] dt-bindings: memory: tegra30: emc: Replace core regulator with power domain
On Thu, Dec 17, 2020 at 09:05:52PM +0300, Dmitry Osipenko wrote: > Power domain fits much better than a voltage regulator in regards to > a proper hardware description and from a software perspective as well. > Hence replace the core regulator with the power domain. Note that this > doesn't affect any existing DTBs because we haven't started to use the > regulator yet, and thus, it's okay to change it. > > Signed-off-by: Dmitry Osipenko > --- > .../bindings/memory-controllers/nvidia,tegra30-emc.yaml | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml > > b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml > index 0a2e2c0d0fdd..7b4af9169b0b 100644 > --- > a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml > +++ > b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml > @@ -39,9 +39,9 @@ properties: > description: >Phandle of the Memory Controller node. > > - core-supply: > + power-domains: > description: > - Phandle of voltage regulator of the SoC "core" power domain. > + Phandle to the SoC "core" power domain. power-domains needs to define how many (maxItems). > >operating-points-v2: > description: > @@ -241,7 +241,7 @@ examples: > > nvidia,memory-controller = <&mc>; > operating-points-v2 = <&dvfs_opp_table>; > -core-supply = <&vdd_core>; > +power-domains = <&domain>; > > #interconnect-cells = <0>; > > -- > 2.29.2 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 04/48] dt-bindings: host1x: Document OPP and power domain properties
On Thu, 17 Dec 2020 21:05:54 +0300, Dmitry Osipenko wrote: > Document new DVFS OPP table and power domain properties of the Host1x bus > and devices sitting on the bus. > > Signed-off-by: Dmitry Osipenko > --- > .../display/tegra/nvidia,tegra20-host1x.txt | 49 +++ > 1 file changed, 49 insertions(+) > Reviewed-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 05/48] media: dt: bindings: tegra-vde: Document OPP and power domain properties
On Thu, 17 Dec 2020 21:05:55 +0300, Dmitry Osipenko wrote: > Document new DVFS OPP table and power domain properties of the video > decoder engine. > > Signed-off-by: Dmitry Osipenko > --- > .../devicetree/bindings/media/nvidia,tegra-vde.txt | 12 > 1 file changed, 12 insertions(+) > Reviewed-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 06/48] dt-bindings: clock: tegra: Document clocks sub-node
On Thu, Dec 17, 2020 at 09:05:56PM +0300, Dmitry Osipenko wrote:
> Document "clocks" sub-node which describes Tegra SoC clocks that require
> a higher voltage of the core power domain in order to operate properly on
> a higher rates.
Seems like an odd reason to have a bunch of child nodes. It very much
seems like a problem you'd need to solve after you design the binding
which should be fixed within the kernel.
This is also above my threshold for 'convert to schema' first...
>
> Signed-off-by: Dmitry Osipenko
> ---
> .../bindings/clock/nvidia,tegra20-car.txt | 26 +++
> .../bindings/clock/nvidia,tegra30-car.txt | 26 +++
> 2 files changed, 52 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> index 6c5901b503d0..353354477785 100644
> --- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> @@ -19,6 +19,16 @@ Required properties :
>In clock consumers, this cell represents the bit number in the CAR's
>array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
>
> +Optional child sub-node "clocks" should contain nodes matching the clocks
> +on the Tegra SoC. Refer to Tegra TRM for mode details on the clock nodes.
> +
> +Required properties :
> +- compatible : Should be "nvidia,tegra20-clock".
> +- operating-points-v2: See ../bindings/opp/opp.txt for details.
> +- clocks : Should contain clock which corresponds to the node.
> +- power-domains: Phandle to a power domain node as described by generic
> + PM domain bindings.
> +
> Example SoC include file:
>
> / {
> @@ -27,6 +37,22 @@ Example SoC include file:
> reg = <0x60006000 0x1000>;
> #clock-cells = <1>;
> #reset-cells = <1>;
> +
> + clocks {
> + hdmi {
> + compatible = "nvidia,tegra20-clock";
> + operating-points-v2 = <&hdmi_opp_table>;
> + clocks = <&tegra_car TEGRA20_CLK_HDMI>;
> + power-domains = <&domain>;
> + };
> +
> + pll_m {
> + compatible = "nvidia,tegra20-clock";
> + operating-points-v2 = <&pll_m_opp_table>;
> + clocks = <&tegra_car TEGRA20_CLK_PLL_M>;
> + power-domains = <&domain>;
> + };
> + };
> };
>
> usb@c5004000 {
> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
> b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
> index 63618cde12df..bc7bbdaa9d3f 100644
> --- a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
> +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
> @@ -19,6 +19,16 @@ Required properties :
>In clock consumers, this cell represents the bit number in the CAR's
>array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
>
> +Optional child sub-node "clocks" should contain nodes matching the clocks
> +on the Tegra SoC. Refer to Tegra TRM for mode details on the clock nodes.
> +
> +Required properties :
> +- compatible : Should be "nvidia,tegra30-clock".
> +- operating-points-v2: See ../bindings/opp/opp.txt for details.
> +- clocks : Should contain clock which corresponds to the node.
> +- power-domains: Phandle to a power domain node as described by generic
> + PM domain bindings.
> +
> Example SoC include file:
>
> / {
> @@ -31,6 +41,22 @@ Example SoC include file:
>
> usb@c5004000 {
> clocks = <&tegra_car TEGRA30_CLK_USB2>;
> +
> + clocks {
> + hdmi {
> + compatible = "nvidia,tegra30-clock";
> + operating-points-v2 = <&hdmi_opp_table>;
> + clocks = <&tegra_car TEGRA30_CLK_HDMI>;
> + power-domains = <&domain>;
> + };
> +
> + pll_m {
> + compatible = "nvidia,tegra30-clock";
> + operating-points-v2 = <&pll_m_opp_table>;
> + clocks = <&tegra_car TEGRA30_CLK_PLL_M>;
> + power-domains = <&domain>;
> + };
> + };
> };
> };
>
> --
> 2.29.2
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 43/48] ARM: tegra: Add OPP tables and power domains to Tegra20 device-tree
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> diff --git a/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
> b/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
> index b84afecea154..7e015cdfbc55 100644
> --- a/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
> +++ b/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
> @@ -1,6 +1,46 @@
> // SPDX-License-Identifier: GPL-2.0
>
> / {
> + core_opp_table: core-power-domain-opp-table {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + core_opp_950: opp@95 {
> + opp-microvolt = <95 95 130>;
> + opp-level = <95>;
> + };
I am not sure I fully understand this, why does it have both microvolt and level
properties ?
--
viresh
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 28/48] soc/tegra: Introduce core power domain driver
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> +++ b/drivers/soc/tegra/core-power-domain.c
> @@ -0,0 +1,125 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * NVIDIA Tegra SoC Core Power Domain Driver
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +static struct lock_class_key tegra_core_domain_lock_class;
> +static bool tegra_core_domain_state_synced;
> +
> +static int tegra_genpd_set_performance_state(struct generic_pm_domain *genpd,
> + unsigned int level)
> +{
> + struct dev_pm_opp *opp;
> + int err;
> +
> + opp = dev_pm_opp_find_level_ceil(&genpd->dev, &level);
We don't need ceil or floor versions for level, but rather _exact() version. Or
maybe just call it dev_pm_opp_find_level().
> + if (IS_ERR(opp)) {
> + dev_err(&genpd->dev, "failed to find OPP for level %u: %pe\n",
> + level, opp);
> + return PTR_ERR(opp);
> + }
> +
> + err = dev_pm_opp_set_voltage(&genpd->dev, opp);
IIUC, you implemented this callback because you want to use the voltage triplet
present in the OPP table ?
And so you are setting the regulator ("power") later in this patch ?
I am not in favor of implementing this routine, as it just adds a wrapper above
the regulator API. What you should be doing rather is get the regulator by
yourself here (instead of depending on the OPP core). And then you can do
dev_pm_opp_get_voltage() here and set the voltage yourself. You may want to
implement a version supporting triplet here though for the same.
And you won't require the sync version of the API as well then.
--
viresh
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 09/48] opp: Add dev_pm_opp_sync_regulators()
On 17-12-20, 21:05, Dmitry Osipenko wrote: > Extend OPP API with dev_pm_opp_sync_regulators() function, which syncs > voltage state of regulators. > > Signed-off-by: Dmitry Osipenko We shouldn't be doing this, details in patch 28. -- viresh ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 10/48] opp: Add dev_pm_opp_set_voltage()
On 17-12-20, 21:06, Dmitry Osipenko wrote: > Add dev_pm_opp_set_voltage() which allows OPP table users to set voltage > in accordance to a given OPP. In particular this is needed for driving > voltage of a generic power domain which uses OPPs and doesn't have a > clock. > > Signed-off-by: Dmitry Osipenko We shouldn't be doing this, details in patch 28. -- viresh ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 11/48] opp: Add dev_pm_opp_find_level_ceil()
On 17-12-20, 21:06, Dmitry Osipenko wrote: > Add a ceil version of the dev_pm_opp_find_level(). It's handy to have if > levels don't start from 0 in OPP table and zero usually means a minimal > level. > > Signed-off-by: Dmitry Osipenko Why doesn't the exact version work for you here ? -- viresh ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
