* [dpdk-dev] [PATCH v2 0/5] support switch management
From: Xiaojun Liu @ 2020-02-20 13:59 UTC (permalink / raw)
To: xiao.w.wang, qi.z.zhang, ngai-mint.kwan, jacob.e.keller; +Cc: dev, Xiaojun Liu
In-Reply-To: <1576057875-7677-2-git-send-email-xiaojun.liu@silicom.co.il>
To avoid configuration for both kernel driver
and userspace SDK outside DPDK, we add switch
management in FM10K DPDK PMD driver.
Split dev init to 2 parts.
First only register the port in switch
management; second init hook will be
called after all the pf are registered
and switch initialization. It will finish
dev init. Also add switch interrupt support.
Add fm10k_mirror_rule_set/fm10k_mirror_rule_reset
to support mirror operation. Add fm10k_dev_filter_ctrl
to support flow operation.
Add dpdk port and pf mapping, so
the dpdk port can map to a specific pf
and 1 dpdk port can map to 2 pf to get
total 100G throughput.
Add flow interface to support offload flow into HW.
It supports parse vlan and parse mpls, all these
data will be transffered to ffu data.
Add switch management, includes initialization,
port mapping, epl port link, LED controller, interrupt handler.
It create 3 threads. One for interrupt handler, one for
LED controller, one for statistics.
Add ffu to support offload flow into HW.
It supports forward, mirror, push VLAN, pop VLAN.
It also supports flowset for a group flow definition.
The config file can configure debug log, port speed,
epl port mapping dpdk port, flowset. All these configuration
will be used by switch management.
Statistics includes epl port, ffu rule, dpdk port, and error.
All these statistics data are read from HW.
Modify switch header file to support getting logical port
and glort and device info.
Add epl serdes include loading spico,
controling pcsl, dma, dfe, ical. Add spico code.
Add state machine for epl lane and port, it creates
a pthread to handle the state changing event.
Add external port management, which will use
state machine to handle the event from lane and port.
The lane state will change between DOWN, WAIT_PLL_LOCK,
WAIT_SIGNAL_OK, WAIT_DFE_ICAL, WAIT_DFE_PCAL, UP.
The port state will change between DOWN, WAIT_LANE_UP, UP.
Add I2C to control the inside LED and PHY.
All the operations of I2C are using fm10k I2C register.
Add SBUS to communicate with spico(micro code in serdes)
by using fm10k SBUS register. This is like I2C operations.
Add registers defination, which include all the registers
will be used in the driver. Add switch management log API.
Add switch management structures. Modify Makefile to add
new files building
Xiaojun Liu (5):
net/fm10k: add basic functions for switch management
net/fm10k: add epl serdes and port control functions
net/fm10k: add ffu and statistics and config file functions
net/fm10k: add flow interface and switch management
net/fm10k: add switch management support
drivers/net/fm10k/Makefile | 25 +
drivers/net/fm10k/fm10k_ethdev.c | 587 +++++-
drivers/net/fm10k/switch/fm10k_config.c | 863 ++++++++
drivers/net/fm10k/switch/fm10k_config.h | 178 ++
drivers/net/fm10k/switch/fm10k_debug.h | 19 +
drivers/net/fm10k/switch/fm10k_ext_port.c | 841 ++++++++
drivers/net/fm10k/switch/fm10k_ext_port.h | 136 ++
drivers/net/fm10k/switch/fm10k_ffu.c | 1253 +++++++++++
drivers/net/fm10k/switch/fm10k_ffu.h | 31 +
drivers/net/fm10k/switch/fm10k_flow.c | 872 ++++++++
drivers/net/fm10k/switch/fm10k_flow.h | 26 +
drivers/net/fm10k/switch/fm10k_i2c.c | 310 +++
drivers/net/fm10k/switch/fm10k_i2c.h | 54 +
drivers/net/fm10k/switch/fm10k_regs.h | 2302 +++++++++++++++++++++
drivers/net/fm10k/switch/fm10k_sbus.c | 292 +++
drivers/net/fm10k/switch/fm10k_sbus.h | 40 +
drivers/net/fm10k/switch/fm10k_serdes.c | 1936 +++++++++++++++++
drivers/net/fm10k/switch/fm10k_serdes.h | 32 +
drivers/net/fm10k/switch/fm10k_sm.c | 190 ++
drivers/net/fm10k/switch/fm10k_sm.h | 81 +
drivers/net/fm10k/switch/fm10k_spico_code.c | 2966 +++++++++++++++++++++++++++
drivers/net/fm10k/switch/fm10k_spico_code.h | 21 +
drivers/net/fm10k/switch/fm10k_stats.c | 1242 +++++++++++
drivers/net/fm10k/switch/fm10k_stats.h | 257 +++
drivers/net/fm10k/switch/fm10k_switch.c | 2376 +++++++++++++++++++++
drivers/net/fm10k/switch/fm10k_switch.h | 475 +++++
26 files changed, 17364 insertions(+), 41 deletions(-)
create mode 100644 drivers/net/fm10k/switch/fm10k_config.c
create mode 100644 drivers/net/fm10k/switch/fm10k_config.h
create mode 100644 drivers/net/fm10k/switch/fm10k_debug.h
create mode 100644 drivers/net/fm10k/switch/fm10k_ext_port.c
create mode 100644 drivers/net/fm10k/switch/fm10k_ext_port.h
create mode 100644 drivers/net/fm10k/switch/fm10k_ffu.c
create mode 100644 drivers/net/fm10k/switch/fm10k_ffu.h
create mode 100644 drivers/net/fm10k/switch/fm10k_flow.c
create mode 100644 drivers/net/fm10k/switch/fm10k_flow.h
create mode 100644 drivers/net/fm10k/switch/fm10k_i2c.c
create mode 100644 drivers/net/fm10k/switch/fm10k_i2c.h
create mode 100644 drivers/net/fm10k/switch/fm10k_regs.h
create mode 100644 drivers/net/fm10k/switch/fm10k_sbus.c
create mode 100644 drivers/net/fm10k/switch/fm10k_sbus.h
create mode 100644 drivers/net/fm10k/switch/fm10k_serdes.c
create mode 100644 drivers/net/fm10k/switch/fm10k_serdes.h
create mode 100644 drivers/net/fm10k/switch/fm10k_sm.c
create mode 100644 drivers/net/fm10k/switch/fm10k_sm.h
create mode 100644 drivers/net/fm10k/switch/fm10k_spico_code.c
create mode 100644 drivers/net/fm10k/switch/fm10k_spico_code.h
create mode 100644 drivers/net/fm10k/switch/fm10k_stats.c
create mode 100644 drivers/net/fm10k/switch/fm10k_stats.h
create mode 100644 drivers/net/fm10k/switch/fm10k_switch.c
create mode 100644 drivers/net/fm10k/switch/fm10k_switch.h
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH 5/6] drm/panel: simple: Add NewEast Optoelectronics CO., LTD WJFH116008A panel support
From: Laurent Pinchart @ 2020-02-20 13:59 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, Neil Armstrong, David Airlie, Linus Walleij,
dri-devel, Andrzej Hajda, Thierry Reding, Sam Ravnborg,
Stephen Rothwell, Samuel Holland, Heiko Stuebner, Chen-Yu Tsai,
Icenowy Zheng, Stephan Gerhold, Jonas Karlman, Torsten Duwe,
Rob Herring, Maxime Ripard, linux-arm-kernel, Jernej Skrabec,
linux-kernel, Mark Brown, Daniel Vetter
In-Reply-To: <20200220083508.792071-6-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:07AM -0800, Vasily Khoruzhick wrote:
> This commit adds support for the NewEast Optoelectronics CO., LTD
> WJFH116008A 11.6" 1920x1080 TFT LCD panel.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 47 ++++++++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index e14c14ac62b5..aa04afaf3d26 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2224,6 +2224,50 @@ static const struct panel_desc netron_dy_e231732 = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> };
>
> +static const struct drm_display_mode neweast_wjfh116008a_modes[] = {
> +{
> + .clock = 138500,
> + .hdisplay = 1920,
> + .hsync_start = 1920 + 48,
> + .hsync_end = 1920 + 48 + 32,
> + .htotal = 1920 + 48 + 32 + 80,
> + .vdisplay = 1080,
> + .vsync_start = 1080 + 3,
> + .vsync_end = 1080 + 3 + 5,
> + .vtotal = 1080 + 3 + 5 + 23,
> + .vrefresh = 60,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +}, {
> + .clock = 110920,
> + .hdisplay = 1920,
> + .hsync_start = 1920 + 48,
> + .hsync_end = 1920 + 48 + 32,
> + .htotal = 1920 + 48 + 32 + 80,
> + .vdisplay = 1080,
> + .vsync_start = 1080 + 3,
> + .vsync_end = 1080 + 3 + 5,
> + .vtotal = 1080 + 3 + 5 + 23,
> + .vrefresh = 48,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +} };
This should be indented one step to the right, see boe_nv101wxmn51_modes
for instance.
The only different between the two modes is the clock, leading to
different refresh rates. Are only those two clock frequencies supported,
or does the panel support anything in-between as well ? In the latter
case, would it make sense to use display_timing instead of
drm_display_mode ? See dlc_dlc0700yzg_1_timing for an example.
> +
> +static const struct panel_desc neweast_wjfh116008a = {
> + .modes = neweast_wjfh116008a_modes,
> + .num_modes = 2,
> + .bpc = 6,
> + .size = {
> + .width = 260,
> + .height = 150,
> + },
> + .delay = {
> + .prepare = 110,
> + .enable = 20,
> + .unprepare = 500,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> + .connector_type = DRM_MODE_CONNECTOR_eDP,
> +};
> +
> static const struct drm_display_mode newhaven_nhd_43_480272ef_atxl_mode = {
> .clock = 9000,
> .hdisplay = 480,
> @@ -3399,6 +3443,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "netron-dy,e231732",
> .data = &netron_dy_e231732,
> + }, {
> + .compatible = "neweast,wjfh116008a",
> + .data = &neweast_wjfh116008a,
> }, {
> .compatible = "newhaven,nhd-4.3-480272ef-atxl",
> .data = &newhaven_nhd_43_480272ef_atxl,
--
Regards,
Laurent Pinchart
_______________________________________________
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 5/6] drm/panel: simple: Add NewEast Optoelectronics CO., LTD WJFH116008A panel support
From: Laurent Pinchart @ 2020-02-20 13:59 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Thierry Reding, Sam Ravnborg, David Airlie, Daniel Vetter,
Rob Herring, Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec,
Icenowy Zheng, Torsten Duwe, Heiko Stuebner, Linus Walleij,
Stephan Gerhold, Mark Brown, Stephen Rothwell, Samuel Holland,
dri-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20200220083508.792071-6-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:07AM -0800, Vasily Khoruzhick wrote:
> This commit adds support for the NewEast Optoelectronics CO., LTD
> WJFH116008A 11.6" 1920x1080 TFT LCD panel.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 47 ++++++++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index e14c14ac62b5..aa04afaf3d26 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2224,6 +2224,50 @@ static const struct panel_desc netron_dy_e231732 = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> };
>
> +static const struct drm_display_mode neweast_wjfh116008a_modes[] = {
> +{
> + .clock = 138500,
> + .hdisplay = 1920,
> + .hsync_start = 1920 + 48,
> + .hsync_end = 1920 + 48 + 32,
> + .htotal = 1920 + 48 + 32 + 80,
> + .vdisplay = 1080,
> + .vsync_start = 1080 + 3,
> + .vsync_end = 1080 + 3 + 5,
> + .vtotal = 1080 + 3 + 5 + 23,
> + .vrefresh = 60,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +}, {
> + .clock = 110920,
> + .hdisplay = 1920,
> + .hsync_start = 1920 + 48,
> + .hsync_end = 1920 + 48 + 32,
> + .htotal = 1920 + 48 + 32 + 80,
> + .vdisplay = 1080,
> + .vsync_start = 1080 + 3,
> + .vsync_end = 1080 + 3 + 5,
> + .vtotal = 1080 + 3 + 5 + 23,
> + .vrefresh = 48,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +} };
This should be indented one step to the right, see boe_nv101wxmn51_modes
for instance.
The only different between the two modes is the clock, leading to
different refresh rates. Are only those two clock frequencies supported,
or does the panel support anything in-between as well ? In the latter
case, would it make sense to use display_timing instead of
drm_display_mode ? See dlc_dlc0700yzg_1_timing for an example.
> +
> +static const struct panel_desc neweast_wjfh116008a = {
> + .modes = neweast_wjfh116008a_modes,
> + .num_modes = 2,
> + .bpc = 6,
> + .size = {
> + .width = 260,
> + .height = 150,
> + },
> + .delay = {
> + .prepare = 110,
> + .enable = 20,
> + .unprepare = 500,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> + .connector_type = DRM_MODE_CONNECTOR_eDP,
> +};
> +
> static const struct drm_display_mode newhaven_nhd_43_480272ef_atxl_mode = {
> .clock = 9000,
> .hdisplay = 480,
> @@ -3399,6 +3443,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "netron-dy,e231732",
> .data = &netron_dy_e231732,
> + }, {
> + .compatible = "neweast,wjfh116008a",
> + .data = &neweast_wjfh116008a,
> }, {
> .compatible = "newhaven,nhd-4.3-480272ef-atxl",
> .data = &newhaven_nhd_43_480272ef_atxl,
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 5/6] drm/panel: simple: Add NewEast Optoelectronics CO., LTD WJFH116008A panel support
From: Laurent Pinchart @ 2020-02-20 13:59 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, Neil Armstrong, David Airlie, dri-devel,
Andrzej Hajda, Thierry Reding, Sam Ravnborg, Stephen Rothwell,
Samuel Holland, Heiko Stuebner, Chen-Yu Tsai, Icenowy Zheng,
Stephan Gerhold, Jonas Karlman, Torsten Duwe, Rob Herring,
Maxime Ripard, linux-arm-kernel, Jernej Skrabec, linux-kernel,
Mark Brown
In-Reply-To: <20200220083508.792071-6-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:07AM -0800, Vasily Khoruzhick wrote:
> This commit adds support for the NewEast Optoelectronics CO., LTD
> WJFH116008A 11.6" 1920x1080 TFT LCD panel.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 47 ++++++++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index e14c14ac62b5..aa04afaf3d26 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2224,6 +2224,50 @@ static const struct panel_desc netron_dy_e231732 = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> };
>
> +static const struct drm_display_mode neweast_wjfh116008a_modes[] = {
> +{
> + .clock = 138500,
> + .hdisplay = 1920,
> + .hsync_start = 1920 + 48,
> + .hsync_end = 1920 + 48 + 32,
> + .htotal = 1920 + 48 + 32 + 80,
> + .vdisplay = 1080,
> + .vsync_start = 1080 + 3,
> + .vsync_end = 1080 + 3 + 5,
> + .vtotal = 1080 + 3 + 5 + 23,
> + .vrefresh = 60,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +}, {
> + .clock = 110920,
> + .hdisplay = 1920,
> + .hsync_start = 1920 + 48,
> + .hsync_end = 1920 + 48 + 32,
> + .htotal = 1920 + 48 + 32 + 80,
> + .vdisplay = 1080,
> + .vsync_start = 1080 + 3,
> + .vsync_end = 1080 + 3 + 5,
> + .vtotal = 1080 + 3 + 5 + 23,
> + .vrefresh = 48,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +} };
This should be indented one step to the right, see boe_nv101wxmn51_modes
for instance.
The only different between the two modes is the clock, leading to
different refresh rates. Are only those two clock frequencies supported,
or does the panel support anything in-between as well ? In the latter
case, would it make sense to use display_timing instead of
drm_display_mode ? See dlc_dlc0700yzg_1_timing for an example.
> +
> +static const struct panel_desc neweast_wjfh116008a = {
> + .modes = neweast_wjfh116008a_modes,
> + .num_modes = 2,
> + .bpc = 6,
> + .size = {
> + .width = 260,
> + .height = 150,
> + },
> + .delay = {
> + .prepare = 110,
> + .enable = 20,
> + .unprepare = 500,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> + .connector_type = DRM_MODE_CONNECTOR_eDP,
> +};
> +
> static const struct drm_display_mode newhaven_nhd_43_480272ef_atxl_mode = {
> .clock = 9000,
> .hdisplay = 480,
> @@ -3399,6 +3443,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "netron-dy,e231732",
> .data = &netron_dy_e231732,
> + }, {
> + .compatible = "neweast,wjfh116008a",
> + .data = &neweast_wjfh116008a,
> }, {
> .compatible = "newhaven,nhd-4.3-480272ef-atxl",
> .data = &newhaven_nhd_43_480272ef_atxl,
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [Bridge] [PATCH][next] netfilter: Replace zero-length array with flexible-array member
From: Gustavo A. R. Silva @ 2020-02-20 13:59 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Roopa Prabhu, Nikolay Aleksandrov, David S. Miller,
Jakub Kicinski, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: Gustavo A. R. Silva, netdev, bridge, linux-kernel, coreteam,
netfilter-devel
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
Lastly, fix checkpatch.pl warning
WARNING: __aligned(size) is preferred over __attribute__((aligned(size)))
in net/bridge/netfilter/ebtables.c
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
include/linux/netfilter/ipset/ip_set.h | 2 +-
include/linux/netfilter/x_tables.h | 8 ++++----
include/linux/netfilter_arp/arp_tables.h | 2 +-
include/linux/netfilter_bridge/ebtables.h | 2 +-
include/linux/netfilter_ipv4/ip_tables.h | 2 +-
include/linux/netfilter_ipv6/ip6_tables.h | 2 +-
include/net/netfilter/nf_conntrack_extend.h | 2 +-
include/net/netfilter/nf_conntrack_timeout.h | 2 +-
include/net/netfilter/nf_tables.h | 6 +++---
include/uapi/linux/netfilter_bridge/ebt_among.h | 2 +-
net/bridge/netfilter/ebtables.c | 2 +-
net/ipv4/netfilter/arp_tables.c | 4 ++--
net/ipv4/netfilter/ip_tables.c | 4 ++--
net/ipv6/netfilter/ip6_tables.c | 4 ++--
net/netfilter/ipset/ip_set_bitmap_ip.c | 2 +-
net/netfilter/ipset/ip_set_bitmap_ipmac.c | 2 +-
net/netfilter/ipset/ip_set_bitmap_port.c | 2 +-
net/netfilter/ipset/ip_set_hash_gen.h | 4 ++--
net/netfilter/nfnetlink_acct.c | 2 +-
net/netfilter/nft_set_pipapo.c | 2 +-
net/netfilter/xt_hashlimit.c | 2 +-
net/netfilter/xt_recent.c | 4 ++--
22 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/include/linux/netfilter/ipset/ip_set.h b/include/linux/netfilter/ipset/ip_set.h
index 908d38dbcb91..155eca0ed68d 100644
--- a/include/linux/netfilter/ipset/ip_set.h
+++ b/include/linux/netfilter/ipset/ip_set.h
@@ -98,7 +98,7 @@ struct ip_set_counter {
struct ip_set_comment_rcu {
struct rcu_head rcu;
- char str[0];
+ char str[];
};
struct ip_set_comment {
diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h
index 1b261c51b3a3..5da88451853b 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -264,7 +264,7 @@ struct xt_table_info {
unsigned int stacksize;
void ***jumpstack;
- unsigned char entries[0] __aligned(8);
+ unsigned char entries[] __aligned(8);
};
int xt_register_target(struct xt_target *target);
@@ -464,7 +464,7 @@ struct compat_xt_entry_match {
} kernel;
u_int16_t match_size;
} u;
- unsigned char data[0];
+ unsigned char data[];
};
struct compat_xt_entry_target {
@@ -480,7 +480,7 @@ struct compat_xt_entry_target {
} kernel;
u_int16_t target_size;
} u;
- unsigned char data[0];
+ unsigned char data[];
};
/* FIXME: this works only on 32 bit tasks
@@ -494,7 +494,7 @@ struct compat_xt_counters {
struct compat_xt_counters_info {
char name[XT_TABLE_MAXNAMELEN];
compat_uint_t num_counters;
- struct compat_xt_counters counters[0];
+ struct compat_xt_counters counters[];
};
struct _compat_xt_align {
diff --git a/include/linux/netfilter_arp/arp_tables.h b/include/linux/netfilter_arp/arp_tables.h
index e98028f00e47..7d3537c40ec9 100644
--- a/include/linux/netfilter_arp/arp_tables.h
+++ b/include/linux/netfilter_arp/arp_tables.h
@@ -67,7 +67,7 @@ struct compat_arpt_entry {
__u16 next_offset;
compat_uint_t comefrom;
struct compat_xt_counters counters;
- unsigned char elems[0];
+ unsigned char elems[];
};
static inline struct xt_entry_target *
diff --git a/include/linux/netfilter_bridge/ebtables.h b/include/linux/netfilter_bridge/ebtables.h
index 162f59d0d17a..2f5c4e6ecd8a 100644
--- a/include/linux/netfilter_bridge/ebtables.h
+++ b/include/linux/netfilter_bridge/ebtables.h
@@ -85,7 +85,7 @@ struct ebt_table_info {
/* room to maintain the stack used for jumping from and into udc */
struct ebt_chainstack **chainstack;
char *entries;
- struct ebt_counter counters[0] ____cacheline_aligned;
+ struct ebt_counter counters[] ____cacheline_aligned;
};
struct ebt_table {
diff --git a/include/linux/netfilter_ipv4/ip_tables.h b/include/linux/netfilter_ipv4/ip_tables.h
index e9e1ed74cdf1..b394bd4f68a3 100644
--- a/include/linux/netfilter_ipv4/ip_tables.h
+++ b/include/linux/netfilter_ipv4/ip_tables.h
@@ -76,7 +76,7 @@ struct compat_ipt_entry {
__u16 next_offset;
compat_uint_t comefrom;
struct compat_xt_counters counters;
- unsigned char elems[0];
+ unsigned char elems[];
};
/* Helper functions */
diff --git a/include/linux/netfilter_ipv6/ip6_tables.h b/include/linux/netfilter_ipv6/ip6_tables.h
index 78ab959c4575..8225f7821a29 100644
--- a/include/linux/netfilter_ipv6/ip6_tables.h
+++ b/include/linux/netfilter_ipv6/ip6_tables.h
@@ -43,7 +43,7 @@ struct compat_ip6t_entry {
__u16 next_offset;
compat_uint_t comefrom;
struct compat_xt_counters counters;
- unsigned char elems[0];
+ unsigned char elems[];
};
static inline struct xt_entry_target *
diff --git a/include/net/netfilter/nf_conntrack_extend.h b/include/net/netfilter/nf_conntrack_extend.h
index 5ae5295aa46d..e1e588387103 100644
--- a/include/net/netfilter/nf_conntrack_extend.h
+++ b/include/net/netfilter/nf_conntrack_extend.h
@@ -45,7 +45,7 @@ enum nf_ct_ext_id {
struct nf_ct_ext {
u8 offset[NF_CT_EXT_NUM];
u8 len;
- char data[0];
+ char data[];
};
static inline bool __nf_ct_ext_exist(const struct nf_ct_ext *ext, u8 id)
diff --git a/include/net/netfilter/nf_conntrack_timeout.h b/include/net/netfilter/nf_conntrack_timeout.h
index 6dd72396f534..659b0ea25b4d 100644
--- a/include/net/netfilter/nf_conntrack_timeout.h
+++ b/include/net/netfilter/nf_conntrack_timeout.h
@@ -14,7 +14,7 @@
struct nf_ct_timeout {
__u16 l3num;
const struct nf_conntrack_l4proto *l4proto;
- char data[0];
+ char data[];
};
struct ctnl_timeout {
diff --git a/include/net/netfilter/nf_tables.h b/include/net/netfilter/nf_tables.h
index 4170c033d461..abcb4c89b0f9 100644
--- a/include/net/netfilter/nf_tables.h
+++ b/include/net/netfilter/nf_tables.h
@@ -224,7 +224,7 @@ int nft_validate_register_store(const struct nft_ctx *ctx,
*/
struct nft_userdata {
u8 len;
- unsigned char data[0];
+ unsigned char data[];
};
/**
@@ -572,7 +572,7 @@ struct nft_set_ext_tmpl {
struct nft_set_ext {
u8 genmask;
u8 offset[NFT_SET_EXT_NUM];
- char data[0];
+ char data[];
};
static inline void nft_set_ext_prepare(struct nft_set_ext_tmpl *tmpl)
@@ -1385,7 +1385,7 @@ struct nft_trans {
int msg_type;
bool put_net;
struct nft_ctx ctx;
- char data[0];
+ char data[];
};
struct nft_trans_rule {
diff --git a/include/uapi/linux/netfilter_bridge/ebt_among.h b/include/uapi/linux/netfilter_bridge/ebt_among.h
index 9acf757bc1f7..73b26a280c4f 100644
--- a/include/uapi/linux/netfilter_bridge/ebt_among.h
+++ b/include/uapi/linux/netfilter_bridge/ebt_among.h
@@ -40,7 +40,7 @@ struct ebt_mac_wormhash_tuple {
struct ebt_mac_wormhash {
int table[257];
int poolsize;
- struct ebt_mac_wormhash_tuple pool[0];
+ struct ebt_mac_wormhash_tuple pool[];
};
#define ebt_mac_wormhash_size(x) ((x) ? sizeof(struct ebt_mac_wormhash) \
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index e1256e03a9a8..78db58c7aec2 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1561,7 +1561,7 @@ struct compat_ebt_entry_mwt {
compat_uptr_t ptr;
} u;
compat_uint_t match_size;
- compat_uint_t data[0] __attribute__ ((aligned (__alignof__(struct compat_ebt_replace))));
+ compat_uint_t data[] __aligned(__alignof__(struct compat_ebt_replace));
};
/* account for possible padding between match_size and ->data */
diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
index f1f78a742b36..b167f4a5b684 100644
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -1057,7 +1057,7 @@ struct compat_arpt_replace {
u32 underflow[NF_ARP_NUMHOOKS];
u32 num_counters;
compat_uptr_t counters;
- struct compat_arpt_entry entries[0];
+ struct compat_arpt_entry entries[];
};
static inline void compat_release_entry(struct compat_arpt_entry *e)
@@ -1383,7 +1383,7 @@ static int compat_copy_entries_to_user(unsigned int total_size,
struct compat_arpt_get_entries {
char name[XT_TABLE_MAXNAMELEN];
compat_uint_t size;
- struct compat_arpt_entry entrytable[0];
+ struct compat_arpt_entry entrytable[];
};
static int compat_get_entries(struct net *net,
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index 10b91ebdf213..c2670eaa74e6 100644
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -1211,7 +1211,7 @@ struct compat_ipt_replace {
u32 underflow[NF_INET_NUMHOOKS];
u32 num_counters;
compat_uptr_t counters; /* struct xt_counters * */
- struct compat_ipt_entry entries[0];
+ struct compat_ipt_entry entries[];
};
static int
@@ -1562,7 +1562,7 @@ compat_do_ipt_set_ctl(struct sock *sk, int cmd, void __user *user,
struct compat_ipt_get_entries {
char name[XT_TABLE_MAXNAMELEN];
compat_uint_t size;
- struct compat_ipt_entry entrytable[0];
+ struct compat_ipt_entry entrytable[];
};
static int
diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
index c973ace208c5..e27393498ecb 100644
--- a/net/ipv6/netfilter/ip6_tables.c
+++ b/net/ipv6/netfilter/ip6_tables.c
@@ -1227,7 +1227,7 @@ struct compat_ip6t_replace {
u32 underflow[NF_INET_NUMHOOKS];
u32 num_counters;
compat_uptr_t counters; /* struct xt_counters * */
- struct compat_ip6t_entry entries[0];
+ struct compat_ip6t_entry entries[];
};
static int
@@ -1571,7 +1571,7 @@ compat_do_ip6t_set_ctl(struct sock *sk, int cmd, void __user *user,
struct compat_ip6t_get_entries {
char name[XT_TABLE_MAXNAMELEN];
compat_uint_t size;
- struct compat_ip6t_entry entrytable[0];
+ struct compat_ip6t_entry entrytable[];
};
static int
diff --git a/net/netfilter/ipset/ip_set_bitmap_ip.c b/net/netfilter/ipset/ip_set_bitmap_ip.c
index 0a2196f59106..486959f70cf3 100644
--- a/net/netfilter/ipset/ip_set_bitmap_ip.c
+++ b/net/netfilter/ipset/ip_set_bitmap_ip.c
@@ -46,7 +46,7 @@ struct bitmap_ip {
u8 netmask; /* subnet netmask */
struct timer_list gc; /* garbage collection */
struct ip_set *set; /* attached to this ip_set */
- unsigned char extensions[0] /* data extensions */
+ unsigned char extensions[] /* data extensions */
__aligned(__alignof__(u64));
};
diff --git a/net/netfilter/ipset/ip_set_bitmap_ipmac.c b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
index 739e343efaf6..2310a316e0af 100644
--- a/net/netfilter/ipset/ip_set_bitmap_ipmac.c
+++ b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
@@ -49,7 +49,7 @@ struct bitmap_ipmac {
size_t memsize; /* members size */
struct timer_list gc; /* garbage collector */
struct ip_set *set; /* attached to this ip_set */
- unsigned char extensions[0] /* MAC + data extensions */
+ unsigned char extensions[] /* MAC + data extensions */
__aligned(__alignof__(u64));
};
diff --git a/net/netfilter/ipset/ip_set_bitmap_port.c b/net/netfilter/ipset/ip_set_bitmap_port.c
index b49978dd810d..e56ced66f202 100644
--- a/net/netfilter/ipset/ip_set_bitmap_port.c
+++ b/net/netfilter/ipset/ip_set_bitmap_port.c
@@ -37,7 +37,7 @@ struct bitmap_port {
size_t memsize; /* members size */
struct timer_list gc; /* garbage collection */
struct ip_set *set; /* attached to this ip_set */
- unsigned char extensions[0] /* data extensions */
+ unsigned char extensions[] /* data extensions */
__aligned(__alignof__(u64));
};
diff --git a/net/netfilter/ipset/ip_set_hash_gen.h b/net/netfilter/ipset/ip_set_hash_gen.h
index 7480ce55b5c8..f1edc5b9b4ce 100644
--- a/net/netfilter/ipset/ip_set_hash_gen.h
+++ b/net/netfilter/ipset/ip_set_hash_gen.h
@@ -68,7 +68,7 @@ struct hbucket {
DECLARE_BITMAP(used, AHASH_MAX_TUNED);
u8 size; /* size of the array */
u8 pos; /* position of the first free entry */
- unsigned char value[0] /* the array of the values */
+ unsigned char value[] /* the array of the values */
__aligned(__alignof__(u64));
};
@@ -77,7 +77,7 @@ struct htable {
atomic_t ref; /* References for resizing */
atomic_t uref; /* References for dumping */
u8 htable_bits; /* size of hash table == 2^htable_bits */
- struct hbucket __rcu *bucket[0]; /* hashtable buckets */
+ struct hbucket __rcu *bucket[]; /* hashtable buckets */
};
#define hbucket(h, i) ((h)->bucket[i])
diff --git a/net/netfilter/nfnetlink_acct.c b/net/netfilter/nfnetlink_acct.c
index 2481470dec36..5827117f2635 100644
--- a/net/netfilter/nfnetlink_acct.c
+++ b/net/netfilter/nfnetlink_acct.c
@@ -33,7 +33,7 @@ struct nf_acct {
refcount_t refcnt;
char name[NFACCT_NAME_MAX];
struct rcu_head rcu_head;
- char data[0];
+ char data[];
};
struct nfacct_filter {
diff --git a/net/netfilter/nft_set_pipapo.c b/net/netfilter/nft_set_pipapo.c
index feac8553f6d9..141cea0c5da2 100644
--- a/net/netfilter/nft_set_pipapo.c
+++ b/net/netfilter/nft_set_pipapo.c
@@ -433,7 +433,7 @@ struct nft_pipapo_match {
unsigned long * __percpu *scratch;
size_t bsize_max;
struct rcu_head rcu;
- struct nft_pipapo_field f[0];
+ struct nft_pipapo_field f[];
};
/* Current working bitmap index, toggled between field matches */
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 7a2c4b8408c4..c687509d882e 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -132,7 +132,7 @@ struct xt_hashlimit_htable {
const char *name;
struct net *net;
- struct hlist_head hash[0]; /* hashtable itself */
+ struct hlist_head hash[]; /* hashtable itself */
};
static int
diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
index 0a9708004e20..6e6bc5b91199 100644
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -71,7 +71,7 @@ struct recent_entry {
u_int8_t ttl;
u_int8_t index;
u_int16_t nstamps;
- unsigned long stamps[0];
+ unsigned long stamps[];
};
struct recent_table {
@@ -82,7 +82,7 @@ struct recent_table {
unsigned int entries;
u8 nstamps_max_mask;
struct list_head lru_list;
- struct list_head iphash[0];
+ struct list_head iphash[];
};
struct recent_net {
--
2.25.0
^ permalink raw reply related
* Re: [RFC v4 2/6] Bindings: nvmem: add bindings for JZ4780 efuse
From: Jiaxun Yang @ 2020-02-20 13:56 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: PrasannaKumar Muralidharan, Paul Cercueil, Mathieu Malaterre,
Srinivas Kandagatla, Linux Kernel Mailing List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-mips, Discussions about the Letux Kernel
In-Reply-To: <CFE9AEF5-FFF9-44A9-90D8-DE6AC7E7DD4F@goldelico.com>
--
Jiaxun Yang
---- 在 星期三, 2020-02-19 13:48:56 H. Nikolaus Schaller <hns@goldelico.com> 撰写 ----
>
> > Am 18.02.2020 um 22:26 schrieb Rob Herring <robh@kernel.org>:
> >
> > On Mon, Feb 17, 2020 at 05:55:26PM +0100, H. Nikolaus Schaller wrote:
> >> From: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
> >>
> >> This patch brings support for the JZ4780 efuse. Currently it only expose
> >> a read only access to the entire 8K bits efuse memory.
> >>
> >> Tested-by: Mathieu Malaterre <malat@debian.org>
> >> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
> >> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> >> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> >> ---
> >> .../bindings/nvmem/ingenic,jz4780-efuse.txt | 17 +++++++++++++++++
> >> 1 file changed, 17 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.txt
> >
> > Please convert to a DT schema.
>
> Is there someone of you who can help to do that?
>
> DT schemas are still like a Chinese dialect for me (i.e. I can decipher with help but neither speak nor write).
I just had a try.
https://paste.ubuntu.com/p/xgDdmwnGsz/
Not sure if it's correct.
Thanks.
--
Jiaxun Yang
^ permalink raw reply
* Re: [PATCH v3 08/22] rcu,tracing: Create trace_rcu_{enter,exit}()
From: Paul E. McKenney @ 2020-02-20 13:58 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Steven Rostedt, linux-kernel, linux-arch, mingo, joel, gregkh,
gustavo, tglx, josh, mathieu.desnoyers, jiangshanlai, luto,
tony.luck, frederic, dan.carpenter, mhiramat
In-Reply-To: <20200220103421.GV18400@hirez.programming.kicks-ass.net>
On Thu, Feb 20, 2020 at 11:34:21AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 19, 2020 at 08:44:50AM -0800, Paul E. McKenney wrote:
> > On Wed, Feb 19, 2020 at 05:35:35PM +0100, Peter Zijlstra wrote:
>
> > > Possibly, and I suppose the current version is less obviously dependent
> > > on the in_nmi() functionality as was the previous, seeing how Paul
> > > frobbed that all the way into the rcu_irq_enter*() implementation.
> > >
> > > So sure, I can go move it I suppose.
> >
> > No objections here.
>
> It now looks like so:
>
> ---
> Subject: rcu,tracing: Create trace_rcu_{enter,exit}()
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Wed Feb 12 09:18:57 CET 2020
>
> To facilitate tracers that need RCU, add some helpers to wrap the
> magic required.
>
> The problem is that we can call into tracers (trace events and
> function tracing) while RCU isn't watching and this can happen from
> any context, including NMI.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> ---
> include/linux/rcupdate.h | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -175,6 +175,35 @@ do { \
> #error "Unknown RCU implementation specified to kernel configuration"
> #endif
>
> +/**
> + * trace_rcu_enter - Force RCU to be active, for code that needs RCU readers
> + *
> + * Very similar to RCU_NONIDLE() above.
> + *
> + * Tracing can happen while RCU isn't active yet, for instance in the idle loop
> + * between rcu_idle_enter() and rcu_idle_exit(), or early in exception entry.
> + * RCU will happily ignore any read-side critical sections in this case.
> + *
> + * This function ensures that RCU is aware hereafter and the code can readily
> + * rely on RCU read-side critical sections working as expected.
> + *
> + * This function is NMI safe -- provided in_nmi() is correct and will nest up-to
> + * INT_MAX/2 times.
> + */
> +static inline int trace_rcu_enter(void)
> +{
> + int state = !rcu_is_watching();
> + if (state)
> + rcu_irq_enter_irqsave();
> + return state;
> +}
> +
> +static inline void trace_rcu_exit(int state)
> +{
> + if (state)
> + rcu_irq_exit_irqsave();
> +}
> +
> /*
> * The init_rcu_head_on_stack() and destroy_rcu_head_on_stack() calls
> * are needed for dynamic initialization and destruction of rcu_head
^ permalink raw reply
* [Printing-architecture] OP Minutes (11 February 2020)
From: Ira McDonald @ 2020-02-20 13:57 UTC (permalink / raw)
To: printing-architecture@lists.linux-foundation.org, Ira McDonald
[-- Attachment #1: Type: text/plain, Size: 3198 bytes --]
Hi,
Minutes from our last OpenPrinting call are posted at:
http://ftp.pwg.org/pub/pwg/liaison/openprinting/minutes/OP-Minutes-20200211.htm
Next OP US/Europe/Brazil/India Conference Calls:
(1) March - US/Europe/Brazil/India - OP Monthly Meeting
- Tuesday 17 March 2020, Daytime
- Bluejeans.com web conference to be announced
- Note - Till and Aveek have schedule conflicts on 3 March and 10
March
- Note - US Daylight Savings Time starts 8 March 2020
- Note - EU Summer Time starts 29 March 2020
- Note - IETF 107 in Vancouver, Canada - 21-27 March 2020
- US
10am in San Francisco - US PDT (Pacific Daylight Time)
11am in Colorado - US MDT (Mountain Daylight Time)
12am in Chicago - US CDT (Central Daylight Time)
1pm in New York - US EDT (Eastern Daylight Time)
- Europe
6pm in Berlin - CET (Central Europe Time)
- Brazil
2pm in Belo Horizonte - BRT (Brasilia Time)
- India
10:30pm in New Delhi - IST (India Standard Time)
(2) April - US/Europe/Brazil/India - OP Monthly Meeting (tentative)
- Tuesday 7 April 2020, Daytime
- Bluejeans.com web conference to be announced
- Note - US Daylight Savings Time starts 8 March 2020
- Note - EU Summer Time starts 29 March 2020
- Note - IETF 107 in Vancouver, Canada - 21-27 March 2020
- Note - IEEE 1609 in Austin, TX - 27-28 April 2020
- US
10am in San Francisco - US PDT (Pacific Daylight Time)
11am in Colorado - US MDT (Mountain Daylight Time)
12am in Chicago - US CDT (Central Daylight Time)
1pm in New York - US EDT (Eastern Daylight Time)
- Europe
7pm in Berlin - CEST (Central Europe Summer Time)
- Brazil
2pm in Belo Horizonte - BRT (Brasilia Time)
- India
10:30pm in New Delhi - IST (India Standard Time)
(3) May - US/Europe/Brazil/India - OP Monthly Meeting (tentative)
- Tuesday 12 May 2020, Daytime
- Bluejeans.com web conference to be announced
- Note - Joint PWG/OP F2F in Lexington, KY (Lexmark Host) - 5-7 May
2020
- US
10am in San Francisco - US PDT (Pacific Daylight Time)
11am in Colorado - US MDT (Mountain Daylight Time)
12am in Chicago - US CDT (Central Daylight Time)
1pm in New York - US EDT (Eastern Daylight Time)
- Europe
7pm in Berlin - CEST (Central Europe Summer Time)
- Brazil
2pm in Belo Horizonte - BRT (Brasilia Time)
- India
10:30pm in New Delhi - IST (India Standard Time)
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
(to 30 April 2020) 203 W Oak St Ellettsville, IN 47429 812-876-9970
[-- Attachment #2: Type: text/html, Size: 5367 bytes --]
^ permalink raw reply
* Re: a bug(BUG: kernel NULL pointer dereference) of ib or mlx happened in 5.4.21 but not in 5.4.20
From: Chuck Lever @ 2020-02-20 13:57 UTC (permalink / raw)
To: Wang Yugui; +Cc: linux-rdma
In-Reply-To: <20200220112231.34FB.409509F4@e16-tech.com>
Hello!
Thanks for your bug report.
> On Feb 19, 2020, at 10:22 PM, Wang Yugui <wangyugui@e16-tech.com> wrote:
>
> Hi, chuck.lever
>
> a bug(BUG: kernel NULL pointer dereference) of ib or mlx happened in 5.4.21 but not in 5.4.20.
>
> maybe some releationship to xprtrdma-fix-dma-scatter-gather-list-mapping-imbalance.patch
I don't see an obvious connection to fix-dma-scatter-gather-list-mapping-imbalance.
The backtrace below is through IPoIB code paths. Those have nothing to do with
NFS/RDMA, which is the only ULP code that is changed by my commit.
> maybe the info is useful.
I'm copying linux-rdma for a bigger set of eyeballs.
My knee-jerk recommendation is that if you have a reliable reproducer, try "git bisect"
between .20 and .21 to nail down a specific commit where the BUG starts to occur.
> Feb 20 10:05:58 T630 kernel: BUG: kernel NULL pointer dereference, address: 0000000000000010
> ...
> Feb 20 10:05:58 T630 kernel: port_pkey_list_insert+0x30/0x1a0 [ib_core]
> Feb 20 10:05:58 T630 kernel: ? kmem_cache_alloc_trace+0x219/0x230
> Feb 20 10:05:58 T630 kernel: ib_security_modify_qp+0x244/0x3b0 [ib_core]
> Feb 20 10:05:58 T630 kernel: _ib_modify_qp+0x1c0/0x3c0 [ib_core]
> Feb 20 10:05:58 T630 kernel: ? dma_pool_free+0x24/0xc0
> Feb 20 10:05:58 T630 kernel: ipoib_init_qp+0x77/0x190 [ib_ipoib]
> Feb 20 10:05:58 T630 kernel: ? __mlx4_ib_query_pkey+0xe7/0x110 [mlx4_ib]
> Feb 20 10:05:58 T630 kernel: ? ib_find_pkey+0x98/0xe0 [ib_core]
> Feb 20 10:05:58 T630 kernel: ipoib_ib_dev_open_default+0x1a/0x180 [ib_ipoib]
> Feb 20 10:05:58 T630 kernel: ipoib_ib_dev_open+0x66/0xa0 [ib_ipoib]
> Feb 20 10:05:58 T630 kernel: ipoib_open+0x44/0x110 [ib_ipoib]
> Feb 20 10:05:58 T630 kernel: __dev_open+0xcd/0x160
>
>
> # ibstat
> CA 'mlx4_0'
> CA type: MT4099
> Number of ports: 2
> Firmware version: 2.42.5000
> Hardware version: 1
> Node GUID: 0xe41d2d03007b4080
> System image GUID: 0xe41d2d03007b4083
> Port 1:
> State: Down
> Physical state: Polling
> Rate: 10
> Base lid: 0
> LMC: 0
> SM lid: 0
> Capability mask: 0x02594868
> Port GUID: 0xe41d2d03007b4081
> Link layer: InfiniBand
> Port 2:
> State: Down
> Physical state: Disabled
> Rate: 40
> Base lid: 0
> LMC: 0
> SM lid: 0
> Capability mask: 0x00010000
> Port GUID: 0xe61d2dfffe7b4082
> Link layer: Ethernet
>
> Best Regards
> 王玉贵
> 2020/02/20
>
> --------------------------------------
> 北京京垓科技有限公司
> 王玉贵 wangyugui@e16-tech.com
> 电话：+86-136-71123776
> <bug-of-ib-in-5.4.21.message>
--
Chuck Lever
^ permalink raw reply
* Re: w83627ehf crash in 5.6.0-rc2-00055-gca7e1fd1026c
From: Dr. David Alan Gilbert @ 2020-02-20 13:57 UTC (permalink / raw)
To: Meelis Roos, linux; +Cc: linux-hwmon, LKML, Chen Zhou
In-Reply-To: <6050ed14-f7a6-cb99-7268-072129226d48@linux.ee>
* Meelis Roos (mroos@linux.ee) wrote:
> > It looks like not all chips have temp_label, so I think we need to change w83627ehf_is_visible
> > which has:
> >
> > if (attr == hwmon_temp_input || attr == hwmon_temp_label)
> > return 0444;
> >
> > to
> > if (attr == hwmon_temp_input)
> > return 0444;
> > if (attr == hwmon_temp_label) {
> > if (data->temp_label)
> > return 0444;
> > else
> > return 0;
> > }
> >
> > Does that work for you?
> Yes, it works - sensors are displayed as they should be, with nothing in dmesg.
>
> Thank you for so quick response!
Great, I need to turn that into a proper patch; (I might need to wait till
Saturday for that, although if someone needs it before then please shout).
Dave
>
> --
> Meelis Roos <mroos@linux.ee>
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
* Re: [Xen-devel] [PATCH v3 03/20] exec: Let qemu_ram_*() functions take a const pointer argument
From: Durrant, Paul @ 2020-02-20 13:56 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Peter Maydell, qemu-devel@nongnu.org
Cc: Fam Zheng, Dmitry Fleytman, Matthew Rosato, Michael S. Tsirkin,
Jason Wang, Gerd Hoffmann, Edgar E. Iglesias, Stefano Stabellini,
kvm@vger.kernel.org, qemu-block@nongnu.org, David Hildenbrand,
Halil Pasic, Christian Borntraeger, Hervé Poussineau,
Marcel Apfelbaum, Anthony Perard, xen-devel@lists.xenproject.org,
Aleksandar Rikalo, David Gibson, Laurent Vivier, Thomas Huth,
Eduardo Habkost, Stefan Weil, Alistair Francis, Richard Henderson,
Paul Durrant, Eric Auger, qemu-s390x@nongnu.org,
qemu-arm@nongnu.org, Cédric Le Goater, John Snow,
Richard Henderson, Igor Mitsyanko, Cornelia Huck, Michael Walle,
qemu-ppc@nongnu.org, Paolo Bonzini
In-Reply-To: <20200220130548.29974-4-philmd@redhat.com>
> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> Philippe Mathieu-Daudé
> Sent: 20 February 2020 13:06
> To: Peter Maydell <peter.maydell@linaro.org>; qemu-devel@nongnu.org
> Cc: Fam Zheng <fam@euphon.net>; Dmitry Fleytman
> <dmitry.fleytman@gmail.com>; kvm@vger.kernel.org; Michael S. Tsirkin
> <mst@redhat.com>; Jason Wang <jasowang@redhat.com>; Gerd Hoffmann
> <kraxel@redhat.com>; Edgar E. Iglesias <edgar.iglesias@gmail.com>; Stefano
> Stabellini <sstabellini@kernel.org>; Matthew Rosato
> <mjrosato@linux.ibm.com>; qemu-block@nongnu.org; David Hildenbrand
> <david@redhat.com>; Halil Pasic <pasic@linux.ibm.com>; Christian
> Borntraeger <borntraeger@de.ibm.com>; Hervé Poussineau
> <hpoussin@reactos.org>; Marcel Apfelbaum <marcel.apfelbaum@gmail.com>;
> Anthony Perard <anthony.perard@citrix.com>; xen-
> devel@lists.xenproject.org; Aleksandar Rikalo <aleksandar.rikalo@rt-
> rk.com>; Richard Henderson <rth@twiddle.net>; Philippe Mathieu-Daudé
> <philmd@redhat.com>; Laurent Vivier <lvivier@redhat.com>; Thomas Huth
> <thuth@redhat.com>; Eduardo Habkost <ehabkost@redhat.com>; Stefan Weil
> <sw@weilnetz.de>; Alistair Francis <alistair@alistair23.me>; Richard
> Henderson <richard.henderson@linaro.org>; Paul Durrant <paul@xen.org>;
> Eric Auger <eric.auger@redhat.com>; qemu-s390x@nongnu.org; qemu-
> arm@nongnu.org; Cédric Le Goater <clg@kaod.org>; John Snow
> <jsnow@redhat.com>; David Gibson <david@gibson.dropbear.id.au>; Igor
> Mitsyanko <i.mitsyanko@gmail.com>; Cornelia Huck <cohuck@redhat.com>;
> Michael Walle <michael@walle.cc>; qemu-ppc@nongnu.org; Paolo Bonzini
> <pbonzini@redhat.com>
> Subject: [Xen-devel] [PATCH v3 03/20] exec: Let qemu_ram_*() functions
> take a const pointer argument
>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Paul Durrant <paul@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v3 10/37] KVM: s390: protvirt: Add KVM api documentation
From: Christian Borntraeger @ 2020-02-20 13:55 UTC (permalink / raw)
To: David Hildenbrand, Janosch Frank
Cc: KVM, Cornelia Huck, Thomas Huth, Ulrich Weigand, Claudio Imbrenda,
linux-s390, Michael Mueller, Vasily Gorbik, Janosch Frank
In-Reply-To: <d9580cae-6448-4d7a-347a-281df969e945@redhat.com>
On 20.02.20 14:05, David Hildenbrand wrote:
> On 20.02.20 11:39, Christian Borntraeger wrote:
>> From: Janosch Frank <frankja@linux.ibm.com>
>>
>> Add documentation for KVM_CAP_S390_PROTECTED capability and the
>> KVM_S390_PV_COMMAND and KVM_S390_PV_COMMAND_VCPU ioctls.
>
> Outdated.
ACK.
>
> I suggest moving this after "[PATCH v3 37/37] KVM: s390: protvirt:
> introduce and enable KVM_CAP_S390_PROTECTED" or even squashing it into
> that one.
Will move at the end.
[...]
>> +8.23 KVM_CAP_S390_PROTECTED
>> +
>> +Architecture: s390
>> +
>> +This capability indicates that KVM can start protected VMs and the
>> +Ultravisor has therefore been initialized.
>>
>
> Maybe document that KVM_S390_PV_COMMAND and the new MP is available.
> Also maybe that MP commands can now fail.
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index faca9977cbe7..7faf32b92d8c 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6081,3 +6081,6 @@ Architecture: s390
This capability indicates that KVM can start protected VMs and the
Ultravisor has therefore been initialized.
+This will provide the new KVM_S390_PV_COMMAND ioctl and it will allow
+KVM_MP_STATE_LOAD as new MP_STATE. KVM_SET_MP_STATE can now fail for
+protected guests when the state change is invalid.
^ permalink raw reply related
* RE: [Xen-devel] [PATCH v3 03/20] exec: Let qemu_ram_*() functions take a const pointer argument
From: Durrant, Paul @ 2020-02-20 13:56 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Peter Maydell, qemu-devel@nongnu.org
Cc: Fam Zheng, Dmitry Fleytman, kvm@vger.kernel.org,
Michael S. Tsirkin, Jason Wang, Gerd Hoffmann, Edgar E. Iglesias,
Stefano Stabellini, Matthew Rosato, qemu-block@nongnu.org,
David Hildenbrand, Halil Pasic, Christian Borntraeger,
Hervé Poussineau, Marcel Apfelbaum, Anthony Perard,
xen-devel@lists.xenproject.org, Aleksandar Rikalo,
Richard Henderson, Laurent Vivier, Thomas Huth, Eduardo Habkost,
Stefan Weil, Alistair Francis, Richard Henderson, Paul Durrant,
Eric Auger, qemu-s390x@nongnu.org, qemu-arm@nongnu.org,
Cédric Le Goater, John Snow, David Gibson, Igor Mitsyanko,
Cornelia Huck, Michael Walle, qemu-ppc@nongnu.org, Paolo Bonzini
In-Reply-To: <20200220130548.29974-4-philmd@redhat.com>
> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> Philippe Mathieu-Daudé
> Sent: 20 February 2020 13:06
> To: Peter Maydell <peter.maydell@linaro.org>; qemu-devel@nongnu.org
> Cc: Fam Zheng <fam@euphon.net>; Dmitry Fleytman
> <dmitry.fleytman@gmail.com>; kvm@vger.kernel.org; Michael S. Tsirkin
> <mst@redhat.com>; Jason Wang <jasowang@redhat.com>; Gerd Hoffmann
> <kraxel@redhat.com>; Edgar E. Iglesias <edgar.iglesias@gmail.com>; Stefano
> Stabellini <sstabellini@kernel.org>; Matthew Rosato
> <mjrosato@linux.ibm.com>; qemu-block@nongnu.org; David Hildenbrand
> <david@redhat.com>; Halil Pasic <pasic@linux.ibm.com>; Christian
> Borntraeger <borntraeger@de.ibm.com>; Hervé Poussineau
> <hpoussin@reactos.org>; Marcel Apfelbaum <marcel.apfelbaum@gmail.com>;
> Anthony Perard <anthony.perard@citrix.com>; xen-
> devel@lists.xenproject.org; Aleksandar Rikalo <aleksandar.rikalo@rt-
> rk.com>; Richard Henderson <rth@twiddle.net>; Philippe Mathieu-Daudé
> <philmd@redhat.com>; Laurent Vivier <lvivier@redhat.com>; Thomas Huth
> <thuth@redhat.com>; Eduardo Habkost <ehabkost@redhat.com>; Stefan Weil
> <sw@weilnetz.de>; Alistair Francis <alistair@alistair23.me>; Richard
> Henderson <richard.henderson@linaro.org>; Paul Durrant <paul@xen.org>;
> Eric Auger <eric.auger@redhat.com>; qemu-s390x@nongnu.org; qemu-
> arm@nongnu.org; Cédric Le Goater <clg@kaod.org>; John Snow
> <jsnow@redhat.com>; David Gibson <david@gibson.dropbear.id.au>; Igor
> Mitsyanko <i.mitsyanko@gmail.com>; Cornelia Huck <cohuck@redhat.com>;
> Michael Walle <michael@walle.cc>; qemu-ppc@nongnu.org; Paolo Bonzini
> <pbonzini@redhat.com>
> Subject: [Xen-devel] [PATCH v3 03/20] exec: Let qemu_ram_*() functions
> take a const pointer argument
>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Paul Durrant <paul@xen.org>
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 04/12] drm/i915: Add i9xx_lut_8()
From: Ville Syrjälä @ 2020-02-20 13:56 UTC (permalink / raw)
To: Emil Velikov; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <CACvgo53oWVf2=DGCopMrk0kjqZ+5ULXApEfj99xWZxD8vSUyMA@mail.gmail.com>
On Thu, Feb 20, 2020 at 11:20:05AM +0000, Emil Velikov wrote:
> On Thu, 7 Nov 2019 at 15:17, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > We have a nice little helper to compute a single LUT entry
> > for everything except the 8bpc legacy gamma mode. Let's
> > complete the set.
> >
> At a later stage one could rename this & the 10bit one, moving them to
> include/drm/.
> There are other drivers doing the same thing... not sure if that's
> worth it though.
I'd say no. These are specifically about formatting the LUT entry for
the hw register. I don't really see much benefit from sharing code to
compute hw register values across totally different hardware, even if
the bits happen to match by accident.
The only good exception I can think of are cases where said
register value comes more or less straight from some cross
vendor spec.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 04/12] drm/i915: Add i9xx_lut_8()
From: Ville Syrjälä @ 2020-02-20 13:56 UTC (permalink / raw)
To: Emil Velikov; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <CACvgo53oWVf2=DGCopMrk0kjqZ+5ULXApEfj99xWZxD8vSUyMA@mail.gmail.com>
On Thu, Feb 20, 2020 at 11:20:05AM +0000, Emil Velikov wrote:
> On Thu, 7 Nov 2019 at 15:17, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > We have a nice little helper to compute a single LUT entry
> > for everything except the 8bpc legacy gamma mode. Let's
> > complete the set.
> >
> At a later stage one could rename this & the 10bit one, moving them to
> include/drm/.
> There are other drivers doing the same thing... not sure if that's
> worth it though.
I'd say no. These are specifically about formatting the LUT entry for
the hw register. I don't really see much benefit from sharing code to
compute hw register values across totally different hardware, even if
the bits happen to match by accident.
The only good exception I can think of are cases where said
register value comes more or less straight from some cross
vendor spec.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] drm/amdgpu/discovery: make the discovery code less chatty
From: Yuan, Xiaojie @ 2020-02-20 13:56 UTC (permalink / raw)
To: Alex Deucher, amd-gfx@lists.freedesktop.org; +Cc: Deucher, Alexander
In-Reply-To: <20200219185130.222028-1-alexander.deucher@amd.com>
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
BR,
Xiaojie
________________________________________
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> on behalf of Alex Deucher <alexdeucher@gmail.com>
Sent: Thursday, February 20, 2020 2:51 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu/discovery: make the discovery code less chatty
Make the IP block base output debug only.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index f95092741c38..27d8ae19a7a4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -307,7 +307,7 @@ int amdgpu_discovery_reg_base_init(struct amdgpu_device *adev)
for (hw_ip = 0; hw_ip < MAX_HWIP; hw_ip++) {
if (hw_id_map[hw_ip] == le16_to_cpu(ip->hw_id)) {
- DRM_INFO("set register base offset for %s\n",
+ DRM_DEBUG("set register base offset for %s\n",
hw_id_names[le16_to_cpu(ip->hw_id)]);
adev->reg_offset[hw_ip][ip->number_instance] =
ip->base_address;
--
2.24.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CXiaojie.Yuan%40amd.com%7C6bea1e07f83447f56c3c08d7b56cc1d1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637177351030201676&sdata=Hyukxx%2FJjHeCQrsvWboFy5t5WTrj1h5zI68ugDbT0m8%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Re: [PATCH 3/6] dt-bindings: Add Guangdong Neweast Optoelectronics CO. LTD vendor prefix
From: Laurent Pinchart @ 2020-02-20 13:56 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Thierry Reding, Sam Ravnborg, David Airlie, Daniel Vetter,
Rob Herring, Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec,
Icenowy Zheng, Torsten Duwe, Heiko Stuebner, Linus Walleij,
Stephan Gerhold, Mark Brown, Stephen Rothwell, Samuel Holland,
dri-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20200220083508.792071-4-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:05AM -0800, Vasily Khoruzhick wrote:
> Add vendor prefix for Guangdong Neweast Optoelectronics CO. LTD
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 6456a6dfd83d..a390a793422b 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -665,6 +665,8 @@ patternProperties:
> description: Nexbox
> "^nextthing,.*":
> description: Next Thing Co.
> + "^neweast,.*":
> + description: Guangdong Neweast Optoelectronics CO., LT
Google only returns two hits for this name, beside the ones related to
this patch series. Are you sure this is the correct company name ?
> "^newhaven,.*":
> description: Newhaven Display International
> "^ni,.*":
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: Add Guangdong Neweast Optoelectronics CO. LTD vendor prefix
From: Laurent Pinchart @ 2020-02-20 13:56 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, Neil Armstrong, David Airlie, Linus Walleij,
dri-devel, Andrzej Hajda, Thierry Reding, Sam Ravnborg,
Stephen Rothwell, Samuel Holland, Heiko Stuebner, Chen-Yu Tsai,
Icenowy Zheng, Stephan Gerhold, Jonas Karlman, Torsten Duwe,
Rob Herring, Maxime Ripard, linux-arm-kernel, Jernej Skrabec,
linux-kernel, Mark Brown, Daniel Vetter
In-Reply-To: <20200220083508.792071-4-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:05AM -0800, Vasily Khoruzhick wrote:
> Add vendor prefix for Guangdong Neweast Optoelectronics CO. LTD
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 6456a6dfd83d..a390a793422b 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -665,6 +665,8 @@ patternProperties:
> description: Nexbox
> "^nextthing,.*":
> description: Next Thing Co.
> + "^neweast,.*":
> + description: Guangdong Neweast Optoelectronics CO., LT
Google only returns two hits for this name, beside the ones related to
this patch series. Are you sure this is the correct company name ?
> "^newhaven,.*":
> description: Newhaven Display International
> "^ni,.*":
--
Regards,
Laurent Pinchart
_______________________________________________
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 3/6] dt-bindings: Add Guangdong Neweast Optoelectronics CO. LTD vendor prefix
From: Laurent Pinchart @ 2020-02-20 13:56 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, Neil Armstrong, David Airlie, dri-devel,
Andrzej Hajda, Thierry Reding, Sam Ravnborg, Stephen Rothwell,
Samuel Holland, Heiko Stuebner, Chen-Yu Tsai, Icenowy Zheng,
Stephan Gerhold, Jonas Karlman, Torsten Duwe, Rob Herring,
Maxime Ripard, linux-arm-kernel, Jernej Skrabec, linux-kernel,
Mark Brown
In-Reply-To: <20200220083508.792071-4-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:05AM -0800, Vasily Khoruzhick wrote:
> Add vendor prefix for Guangdong Neweast Optoelectronics CO. LTD
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 6456a6dfd83d..a390a793422b 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -665,6 +665,8 @@ patternProperties:
> description: Nexbox
> "^nextthing,.*":
> description: Next Thing Co.
> + "^neweast,.*":
> + description: Guangdong Neweast Optoelectronics CO., LT
Google only returns two hits for this name, beside the ones related to
this patch series. Are you sure this is the correct company name ?
> "^newhaven,.*":
> description: Newhaven Display International
> "^ni,.*":
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: load a freebsd derived kernel on Qemu-system-arm
From: Peter Maydell @ 2020-02-20 13:55 UTC (permalink / raw)
To: kamalp; +Cc: qemu-arm
In-Reply-To: <CAK=yUG+jKnNYV=QiD_CHYhjKQOWky1Y2g9gGDbPnABH5hSwx-w@mail.gmail.com>
On Thu, 20 Feb 2020 at 10:52, Kamal R. Prasad <kamalpr@gmail.com> wrote:
> when I try to load a freebsd kernel onto Qemu running on my Mac, I get this error:-
>
> # qemu-system-arm -machine versatileab -kernel ./kernel
First step with any "this doesn't work on Mac" bug is
"does this repro on a Linux host?". Very few QEMU developers
use Macs.
Secondly, what QEMU version are you using? Does this repro
on the most recent version?
> qemu-system-arm: GLib: g_mapped_file_unref: assertion 'file != NULL' failed
>
>
> Can someone tell me what I am missing? The code is built for arm but online linux, freebsd build does not generate a vmlinuz or ignited file. The target is a cortex -arm quad core board (from Broadcom).
This explanation doesn't match up with your command line.
The 'versatileab' machine is a very old development board
which uses a single-core ARM926 CPU. As a general principle,
all Arm boards are different in significant ways. It is
not possible to run a kernel image on a particular board
unless that kernel was built to specifically include
support for that board. So you need to look at what boards
QEMU has support for, and build a FreeBSD kernel for one
of those, and then use the right -machine argument to
get QEMU to use that board model. (In particular, "I
got this kernel image file from some real hardware
embedded system and want to run it on QEMU instead" is
not going to work in 99% of cases, because QEMU will not
have a model of whatever that specific embedded hardware is.)
Finally, the -kernel argument is intended to boot a Linux
kernel, and uses the documented Arm kernel booting ABI.
I don't know whether FreeBSD kernel images are intended
to boot this way; if not, then you may find they don't
boot correctly. If I were you, I would start by seeing
if there are any online tutorials on how to build and
run a FreeBSD kernel on an Arm QEMU platform.
thanks
-- PMM
^ permalink raw reply
* [igt-dev] ✗ Fi.CI.BAT: failure for series starting with [i-g-t,1/2] lib: Update selftests to use dynamic subtests
From: Patchwork @ 2020-02-20 13:55 UTC (permalink / raw)
To: Petri Latvala; +Cc: igt-dev
In-Reply-To: <20200220125207.16423-1-petri.latvala@intel.com>
== Series Details ==
Series: series starting with [i-g-t,1/2] lib: Update selftests to use dynamic subtests
URL : https://patchwork.freedesktop.org/series/73710/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> IGTPW_4193
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with IGTPW_4193 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_4193, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in IGTPW_4193:
### IGT changes ###
#### Possible regressions ####
* igt@dmabuf@sanitycheck:
- fi-icl-u3: [PASS][1] -> [SKIP][2] +29 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u3/igt@dmabuf@sanitycheck.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-u3/igt@dmabuf@sanitycheck.html
* {igt@i915_selftest@live@gt_lrc} (NEW):
- {fi-tgl-dsi}: NOTRUN -> [DMESG-FAIL][3]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
- {fi-tgl-u}: NOTRUN -> [INCOMPLETE][4]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-tgl-u/igt@i915_selftest@live@gt_lrc.html
* {igt@i915_selftest@live@gt_pm} (NEW):
- {fi-ehl-1}: NOTRUN -> [DMESG-FAIL][5]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-ehl-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live_evict:
- fi-cml-u2: [PASS][6] -> [SKIP][7] +31 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cml-u2/igt@i915_selftest@live_evict.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-cml-u2/igt@i915_selftest@live_evict.html
* igt@i915_selftest@live_gt_contexts:
- fi-icl-guc: [PASS][8] -> [SKIP][9] +30 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-guc/igt@i915_selftest@live_gt_contexts.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-guc/igt@i915_selftest@live_gt_contexts.html
* igt@i915_selftest@live_gt_heartbeat:
- fi-icl-dsi: [PASS][10] -> [SKIP][11] +30 similar issues
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-dsi/igt@i915_selftest@live_gt_heartbeat.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-dsi/igt@i915_selftest@live_gt_heartbeat.html
* igt@i915_selftest@live_gt_mocs:
- fi-icl-y: [PASS][12] -> [SKIP][13] +30 similar issues
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-y/igt@i915_selftest@live_gt_mocs.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-y/igt@i915_selftest@live_gt_mocs.html
* igt@i915_selftest@live_hugepages:
- fi-icl-u2: [PASS][14] -> [SKIP][15] +30 similar issues
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@i915_selftest@live_hugepages.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-u2/igt@i915_selftest@live_hugepages.html
* igt@i915_selftest@live_uncore:
- fi-cml-s: [PASS][16] -> [SKIP][17] +30 similar issues
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cml-s/igt@i915_selftest@live_uncore.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-cml-s/igt@i915_selftest@live_uncore.html
#### Warnings ####
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][18] ([i915#877]) -> [SKIP][19]
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@dmabuf@dma_fence:
- {fi-ehl-1}: [PASS][20] -> [SKIP][21] +30 similar issues
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-ehl-1/igt@dmabuf@dma_fence.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-ehl-1/igt@dmabuf@dma_fence.html
* igt@i915_selftest@live_execlists:
- {fi-tgl-dsi}: [PASS][22] -> [SKIP][23] +30 similar issues
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-dsi/igt@i915_selftest@live_execlists.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-tgl-dsi/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gt_lrc:
- {fi-tgl-dsi}: [DMESG-FAIL][24] ([i915#1233]) -> [SKIP][25]
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-dsi/igt@i915_selftest@live_gt_lrc.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-tgl-dsi/igt@i915_selftest@live_gt_lrc.html
* igt@i915_selftest@live_gt_pm:
- {fi-ehl-1}: [DMESG-FAIL][26] ([i915#801]) -> [SKIP][27]
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-ehl-1/igt@i915_selftest@live_gt_pm.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-ehl-1/igt@i915_selftest@live_gt_pm.html
New tests
---------
New tests have been introduced between CI_DRM_7973 and IGTPW_4193:
### New IGT tests (34) ###
* igt@dmabuf@all:
- Statuses :
- Exec time: [None] s
* igt@dmabuf@all@dma_fence:
- Statuses : 39 pass(s)
- Exec time: [0.13, 0.23] s
* igt@dmabuf@all@sanitycheck:
- Statuses : 39 pass(s)
- Exec time: [0.02, 0.04] s
* igt@i915_selftest@live:
- Statuses :
- Exec time: [None] s
* igt@i915_selftest@live@active:
- Statuses : 39 pass(s)
- Exec time: [0.42, 2.16] s
* igt@i915_selftest@live@blt:
- Statuses : 39 pass(s)
- Exec time: [0.47, 11.35] s
* igt@i915_selftest@live@client:
- Statuses : 39 pass(s)
- Exec time: [0.47, 6.56] s
* igt@i915_selftest@live@coherency:
- Statuses : 39 pass(s)
- Exec time: [0.83, 15.78] s
* igt@i915_selftest@live@dmabuf:
- Statuses : 39 pass(s)
- Exec time: [0.41, 2.04] s
* igt@i915_selftest@live@evict:
- Statuses : 39 pass(s)
- Exec time: [0.46, 15.20] s
* igt@i915_selftest@live@execlists:
- Statuses : 39 pass(s)
- Exec time: [0.46, 52.23] s
* igt@i915_selftest@live@gem:
- Statuses : 39 pass(s)
- Exec time: [0.53, 6.78] s
* igt@i915_selftest@live@gem_contexts:
- Statuses : 39 pass(s)
- Exec time: [0.46, 31.79] s
* igt@i915_selftest@live@gt_contexts:
- Statuses : 40 pass(s)
- Exec time: [0.42, 2.19] s
* igt@i915_selftest@live@gt_engines:
- Statuses : 40 pass(s)
- Exec time: [0.41, 2.11] s
* igt@i915_selftest@live@gt_heartbeat:
- Statuses : 39 pass(s)
- Exec time: [0.49, 2.22] s
* igt@i915_selftest@live@gt_lrc:
- Statuses : 2 dmesg-fail(s) 1 incomplete(s) 37 pass(s)
- Exec time: [0.0, 4.00] s
* igt@i915_selftest@live@gt_mocs:
- Statuses : 39 pass(s)
- Exec time: [0.45, 2.52] s
* igt@i915_selftest@live@gt_pm:
- Statuses : 1 dmesg-fail(s) 38 pass(s)
- Exec time: [0.96, 2.86] s
* igt@i915_selftest@live@gt_timelines:
- Statuses : 40 pass(s)
- Exec time: [1.54, 16.75] s
* igt@i915_selftest@live@gtt:
- Statuses : 39 pass(s)
- Exec time: [3.28, 11.92] s
* igt@i915_selftest@live@hangcheck:
- Statuses : 39 pass(s)
- Exec time: [1.54, 28.85] s
* igt@i915_selftest@live@hugepages:
- Statuses : 39 pass(s)
- Exec time: [0.47, 10.23] s
* igt@i915_selftest@live@late_gt_pm:
- Statuses : 39 pass(s)
- Exec time: [0.44, 2.15] s
* igt@i915_selftest@live@memory_region:
- Statuses : 39 pass(s)
- Exec time: [0.40, 2.04] s
* igt@i915_selftest@live@mman:
- Statuses : 39 pass(s)
- Exec time: [2.04, 17.68] s
* igt@i915_selftest@live@objects:
- Statuses : 39 pass(s)
- Exec time: [0.75, 6.90] s
* igt@i915_selftest@live@perf:
- Statuses : 39 pass(s)
- Exec time: [0.46, 2.24] s
* igt@i915_selftest@live@requests:
- Statuses : 39 pass(s)
- Exec time: [1.99, 10.35] s
* igt@i915_selftest@live@reset:
- Statuses : 39 pass(s)
- Exec time: [0.40, 2.63] s
* igt@i915_selftest@live@sanitycheck:
- Statuses : 40 pass(s)
- Exec time: [0.40, 2.08] s
* igt@i915_selftest@live@uncore:
- Statuses : 40 pass(s)
- Exec time: [0.43, 2.06] s
* igt@i915_selftest@live@vma:
- Statuses : 39 pass(s)
- Exec time: [0.41, 2.09] s
* igt@i915_selftest@live@workarounds:
- Statuses : 40 pass(s)
- Exec time: [0.47, 2.63] s
Known issues
------------
Here are the changes found in IGTPW_4193 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@dmabuf@sanitycheck:
- fi-tgl-y: [PASS][28] -> [SKIP][29] ([CI#94]) +30 similar issues
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@dmabuf@sanitycheck.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-tgl-y/igt@dmabuf@sanitycheck.html
- fi-glk-dsi: [PASS][30] -> [SKIP][31] ([fdo#109271]) +31 similar issues
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-glk-dsi/igt@dmabuf@sanitycheck.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-glk-dsi/igt@dmabuf@sanitycheck.html
* igt@i915_selftest@live_active:
- fi-bdw-5557u: [PASS][32] -> [SKIP][33] ([fdo#109271]) +31 similar issues
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bdw-5557u/igt@i915_selftest@live_active.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-bdw-5557u/igt@i915_selftest@live_active.html
- fi-snb-2600: [PASS][34] -> [SKIP][35] ([fdo#109271]) +31 similar issues
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-snb-2600/igt@i915_selftest@live_active.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-snb-2600/igt@i915_selftest@live_active.html
* igt@i915_selftest@live_coherency:
- fi-byt-n2820: [PASS][36] -> [SKIP][37] ([fdo#109271]) +31 similar issues
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@i915_selftest@live_coherency.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-byt-n2820/igt@i915_selftest@live_coherency.html
* igt@i915_selftest@live_dmabuf:
- fi-hsw-4770r: [PASS][38] -> [SKIP][39] ([fdo#109271]) +31 similar issues
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-4770r/igt@i915_selftest@live_dmabuf.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-hsw-4770r/igt@i915_selftest@live_dmabuf.html
- fi-kbl-r: [PASS][40] -> [SKIP][41] ([fdo#109271]) +31 similar issues
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-r/igt@i915_selftest@live_dmabuf.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-kbl-r/igt@i915_selftest@live_dmabuf.html
* igt@i915_selftest@live_execlists:
- fi-bsw-nick: [PASS][42] -> [SKIP][43] ([fdo#109271]) +31 similar issues
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bsw-nick/igt@i915_selftest@live_execlists.html
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-bsw-nick/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gem_contexts:
- fi-apl-guc: [PASS][44] -> [SKIP][45] ([fdo#109271]) +31 similar issues
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-apl-guc/igt@i915_selftest@live_gem_contexts.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-apl-guc/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gt_heartbeat:
- fi-kbl-x1275: [PASS][46] -> [SKIP][47] ([fdo#109271]) +31 similar issues
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-x1275/igt@i915_selftest@live_gt_heartbeat.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-kbl-x1275/igt@i915_selftest@live_gt_heartbeat.html
- fi-cfl-8700k: [PASS][48] -> [SKIP][49] ([fdo#109271]) +31 similar issues
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cfl-8700k/igt@i915_selftest@live_gt_heartbeat.html
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-cfl-8700k/igt@i915_selftest@live_gt_heartbeat.html
* igt@i915_selftest@live_gt_mocs:
- fi-blb-e6850: [PASS][50] -> [SKIP][51] ([fdo#109271]) +31 similar issues
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-blb-e6850/igt@i915_selftest@live_gt_mocs.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-blb-e6850/igt@i915_selftest@live_gt_mocs.html
* igt@i915_selftest@live_gt_pm:
- fi-cfl-8109u: [PASS][52] -> [SKIP][53] ([fdo#109271]) +31 similar issues
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cfl-8109u/igt@i915_selftest@live_gt_pm.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-cfl-8109u/igt@i915_selftest@live_gt_pm.html
- fi-kbl-7500u: [PASS][54] -> [SKIP][55] ([fdo#109271]) +31 similar issues
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-7500u/igt@i915_selftest@live_gt_pm.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-kbl-7500u/igt@i915_selftest@live_gt_pm.html
* igt@i915_selftest@live_gtt:
- fi-kbl-guc: [PASS][56] -> [SKIP][57] ([fdo#109271]) +31 similar issues
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-guc/igt@i915_selftest@live_gtt.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-kbl-guc/igt@i915_selftest@live_gtt.html
* igt@i915_selftest@live_late_gt_pm:
- fi-bsw-kefka: [PASS][58] -> [SKIP][59] ([fdo#109271]) +31 similar issues
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bsw-kefka/igt@i915_selftest@live_late_gt_pm.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-bsw-kefka/igt@i915_selftest@live_late_gt_pm.html
- fi-skl-6600u: [PASS][60] -> [SKIP][61] ([fdo#109271]) +31 similar issues
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-skl-6600u/igt@i915_selftest@live_late_gt_pm.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-skl-6600u/igt@i915_selftest@live_late_gt_pm.html
* igt@i915_selftest@live_mman:
- fi-bxt-dsi: [PASS][62] -> [SKIP][63] ([fdo#109271]) +31 similar issues
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bxt-dsi/igt@i915_selftest@live_mman.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-bxt-dsi/igt@i915_selftest@live_mman.html
- fi-gdg-551: [PASS][64] -> [SKIP][65] ([fdo#109271]) +31 similar issues
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-gdg-551/igt@i915_selftest@live_mman.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-gdg-551/igt@i915_selftest@live_mman.html
* igt@i915_selftest@live_perf:
- fi-skl-6700k2: [PASS][66] -> [SKIP][67] ([fdo#109271]) +31 similar issues
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-skl-6700k2/igt@i915_selftest@live_perf.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-skl-6700k2/igt@i915_selftest@live_perf.html
* igt@i915_selftest@live_requests:
- fi-hsw-peppy: [PASS][68] -> [SKIP][69] ([fdo#109271]) +31 similar issues
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-peppy/igt@i915_selftest@live_requests.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-hsw-peppy/igt@i915_selftest@live_requests.html
- fi-icl-dsi: [PASS][70] -> [SKIP][71] ([fdo#109644] / [fdo#110464])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-dsi/igt@i915_selftest@live_requests.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-dsi/igt@i915_selftest@live_requests.html
- fi-icl-y: [PASS][72] -> [SKIP][73] ([fdo#109644] / [fdo#110464])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-y/igt@i915_selftest@live_requests.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-y/igt@i915_selftest@live_requests.html
- fi-icl-u3: [PASS][74] -> [SKIP][75] ([fdo#109644] / [fdo#110464])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u3/igt@i915_selftest@live_requests.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-u3/igt@i915_selftest@live_requests.html
- fi-icl-guc: [PASS][76] -> [SKIP][77] ([fdo#109644] / [fdo#110464])
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-guc/igt@i915_selftest@live_requests.html
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-guc/igt@i915_selftest@live_requests.html
- fi-icl-u2: [PASS][78] -> [SKIP][79] ([fdo#109644] / [fdo#110464])
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@i915_selftest@live_requests.html
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-u2/igt@i915_selftest@live_requests.html
* igt@i915_selftest@live_reset:
- fi-snb-2520m: [PASS][80] -> [SKIP][81] ([fdo#109271]) +31 similar issues
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-snb-2520m/igt@i915_selftest@live_reset.html
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-snb-2520m/igt@i915_selftest@live_reset.html
* igt@i915_selftest@live_sanitycheck:
- fi-hsw-4770: [PASS][82] -> [SKIP][83] ([fdo#109271]) +31 similar issues
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-4770/igt@i915_selftest@live_sanitycheck.html
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-hsw-4770/igt@i915_selftest@live_sanitycheck.html
* igt@i915_selftest@live_workarounds:
- fi-ilk-650: [PASS][84] -> [SKIP][85] ([fdo#109271]) +31 similar issues
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-ilk-650/igt@i915_selftest@live_workarounds.html
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-ilk-650/igt@i915_selftest@live_workarounds.html
- fi-bsw-n3050: [PASS][86] -> [SKIP][87] ([fdo#109271]) +31 similar issues
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bsw-n3050/igt@i915_selftest@live_workarounds.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-bsw-n3050/igt@i915_selftest@live_workarounds.html
- fi-cfl-guc: [PASS][88] -> [SKIP][89] ([fdo#109271]) +31 similar issues
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cfl-guc/igt@i915_selftest@live_workarounds.html
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-cfl-guc/igt@i915_selftest@live_workarounds.html
* igt@kms_addfb_basic@addfb25-x-tiled-mismatch:
- fi-tgl-y: [PASS][90] -> [DMESG-WARN][91] ([CI#94] / [i915#402]) +1 similar issue
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@kms_addfb_basic@addfb25-x-tiled-mismatch.html
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-tgl-y/igt@kms_addfb_basic@addfb25-x-tiled-mismatch.html
#### Possible fixes ####
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][92] ([i915#217]) -> [PASS][93]
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
* igt@prime_self_import@basic-llseek-bad:
- fi-tgl-y: [DMESG-WARN][94] ([CI#94] / [i915#402]) -> [PASS][95] +1 similar issue
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@prime_self_import@basic-llseek-bad.html
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-tgl-y/igt@prime_self_import@basic-llseek-bad.html
#### Warnings ####
* igt@i915_selftest@live_gt_lrc:
- fi-tgl-y: [DMESG-FAIL][96] ([CI#94] / [i915#1233]) -> [SKIP][97] ([CI#94])
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@i915_selftest@live_gt_lrc.html
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-tgl-y/igt@i915_selftest@live_gt_lrc.html
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [DMESG-WARN][98] ([i915#585]) -> [SKIP][99] ([i915#585])
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109644]: https://bugs.freedesktop.org/show_bug.cgi?id=109644
[fdo#110464]: https://bugs.freedesktop.org/show_bug.cgi?id=110464
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#801]: https://gitlab.freedesktop.org/drm/intel/issues/801
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 43)
------------------------------
Additional (4): fi-kbl-soraka fi-skl-lmem fi-ivb-3770 fi-pnv-d510
Missing (10): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-bdw-gvtdvm fi-skl-guc fi-byt-squawks fi-bwr-2160 fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5453 -> IGTPW_4193
CI-20190529: 20190529
CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4193: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/index.html
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Testlist changes ==
+igt@dmabuf@all
+igt@drm_mm@all
+igt@i915_selftest@live
+igt@i915_selftest@mock
+igt@i915_selftest@perf
+igt@kms_selftest@all
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4193/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Applied "ASoC: samsung: Update dependencies for Arizona machine drivers" to the asoc tree
From: Mark Brown @ 2020-02-20 13:54 UTC (permalink / raw)
To: Charles Keepax
Cc: alsa-devel, sbkim73, patches, rdunlap, lgirdwood, Mark Brown,
s.nawrocki
In-Reply-To: <20200220125654.7064-1-ckeepax@opensource.cirrus.com>
The patch
ASoC: samsung: Update dependencies for Arizona machine drivers
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From dc7f090d9ab2f36fc404f8d903f806a1b811739e Mon Sep 17 00:00:00 2001
From: Charles Keepax <ckeepax@opensource.cirrus.com>
Date: Thu, 20 Feb 2020 12:56:54 +0000
Subject: [PATCH] ASoC: samsung: Update dependencies for Arizona machine
drivers
Currently it is possible to get the following bad config:
WARNING: unmet direct dependencies detected for SND_SOC_WM5110
Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && MFD_WM5110 [=n]
commit ea00d95200d0 ("ASoC: Use imply for SND_SOC_ALL_CODECS")
commit d8dd3f92a6ba ("ASoC: Fix SND_SOC_ALL_CODECS imply misc fallout")
After these two patches the machine drivers still selects the
SND_SOC_WM5110 symbol which doesn't take account of the dependency
added on the MFD_WM5110 symbol, fix this by also adding a dependency on
MFD_WM5110 itself.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200220125654.7064-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 1a0b163ca47b..112911dc271b 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -151,7 +151,7 @@ config SND_SOC_TOBERMORY
config SND_SOC_BELLS
tristate "Audio support for Wolfson Bells"
- depends on MFD_ARIZONA && I2C && SPI_MASTER
+ depends on MFD_ARIZONA && MFD_WM5102 && MFD_WM5110 && I2C && SPI_MASTER
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select SND_SOC_WM5102
@@ -204,7 +204,7 @@ config SND_SOC_ARNDALE
config SND_SOC_SAMSUNG_TM2_WM5110
tristate "SoC I2S Audio support for WM5110 on TM2 board"
- depends on SND_SOC_SAMSUNG && MFD_ARIZONA && I2C && SPI_MASTER
+ depends on SND_SOC_SAMSUNG && MFD_ARIZONA && MFD_WM5110 && I2C && SPI_MASTER
depends on GPIOLIB || COMPILE_TEST
select SND_SOC_MAX98504
select SND_SOC_WM5110
--
2.20.1
^ permalink raw reply related
* Re: [Xen-devel] [PATCH v3 19/20] Let cpu_[physical]_memory() calls pass a boolean 'is_write' argument
From: Durrant, Paul @ 2020-02-20 13:54 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Peter Maydell, qemu-devel@nongnu.org
Cc: Fam Zheng, Dmitry Fleytman, Matthew Rosato, Michael S. Tsirkin,
Jason Wang, Gerd Hoffmann, Edgar E. Iglesias, Stefano Stabellini,
kvm@vger.kernel.org, qemu-block@nongnu.org, David Hildenbrand,
Halil Pasic, Christian Borntraeger, Hervé Poussineau,
Marcel Apfelbaum, Anthony Perard, xen-devel@lists.xenproject.org,
Aleksandar Rikalo, David Gibson, Laurent Vivier, Thomas Huth,
Eduardo Habkost, Stefan Weil, Alistair Francis, Richard Henderson,
Paul Durrant, Eric Auger, qemu-s390x@nongnu.org,
qemu-arm@nongnu.org, Cédric Le Goater, John Snow,
Richard Henderson, Igor Mitsyanko, Cornelia Huck, Michael Walle,
qemu-ppc@nongnu.org, Paolo Bonzini
In-Reply-To: <20200220130548.29974-20-philmd@redhat.com>
> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> Philippe Mathieu-Daudé
> Sent: 20 February 2020 13:06
> To: Peter Maydell <peter.maydell@linaro.org>; qemu-devel@nongnu.org
> Cc: Fam Zheng <fam@euphon.net>; Dmitry Fleytman
> <dmitry.fleytman@gmail.com>; kvm@vger.kernel.org; Michael S. Tsirkin
> <mst@redhat.com>; Jason Wang <jasowang@redhat.com>; Gerd Hoffmann
> <kraxel@redhat.com>; Edgar E. Iglesias <edgar.iglesias@gmail.com>; Stefano
> Stabellini <sstabellini@kernel.org>; Matthew Rosato
> <mjrosato@linux.ibm.com>; qemu-block@nongnu.org; David Hildenbrand
> <david@redhat.com>; Halil Pasic <pasic@linux.ibm.com>; Christian
> Borntraeger <borntraeger@de.ibm.com>; Hervé Poussineau
> <hpoussin@reactos.org>; Marcel Apfelbaum <marcel.apfelbaum@gmail.com>;
> Anthony Perard <anthony.perard@citrix.com>; xen-
> devel@lists.xenproject.org; Aleksandar Rikalo <aleksandar.rikalo@rt-
> rk.com>; Richard Henderson <rth@twiddle.net>; Philippe Mathieu-Daudé
> <philmd@redhat.com>; Laurent Vivier <lvivier@redhat.com>; Thomas Huth
> <thuth@redhat.com>; Eduardo Habkost <ehabkost@redhat.com>; Stefan Weil
> <sw@weilnetz.de>; Alistair Francis <alistair@alistair23.me>; Richard
> Henderson <richard.henderson@linaro.org>; Paul Durrant <paul@xen.org>;
> Eric Auger <eric.auger@redhat.com>; qemu-s390x@nongnu.org; qemu-
> arm@nongnu.org; Cédric Le Goater <clg@kaod.org>; John Snow
> <jsnow@redhat.com>; David Gibson <david@gibson.dropbear.id.au>; Igor
> Mitsyanko <i.mitsyanko@gmail.com>; Cornelia Huck <cohuck@redhat.com>;
> Michael Walle <michael@walle.cc>; qemu-ppc@nongnu.org; Paolo Bonzini
> <pbonzini@redhat.com>
> Subject: [Xen-devel] [PATCH v3 19/20] Let cpu_[physical]_memory() calls
> pass a boolean 'is_write' argument
>
> Use an explicit boolean type.
>
> This commit was produced with the included Coccinelle script
> scripts/coccinelle/exec_rw_const.
>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Paul Durrant <paul@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* RE: [Xen-devel] [PATCH v3 19/20] Let cpu_[physical]_memory() calls pass a boolean 'is_write' argument
From: Durrant, Paul @ 2020-02-20 13:54 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Peter Maydell, qemu-devel@nongnu.org
Cc: Fam Zheng, Dmitry Fleytman, kvm@vger.kernel.org,
Michael S. Tsirkin, Jason Wang, Gerd Hoffmann, Edgar E. Iglesias,
Stefano Stabellini, Matthew Rosato, qemu-block@nongnu.org,
David Hildenbrand, Halil Pasic, Christian Borntraeger,
Hervé Poussineau, Marcel Apfelbaum, Anthony Perard,
xen-devel@lists.xenproject.org, Aleksandar Rikalo,
Richard Henderson, Laurent Vivier, Thomas Huth, Eduardo Habkost,
Stefan Weil, Alistair Francis, Richard Henderson, Paul Durrant,
Eric Auger, qemu-s390x@nongnu.org, qemu-arm@nongnu.org,
Cédric Le Goater, John Snow, David Gibson, Igor Mitsyanko,
Cornelia Huck, Michael Walle, qemu-ppc@nongnu.org, Paolo Bonzini
In-Reply-To: <20200220130548.29974-20-philmd@redhat.com>
> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> Philippe Mathieu-Daudé
> Sent: 20 February 2020 13:06
> To: Peter Maydell <peter.maydell@linaro.org>; qemu-devel@nongnu.org
> Cc: Fam Zheng <fam@euphon.net>; Dmitry Fleytman
> <dmitry.fleytman@gmail.com>; kvm@vger.kernel.org; Michael S. Tsirkin
> <mst@redhat.com>; Jason Wang <jasowang@redhat.com>; Gerd Hoffmann
> <kraxel@redhat.com>; Edgar E. Iglesias <edgar.iglesias@gmail.com>; Stefano
> Stabellini <sstabellini@kernel.org>; Matthew Rosato
> <mjrosato@linux.ibm.com>; qemu-block@nongnu.org; David Hildenbrand
> <david@redhat.com>; Halil Pasic <pasic@linux.ibm.com>; Christian
> Borntraeger <borntraeger@de.ibm.com>; Hervé Poussineau
> <hpoussin@reactos.org>; Marcel Apfelbaum <marcel.apfelbaum@gmail.com>;
> Anthony Perard <anthony.perard@citrix.com>; xen-
> devel@lists.xenproject.org; Aleksandar Rikalo <aleksandar.rikalo@rt-
> rk.com>; Richard Henderson <rth@twiddle.net>; Philippe Mathieu-Daudé
> <philmd@redhat.com>; Laurent Vivier <lvivier@redhat.com>; Thomas Huth
> <thuth@redhat.com>; Eduardo Habkost <ehabkost@redhat.com>; Stefan Weil
> <sw@weilnetz.de>; Alistair Francis <alistair@alistair23.me>; Richard
> Henderson <richard.henderson@linaro.org>; Paul Durrant <paul@xen.org>;
> Eric Auger <eric.auger@redhat.com>; qemu-s390x@nongnu.org; qemu-
> arm@nongnu.org; Cédric Le Goater <clg@kaod.org>; John Snow
> <jsnow@redhat.com>; David Gibson <david@gibson.dropbear.id.au>; Igor
> Mitsyanko <i.mitsyanko@gmail.com>; Cornelia Huck <cohuck@redhat.com>;
> Michael Walle <michael@walle.cc>; qemu-ppc@nongnu.org; Paolo Bonzini
> <pbonzini@redhat.com>
> Subject: [Xen-devel] [PATCH v3 19/20] Let cpu_[physical]_memory() calls
> pass a boolean 'is_write' argument
>
> Use an explicit boolean type.
>
> This commit was produced with the included Coccinelle script
> scripts/coccinelle/exec_rw_const.
>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Paul Durrant <paul@xen.org>
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: display: simple: Add NewEast Optoelectronics WJFH116008A compatible
From: Laurent Pinchart @ 2020-02-20 13:54 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, Neil Armstrong, David Airlie, Linus Walleij,
dri-devel, Andrzej Hajda, Thierry Reding, Sam Ravnborg,
Stephen Rothwell, Samuel Holland, Heiko Stuebner, Chen-Yu Tsai,
Icenowy Zheng, Stephan Gerhold, Jonas Karlman, Torsten Duwe,
Rob Herring, Maxime Ripard, linux-arm-kernel, Jernej Skrabec,
linux-kernel, Mark Brown, Daniel Vetter
In-Reply-To: <20200220083508.792071-5-anarsoul@gmail.com>
On Thu, Feb 20, 2020 at 12:35:06AM -0800, Vasily Khoruzhick wrote:
> This commit adds compatible for NewEast Optoelectronics WJFH116008A panel
> to panel-simple binding
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 8fe60ee2531c..721de94cc80a 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -43,6 +43,8 @@ properties:
> - satoz,sat050at40h12r2
> # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
> - sharp,ls020b1dd01d
> + # NewEast Optoelectronics CO., LTD WJFH116008A eDP TFT LCD panel
> + - neweast,wjfh116008a
Please keep the entries alphabetically sorted. With this fixed,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> backlight: true
> enable-gpios: true
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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.