* [PATCH 2/2] dt-bindings: simple-panel: Set compatible string to "simple-panel".
From: Christoph Muellner @ 2019-04-10 14:10 UTC (permalink / raw)
Cc: heiko, Christoph Muellner, Thierry Reding, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, dri-devel, devicetree,
linux-kernel
In-Reply-To: <20190410141045.58097-1-christoph.muellner@theobroma-systems.com>
The documentation for simple-panel lists "cptt,claa101wb01" as
compatible string. However, the kernel contains no driver, which
recognizes this string. Therefore this patch replaces the compatible
string with "simple-panel".
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
---
Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index b2b872c710f2..2000692ba44f 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -18,7 +18,7 @@ Optional properties:
Example:
panel: panel {
- compatible = "cptt,claa101wb01";
+ compatible = "simple-panel";
ddc-i2c-bus = <&panelddc>;
power-supply = <&vdd_pnl_reg>;
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] drm: panel-simple: Add simple-panel driver.
From: Christoph Muellner @ 2019-04-10 14:10 UTC (permalink / raw)
Cc: heiko, Christoph Muellner, Thierry Reding, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, dri-devel, devicetree,
linux-kernel
On our RK3399-Q7 EVK base board we have the option to connect an arbitrary
monitor via DP cable. The actual monitor is therefore not known in advance.
This means, we don't have any panel information besides the EDID
data from the device itself.
The functionality for a 'simple-panel' has been remove a couple
of years ago with 81cf32b. This patch brings this feature back.
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
---
drivers/gpu/drm/panel/panel-simple.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 9e8218f6a3f2..1f69283f3e4b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -176,7 +176,7 @@ static int panel_simple_disable(struct drm_panel *panel)
backlight_update_status(p->backlight);
}
- if (p->desc->delay.disable)
+ if (p->desc && p->desc->delay.disable)
msleep(p->desc->delay.disable);
p->enabled = false;
@@ -195,7 +195,7 @@ static int panel_simple_unprepare(struct drm_panel *panel)
regulator_disable(p->supply);
- if (p->desc->delay.unprepare)
+ if (p->desc && p->desc->delay.unprepare)
msleep(p->desc->delay.unprepare);
p->prepared = false;
@@ -220,11 +220,13 @@ static int panel_simple_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(p->enable_gpio, 1);
- delay = p->desc->delay.prepare;
- if (p->no_hpd)
- delay += p->desc->delay.hpd_absent_delay;
- if (delay)
- msleep(delay);
+ if (p->desc) {
+ delay = p->desc->delay.prepare;
+ if (p->no_hpd)
+ delay += p->desc->delay.hpd_absent_delay;
+ if (delay)
+ msleep(delay);
+ }
p->prepared = true;
@@ -238,7 +240,7 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p->enabled)
return 0;
- if (p->desc->delay.enable)
+ if (p->desc && p->desc->delay.enable)
msleep(p->desc->delay.enable);
if (p->backlight) {
@@ -280,6 +282,9 @@ static int panel_simple_get_timings(struct drm_panel *panel,
struct panel_simple *p = to_panel_simple(panel);
unsigned int i;
+ if (!p->desc)
+ return 0;
+
if (p->desc->num_timings < num_timings)
num_timings = p->desc->num_timings;
@@ -2536,6 +2541,9 @@ static const struct panel_desc arm_rtsm = {
static const struct of_device_id platform_of_match[] = {
{
+ .compatible = "simple-panel",
+ .data = NULL,
+ }, {
.compatible = "ampire,am-480272h3tmqw-t01h",
.data = &ire_am_480272h3tmqw_t01h,
}, {
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
From: Boris Brezillon @ 2019-04-10 14:10 UTC (permalink / raw)
To: Yue Haibing
Cc: bbrezillon, richard, linux-kernel, marek.vasut, paul.burton,
linux-mtd, miquel.raynal, computersforpeace
In-Reply-To: <20190410155856.655122c8@collabora.com>
On Wed, 10 Apr 2019 15:58:56 +0200
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> On Wed, 10 Apr 2019 15:39:28 +0200
> Boris Brezillon <boris.brezillon@collabora.com> wrote:
>
> > On Wed, 10 Apr 2019 21:07:47 +0800
> > Yue Haibing <yuehaibing@huawei.com> wrote:
> >
> > > From: YueHaibing <yuehaibing@huawei.com>
> > >
> > > Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
> > > is set to module:
> > >
> > > drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
> > > (.text+0xef6): undefined reference to `nand_bch_free'
> > > drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
> > > nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
> > > nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
> > > nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
> > >
> > > CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
> > > because MTD_RAW_NAND need it while linked.
> > >
> > > Reported-by: Hulk Robot <hulkci@huawei.com>
> > > Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
> >
> > Nope, it's not this one that introduced the regression.
> >
> >
> >
> > > Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> > > ---
> > > drivers/mtd/nand/raw/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> > > index 615d738..0500c42 100644
> > > --- a/drivers/mtd/nand/raw/Kconfig
> > > +++ b/drivers/mtd/nand/raw/Kconfig
> > > @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
> > > if MTD_RAW_NAND
> > >
> > > config MTD_NAND_ECC_SW_BCH
> > > - tristate "Support software BCH ECC"
> > > + bool "Support software BCH ECC"
> > > select BCH
> > > default n
> > > help
> >
> > Should be fixed with the following diff squashed into:
> >
> > 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC algorithm")
> >
> > --->8---
> > diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
> > index b8106651f807..06ce2b655c13 100644
> > --- a/include/linux/mtd/nand_bch.h
> > +++ b/include/linux/mtd/nand_bch.h
> > @@ -15,7 +15,7 @@ struct mtd_info;
> > struct nand_chip;
> > struct nand_bch_control;
> >
> > -#if defined(CONFIG_MTD_NAND_ECC_BCH)
> > +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
> >
> > static inline int mtd_nand_has_bch(void) { return 1; }
> >
> > @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
> > */
> > void nand_bch_free(struct nand_bch_control *nbc);
> >
> > -#else /* !CONFIG_MTD_NAND_ECC_BCH */
> > +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
> >
> > static inline int mtd_nand_has_bch(void) { return 0; }
> >
> > @@ -64,6 +64,6 @@ static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> >
> > static inline void nand_bch_free(struct nand_bch_control *nbc) {}
> >
> > -#endif /* CONFIG_MTD_NAND_ECC_BCH */
> > +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
> >
> > #endif /* __MTD_NAND_BCH_H__ */
>
> Sorry, I didn't look at the right branch, this part of the code was
> correct, but we still have a problem to express the RAW_NAND(y) ->
> SW_BCH(y) dependency.
This one should do the trick, though imply means MTD_NAND_ECC_SW_BCH will
now be selected by default.
--->8---
diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index 7fcdaf6c279d..f9258d666846 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -207,7 +207,7 @@ comment "Disk-On-Chip Device Drivers"
config MTD_DOCG3
tristate "M-Systems Disk-On-Chip G3"
select BCH
- select BCH_CONST_PARAMS if !CONFIG_MTD_NAND_ECC_SW_BCH
+ select BCH_CONST_PARAMS if !MTD_NAND_ECC_SW_BCH
select BITREVERSE
help
This provides an MTD device driver for the M-Systems DiskOnChip
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 615d738be411..65c85fc53c41 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -9,18 +9,6 @@ config MTD_NAND_ECC_SW_HAMMING_SMC
Software ECC according to the Smart Media Specification.
The original Linux implementation had byte 0 and 1 swapped.
-menuconfig MTD_RAW_NAND
- tristate "Raw/Parallel NAND Device Support"
- depends on MTD
- select MTD_NAND_CORE
- select MTD_NAND_ECC_SW_HAMMING
- help
- This enables support for accessing all type of raw/parallel
- NAND flash devices. For further information see
- <http://www.linux-mtd.infradead.org/doc/nand.html>.
-
-if MTD_RAW_NAND
-
config MTD_NAND_ECC_SW_BCH
tristate "Support software BCH ECC"
select BCH
@@ -31,6 +19,19 @@ config MTD_NAND_ECC_SW_BCH
ECC codes. They are used with NAND devices requiring more than 1 bit
of error correction.
+menuconfig MTD_RAW_NAND
+ tristate "Raw/Parallel NAND Device Support"
+ depends on MTD
+ select MTD_NAND_CORE
+ select MTD_NAND_ECC_SW_HAMMING
+ imply MTD_NAND_ECC_SW_BCH
+ help
+ This enables support for accessing all type of raw/parallel
+ NAND flash devices. For further information see
+ <http://www.linux-mtd.infradead.org/doc/nand.html>.
+
+if MTD_RAW_NAND
+
comment "Raw/parallel NAND flash controllers"
config MTD_NAND_DENALI
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related
* Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
From: Boris Brezillon @ 2019-04-10 14:10 UTC (permalink / raw)
To: Yue Haibing
Cc: miquel.raynal, richard, computersforpeace, marek.vasut,
paul.burton, bbrezillon, linux-kernel, linux-mtd
In-Reply-To: <20190410155856.655122c8@collabora.com>
On Wed, 10 Apr 2019 15:58:56 +0200
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> On Wed, 10 Apr 2019 15:39:28 +0200
> Boris Brezillon <boris.brezillon@collabora.com> wrote:
>
> > On Wed, 10 Apr 2019 21:07:47 +0800
> > Yue Haibing <yuehaibing@huawei.com> wrote:
> >
> > > From: YueHaibing <yuehaibing@huawei.com>
> > >
> > > Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
> > > is set to module:
> > >
> > > drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
> > > (.text+0xef6): undefined reference to `nand_bch_free'
> > > drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
> > > nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
> > > nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
> > > nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
> > >
> > > CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
> > > because MTD_RAW_NAND need it while linked.
> > >
> > > Reported-by: Hulk Robot <hulkci@huawei.com>
> > > Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
> >
> > Nope, it's not this one that introduced the regression.
> >
> >
> >
> > > Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> > > ---
> > > drivers/mtd/nand/raw/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> > > index 615d738..0500c42 100644
> > > --- a/drivers/mtd/nand/raw/Kconfig
> > > +++ b/drivers/mtd/nand/raw/Kconfig
> > > @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
> > > if MTD_RAW_NAND
> > >
> > > config MTD_NAND_ECC_SW_BCH
> > > - tristate "Support software BCH ECC"
> > > + bool "Support software BCH ECC"
> > > select BCH
> > > default n
> > > help
> >
> > Should be fixed with the following diff squashed into:
> >
> > 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC algorithm")
> >
> > --->8---
> > diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
> > index b8106651f807..06ce2b655c13 100644
> > --- a/include/linux/mtd/nand_bch.h
> > +++ b/include/linux/mtd/nand_bch.h
> > @@ -15,7 +15,7 @@ struct mtd_info;
> > struct nand_chip;
> > struct nand_bch_control;
> >
> > -#if defined(CONFIG_MTD_NAND_ECC_BCH)
> > +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
> >
> > static inline int mtd_nand_has_bch(void) { return 1; }
> >
> > @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
> > */
> > void nand_bch_free(struct nand_bch_control *nbc);
> >
> > -#else /* !CONFIG_MTD_NAND_ECC_BCH */
> > +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
> >
> > static inline int mtd_nand_has_bch(void) { return 0; }
> >
> > @@ -64,6 +64,6 @@ static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
> >
> > static inline void nand_bch_free(struct nand_bch_control *nbc) {}
> >
> > -#endif /* CONFIG_MTD_NAND_ECC_BCH */
> > +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
> >
> > #endif /* __MTD_NAND_BCH_H__ */
>
> Sorry, I didn't look at the right branch, this part of the code was
> correct, but we still have a problem to express the RAW_NAND(y) ->
> SW_BCH(y) dependency.
This one should do the trick, though imply means MTD_NAND_ECC_SW_BCH will
now be selected by default.
--->8---
diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index 7fcdaf6c279d..f9258d666846 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -207,7 +207,7 @@ comment "Disk-On-Chip Device Drivers"
config MTD_DOCG3
tristate "M-Systems Disk-On-Chip G3"
select BCH
- select BCH_CONST_PARAMS if !CONFIG_MTD_NAND_ECC_SW_BCH
+ select BCH_CONST_PARAMS if !MTD_NAND_ECC_SW_BCH
select BITREVERSE
help
This provides an MTD device driver for the M-Systems DiskOnChip
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 615d738be411..65c85fc53c41 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -9,18 +9,6 @@ config MTD_NAND_ECC_SW_HAMMING_SMC
Software ECC according to the Smart Media Specification.
The original Linux implementation had byte 0 and 1 swapped.
-menuconfig MTD_RAW_NAND
- tristate "Raw/Parallel NAND Device Support"
- depends on MTD
- select MTD_NAND_CORE
- select MTD_NAND_ECC_SW_HAMMING
- help
- This enables support for accessing all type of raw/parallel
- NAND flash devices. For further information see
- <http://www.linux-mtd.infradead.org/doc/nand.html>.
-
-if MTD_RAW_NAND
-
config MTD_NAND_ECC_SW_BCH
tristate "Support software BCH ECC"
select BCH
@@ -31,6 +19,19 @@ config MTD_NAND_ECC_SW_BCH
ECC codes. They are used with NAND devices requiring more than 1 bit
of error correction.
+menuconfig MTD_RAW_NAND
+ tristate "Raw/Parallel NAND Device Support"
+ depends on MTD
+ select MTD_NAND_CORE
+ select MTD_NAND_ECC_SW_HAMMING
+ imply MTD_NAND_ECC_SW_BCH
+ help
+ This enables support for accessing all type of raw/parallel
+ NAND flash devices. For further information see
+ <http://www.linux-mtd.infradead.org/doc/nand.html>.
+
+if MTD_RAW_NAND
+
comment "Raw/parallel NAND flash controllers"
config MTD_NAND_DENALI
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: simple-panel: Set compatible string to "simple-panel".
From: Christoph Muellner @ 2019-04-10 14:10 UTC (permalink / raw)
Cc: heiko, Christoph Muellner, Thierry Reding, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, dri-devel, devicetree,
linux-kernel
In-Reply-To: <20190410141045.58097-1-christoph.muellner@theobroma-systems.com>
The documentation for simple-panel lists "cptt,claa101wb01" as
compatible string. However, the kernel contains no driver, which
recognizes this string. Therefore this patch replaces the compatible
string with "simple-panel".
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
---
Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index b2b872c710f2..2000692ba44f 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -18,7 +18,7 @@ Optional properties:
Example:
panel: panel {
- compatible = "cptt,claa101wb01";
+ compatible = "simple-panel";
ddc-i2c-bus = <&panelddc>;
power-supply = <&vdd_pnl_reg>;
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] drm: panel-simple: Add simple-panel driver.
From: Christoph Muellner @ 2019-04-10 14:10 UTC (permalink / raw)
Cc: heiko, Christoph Muellner, Thierry Reding, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, dri-devel, devicetree,
linux-kernel
On our RK3399-Q7 EVK base board we have the option to connect an arbitrary
monitor via DP cable. The actual monitor is therefore not known in advance.
This means, we don't have any panel information besides the EDID
data from the device itself.
The functionality for a 'simple-panel' has been remove a couple
of years ago with 81cf32b. This patch brings this feature back.
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>
---
drivers/gpu/drm/panel/panel-simple.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 9e8218f6a3f2..1f69283f3e4b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -176,7 +176,7 @@ static int panel_simple_disable(struct drm_panel *panel)
backlight_update_status(p->backlight);
}
- if (p->desc->delay.disable)
+ if (p->desc && p->desc->delay.disable)
msleep(p->desc->delay.disable);
p->enabled = false;
@@ -195,7 +195,7 @@ static int panel_simple_unprepare(struct drm_panel *panel)
regulator_disable(p->supply);
- if (p->desc->delay.unprepare)
+ if (p->desc && p->desc->delay.unprepare)
msleep(p->desc->delay.unprepare);
p->prepared = false;
@@ -220,11 +220,13 @@ static int panel_simple_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(p->enable_gpio, 1);
- delay = p->desc->delay.prepare;
- if (p->no_hpd)
- delay += p->desc->delay.hpd_absent_delay;
- if (delay)
- msleep(delay);
+ if (p->desc) {
+ delay = p->desc->delay.prepare;
+ if (p->no_hpd)
+ delay += p->desc->delay.hpd_absent_delay;
+ if (delay)
+ msleep(delay);
+ }
p->prepared = true;
@@ -238,7 +240,7 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p->enabled)
return 0;
- if (p->desc->delay.enable)
+ if (p->desc && p->desc->delay.enable)
msleep(p->desc->delay.enable);
if (p->backlight) {
@@ -280,6 +282,9 @@ static int panel_simple_get_timings(struct drm_panel *panel,
struct panel_simple *p = to_panel_simple(panel);
unsigned int i;
+ if (!p->desc)
+ return 0;
+
if (p->desc->num_timings < num_timings)
num_timings = p->desc->num_timings;
@@ -2536,6 +2541,9 @@ static const struct panel_desc arm_rtsm = {
static const struct of_device_id platform_of_match[] = {
{
+ .compatible = "simple-panel",
+ .data = NULL,
+ }, {
.compatible = "ampire,am-480272h3tmqw-t01h",
.data = &ire_am_480272h3tmqw_t01h,
}, {
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v1 0/2] add cec pins muxing
From: Alexandre Torgue @ 2019-04-10 14:08 UTC (permalink / raw)
To: Yannick Fertré, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Philippe Cornu
In-Reply-To: <1553863315-6652-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 3/29/19 1:41 PM, Yannick Fertré wrote:
> Add cec pins muxing
>
> Yannick Fertré (2):
> ARM: dts: stm32: add cec pins muxing on stm32mp157
> ARM: dts: stm32: add sleep pinctrl for cec on stm32mp157c
>
> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
Series applied on stm32-next. Note that I squashed the both patches
as they deal only with pins muxing group definition.
Regards
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 58/59] LSM: Specify which LSM to display with /proc/self/attr/display
From: Stephen Smalley @ 2019-04-10 14:09 UTC (permalink / raw)
To: Casey Schaufler
Cc: Schaufler, Casey, James Morris, linux-security-module, selinux
In-Reply-To: <CAB9W1A0ZVUHAtAEhYw+HSyOnRdekg=6WQ2RP8PqNAirmDxBkZw@mail.gmail.com>
On Wed, Apr 10, 2019 at 8:43 AM Stephen Smalley
<stephen.smalley@gmail.com> wrote:
>
> On Tue, Apr 9, 2019 at 5:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >
> > Create a new entry "display" in /proc/.../attr for controlling
> > which LSM security information is displayed for a process.
> > The name of an active LSM that supplies hooks for human readable
> > data may be written to "display" to set the value. The name of
> > the LSM currently in use can be read from "display".
> >
> > Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> > ---
> > fs/proc/base.c | 1 +
> > security/security.c | 123 ++++++++++++++++++++++++++++++++++++++++++--
> > 2 files changed, 121 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > index ddef482f1334..7bf70e041315 100644
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -2618,6 +2618,7 @@ static const struct pid_entry attr_dir_stuff[] = {
> > ATTR(NULL, "fscreate", 0666),
> > ATTR(NULL, "keycreate", 0666),
> > ATTR(NULL, "sockcreate", 0666),
> > + ATTR(NULL, "display", 0666),
> > #ifdef CONFIG_SECURITY_SMACK
> > DIR("smack", 0555,
> > proc_smack_attr_dir_inode_ops, proc_smack_attr_dir_ops),
> > diff --git a/security/security.c b/security/security.c
> > index 29149db3f78a..6e304aa796f9 100644
> > --- a/security/security.c
> > +++ b/security/security.c
> > @@ -47,9 +47,13 @@ static struct kmem_cache *lsm_inode_cache;
> >
> > char *lsm_names;
> >
> > -/* Socket blobs include infrastructure managed data */
> > +/*
> > + * Socket blobs include infrastructure managed data
> > + * Cred blobs include context display instructions
> > + */
> > static struct lsm_blob_sizes blob_sizes __lsm_ro_after_init = {
> > .lbs_sock = sizeof(struct lsm_export),
> > + .lbs_cred = sizeof(struct lsm_one_hooks),
> > };
> >
> > /**
> > @@ -751,7 +755,10 @@ int lsm_superblock_alloc(struct super_block *sb)
> >
> > #define call_one_int_hook(FUNC, IRC, ...) ({ \
> > int RC = IRC; \
> > - if (lsm_base_one.FUNC.FUNC) \
> > + struct lsm_one_hooks *LOH = current_cred()->security; \
> > + if (LOH->FUNC.FUNC) \
> > + RC = LOH->FUNC.FUNC(__VA_ARGS__); \
> > + else if (LOH->lsm == NULL && lsm_base_one.FUNC.FUNC) \
> > RC = lsm_base_one.FUNC.FUNC(__VA_ARGS__); \
> > RC; \
> > })
> > @@ -1617,6 +1624,7 @@ int security_cred_alloc_blank(struct cred *cred, gfp_t gfp)
> >
> > void security_cred_free(struct cred *cred)
> > {
> > + struct lsm_one_hooks *loh;
> > /*
> > * There is a failure case in prepare_creds() that
> > * may result in a call here with ->security being NULL.
> > @@ -1626,26 +1634,44 @@ void security_cred_free(struct cred *cred)
> >
> > call_void_hook(cred_free, cred);
> >
> > + loh = cred->security;
> > + kfree(loh->lsm);
> > kfree(cred->security);
> > cred->security = NULL;
> > }
> >
> > +static int copy_loh(struct lsm_one_hooks *new, struct lsm_one_hooks *old,
> > + gfp_t gfp)
> > +{
> > + *new = *old;
> > + if (old->lsm) {
> > + new->lsm = kstrdup(old->lsm, gfp);
> > + if (unlikely(new->lsm == NULL))
> > + return -ENOMEM;
> > + }
> > + return 0;
> > +}
> > +
> > int security_prepare_creds(struct cred *new, const struct cred *old, gfp_t gfp)
> > {
> > int rc = lsm_cred_alloc(new, gfp);
> >
> > - if (rc)
> > + if (unlikely(rc))
> > return rc;
> >
> > rc = call_int_hook(cred_prepare, 0, new, old, gfp);
> > if (unlikely(rc))
> > security_cred_free(new);
> > + else
> > + rc = copy_loh(new->security, old->security, gfp);
> > +
> > return rc;
> > }
> >
> > void security_transfer_creds(struct cred *new, const struct cred *old)
> > {
> > call_void_hook(cred_transfer, new, old);
> > + WARN_ON(copy_loh(new->security, old->security, GFP_KERNEL));
> > }
> >
> > void security_cred_getsecid(const struct cred *c, struct lsm_export *l)
> > @@ -1960,10 +1986,28 @@ int security_getprocattr(struct task_struct *p, const char *lsm, char *name,
> > char **value)
> > {
> > struct security_hook_list *hp;
> > + struct lsm_one_hooks *loh = current_cred()->security;
> > + char *s;
> > +
> > + if (!strcmp(name, "display")) {
> > + if (loh->lsm)
> > + s = loh->lsm;
> > + else if (lsm_base_one.lsm)
> > + s = lsm_base_one.lsm;
> > + else
> > + return -EINVAL;
> > +
> > + *value = kstrdup(s, GFP_KERNEL);
> > + if (*value)
> > + return strlen(s);
> > + return -ENOMEM;
> > + }
> >
> > hlist_for_each_entry(hp, &security_hook_heads.getprocattr, list) {
> > if (lsm != NULL && strcmp(lsm, hp->lsm))
> > continue;
> > + if (lsm == NULL && loh->lsm && strcmp(loh->lsm, hp->lsm))
> > + continue;
> > return hp->hook.getprocattr(p, name, value);
> > }
> > return -EINVAL;
> > @@ -1973,10 +2017,83 @@ int security_setprocattr(const char *lsm, const char *name, void *value,
> > size_t size)
> > {
> > struct security_hook_list *hp;
> > + struct lsm_one_hooks *loh = current_cred()->security;
> > + bool found = false;
> > + char *s;
> > +
> > + /*
> > + * End the passed name at a newline.
> > + */
> > + s = strnchr(value, size, '\n');
> > + if (s)
> > + *s = '\0';
> > +
> > + if (!strcmp(name, "display")) {
> > + union security_list_options secid_to_secctx;
> > + union security_list_options secctx_to_secid;
> > + union security_list_options socket_getpeersec_stream;
> > +
> > + if (size == 0 || size >= 100)
> > + return -EINVAL;
> > +
> > + secid_to_secctx.secid_to_secctx = NULL;
> > + hlist_for_each_entry(hp, &security_hook_heads.secid_to_secctx,
> > + list) {
> > + if (size >= strlen(hp->lsm) &&
> > + !strncmp(value, hp->lsm, size)) {
> > + secid_to_secctx = hp->hook;
> > + found = true;
> > + break;
> > + }
> > + }
> > + secctx_to_secid.secctx_to_secid = NULL;
> > + hlist_for_each_entry(hp, &security_hook_heads.secctx_to_secid,
> > + list) {
> > + if (size >= strlen(hp->lsm) &&
> > + !strncmp(value, hp->lsm, size)) {
> > + secctx_to_secid = hp->hook;
> > + found = true;
> > + break;
> > + }
> > + }
> > + socket_getpeersec_stream.socket_getpeersec_stream = NULL;
> > + hlist_for_each_entry(hp,
> > + &security_hook_heads.socket_getpeersec_stream,
> > + list) {
> > + if (size >= strlen(hp->lsm) &&
> > + !strncmp(value, hp->lsm, size)) {
> > + socket_getpeersec_stream = hp->hook;
> > + found = true;
> > + break;
> > + }
> > + }
> > + if (!found)
> > + return -EINVAL;
> > +
> > + /*
> > + * The named lsm is active and supplies one or more
> > + * of the relevant hooks. Switch to it.
> > + */
> > + s = kmemdup(value, size + 1, GFP_KERNEL);
> > + if (s == NULL)
> > + return -ENOMEM;
> > + s[size] = '\0';
> > +
> > + if (loh->lsm)
> > + kfree(loh->lsm);
> > + loh->lsm = s;
> > + loh->secid_to_secctx = secid_to_secctx;
> > + loh->secctx_to_secid = secctx_to_secid;
> > + loh->socket_getpeersec_stream = socket_getpeersec_stream;
>
> You can't just write to the cred security blob like this; it is a
> shared data structure, not per-task.
To be clear, you either need to perform a new = prepare_creds(); /*
modify new->security as desired */; commit_creds(new); sequence here,
or use the task security blob instead of the cred security blob. The
latter seems more amenable to your needs.
>
> > +
> > + return size;
> > + }
> >
> > hlist_for_each_entry(hp, &security_hook_heads.setprocattr, list) {
> > if (lsm != NULL && strcmp(lsm, hp->lsm))
> > continue;
> > + if (lsm == NULL && loh->lsm && strcmp(loh->lsm, hp->lsm))
> > + continue;
> > return hp->hook.setprocattr(name, value, size);
> > }
> > return -EINVAL;
> > --
> > 2.19.1
> >
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: thermal: al-thermal: Add binding documentation
From: Rob Herring @ 2019-04-10 14:10 UTC (permalink / raw)
To: Talel Shenhar
Cc: edubezval, dwmw, jonnyc, rui.zhang, hhhawa, ronenk, hanochu,
linux-kernel, linux-pm, mark.rutland, devicetree
In-Reply-To: <1554373016-1442-2-git-send-email-talel@amazon.com>
On Thu, Apr 04, 2019 at 01:16:55PM +0300, Talel Shenhar wrote:
> Add thermal binding documentation for Amazon's Annapurna Labs Thermal
> Sensor.
>
> Signed-off-by: Talel Shenhar <talel@amazon.com>
> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> .../bindings/thermal/amazon,al-thermal.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
> new file mode 100644
> index 0000000..af8cf18
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
> @@ -0,0 +1,33 @@
> +Amazon's Annapurna Labs Thermal Sensor
> +
> +Simple thermal device that allows temperature reading by a single MMIO
> +transaction.
> +
> +Required properties:
> +- compatible: "amazon,al-thermal".
> +- reg: The physical base address and length of the sensor's registers.
> +- #thermal-sensor-cells: Must be 1. See ./thermal.txt for a description.
> +
> +Example:
> + thermal: thermal {
> + compatible = "amazon,al-thermal";
> + reg = <0x0 0x05002860 0x0 0x1>;
> + #thermal-sensor-cells = <0x1>;
> + };
> +
> + thermal-zones {
> + thermal_z0 {
thermal-z0 {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> + thermal-sensors = <&thermal 0>;
> + trips {
> + thermalz0_crit {
critical {
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
> + temperature = <105000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> +
> + };
> + };
> +
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 23/23] watchdog: tangox_wdt: Convert to use device managed functions and other improvements
From: Marc Gonzalez @ 2019-04-10 14:09 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck; +Cc: LKML, Mans Rullgard, Dmitry Torokhov
In-Reply-To: <c875ddd9-13f4-c6d4-4537-21b80000b9b5@roeck-us.net>
On 10/04/2019 15:37, Guenter Roeck wrote:
> On 4/10/19 6:04 AM, Marc Gonzalez wrote:
>
>> On 09/04/2019 19:24, Guenter Roeck wrote:
>>
>>> Use device managed functions to simplify error handling, reduce
>>> source code size, improve readability, and reduce the likelihood of bugs.
>>> Other improvements as listed below.
>>>
>>> The conversion was done automatically with coccinelle using the
>>> following semantic patches. The semantic patches and the scripts
>>> used to generate this commit log are available at
>>> https://github.com/groeck/coccinelle-patches
>>>
>>> - Drop assignments to otherwise unused variables
>>> - Drop unnecessary braces around conditional return statements
>>> - Drop empty remove function
>>> - Use devm_add_action_or_reset() for calls to clk_disable_unprepare
>>> - Replace stop on remove with call to watchdog_stop_on_unregister()
>>> - Use devm_watchdog_register_driver() to register watchdog device
>>
>> No devm_clk_prepare() in mainline? :-(
>>
>> https://lore.kernel.org/patchwork/patch/755487/
>
> We went through that several times and never succeeded. This was the major
> reason why I didn't submit this series earlier since I was hoping for it
> to appear at some point. Unfortunately, someone always objected, typically
> with comments along the line that it could be misused, or citing individual
> examples where the current code in some driver is wrong and should be fixed
> instead.
>
> This isn't really a technical argument: Everything can be misused, and all
> code has bugs. Neither is a reason to reject a new useful API. As such, one
> has to assume that after refuting such arguments, and even after fixing all
> bugs in existing code, the opponents of the new API will come up with other
> reasons to reject it.
>
> At the end, I gave up trying. Feel free to try yourself; I most definitely
> won't try it anymore. Using devm_add_action_or_reset() is a bit more clumsy,
> but works just as well.
Hello Guenter,
I am saddened to read about your frustration. I might give it a try, if Dmitry
doesn't feel like giving it another shot.
Regards.
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 1/2] acl: remove use of weak functions
From: Aaron Conole @ 2019-04-10 14:08 UTC (permalink / raw)
To: Bruce Richardson; +Cc: konstantin.ananyev, dev
In-Reply-To: <20190410140232.GD718@bricha3-MOBL.ger.corp.intel.com>
Bruce Richardson <bruce.richardson@intel.com> writes:
> On Wed, Apr 10, 2019 at 09:54:02AM -0400, Aaron Conole wrote:
>> Bruce Richardson <bruce.richardson@intel.com> writes:
>>
>> > Weak functions don't work well with static libraries and require the
>> > use of "whole-archive" flag to ensure that the correct function is used
>> > when linking. Since the weak functions are only used as placeholders
>> > within this library alone, we can replace them with non-weak functions
>> > using preprocessor ifdefs.
>> >
>> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> ---
>> > lib/librte_acl/meson.build | 7 ++++++- lib/librte_acl/rte_acl.c | 18
>> > ++++++++++++++---- mk/rte.app.mk | 3 --- 3 files changed,
>> > 20 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/lib/librte_acl/meson.build b/lib/librte_acl/meson.build
>> > index 2207dbafe..98ece7d85 100644 --- a/lib/librte_acl/meson.build +++
>> > b/lib/librte_acl/meson.build @@ -6,7 +6,7 @@ sources =
>> > files('acl_bld.c', 'acl_gen.c', 'acl_run_scalar.c', 'rte_acl.c',
>> > 'tb_mem.c') headers = files('rte_acl.h', 'rte_acl_osdep.h')
>> >
>> > -if arch_subdir == 'x86' +if dpdk_conf.has('RTE_ARCH_X86') sources +=
>> > files('acl_run_sse.c')
>> >
>> > # compile AVX2 version if either: @@ -28,4 +28,9 @@ if arch_subdir
>> > == 'x86' cflags += '-DCC_AVX2_SUPPORT' endif
>> >
>> > +elif dpdk_conf.has('RTE_ARCH_ARM') or dpdk_conf.has('RTE_ARCH_ARM64')
>> > + cflags += '-flax-vector-conversions' + sources +=
>> > files('acl_run_neon.c')
>>
>> This will also need -Wno-uninitialized (otherwise it will generate
>> warnings about the search_neon_4 and search_neon_8 functions).
>>
>> But I don't like papering over these conversions. I'd prefer instead the
>> patches I posted at:
>>
>> http://mails.dpdk.org/archives/dev/2019-April/129540.html and
>> http://mails.dpdk.org/archives/dev/2019-April/129541.html
>>
>> Are you opposed to merging those?
>>
> Nope, not in the least. I'm happy enough to rework this patch on top of
> those - I'd just had forgotten about them in my rush to get a potential
> solution out here. I did these up quickly to show how easy it is to remove
> the need for the weak functions and the subsequent linker "--whole-archive"
> flag.
>
> /Bruce
>
> PS: I see your patch 2 does not include the Wno-uninitialized flag, is it
> not needed in your patch, or just an oversight?
It isn't needed, I resolved the issue with an explicit initialization.
^ permalink raw reply
* Re: [PATCH v1 0/2] add cec pins muxing
From: Alexandre Torgue @ 2019-04-10 14:08 UTC (permalink / raw)
To: Yannick Fertré, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Philippe Cornu
In-Reply-To: <1553863315-6652-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 3/29/19 1:41 PM, Yannick Fertré wrote:
> Add cec pins muxing
>
> Yannick Fertré (2):
> ARM: dts: stm32: add cec pins muxing on stm32mp157
> ARM: dts: stm32: add sleep pinctrl for cec on stm32mp157c
>
> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
Series applied on stm32-next. Note that I squashed the both patches
as they deal only with pins muxing group definition.
Regards
Alex
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: usb: Add usb-phy property to the jz4740-musb node
From: Rob Herring @ 2019-04-10 14:07 UTC (permalink / raw)
To: Paul Cercueil
Cc: Mark Rutland, Bin Liu, od, linux-usb, devicetree, linux-kernel,
Paul Cercueil
In-Reply-To: <20190404094739.23503-1-paul@crapouillou.net>
On Thu, 4 Apr 2019 11:47:37 +0200, Paul Cercueil wrote:
> Add a required 'usb-phy' property, to obtain a phandle to the USB PHY
> from devicetree.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v2: Change "usb-phy" DT property to "phys"
>
> Documentation/devicetree/bindings/usb/ingenic,jz4740-musb.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: usb: Add usb-phy property to the jz4740-musb node
From: Rob Herring @ 2019-04-10 14:07 UTC (permalink / raw)
Cc: Mark Rutland, Bin Liu, od, linux-usb, devicetree, linux-kernel,
Paul Cercueil
In-Reply-To: <20190404094739.23503-1-paul@crapouillou.net>
On Thu, 4 Apr 2019 11:47:37 +0200, Paul Cercueil wrote:
> Add a required 'usb-phy' property, to obtain a phandle to the USB PHY
> from devicetree.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v2: Change "usb-phy" DT property to "phys"
>
> Documentation/devicetree/bindings/usb/ingenic,jz4740-musb.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [v2,1/3] dt-bindings: usb: Add usb-phy property to the jz4740-musb node
From: Rob Herring @ 2019-04-10 14:07 UTC (permalink / raw)
To: Paul Cercueil
Cc: Mark Rutland, Bin Liu, od, linux-usb, devicetree, linux-kernel
On Thu, 4 Apr 2019 11:47:37 +0200, Paul Cercueil wrote:
> Add a required 'usb-phy' property, to obtain a phandle to the USB PHY
> from devicetree.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v2: Change "usb-phy" DT property to "phys"
>
> Documentation/devicetree/bindings/usb/ingenic,jz4740-musb.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 2/2] bpf: remove use of weak functions
From: Aaron Conole @ 2019-04-10 14:07 UTC (permalink / raw)
To: Bruce Richardson; +Cc: konstantin.ananyev, dev
In-Reply-To: <20190410134517.63896-3-bruce.richardson@intel.com>
Bruce Richardson <bruce.richardson@intel.com> writes:
> Weak functions don't work well with static libraries and require the use of
> "whole-archive" flag to ensure that the correct function is used when
> linking. Since the weak function is only used as a placeholder within this
> library alone, we can replace it with a non-weak version protected using
> preprocessor ifdefs.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
I agree with dropping the weak implementations.
But, can't we adjust the order of objects when building with multiple
strong definitions and the linker will choose the first? I know this
works for the GNU linker.
I do find this information to help support this statement:
https://stackoverflow.com/questions/51656838/attribute-weak-and-static-libraries
Unfortunately, I don't find anything in the C standard to govern entity
precedence. This means it isn't something that works across linker
implementations (but compatible implementations like clang will maintain
that behavior).
> lib/librte_bpf/bpf_load.c | 4 +++-
> lib/librte_bpf/meson.build | 1 +
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_bpf/bpf_load.c b/lib/librte_bpf/bpf_load.c
> index d9d163b7d..194103ec7 100644
> --- a/lib/librte_bpf/bpf_load.c
> +++ b/lib/librte_bpf/bpf_load.c
> @@ -131,7 +131,8 @@ rte_bpf_load(const struct rte_bpf_prm *prm)
> return bpf;
> }
>
> -__rte_experimental __rte_weak struct rte_bpf *
> +#ifndef RTE_LIBRTE_BPF_ELF
> +__rte_experimental struct rte_bpf *
> rte_bpf_elf_load(const struct rte_bpf_prm *prm, const char *fname,
> const char *sname)
> {
> @@ -146,3 +147,4 @@ rte_bpf_elf_load(const struct rte_bpf_prm *prm, const char *fname,
> rte_errno = ENOTSUP;
> return NULL;
> }
> +#endif
> diff --git a/lib/librte_bpf/meson.build b/lib/librte_bpf/meson.build
> index 8a79878ff..11c1fb558 100644
> --- a/lib/librte_bpf/meson.build
> +++ b/lib/librte_bpf/meson.build
> @@ -20,6 +20,7 @@ deps += ['mbuf', 'net', 'ethdev']
>
> dep = dependency('libelf', required: false)
> if dep.found()
> + dpdk_conf.set('RTE_LIBRTE_BPF_ELF', 1)
> sources += files('bpf_load_elf.c')
> ext_deps += dep
> endif
^ permalink raw reply
* Re: [PATCH] of: Improve of_phandle_iterator_next() error message
From: Rob Herring @ 2019-04-10 14:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE
In-Reply-To: <20190403175633.1839-1-f.fainelli@gmail.com>
On Wed, Apr 03, 2019 at 10:56:33AM -0700, Florian Fainelli wrote:
> Understanding why of_phandle_iterator_next() returns an error can
> sometimes be hard to decipher based solely on the error message, a
> typical error example is that #foo-cells = <X> and the phandle property
> used has a smaller number of cells specified, e.g.:
>
> #thermal-sensor-cells = <1>;
> phandle = <&scmi_sensor>
>
> instead of:
>
> phandle <&scmi_sensor 0>;
>
> Instead, make it clear what the expectations are towards debugging
> incorrect Device Tree faster:
>
> OF: /thermal-zones/scmi-thermal: #thermal-sensor-cells = 1, found 0 instead
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/of/base.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Applied.
Rob
^ permalink raw reply
* Re: How can I change Vendor name LIO-ORG
From: Özkan Göksu @ 2019-04-10 14:07 UTC (permalink / raw)
To: target-devel
In-Reply-To: <CAPUHmCreBhAa7Dzr+6pkYXyifXnRQfXt39KLHMVCer9jd+Lh3A@mail.gmail.com>
Thank you for the answer.
Currently I'm using "14.14.71-1-lts #1 SMP Thu Sep 20 20:14:07 CEST
2018" and I need to upgrade for this change.
I will upgrade my kernel and re-answer again.
Regards.
David Disseldorp <ddiss@suse.de>, 10 Nis 2019 Çar, 16:25 tarihinde şunu yazdı:
>
> Hi,
>
> On Wed, 10 Apr 2019 15:43:47 +0300, Özkan Göksu wrote:
>
> > Hello.
> >
> > I couldn't find any way to change LIO-SCSI Vendor name which is shown
> > as LIO-ORG when we attached to client.
> > I do not want to re-compile kernel with the changing hard-coded Vendor name.
> >
> > If there is any way to change it, please can you show me the way?
>
> This functionality was added recently via:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54a6f3f6a43cf5a5ad0421e4440a4c7095e7a223
>
> With this change (and 2d882847280e3ae1ddc95175d0fc2006e11bb63f), you
> can change the vendor ID via the configfs path at:
> target/core/$backstore/$name/wwn/vendor_id
>
> Cheers, David
^ permalink raw reply
* [PATCH v1] rtc: rx8025: Fix a parameter to %ptR in rx8025_read_alarm()
From: Andy Shevchenko @ 2019-04-10 14:05 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, linux-rtc, Dan Carpenter
Cc: Andy Shevchenko
The commit 1921cab11723 ("rtc: rx8025: Switch to use %ptR") converted
the driver to use new %p extension, but actually used wrong type of
the parameter in one case.
Fix a parameter to %ptR in rx8025_read_alarm().
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/rtc/rtc-rx8025.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-rx8025.c b/drivers/rtc/rtc-rx8025.c
index 41de38acc570..fddc996cb38d 100644
--- a/drivers/rtc/rtc-rx8025.c
+++ b/drivers/rtc/rtc-rx8025.c
@@ -311,7 +311,7 @@ static int rx8025_read_alarm(struct device *dev, struct rtc_wkalrm *t)
t->time.tm_hour = bcd2bin(ald[1] & 0x1f) % 12
+ (ald[1] & 0x20 ? 12 : 0);
- dev_dbg(dev, "%s: date: %ptRr\n", __func__, t);
+ dev_dbg(dev, "%s: date: %ptRr\n", __func__, &t->time);
t->enabled = !!(rx8025->ctrl1 & RX8025_BIT_CTRL1_DALE);
t->pending = (ctrl2 & RX8025_BIT_CTRL2_DAFG) && t->enabled;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 3/3] drm/amdgpu: Avoid HW reset if guilty job already signaled.
From: Christian König @ 2019-04-10 14:06 UTC (permalink / raw)
To: Grodzovsky, Andrey, Koenig, Christian,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
etnaviv-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org
In-Reply-To: <209e53f7-5842-1f34-f9bb-a800670b31fe-5C7GfCeVMHo@public.gmane.org>
Am 09.04.19 um 18:42 schrieb Grodzovsky, Andrey:
> On 4/9/19 10:50 AM, Christian König wrote:
>> Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
>>> Also reject TDRs if another one already running.
>>>
>>> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 94
>>> +++++++++++++++++++++---------
>>> 1 file changed, 67 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> index aabd043..4446892 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> @@ -3327,10 +3327,12 @@ bool amdgpu_device_should_recover_gpu(struct
>>> amdgpu_device *adev)
>>> static int amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
>>> struct amdgpu_job *job,
>>> - bool *need_full_reset_arg)
>>> + bool *need_full_reset_arg,
>>> + bool *job_signaled)
>>> {
>>> int i, r = 0;
>>> bool need_full_reset = *need_full_reset_arg;
>>> + struct amdgpu_ring *job_ring = job ?
>>> to_amdgpu_ring(job->base.sched) : NULL;
>>> /* block all schedulers and reset given job's ring */
>>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>>> @@ -3341,6 +3343,17 @@ static int amdgpu_device_pre_asic_reset(struct
>>> amdgpu_device *adev,
>>> drm_sched_stop(&ring->sched, &job->base);
>>> + /*
>>> + * Must check guilty signal here since after this point all old
>>> + * HW fences are force signaled.
>>> + *
>>> + * job->base holds a reference to parent fence
>>> + */
>>> + if (job_signaled && job && ring == job_ring &&
>>> + job->base.s_fence->parent &&
>>> + dma_fence_is_signaled(job->base.s_fence->parent))
>>> + *job_signaled = true;
>>> +
>> That won't work correctly. See when the guilty job is not on the first
>> scheduler, you would already have force completed some before getting
>> here.
>>
>> Better to stop all schedulers first and then do the check.
>>
>> Christian.
>
> What do you mean by first scheduler ? There is one scheduler object per
> ring so I am not clear what 'first' means here.
Well for example if the guilty job is from a compute ring the we have
already force signaled the gfx ring here.
Same is true for other devices in the same hive, so it would probably be
a good idea to move the force signaling and the IP reset somewhere else
and this check up a layer.
Christian.
>
> Andrey
>
>
>>> /* after all hw jobs are reset, hw fence is meaningless, so
>>> force_completion */
>>> amdgpu_fence_driver_force_completion(ring);
>>> }
>>> @@ -3358,7 +3371,8 @@ static int amdgpu_device_pre_asic_reset(struct
>>> amdgpu_device *adev,
>>> - if (!amdgpu_sriov_vf(adev)) {
>>> + /* Don't suspend on bare metal if we are not going to HW reset
>>> the ASIC */
>>> + if (!amdgpu_sriov_vf(adev) && !(*job_signaled)) {
>>> if (!need_full_reset)
>>> need_full_reset = amdgpu_device_ip_need_full_reset(adev);
>>> @@ -3495,7 +3509,7 @@ static int amdgpu_do_asic_reset(struct
>>> amdgpu_hive_info *hive,
>>> return r;
>>> }
>>> -static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>>> +static void amdgpu_device_post_asic_reset(struct amdgpu_device
>>> *adev, bool job_signaled)
>>> {
>>> int i;
>>> @@ -3505,7 +3519,8 @@ static void
>>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>>> if (!ring || !ring->sched.thread)
>>> continue;
>>> - if (!adev->asic_reset_res)
>>> + /* No point to resubmit jobs if we didn't HW reset*/
>>> + if (!adev->asic_reset_res && !job_signaled)
>>> drm_sched_resubmit_jobs(&ring->sched);
>>> drm_sched_start(&ring->sched, !adev->asic_reset_res);
>>> @@ -3518,14 +3533,21 @@ static void
>>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>>> adev->asic_reset_res = 0;
>>> }
>>> -static void amdgpu_device_lock_adev(struct amdgpu_device *adev)
>>> +static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool
>>> trylock)
>>> {
>>> - mutex_lock(&adev->lock_reset);
>>> + if (trylock) {
>>> + if (!mutex_trylock(&adev->lock_reset))
>>> + return false;
>>> + } else
>>> + mutex_lock(&adev->lock_reset);
>>> +
>>> atomic_inc(&adev->gpu_reset_counter);
>>> adev->in_gpu_reset = 1;
>>> /* Block kfd: SRIOV would do it separately */
>>> if (!amdgpu_sriov_vf(adev))
>>> amdgpu_amdkfd_pre_reset(adev);
>>> +
>>> + return true;
>>> }
>>> static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
>>> @@ -3555,29 +3577,44 @@ int amdgpu_device_gpu_recover(struct
>>> amdgpu_device *adev,
>>> {
>>> int r;
>>> struct amdgpu_hive_info *hive = NULL;
>>> - bool need_full_reset = false;
>>> struct amdgpu_device *tmp_adev = NULL;
>>> struct list_head device_list, *device_list_handle = NULL;
>>> + bool xgmi_topology_present, need_full_reset, job_signaled;
>>> + need_full_reset = job_signaled = false;
>>> INIT_LIST_HEAD(&device_list);
>>> dev_info(adev->dev, "GPU reset begin!\n");
>>> + hive = amdgpu_get_xgmi_hive(adev, 0);
>>> + xgmi_topology_present = hive &&
>>> adev->gmc.xgmi.num_physical_nodes > 1;
>>> +
>>> /*
>>> - * In case of XGMI hive disallow concurrent resets to be triggered
>>> - * by different nodes. No point also since the one node already
>>> executing
>>> - * reset will also reset all the other nodes in the hive.
>>> + * Here we trylock to avoid chain of resets executing from
>>> + * either trigger by jobs on different adevs in XGMI hive or
>>> jobs on
>>> + * different schedulers for same device while this tdr is running.
>>> + * We always reset all schedulers for device and all devices for
>>> XGMI
>>> + * hive so that should take care of them too.
>>> */
>>> - hive = amdgpu_get_xgmi_hive(adev, 0);
>>> - if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
>>> - !mutex_trylock(&hive->reset_lock))
>>> +
>>> + if (xgmi_topology_present && !mutex_trylock(&hive->reset_lock)) {
>>> + DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as
>>> another already in progress",
>>> + job->base.id, hive->hive_id);
>>> return 0;
>>> + }
>>> /* Start with adev pre asic reset first for soft reset check.*/
>>> - amdgpu_device_lock_adev(adev);
>>> + if (!amdgpu_device_lock_adev(adev, !xgmi_topology_present)) {
>>> + DRM_INFO("Bailing on TDR for s_job:%llx, as another already
>>> in progress",
>>> + job->base.id);
>>> + return 0;
>>> + }
>>> +
>>> + /* Guilty job will be freed after this*/
>>> r = amdgpu_device_pre_asic_reset(adev,
>>> job,
>>> - &need_full_reset);
>>> + &need_full_reset,
>>> + &job_signaled);
>>> if (r) {
>>> /*TODO Should we stop ?*/
>>> DRM_ERROR("GPU pre asic reset failed with err, %d for drm
>>> dev, %s ",
>>> @@ -3609,10 +3646,11 @@ int amdgpu_device_gpu_recover(struct
>>> amdgpu_device *adev,
>>> if (tmp_adev == adev)
>>> continue;
>>> - amdgpu_device_lock_adev(tmp_adev);
>>> + amdgpu_device_lock_adev(tmp_adev, false);
>>> r = amdgpu_device_pre_asic_reset(tmp_adev,
>>> NULL,
>>> - &need_full_reset);
>>> + &need_full_reset,
>>> + &job_signaled);
>>> /*TODO Should we stop ?*/
>>> if (r) {
>>> DRM_ERROR("GPU pre asic reset failed with err, %d for
>>> drm dev, %s ",
>>> @@ -3623,19 +3661,21 @@ int amdgpu_device_gpu_recover(struct
>>> amdgpu_device *adev,
>>> /* Actual ASIC resets if needed.*/
>>> /* TODO Implement XGMI hive reset logic for SRIOV */
>>> - if (amdgpu_sriov_vf(adev)) {
>>> - r = amdgpu_device_reset_sriov(adev, job ? false : true);
>>> - if (r)
>>> - adev->asic_reset_res = r;
>>> - } else {
>>> - r = amdgpu_do_asic_reset(hive, device_list_handle,
>>> &need_full_reset);
>>> - if (r && r == -EAGAIN)
>>> - goto retry;
>>> + if (!job || !job_signaled) {
>>> + if (amdgpu_sriov_vf(adev)) {
>>> + r = amdgpu_device_reset_sriov(adev, job ? false : true);
>>> + if (r)
>>> + adev->asic_reset_res = r;
>>> + } else {
>>> + r = amdgpu_do_asic_reset(hive, device_list_handle,
>>> &need_full_reset);
>>> + if (r && r == -EAGAIN)
>>> + goto retry;
>>> + }
>>> }
>>> /* Post ASIC reset for all devs .*/
>>> list_for_each_entry(tmp_adev, device_list_handle, gmc.xgmi.head) {
>>> - amdgpu_device_post_asic_reset(tmp_adev);
>>> + amdgpu_device_post_asic_reset(tmp_adev, job_signaled);
>>> if (r) {
>>> /* bad news, how to tell it to userspace ? */
>>> @@ -3648,7 +3688,7 @@ int amdgpu_device_gpu_recover(struct
>>> amdgpu_device *adev,
>>> amdgpu_device_unlock_adev(tmp_adev);
>>> }
>>> - if (hive && adev->gmc.xgmi.num_physical_nodes > 1)
>>> + if (xgmi_topology_present)
>>> mutex_unlock(&hive->reset_lock);
>>> if (r)
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* [PATCH -next] memory: tegra: Make terga20_mc_reset_ops static
From: Yue Haibing @ 2019-04-10 14:04 UTC (permalink / raw)
To: thierry.reding, jonathanh, digetx, jroedel
Cc: linux-kernel, linux-tegra, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
Fix sparse warning:
drivers/memory/tegra/tegra20.c:277:33: warning:
symbol 'terga20_mc_reset_ops' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/memory/tegra/tegra20.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/tegra/tegra20.c b/drivers/memory/tegra/tegra20.c
index 7119e53..b786aec 100644
--- a/drivers/memory/tegra/tegra20.c
+++ b/drivers/memory/tegra/tegra20.c
@@ -274,7 +274,7 @@ static int terga20_mc_unblock_dma(struct tegra_mc *mc,
return 0;
}
-const struct tegra_mc_reset_ops terga20_mc_reset_ops = {
+static const struct tegra_mc_reset_ops terga20_mc_reset_ops = {
.hotreset_assert = terga20_mc_hotreset_assert,
.hotreset_deassert = terga20_mc_hotreset_deassert,
.block_dma = terga20_mc_block_dma,
--
2.7.4
^ permalink raw reply related
* Re: [dpdk-dev] [PATCH v4 2/3] test/distributor: replace sync builtins with atomic builtins
From: Hunt, David @ 2019-04-10 14:05 UTC (permalink / raw)
To: Phil Yang, dev, thomas; +Cc: reshma.pattan, gavin.hu, honnappa.nagarahalli, nd
In-Reply-To: <1554692551-28275-3-git-send-email-phil.yang@arm.com>
Hi Phil,
On 8/4/2019 4:02 AM, Phil Yang wrote:
> '__sync' built-in functions are deprecated, should use the '__atomic'
> built-in instead. the sync built-in functions are full barriers, while
> atomic built-in functions offer less restrictive one-way barriers,
> which help performance.
>
> Here is the example test result on TX2:
> sudo ./arm64-armv8a-linuxapp-gcc/app/test -l 112-139 \
> -n 4 --socket-mem=1024,1024 -- -i
> RTE>>distributor_perf_autotest
>
> *** distributor_perf_autotest without this patch ***
> ==== Cache line switch test ===
> Time for 33554432 iterations = 1519202730 ticks
> Ticks per iteration = 45
>
> *** distributor_perf_autotest with this patch ***
> ==== Cache line switch test ===
> Time for 33554432 iterations = 1251715496 ticks
> Ticks per iteration = 37
>
> Less ticks needed for the cache line switch test. It got 17% of
> performance improvement.
I'm seeing about an 8% performance degradation on my platform for the
cache line switch test with the patch, however the single mode and burst
mode tests area showing no difference, which are the more important
tests. What kind of differences are you seeing in the single/burst mode
tests?
Rgds,
Dave.
---snip---
^ permalink raw reply
* RE: [PATCH 2/2] spi: pxa2xx: use a module softdep for dw_dmac
From: Flavio Suligoi @ 2019-04-10 14:05 UTC (permalink / raw)
To: Mark Brown
Cc: linux-kernel@vger.kernel.org, Haojian Zhuang,
linux-spi@vger.kernel.org, Daniel Mack, Robert Jarzmik,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190410125612.GR6106@sirena.org.uk>
Hi Mark,
> On Wed, Apr 10, 2019 at 02:51:36PM +0200, Flavio Suligoi wrote:
> > With dw_dmac, sometimes the request of a DMA channel fails because
> > the DMA driver is not ready, so an explicit dependency request
> > is necessary.
>
> While this isn't going to hurt anything and might actually help so it's
> fine doesn't this also suggest that there's an issue with deferred probe
> going on as well?
I think that the problem could be related to how the DMA channel is requested.
At the moment the function used are:
pxa2xx_spi_dma_setup --> dma_request_slave_channel_compat -->
--> __dma_request_slave_channel_compat --> dma_request_slave_channel -->
--> dma_request_chan
Actually the final function "dma_request_chan" return
the channel number or "-EPROBE_DEFER" if it's not ready.
But this information ("-EPROBE_DEFER") is lost in the penultimate function
"dma_request_slave_channel", which return only the chann, if all is ok, or
NULL, in case of errors.
So the deferral mechanism is not used.
Flavio
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 2/2] spi: pxa2xx: use a module softdep for dw_dmac
From: Flavio Suligoi @ 2019-04-10 14:05 UTC (permalink / raw)
To: Mark Brown
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik,
linux-arm-kernel@lists.infradead.org, linux-spi@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190410125612.GR6106@sirena.org.uk>
Hi Mark,
> On Wed, Apr 10, 2019 at 02:51:36PM +0200, Flavio Suligoi wrote:
> > With dw_dmac, sometimes the request of a DMA channel fails because
> > the DMA driver is not ready, so an explicit dependency request
> > is necessary.
>
> While this isn't going to hurt anything and might actually help so it's
> fine doesn't this also suggest that there's an issue with deferred probe
> going on as well?
I think that the problem could be related to how the DMA channel is requested.
At the moment the function used are:
pxa2xx_spi_dma_setup --> dma_request_slave_channel_compat -->
--> __dma_request_slave_channel_compat --> dma_request_slave_channel -->
--> dma_request_chan
Actually the final function "dma_request_chan" return
the channel number or "-EPROBE_DEFER" if it's not ready.
But this information ("-EPROBE_DEFER") is lost in the penultimate function
"dma_request_slave_channel", which return only the chann, if all is ok, or
NULL, in case of errors.
So the deferral mechanism is not used.
Flavio
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH] media: omap_vout: potential buffer overflow in vidioc_dqbuf()
From: Scheurer, Amber @ 2019-04-10 14:05 UTC (permalink / raw)
To: Dan Carpenter, Hans Verkuil
Cc: Mauro Carvalho Chehab, Niklas Söderlund, Philipp Zabel,
Parrot, Benoit, linux-media@vger.kernel.org,
kernel-janitors@vger.kernel.org, Andrzej Hajda
In-Reply-To: <20190410111415.GB31633@kadam>
I think you might have the wrong Amber copied on this email.
Amber
-----Original Message-----
From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
Sent: Wednesday, April 10, 2019 6:14 AM
To: Hans Verkuil
Cc: Mauro Carvalho Chehab; Scheurer, Amber; Niklas Söderlund; Philipp Zabel; Parrot, Benoit; linux-media@vger.kernel.org; kernel-janitors@vger.kernel.org; Andrzej Hajda
Subject: [EXTERNAL] Re: [PATCH] media: omap_vout: potential buffer overflow in vidioc_dqbuf()
On Wed, Apr 10, 2019 at 12:50:31PM +0200, Hans Verkuil wrote:
> On 4/9/19 1:29 PM, Dan Carpenter wrote:
> > diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
> > index 37f0d7146dfa..15e38990e85a 100644
> > --- a/drivers/media/platform/omap/omap_vout.c
> > +++ b/drivers/media/platform/omap/omap_vout.c
> > @@ -1527,8 +1527,6 @@ static int vidioc_dqbuf(struct file *file, void *fh, struct v4l2_buffer *b)
> > unsigned long size;
> > struct videobuf_buffer *vb;
> >
> > - vb = q->bufs[b->index];
> > -
> > if (!vout->streaming)
> > return -EINVAL;
> >
> > @@ -1539,6 +1537,8 @@ static int vidioc_dqbuf(struct file *file, void *fh, struct v4l2_buffer *b)
> > /* Call videobuf_dqbuf for blocking mode */
> > ret = videobuf_dqbuf(q, (struct v4l2_buffer *)b, 0);
>
> We need a:
>
> if (ret)
> return ret;
>
> here. Or alternatively, add 'if (!ret)' around the next five lines.
>
> b->index is only valid if the videobuf_dqbuf call returned 0.
>
Doh. Thanks.
regards,
dan carpenter
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.