[PATCH v17 3/7] drm/rockchip: cdn-dp: Do not run worker while suspended
From: Guenter Roeck
If the driver is in suspended mode, the dp block may be disabled, and
chip registers may not be accessible. Yet, the worker may be triggered
in this situation by an extcon event. If that happens, the following crash
will be seen.
cdn-dp fec0.dp: [drm:cdn_dp_pd_event_work] *ERROR* Enable dp failed -19
cdn-dp fec0.dp: [drm:cdn_dp_pd_event_work] Connected, not enabled. Enabling
cdn
Bad mode in Error handler detected, code 0xbf02 -- SError
CPU: 1 PID: 10357 Comm: kworker/1:2 Not tainted 4.4.21-05903-ge0514ea #1
Hardware name: Google Kevin (DT)
Workqueue: events cdn_dp_pd_event_work
task: ffc0cda67080 ti: ffc0b9b8 task.ti: ffc0b9b8
PC is at cdn_dp_clock_reset+0x30/0xa8
LR is at cdn_dp_enable+0x1e0/0x69c
...
Call trace:
[] cdn_dp_pd_event_work+0x58/0x3f4
[] process_one_work+0x240/0x424
[] worker_thread+0x2fc/0x424
[] kthread+0x10c/0x114
[] ret_from_fork+0x10/0x40
Problem is two-fold: The worker should not run while suspended, and the
suspend function should not call cdn_dp_disable() while the worker is
running.
Signed-off-by: Guenter Roeck
Signed-off-by: Sean Paul
Signed-off-by: Chris Zhong
---
Changes in v17: None
drivers/gpu/drm/rockchip/cdn-dp-core.c | 15 +--
drivers/gpu/drm/rockchip/cdn-dp-core.h | 1 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index b8d0dd7..a70eedc 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -939,6 +939,10 @@ static void cdn_dp_pd_event_work(struct work_struct *work)
u8 sink_count;
mutex_lock(&dp->lock);
+
+ if (dp->suspended)
+ goto out;
+
ret = cdn_dp_request_firmware(dp);
if (ret)
goto out;
@@ -1123,19 +1127,26 @@ static const struct component_ops cdn_dp_component_ops
= {
int cdn_dp_suspend(struct device *dev)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
+ int ret = 0;
+ mutex_lock(&dp->lock);
if (dp->active)
- return cdn_dp_disable(dp);
+ ret = cdn_dp_disable(dp);
+ dp->suspended = true;
+ mutex_unlock(&dp->lock);
- return 0;
+ return ret;
}
int cdn_dp_resume(struct device *dev)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
+ mutex_lock(&dp->lock);
+ dp->suspended = false;
if (dp->fw_loaded)
schedule_work(&dp->event_work);
+ mutex_unlock(&dp->lock);
return 0;
}
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index 3bea4b8..7d48661 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -82,6 +82,7 @@ struct cdn_dp_device {
struct mutex lock;
bool connected;
bool active;
+ bool suspended;
const struct firmware *fw; /* cdn dp firmware */
unsigned int fw_version;/* cdn fw version */
--
2.6.3
[PATCH v17 2/7] drm/rockchip: cdn-dp: Load firmware if no monitor connected
From: Guenter Roeck If no monitor is connected, suspend/resume cycles result in firmware load errors because the driver attempts to load the firmware while the system is in suspend state. This results in a kernel warning and traceback. Loading the firmware during boot fixes the problem. Note that we can not just call schedule_work conditionally in cdn_dp_pd_event() if the insertion status changed. The problem would still be seen if a monitor is connected for the first time during suspend. Signed-off-by: Guenter Roeck Signed-off-by: Sean Paul Signed-off-by: Chris Zhong --- Changes in v17: None drivers/gpu/drm/rockchip/cdn-dp-core.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c index 7db2508..b8d0dd7 100644 --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c @@ -1021,7 +1021,6 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data) struct cdn_dp_port *port; struct drm_device *drm_dev = data; int ret, i; - bool schedule_event = false; ret = cdn_dp_parse_dt(dp); if (ret < 0) @@ -1083,15 +1082,11 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data) "register EXTCON_DISP_DP notifier err\n"); goto err_free_connector; } - - if (extcon_get_state(port->extcon, EXTCON_DISP_DP)) - schedule_event = true; } pm_runtime_enable(dev); - if (schedule_event) - schedule_work(&dp->event_work); + schedule_work(&dp->event_work); return 0; -- 2.6.3
[PATCH v17 5/7] drm/rockchip: cdn-dp: Move mutex_init to probe
From: Jeffy Chen We're trying to lock mutex when cdn-dp shutdown, so we need to make sure the mutex is inited in cdn-dp's probe. Signed-off-by: Jeffy Chen Reviewed-by: Guenter Roeck Reviewed-by: Chris Zhong Signed-off-by: Chris Zhong --- Changes in v17: None drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c index 62e02a4..799e826 100644 --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c @@ -1041,7 +1041,6 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data) dp->connected = false; dp->active = false; - mutex_init(&dp->lock); INIT_WORK(&dp->event_work, cdn_dp_pd_event_work); encoder = &dp->encoder; @@ -1204,6 +1203,7 @@ static int cdn_dp_probe(struct platform_device *pdev) return -EINVAL; } + mutex_init(&dp->lock); dev_set_drvdata(dev, dp); return component_add(dev, &cdn_dp_component_ops); -- 2.6.3
[PATCH v17 6/7] drm/rockchip: cdn-dp: retry to check sink count
Sometimes the Dock is disconnected, but cdn_dp_encoder_disable is not
triggered by DRM. For example, unplug the Dock in console mode, and
re-plug it again, the cdn_dp_event_work will try to get the sink count
of Dock, since the DP is still active. But the Dock has been powered
down, it need re-power on, and wait for a while until it is ready to
DPCD communication.
Signed-off-by: Chris Zhong
---
Changes in v17: None
drivers/gpu/drm/rockchip/cdn-dp-core.c | 91 +++---
drivers/gpu/drm/rockchip/cdn-dp-core.h | 1 +
2 files changed, 52 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 799e826..a630b0d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -197,6 +197,39 @@ static struct cdn_dp_port *cdn_dp_connected_port(struct
cdn_dp_device *dp)
return NULL;
}
+static bool cdn_dp_check_sink_connection(struct cdn_dp_device *dp)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(CDN_DPCD_TIMEOUT_MS);
+ struct cdn_dp_port *port;
+ u8 sink_count = 0;
+
+ if (dp->active_port < 0 || dp->active_port >= dp->ports) {
+ DRM_DEV_ERROR(dp->dev, "active_port is wrong!\n");
+ return false;
+ }
+
+ port = dp->port[dp->active_port];
+
+ /*
+* Attempt to read sink count, retry in case the sink may not be ready.
+*
+* Sinks are *supposed* to come up within 1ms from an off state, but
+* some docks need more time to power up.
+*/
+ while (time_before(jiffies, timeout)) {
+ if (!extcon_get_state(port->extcon, EXTCON_DISP_DP))
+ return false;
+
+ if (!cdn_dp_get_sink_count(dp, &sink_count))
+ return sink_count ? true : false;
+
+ usleep_range(5000, 1);
+ }
+
+ DRM_DEV_ERROR(dp->dev, "Get sink capability timed out\n");
+ return false;
+}
+
static enum drm_connector_status
cdn_dp_connector_detect(struct drm_connector *connector, bool force)
{
@@ -345,47 +378,24 @@ static int cdn_dp_firmware_init(struct cdn_dp_device *dp)
return cdn_dp_event_config(dp);
}
-static int cdn_dp_get_sink_capability(struct cdn_dp_device *dp,
- struct cdn_dp_port *port,
- u8 *sink_count)
+static int cdn_dp_get_sink_capability(struct cdn_dp_device *dp)
{
int ret;
- unsigned long timeout = jiffies + msecs_to_jiffies(CDN_DPCD_TIMEOUT_MS);
- /*
-* Attempt to read sink count & sink capability, retry in case the sink
-* may not be ready.
-*
-* Sinks are *supposed* to come up within 1ms from an off state, but
-* some docks need more time to power up.
-*/
- while (time_before(jiffies, timeout)) {
- if (!extcon_get_state(port->extcon, EXTCON_DISP_DP))
- return -ENODEV;
-
- if (cdn_dp_get_sink_count(dp, sink_count)) {
- usleep_range(5000, 1);
- continue;
- }
-
- if (!*sink_count)
- return -ENODEV;
-
- ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
- DP_RECEIVER_CAP_SIZE);
- if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
- return ret;
- }
+ if (!cdn_dp_check_sink_connection(dp))
+ return -ENODEV;
- kfree(dp->edid);
- dp->edid = drm_do_get_edid(&dp->connector,
- cdn_dp_get_edid_block, dp);
- return 0;
+ ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
+ DP_RECEIVER_CAP_SIZE);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
+ return ret;
}
- DRM_DEV_ERROR(dp->dev, "Get sink capability timed out\n");
- return -ETIMEDOUT;
+ kfree(dp->edid);
+ dp->edid = drm_do_get_edid(&dp->connector,
+ cdn_dp_get_edid_block, dp);
+ return 0;
}
static int cdn_dp_enable_phy(struct cdn_dp_device *dp, struct cdn_dp_port
*port)
@@ -437,6 +447,7 @@ static int cdn_dp_enable_phy(struct cdn_dp_device *dp,
struct cdn_dp_port *port)
goto err_power_on;
}
+ dp->active_port = port->id;
return 0;
err_power_on:
@@ -466,6 +477,7 @@ static int cdn_dp_disable_phy(struct cdn_dp_device *dp,
port->phy_enabled = false;
port->lanes = 0;
+ dp->active_port = -1;
return 0;
}
@@ -504,7 +516,6 @@ static int cdn_dp_enable(struct cdn_dp_device *dp)
{
int ret, i, lanes;
struct cdn_dp_port *port;
- u8 sink
[PATCH v17 4/7] drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event
The cdn_dp_pd_event_work is using drm_helper_hpd_irq_event to update the
connector status, this function is used to update all connectors of
drm_device. Therefore, the detect of other connector will be call, when
cdn_dp_pd_event_work is triggered, every time. It is not necessary, and
it may cause system crash. replace drm_helper_hpd_irq_event with
drm_kms_helper_hotplug_event, only update cdn-dp status.
Signed-off-by: Chris Zhong
Tested-by: Guenter Roeck
Reviewed-by: Guenter Roeck
---
Changes in v17: None
drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a70eedc..62e02a4 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -935,6 +935,9 @@ static void cdn_dp_pd_event_work(struct work_struct *work)
{
struct cdn_dp_device *dp = container_of(work, struct cdn_dp_device,
event_work);
+ struct drm_connector *connector = &dp->connector;
+ enum drm_connector_status old_status;
+
int ret;
u8 sink_count;
@@ -997,7 +1000,11 @@ static void cdn_dp_pd_event_work(struct work_struct *work)
out:
mutex_unlock(&dp->lock);
- drm_helper_hpd_irq_event(dp->drm_dev);
+
+ old_status = connector->status;
+ connector->status = connector->funcs->detect(connector, false);
+ if (old_status != connector->status)
+ drm_kms_helper_hotplug_event(dp->drm_dev);
}
static int cdn_dp_pd_event(struct notifier_block *nb,
--
2.6.3
[PATCH v17 7/7] drm/rockchip: cdn-dp: don't configure hardware in mode_set
With atomic modesetting the hardware will be powered off when the
mode_set function is called. We should configure the hardware in the
enable function.
Signed-off-by: Chris Zhong
---
Changes in v17: None
drivers/gpu/drm/rockchip/cdn-dp-core.c | 49 +-
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a630b0d..9ab67a6 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -568,9 +568,7 @@ static void cdn_dp_encoder_mode_set(struct drm_encoder
*encoder,
{
struct cdn_dp_device *dp = encoder_to_dp(encoder);
struct drm_display_info *display_info = &dp->connector.display_info;
- struct rockchip_crtc_state *state;
struct video_info *video = &dp->video_info;
- int ret, val;
switch (display_info->bpc) {
case 10:
@@ -585,31 +583,9 @@ static void cdn_dp_encoder_mode_set(struct drm_encoder
*encoder,
}
video->color_fmt = PXL_RGB;
-
video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
- ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
- if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "Could not get vop id, %d", ret);
- return;
- }
-
- DRM_DEV_DEBUG_KMS(dp->dev, "vop %s output to cdn-dp\n",
- (ret) ? "LIT" : "BIG");
- state = to_rockchip_crtc_state(encoder->crtc->state);
- if (ret) {
- val = DP_SEL_VOP_LIT | (DP_SEL_VOP_LIT << 16);
- state->output_mode = ROCKCHIP_OUT_MODE_P888;
- } else {
- val = DP_SEL_VOP_LIT << 16;
- state->output_mode = ROCKCHIP_OUT_MODE_;
- }
-
- ret = cdn_dp_grf_write(dp, GRF_SOC_CON9, val);
- if (ret)
- return;
-
memcpy(&dp->mode, adjusted, sizeof(*mode));
}
@@ -635,9 +611,32 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device
*dp)
static void cdn_dp_encoder_enable(struct drm_encoder *encoder)
{
struct cdn_dp_device *dp = encoder_to_dp(encoder);
- int ret;
+ int ret, val;
+ struct rockchip_crtc_state *state;
+
+ ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dp->dev, "Could not get vop id, %d", ret);
+ return;
+ }
+
+ DRM_DEV_DEBUG_KMS(dp->dev, "vop %s output to cdn-dp\n",
+ (ret) ? "LIT" : "BIG");
+ state = to_rockchip_crtc_state(encoder->crtc->state);
+ if (ret) {
+ val = DP_SEL_VOP_LIT | (DP_SEL_VOP_LIT << 16);
+ state->output_mode = ROCKCHIP_OUT_MODE_P888;
+ } else {
+ val = DP_SEL_VOP_LIT << 16;
+ state->output_mode = ROCKCHIP_OUT_MODE_;
+ }
+
+ ret = cdn_dp_grf_write(dp, GRF_SOC_CON9, val);
+ if (ret)
+ return;
mutex_lock(&dp->lock);
+
ret = cdn_dp_enable(dp);
if (ret) {
DRM_DEV_ERROR(dp->dev, "Failed to enable encoder %d\n",
--
2.6.3
[PATCH v17 0/7] drm/rockchip: Add CDN DP driver
This series adds support for the CDN DP controller to the rockchip drm driver. This version fixes some coding style error in v16, it post by Sean Paul, you can find it here: https://patchwork.kernel.org/patch/9442135/ And I sorted out a few patches to fix the following problems: - suspend/resume crash cause by drm_helper_hpd_irq_event - crash during shutdown when cdn-dp failed to bind - check sink count failed after reconnection - suspend/reusme crash in mode_set function I also added these 2 patches to this series, although nothing changed: https://patchwork.kernel.org/patch/9442141/ https://patchwork.kernel.org/patch/9442151/ Changes in v17: - Correct the clock check condition - Correct the coding style - change LANE_REF_CYC to 0x8000 Chris Zhong (4): drm/rockchip: cdn-dp: add cdn DP support for rk3399 drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event drm/rockchip: cdn-dp: retry to check sink count drm/rockchip: cdn-dp: don't configure hardware in mode_set Guenter Roeck (2): drm/rockchip: cdn-dp: Load firmware if no monitor connected drm/rockchip: cdn-dp: Do not run worker while suspended Jeffy Chen (1): drm/rockchip: cdn-dp: Move mutex_init to probe drivers/gpu/drm/rockchip/Kconfig| 10 + drivers/gpu/drm/rockchip/Makefile |2 + drivers/gpu/drm/rockchip/cdn-dp-core.c | 1260 +++ drivers/gpu/drm/rockchip/cdn-dp-core.h | 112 +++ drivers/gpu/drm/rockchip/cdn-dp-reg.c | 979 + drivers/gpu/drm/rockchip/cdn-dp-reg.h | 483 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 + 9 files changed, 2867 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h -- 2.6.3
[PATCH v17 1/7] drm/rockchip: cdn-dp: add cdn DP support for rk3399
Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/rockchip/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.
Signed-off-by: Chris Zhong
[seanpaul fixed up some races between the worker and modeset]
[seanpaul squashed ~15 commits from chromium.org gerrit]
Signed-off-by: Sean Paul
[groeck fixed compilation errors when building as module]
Signed-off-by: Guenter Roeck
---
Changes in v17:
- Correct the clock check condition
- Correct the coding style
- change LANE_REF_CYC to 0x8000
drivers/gpu/drm/rockchip/Kconfig| 10 +
drivers/gpu/drm/rockchip/Makefile |2 +
drivers/gpu/drm/rockchip/cdn-dp-core.c | 1237 +++
drivers/gpu/drm/rockchip/cdn-dp-core.h | 110 +++
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 979 +
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 483 +++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 +
9 files changed, 2842 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 6f7f9c5..ad31b3e 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -21,6 +21,16 @@ config ROCKCHIP_ANALOGIX_DP
for the Analogix Core DP driver. If you want to enable DP
on RK3288 based SoC, you should selet this option.
+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+ select SND_SOC_HDMI_CODEC if SND_SOC
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn DP driver. If you want to enable Dp on
+ RK3399 based SoC, you should select this
+ option.
+
config ROCKCHIP_DW_HDMI
tristate "Rockchip specific extensions for Synopsys DW HDMI"
depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index 9746365..c931e2a 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp.o
+cdn-dp-objs := cdn-dp-core.o cdn-dp-reg.o
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
new file mode 100644
index 000..7db2508
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -0,0 +1,1237 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "cdn-dp-core.h"
+#include "cdn-dp-reg.h"
+#include "rockchip_drm_vop.h"
+
+#define connector_to_dp(c) \
+ container_of(c, struct cdn_dp_device, connector)
+
+#define encoder_to_dp(c) \
+ container_of(c, struct cdn_dp_device, encoder)
+
+#define GRF_SOC_CON9 0x6224
+#define DP_SEL_VOP_LIT BIT(12)
+#define GRF_SOC_CON26 0x6268
+#define UPHY_SEL_BIT 3
+#define UPHY_SEL_MASK BIT(19)
+#define DPTX_HPD_SEL (3 << 12)
+#define DPTX_HPD_DEL (2 << 12)
+#define DPTX_HPD_SEL_MASK (3 << 28)
+
+#define CDN_FW_TIMEOUT_MS (64 * 1000)
+#define CDN_DPCD_TIMEOUT_MS5000
+#define CDN_DP_FIRMWARE"rockchip/dptx.bin"
+
+struct cdn_dp_data {
+ u8 max_phy;
+};
+
+struct cdn_dp_data rk3399_cdn_dp = {
+ .max_phy = 2,
+};
+
+static const struct of_de
Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount
On Sat, Feb 4, 2017 at 9:19 PM, James Bottomley
wrote:
> This allows any subtree to be uid/gid shifted and bound elsewhere. It
> does this by operating simlarly to overlayfs. Its primary use is for
> shifting the underlying uids of filesystems used to support
> unpriviliged (uid shifted) containers. The usual use case here is
> that the container is operating with an uid shifted unprivileged root
> but sometimes needs to make use of or work with a filesystem image
> that has root at real uid 0.
>
> The mechanism is to allow any subordinate mount namespace to mount a
> shiftfs filesystem (by marking it FS_USERNS_MOUNT) but only allowing
> it to mount marked subtrees (using the -o mark option as root). Once
> mounted, the subtree is mapped via the super block user namespace so
> that the interior ids of the mounting user namespace are the ids
> written to the filesystem.
>
> Signed-off-by: James Bottomley
>
James,
Allow me to point out some problems in this patch and offer a slightly different
approach.
First of all, the subject says "uid/gid shifting bind mount", but it's not
really a bind mount. What it is is a stackable mount and 2 levels of
stack no less.
So one thing that is missing is increasing of sb->s_stack_depth and that
also means that shiftfs cannot be used to recursively shift uids in child userns
if that was ever the intention.
The other problem is that by forking overlayfs functionality, shiftfs is going
to miss out on overlayfs bug fixes related to user credentials differ
from mounter
credentials, like fd3220d ("ovl: update S_ISGID when setting posix ACLs").
I am not sure that this specific case is relevant to shiftfs, but
there could be other.
So how about, instead of forking a new containers specialized stackable fs,
that the needed functionality be merged into overlayfs code?
I think overlayfs container users may also benefit from shiftfs
functionality, no?
In any case, overlayfs has considerable millage used as fs for containers,
so many issues related to running with different userns may have already been
addressed.
Overlayfs already stores the mounter's credentials and uses them to perform
most of the operations on upper.
I know it wasn't the original purpose of overlayfs to run as a single layer, but
there is nothing really preventing from doing that. In fact, I am
doing just that
with my snapshot mount patches, see:
https://github.com/amir73il/linux/commit/acc6c25eab03c176c9ef736544fab3fba663765d#diff-2b85a3c5bea4263d08a2bdff639192c3
I registered a new fs type ("snapshot"), which reuses most of the existing
overlayfs operations.
With this patch it is possible to mount an overlay with only upper layer, so all
the operations are pass through except for the credentials, e.g.:
mount -t snapshot -o upper= shiftfs_test
If you think this concept is workable, then the functionality of
mounting overlayfs
with only upper should be integrated into plain overlayfs and shiftfs could be
a very thin variant of overlayfs mount using shitfs_fs_type, just for the sake
of having FS_USERNS_MOUNT, e.g:
+ /*
+ * XXX: reusing ovl_mount()/ovl_fill_super(), but could also just reuse
+ *
ovl_dentry_operations/ovl_super_operations/ovl_xattr_handlers/ovl_new_inode()
+ */
+static struct file_system_type shiftfs_type = {
+ .owner = THIS_MODULE,
+ .name = "shiftfs",
+ .mount = ovl_mount,
+ .kill_sb= kill_anon_super,
+ .fs_flags = FS_USERNS_MOUNT,
+};
+MODULE_ALIAS_FS("shiftfs");
+MODULE_ALIAS("shiftfs");
+#define IS_SHIFTFS_SB(sb) ((sb)->s_type == &shiftfs_type)
And instead of verifying that shiftfs is mounted inside container over shiftfs,
verify that it is mounted over an overlayfs noexec mount e.g.:
+ if (IS_SHIFTFS_SB(sb)) {
+ /*
+* this leg executes if we're admin capable in
+* the namespace, so be very careful
+*/
+ if (path.dentry->d_sb->s_magic != OVERLAYFS_MAGIC ||
!(path.dentry->d_sb->s_iflags & SB_I_NOEXEC))
+ goto out_put;
>From users manual POV:
in host:
mount -t overlay -o noexec,upper= container_visible
in container:
mount -t shiftfs -o upper= container_writable
Thought?
Re: [PATCH v3 3/5] drm/rockchip/dsi: remove mode_valid function
On 2017年02月05日 11:42, Chris Zhong wrote:
On 02/02/2017 02:12 AM, Sean Paul wrote:
On Tue, Jan 24, 2017 at 10:27:27AM +0800, Chris Zhong wrote:
Hi Sean
On 01/24/2017 01:48 AM, Sean Paul wrote:
On Fri, Jan 20, 2017 at 06:10:49PM +0800, Chris Zhong wrote:
The MIPI DSI do not need check the validity of resolution, the max
resolution should depend VOP. Hence, remove
rk3288_mipi_dsi_mode_valid
here.
Does vop actually enforce this, though? I see that
mode_config.max_width is
4096, but there is no bounds checking in mode_fixup().
The connector is currently rejecting everything greater than 2047.
So I think
you're going to regress behavior here.
Sean
The mipi controller has not this width limit, it depend the VOP,
such as RK3399, VOP_LIT only support 2560,
but VOP_BIG support 4K. So this driver should check the width here.
I don't see anything in the vop driver that rejects large modes for
little vop.
So, while I agree the check shouldn't be here, you should move it to
where it
should be instead of removing it entirely.
Sean
drm_mode_validate_size will check the dev->mode_config.max_width and
dev->mode_config.max_height, these 2 value come from
rockchip_drm_mode_config_init,
currently, they are both 4096. So you are right, drm driver does not
distinguish
between vop lit and big.
I think Mark Yao already have a local solution, and he will post it soon.
Hi
See follow patches, support mode valid with vop callback.
[0] https://patchwork.kernel.org/patch/9555943/
[1] https://patchwork.kernel.org/patch/9555945/
Signed-off-by: Chris Zhong
---
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39
--
1 file changed, 39 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index a93ce97..6f0e252 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -278,8 +278,6 @@ struct dw_mipi_dsi_plat_data {
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
-enum drm_mode_status (*mode_valid)(struct drm_connector
*connector,
- struct drm_display_mode *mode);
};
struct dw_mipi_dsi {
@@ -1081,23 +1079,8 @@ static int
dw_mipi_dsi_connector_get_modes(struct drm_connector *connector)
return drm_panel_get_modes(dsi->panel);
}
-static enum drm_mode_status dw_mipi_dsi_mode_valid(
-struct drm_connector *connector,
-struct drm_display_mode *mode)
-{
-struct dw_mipi_dsi *dsi = con_to_dsi(connector);
-
-enum drm_mode_status mode_status = MODE_OK;
-
-if (dsi->pdata->mode_valid)
-mode_status = dsi->pdata->mode_valid(connector, mode);
-
-return mode_status;
-}
-
static struct drm_connector_helper_funcs
dw_mipi_dsi_connector_helper_funcs = {
.get_modes = dw_mipi_dsi_connector_get_modes,
-.mode_valid = dw_mipi_dsi_mode_valid,
};
static void dw_mipi_dsi_drm_connector_destroy(struct
drm_connector *connector)
@@ -1168,33 +1151,11 @@ static int rockchip_mipi_parse_dt(struct
dw_mipi_dsi *dsi)
return 0;
}
-static enum drm_mode_status rk3288_mipi_dsi_mode_valid(
-struct drm_connector *connector,
-struct drm_display_mode *mode)
-{
-/*
- * The VID_PKT_SIZE field in the DSI_VID_PKT_CFG
- * register is 11-bit.
- */
-if (mode->hdisplay > 0x7ff)
-return MODE_BAD_HVALUE;
-
-/*
- * The V_ACTIVE_LINES field in the DSI_VTIMING_CFG
- * register is 11-bit.
- */
-if (mode->vdisplay > 0x7ff)
-return MODE_BAD_VVALUE;
-
-return MODE_OK;
-}
-
static struct dw_mipi_dsi_plat_data rk3288_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3288_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3288_DSI1_SEL_VOP_LIT,
.grf_switch_reg = RK3288_GRF_SOC_CON6,
.max_data_lanes = 4,
-.mode_valid = rk3288_mipi_dsi_mode_valid,
};
static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
--
2.6.3
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ｍark Yao
Re: [PATCH v2] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver
On Fri, Feb 03, 2017 at 11:55:24AM +0100, Richard Leitner wrote:
> +/**
> + * ascii2utf16le() - Helper routine for producing UTF-16LE string descriptors
> + * @s: Null-terminated ASCII (actually ISO-8859-1) string
> + * @buf: Buffer for UTF-16LE string
> + * @len: Length (in bytes; may be odd) of UTF-16LE buffer.
> + *
> + * Return: The number of bytes filled in: 2*strlen(s) or @len, whichever is
> less
> + *
> + * Note:
> + * The UTF-16LE USB String descriptors can contain at most 31 characters (as
> + * specified in the datasheet); input strings longer than that are truncated.
> + *
> + * Based on ascii2desc from drivers/usb/core/hcd.c
> + */
> +static unsigned int ascii2utf16le(char const *s, u8 *buf, unsigned int len)
> +{
> + unsigned int n, t = 2 * strlen(s);
> +
> + if (t > USB251XB_STRING_BUFSIZE)
> + t = USB251XB_STRING_BUFSIZE;
> + if (len > t)
> + len = t;
> + n = len;
> + while (n--) {
> + t = (unsigned char)*s++;
> + *buf++ = t;
> + if (!n--)
> + break;
> + *buf++ = t >> 8;
> + }
> + return len;
> +}
Don't we have a kernel function for this already? If we need to export
ascii2desc() from the USB core, we can do that, or better yet, move both
of them to a string library function in the core part of the kernel. We
shouldn't have to duplicate this type of thin in an individual driver.
> --- /dev/null
> +++ b/include/linux/platform_data/usb251xb.h
> @@ -0,0 +1,33 @@
> +#ifndef __USB251XB_H__
> +#define __USB251XB_H__
> +
> +struct usb251xb_platform_data {
> + int gpio_reset;
> + u16 vendor_id;
> + u16 product_id;
> + u16 device_id;
> + u8 conf_data1;
> + u8 conf_data2;
> + u8 conf_data3;
> + u8 non_rem_dev;
> + u8 port_disable_sp;
> + u8 port_disable_bp;
> + u8 max_power_sp;
> + u8 max_power_bp;
> + u8 max_current_sp;
> + u8 max_current_bp;
> + u8 power_on_time;
> + u16 lang_id;
> + char manufacturer[31]; /* NULL terminated ASCII string */
> + char product[31]; /* NULL terminated ASCII string */
> + char serial[31];/* NULL terminated ASCII string */
> + u8 bat_charge_en;
> + u8 boost_up;
> + u8 boost_x;
> + u8 port_swap;
> + u8 port_map12;
> + u8 port_map34;
> + u8 status;
> +};
Do you need a platform data structure here? Shouldn't we be only using
DT now?
thanks,
greg k-h
[PATCH 2/2] drm/rockchip: dw_hdmi: check display mode with crtc mode valid
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 47 +++--
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index a6d4a02..64408bc 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -158,18 +158,59 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi
*hdmi)
struct drm_display_mode *mode)
{
const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
+ struct drm_device *dev = connector->dev;
+ struct drm_encoder *encoder = connector->encoder;
+ struct rockchip_drm_private *priv = dev->dev_private;
int pclk = mode->clock * 1000;
- bool valid = false;
+ enum drm_mode_status status = MODE_BAD;
+ struct drm_crtc *crtc;
int i;
for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++) {
if (pclk == mpll_cfg[i].mpixelclock) {
- valid = true;
+ status = MODE_OK;
break;
}
}
- return (valid) ? MODE_OK : MODE_BAD;
+
+ if (status != MODE_OK)
+ return status;
+
+ if (!encoder) {
+ const struct drm_connector_helper_funcs *funcs;
+
+ funcs = connector->helper_private;
+ if (funcs->atomic_best_encoder)
+ encoder = funcs->atomic_best_encoder(connector,
+connector->state);
+ else
+ encoder = funcs->best_encoder(connector);
+ }
+
+ if (!encoder || !encoder->possible_crtcs)
+ return MODE_BAD;
+ /*
+* ensure all drm display mode can work, if someone want support more
+* resolutions, please limit the possible_crtc, only connect to
+* needed crtc.
+*/
+ drm_for_each_crtc(crtc, connector->dev) {
+ int pipe = drm_crtc_index(crtc);
+ const struct rockchip_crtc_funcs *funcs =
+ priv->crtc_funcs[pipe];
+
+ if (!(encoder->possible_crtcs & drm_crtc_mask(crtc)))
+ continue;
+ if (!funcs || !funcs->mode_valid)
+ continue;
+
+ status = funcs->mode_valid(crtc, mode);
+ if (status != MODE_OK)
+ return status;
+ }
+
+ return status;
}
static const struct drm_encoder_funcs dw_hdmi_rockchip_encoder_funcs = {
--
1.9.1
[PATCH 1/2] drm/rockchip: support mode_valid for crtc
drm crtc already has mode_fixup callback to can do mode check, but
We actually want to valid display mode on connector getmode time,
mode_fixup can't do it.
So add a private mode_valid callback to rockchip crtc, connectors can
check mode with this mode_valid callback.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 ++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 +++
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 7 +++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 +
4 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index fb6226c..d10b15c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -39,6 +39,8 @@
struct rockchip_crtc_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
+ enum drm_mode_status (*mode_valid)(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode);
};
struct rockchip_crtc_state {
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb5f001..256fe73 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -853,9 +853,24 @@ static void vop_crtc_disable_vblank(struct drm_crtc *crtc)
spin_unlock_irqrestore(&vop->irq_lock, flags);
}
+static enum drm_mode_status
+vop_crtc_mode_valid(struct drm_crtc *crtc, const struct drm_display_mode *mode)
+{
+ struct vop *vop = to_vop(crtc);
+ const struct vop_data *vop_data = vop->data;
+
+ if (mode->hdisplay > vop_data->max_output.width)
+ return MODE_BAD_HVALUE;
+ if (mode->vdisplay > vop_data->max_output.height)
+ return MODE_BAD_VVALUE;
+
+ return MODE_OK;
+}
+
static const struct rockchip_crtc_funcs private_crtc_funcs = {
.enable_vblank = vop_crtc_enable_vblank,
.disable_vblank = vop_crtc_disable_vblank,
+ .mode_valid = vop_crtc_mode_valid,
};
static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 1dbc526..9e9dba1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -133,6 +133,11 @@ struct vop_win_data {
enum drm_plane_type type;
};
+struct vop_rect {
+ int width;
+ int height;
+};
+
struct vop_data {
const struct vop_reg_data *init_table;
unsigned int table_size;
@@ -140,6 +145,8 @@ struct vop_data {
const struct vop_intr *intr;
const struct vop_win_data *win;
unsigned int win_size;
+ struct vop_rect max_input;
+ struct vop_rect max_output;
};
/* interrupt define */
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 35c51f3..0c72361 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -132,6 +132,8 @@
};
static const struct vop_data rk3036_vop = {
+ .max_input = { 1920, 1080},
+ .max_output = { 1920, 1080},
.init_table = rk3036_vop_init_reg_table,
.table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
.ctrl = &rk3036_ctrl_data,
@@ -273,6 +275,13 @@
};
static const struct vop_data rk3288_vop = {
+ .max_input = { 4096, 8192},
+ /*
+* TODO: rk3288 have two vop, big one support 3840x2160,
+* little one only support 2560x1600.
+* Now force use 3840x2160.
+*/
+ .max_output = { 3840, 2160},
.init_table = rk3288_init_reg_table,
.table_size = ARRAY_SIZE(rk3288_init_reg_table),
.intr = &rk3288_vop_intr,
@@ -339,6 +348,8 @@
};
static const struct vop_data rk3399_vop_big = {
+ .max_input = { 4096, 8192},
+ .max_output = { 4096, 2160},
.init_table = rk3399_init_reg_table,
.table_size = ARRAY_SIZE(rk3399_init_reg_table),
.intr = &rk3399_vop_intr,
@@ -358,6 +369,8 @@
};
static const struct vop_data rk3399_vop_lit = {
+ .max_input = { 4096, 8192},
+ .max_output = { 2560, 1600},
.init_table = rk3399_init_reg_table,
.table_size = ARRAY_SIZE(rk3399_init_reg_table),
.intr = &rk3399_vop_intr,
--
1.9.1
Re: pciehp is broken from 4.10-rc1
On Sat, Feb 04, 2017 at 08:22:59PM -0800, Yinghai Lu wrote:
> On Sat, Feb 4, 2017 at 3:34 PM, Lukas Wunner wrote:
> > On Sat, Feb 04, 2017 at 01:44:34PM -0800, Yinghai Lu wrote:
> >> On Sat, Feb 4, 2017 at 10:56 AM, Lukas Wunner wrote:
> >> > On Sat, Feb 04, 2017 at 09:12:54AM +0100, Lukas Wunner wrote:
> >> > Section 6.7.3.4 of the PCIe Base spec seems to support the theory above,
> >> > so here's a tentative patch.
> >> >
> >> > -- >8 --
> >> > Subject: [PATCH] PCI: pciehp: Don't enable PME on runtime suspend
> >>
> >> it works:
> >
> > Thanks a lot for the report and for testing the patch!
>
> Wait, Commit 68db9bc still has problem with another server (skylake
> based), and this patch does not help.
[...]
> sca05-0a81fd8d:~ # echo 1 > /sys/bus/pci/slots/11/power
> [ 375.376609] pci_hotplug: power_write_file: power = 1
> [ 375.382175] pciehp :b3:00.0:pcie004: pciehp_get_power_status: SLOTCTRL
> a8 value read 17f1
> [ 375.392695] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from
> Slot Status
> [ 375.401370] pciehp :b3:00.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8
> write cmd 0
> [ 375.410231] pciehp :b3:00.0:pcie004: pciehp_green_led_blink: SLOTCTRL
> a8 write cmd 200
> [ 375.411071] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from
> Slot Status
> [ 375.445222] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from
> Slot Status
> [ 377.00] pciehp :b3:00.0:pcie004: Data Link Layer Link Active not
> set in 1000 msec
> [ 378.960364] pci :b4:00.0 id reading try 50 times with interval 20 ms
> to get
> [ 378.969406] pciehp :b3:00.0:pcie004: pciehp_check_link_status:
> lnk_status = 5001
> [ 378.978059] pciehp :b3:00.0:pcie004: link training error: status 0x5001
> [ 378.985834] pciehp :b3:00.0:pcie004: Failed to check link status
> [ 378.987185] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from
> Slot Status
> [ 378.987253] pciehp :b3:00.0:pcie004: pciehp_power_off_slot: SLOTCTRL
> a8 write cmd 400
> [ 380.000409] pciehp :b3:00.0:pcie004: pciehp_green_led_off: SLOTCTRL a8
> write cmd 300
> [ 380.000674] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from
> Slot Status
> [ 380.018020] pciehp :b3:00.0:pcie004: pciehp_set_attention_status:
> SLOTCTRL a8 write cmd 40
> [ 380.019053] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from
> Slot Status
So on this Skylake machine link training fails after resuming from D3hot
to D0.
One thing that's a bit fishy is that normally the Link Disable bit is
cleared when powering on the slot. This results in a debug message
in dmesg containg the string "lnk_ctrl = ", and that line is missing
from the output you've pasted above, suggesting that the machine is
not running a stock v4.10 kernel after all but something else. Could
you check why this message is not printed? Could you check with lspci
if the Link Disable bit is set before you invoke "echo 1"?
This is the call stack:
pciehp_sysfs_enable_slot()
pciehp_enable_slot()
board_added()
pciehp_power_on_slot()
pciehp_link_enable()
__pciehp_link_set()
Another theory is that the link is generally unreliable on this machine
since the Link Bandwidth Management Status bit is set in the Link Status
Register ("lnk_status = 5001"), which according to the spec means:
"Hardware has changed Link speed or width to attempt to correct unreliable
Link operation, either through an LTSSM timeout or a higher level process.
This bit must be set if the Physical Layer reports a speed or width change
was initiated by the Downstream component that was not indicated as an
autonomous change."
In this case it would be good to know which hardware exactly we're dealing
with so that we might quirk it to not runtime suspend the port. To that
end, could you attach a full dmesg log to the bugzilla entry I've created?
https://bugzilla.kernel.org/show_bug.cgi?id=193951
@Mika, Rafael: Are you aware of Skylake machines with unreliable link
training, or perhaps errata of Skylake chips related to link training
on hotplug ports?
Thanks,
Lukas
Re: [PATCH v3 08/10] dmaengine: sun6i: allow build on ARM64 platforms (sun50i)
On Sun, Jan 29, 2017 at 10:33:29AM +0800, Icenowy Zheng wrote: > As 64-bit Allwinner H5 SoC has the same DMA engine with H3, the DMA > driver should be allowed to be built for ARM64, in order to make it work on > H5. Applied, thanks -- ~Vinod
Re: [PATCH] somedriver: remove the initialization of static pointers.
On Sun, 5 Feb 2017 01:29:43 +0100 Greg Kroah-Hartman wrote: > On Sat, Feb 04, 2017 at 08:39:21PM +0100, AbdAllah-MEZITI wrote: > > In C a static pointer will be initialized to NULL (e.g: draft C99 > > standard $6.7.8): "If an object that has static storage duration is > > not initialized explicitly, then: > > __ if it has pointer type, it is initialized to a null pointer;" > > > > Signed-off-by: AbdAllah-MEZITI > > Your subject is very odd :( > > And is that the correct spelling of your name that you use for legal > documents? If not, please fix up when you resend this. > > Also, fix the line-wrapping of your changelog, and the C99 standard is > not a "draft" anymore, it was released in 1999 :) > > thanks, > > greg k-h Do not worry, this is just an answer to the Task 10 of the Eudyptula Challenge. yes, this is the correct spelling of my name that i use for legal documents. OK. AbdAllah MEZITI.
[PATCH 1/2] libceph: Remove unneeded stddef.h include
This was causing a build failure for openrisc when using musl and gcc 5.4.0 since the file is not available in the toolchain. It doesnt seem this is needed and removing it does not cause any build warnings for me. Signed-off-by: Stafford Horne --- net/ceph/snapshot.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/net/ceph/snapshot.c b/net/ceph/snapshot.c index 154683f..705414e 100644 --- a/net/ceph/snapshot.c +++ b/net/ceph/snapshot.c @@ -18,8 +18,6 @@ * 02110-1301, USA. */ -#include - #include #include #include -- 2.9.3
[PATCH 2/2] staging: vchip_shim: Remove unneeded stddef.h include
Building on openrisc musl toolchain this causes the allyesconfig build
to fail.
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c:42:20:
fatal error: stddef.h: No such file or directory
Removing this causes no issues with the build.
Signed-off-by: Stafford Horne
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
index d977139..70c530c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
@@ -39,8 +39,6 @@
#include "vchiq_util.h"
-#include
-
#define vchiq_status_to_vchi(status) ((int32_t)status)
typedef struct {
--
2.9.3
[PATCH 0/2] Remove unneeded stddef.h includes
Hi All, These were causing openrisc build to fail when building with allyesconfig using a musl toolchain. Removing them doesnt seem to cause any issues. The line removed was: #include Perhaps what was wanted was 'linux/stddef.h' but there did seem to be any special uses so I just removed it. Also, sending these patches should help the kbuild robots verify that. If I can get acks I will push it in with my openrisc branch. But if this should got through the net and staging paths I am happy with that. -Stafford Stafford Horne (2): libceph: Remove unneeded stddef.h include staging: vchip_shim: Remove unneeded stddef.h include drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c | 2 -- net/ceph/snapshot.c| 2 -- 2 files changed, 4 deletions(-) -- 2.9.3
[PATCH 0/4] md: use bio_clone_fast()
Hi, This patches replaces bio_clone() with bio_fast_clone() in bio_clone_mddev() because: 1) bio_clone_mddev() is used in raid normal I/O and isn't in resync I/O path, and all the direct access to bvec table in raid happens on resync I/O only except for write behind of raid1. Write behind is treated specially, so the replacement is safe. 2) for write behind, bio_clone() is kept, but this patchset introduces bio_clone_bioset_partial() to just clone one specific bvecs range instead of whole table. Then write behind is improved too. Thanks, Ming Ming Lei (4): block: introduce bio_clone_bioset_partial() md: introduce bio_clone_slow_mddev_partial() md/raid1: use bio_clone_slow_mddev_partial in case of write behind md: fast clone bio in bio_clone_mddev() block/bio.c | 61 + drivers/md/md.c | 24 +++-- drivers/md/md.h | 3 +++ drivers/md/raid1.c | 21 +- include/linux/bio.h | 11 -- 5 files changed, 98 insertions(+), 22 deletions(-) -- 2.7.4
[PATCH 1/4] block: introduce bio_clone_bioset_partial()
md still need bio clone(not the fast version) for behind write,
and it is more efficient to use bio_clone_bioset_partial().
The idea is simple and just copy the bvecs range specified from
parameters.
Signed-off-by: Ming Lei
---
block/bio.c | 61 +
include/linux/bio.h | 11 --
2 files changed, 57 insertions(+), 15 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index 4b564d0c3e29..5eec5e08417f 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -625,21 +625,20 @@ struct bio *bio_clone_fast(struct bio *bio, gfp_t
gfp_mask, struct bio_set *bs)
}
EXPORT_SYMBOL(bio_clone_fast);
-/**
- * bio_clone_bioset - clone a bio
- * @bio_src: bio to clone
- * @gfp_mask: allocation priority
- * @bs: bio_set to allocate from
- *
- * Clone bio. Caller will own the returned bio, but not the actual data it
- * points to. Reference count of returned bio will be one.
- */
-struct bio *bio_clone_bioset(struct bio *bio_src, gfp_t gfp_mask,
-struct bio_set *bs)
+static struct bio *__bio_clone_bioset(struct bio *bio_src, gfp_t gfp_mask,
+ struct bio_set *bs, int offset,
+ int size)
{
struct bvec_iter iter;
struct bio_vec bv;
struct bio *bio;
+ struct bvec_iter iter_src = bio_src->bi_iter;
+
+ /* for supporting partial clone */
+ if (offset || size != bio_src->bi_iter.bi_size) {
+ bio_advance_iter(bio_src, &iter_src, offset);
+ iter_src.bi_size = size;
+ }
/*
* Pre immutable biovecs, __bio_clone() used to just do a memcpy from
@@ -663,7 +662,8 @@ struct bio *bio_clone_bioset(struct bio *bio_src, gfp_t
gfp_mask,
*__bio_clone_fast() anyways.
*/
- bio = bio_alloc_bioset(gfp_mask, bio_segments(bio_src), bs);
+ bio = bio_alloc_bioset(gfp_mask, __bio_segments(bio_src,
+ &iter_src), bs);
if (!bio)
return NULL;
bio->bi_bdev= bio_src->bi_bdev;
@@ -680,7 +680,7 @@ struct bio *bio_clone_bioset(struct bio *bio_src, gfp_t
gfp_mask,
bio->bi_io_vec[bio->bi_vcnt++] = bio_src->bi_io_vec[0];
break;
default:
- bio_for_each_segment(bv, bio_src, iter)
+ __bio_for_each_segment(bv, bio_src, iter, iter_src)
bio->bi_io_vec[bio->bi_vcnt++] = bv;
break;
}
@@ -699,9 +699,44 @@ struct bio *bio_clone_bioset(struct bio *bio_src, gfp_t
gfp_mask,
return bio;
}
+
+/**
+ * bio_clone_bioset - clone a bio
+ * @bio_src: bio to clone
+ * @gfp_mask: allocation priority
+ * @bs: bio_set to allocate from
+ *
+ * Clone bio. Caller will own the returned bio, but not the actual data it
+ * points to. Reference count of returned bio will be one.
+ */
+struct bio *bio_clone_bioset(struct bio *bio_src, gfp_t gfp_mask,
+struct bio_set *bs)
+{
+ return __bio_clone_bioset(bio_src, gfp_mask, bs, 0,
+ bio_src->bi_iter.bi_size);
+}
EXPORT_SYMBOL(bio_clone_bioset);
/**
+ * bio_clone_bioset_partial - clone a partial bio
+ * @bio_src: bio to clone
+ * @gfp_mask: allocation priority
+ * @bs: bio_set to allocate from
+ * @offset: cloned starting from the offset
+ * @size: size for the cloned bio
+ *
+ * Clone bio. Caller will own the returned bio, but not the actual data it
+ * points to. Reference count of returned bio will be one.
+ */
+struct bio *bio_clone_bioset_partial(struct bio *bio_src, gfp_t gfp_mask,
+struct bio_set *bs, int offset,
+int size)
+{
+ return __bio_clone_bioset(bio_src, gfp_mask, bs, offset, size);
+}
+EXPORT_SYMBOL(bio_clone_bioset_partial);
+
+/**
* bio_add_pc_page - attempt to add page to bio
* @q: the target queue
* @bio: destination bio
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 7cf8a6c70a3f..8e521194f6fc 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -183,7 +183,7 @@ static inline void bio_advance_iter(struct bio *bio, struct
bvec_iter *iter,
#define bio_iter_last(bvec, iter) ((iter).bi_size == (bvec).bv_len)
-static inline unsigned bio_segments(struct bio *bio)
+static inline unsigned __bio_segments(struct bio *bio, struct bvec_iter *bvec)
{
unsigned segs = 0;
struct bio_vec bv;
@@ -205,12 +205,17 @@ static inline unsigned bio_segments(struct bio *bio)
break;
}
- bio_for_each_segment(bv, bio, iter)
+ __bio_for_each_segment(bv, bio, iter, *bvec)
segs++;
return segs;
}
+static inline unsigned bio_segments(struct bio *bio)
+{
+ return __bio_segments(bio, &bio->bi_iter);
+}
+
/*
* get a r
[PATCH 2/4] md: introduce bio_clone_slow_mddev_partial()
In raid1/raid10, most users of bio_clone_mddev() need bio_trim() too,
that means only part of the bio is required to be cloned, and not
necessary to clone the whole bio each time, and it is just enough
to clone the specified bvecs range.
So this patch introduces bio_clone_slow_mddev_partial() to improve
the situation, and it is named as slow because the following patch
will switch to bio_clone_fast() in bio_clone_mddev().
Signed-off-by: Ming Lei
---
drivers/md/md.c | 16
drivers/md/md.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 4c1b82defa78..704be11355a9 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -200,6 +200,22 @@ struct bio *bio_clone_mddev(struct bio *bio, gfp_t
gfp_mask,
}
EXPORT_SYMBOL_GPL(bio_clone_mddev);
+struct bio *bio_clone_slow_mddev_partial(struct bio *bio, gfp_t gfp_mask,
+struct mddev *mddev, int offset,
+int size)
+{
+ struct bio_set *bs;
+
+ if (!mddev || !mddev->bio_set)
+ bs = fs_bio_set;
+ else
+ bs = mddev->bio_set;
+
+ return bio_clone_bioset_partial(bio, gfp_mask, bs, offset << 9,
+ size << 9);
+}
+EXPORT_SYMBOL_GPL(bio_clone_slow_mddev_partial);
+
/*
* We have a system wide 'event count' that is incremented
* on any 'interesting' event, and readers of /proc/mdstat
diff --git a/drivers/md/md.h b/drivers/md/md.h
index 968bbe72b237..4f4e6ded59e5 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -675,6 +675,9 @@ extern void mddev_suspend(struct mddev *mddev);
extern void mddev_resume(struct mddev *mddev);
extern struct bio *bio_clone_mddev(struct bio *bio, gfp_t gfp_mask,
struct mddev *mddev);
+extern struct bio *bio_clone_slow_mddev_partial(struct bio *bio, gfp_t
gfp_mask,
+ struct mddev *mddev, int offset,
+ int size);
extern struct bio *bio_alloc_mddev(gfp_t gfp_mask, int nr_iovecs,
struct mddev *mddev);
--
2.7.4
[PATCH 4/4] md: fast clone bio in bio_clone_mddev()
Firstly bio_clone_mddev() is used in raid normal I/O and isn't
in resync I/O path.
Secondly all the direct access to bvec table in raid happens on
resync I/O except for write behind of raid1, in which we still
use bio_clone() for allocating new bvec table.
So this patch replaces bio_clone() with bio_clone_fast()
in bio_clone_mddev().
Signed-off-by: Ming Lei
---
drivers/md/md.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 704be11355a9..7d176f025add 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -193,10 +193,14 @@ EXPORT_SYMBOL_GPL(bio_alloc_mddev);
struct bio *bio_clone_mddev(struct bio *bio, gfp_t gfp_mask,
struct mddev *mddev)
{
+ struct bio_set *bs;
+
if (!mddev || !mddev->bio_set)
- return bio_clone(bio, gfp_mask);
+ bs = fs_bio_set;
+ else
+ bs = mddev->bio_set;
- return bio_clone_bioset(bio, gfp_mask, mddev->bio_set);
+ return bio_clone_fast(bio, gfp_mask, bs);
}
EXPORT_SYMBOL_GPL(bio_clone_mddev);
--
2.7.4
[PATCH 3/4] md/raid1: use bio_clone_slow_mddev_partial in case of write behind
Write behind need to replace pages in bio's bvecs, and we have
to clone a fresh bio with new bvec table, so use the introduced
bio_clone_slow_mddev_partial() for it.
For other bio_clone_mddev() cases, we will use fast clone since
they don't need to touch bvec table.
Signed-off-by: Ming Lei
---
drivers/md/raid1.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 830ff2b20346..e1c5639febdb 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1341,13 +1341,12 @@ static void raid1_write_request(struct mddev *mddev,
struct bio *bio,
first_clone = 1;
for (i = 0; i < disks; i++) {
- struct bio *mbio;
+ struct bio *mbio = NULL;
+ int offset;
if (!r1_bio->bios[i])
continue;
- mbio = bio_clone_mddev(bio, GFP_NOIO, mddev);
- bio_trim(mbio, r1_bio->sector - bio->bi_iter.bi_sector,
-max_sectors);
+ offset = r1_bio->sector - bio->bi_iter.bi_sector;
if (first_clone) {
/* do behind I/O ?
@@ -1357,8 +1356,14 @@ static void raid1_write_request(struct mddev *mddev,
struct bio *bio,
if (bitmap &&
(atomic_read(&bitmap->behind_writes)
< mddev->bitmap_info.max_write_behind) &&
- !waitqueue_active(&bitmap->behind_wait))
+ !waitqueue_active(&bitmap->behind_wait)) {
+ mbio = bio_clone_slow_mddev_partial(bio,
+ GFP_NOIO,
+ mddev,
+ offset,
+
max_sectors);
alloc_behind_pages(mbio, r1_bio);
+ }
bitmap_startwrite(bitmap, r1_bio->sector,
r1_bio->sectors,
@@ -1366,6 +1371,12 @@ static void raid1_write_request(struct mddev *mddev,
struct bio *bio,
&r1_bio->state));
first_clone = 0;
}
+
+ if (!mbio) {
+ mbio = bio_clone_mddev(bio, GFP_NOIO, mddev);
+ bio_trim(mbio, offset, max_sectors);
+ }
+
if (r1_bio->behind_bvecs) {
struct bio_vec *bvec;
int j;
--
2.7.4
Re: [PATCH 5/6] dmaengine: Add Broadcom SBA RAID driver
On Thu, Feb 02, 2017 at 10:17:15AM +0530, Anup Patel wrote:
> +config BCM_SBA_RAID
> +tristate "Broadcom SBA RAID engine support"
> +depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
> +select DMA_ENGINE
> +select DMA_ENGINE_RAID
> + select ASYNC_TX_ENABLE_CHANNEL_SWITCH
> + default ARCH_BCM_IPROC
whats with the funny alignement?
> +/* SBA command related defines */
> +#define SBA_TYPE_SHIFT 48
> +#define SBA_TYPE_MASK0x3
> +#define SBA_TYPE_A 0x0
> +#define SBA_TYPE_B 0x2
> +#define SBA_TYPE_C 0x3
> +#define SBA_USER_DEF_SHIFT 32
> +#define SBA_USER_DEF_MASK0x
> +#define SBA_R_MDATA_SHIFT24
> +#define SBA_R_MDATA_MASK 0xff
> +#define SBA_C_MDATA_MS_SHIFT 18
> +#define SBA_C_MDATA_MS_MASK 0x3
> +#define SBA_INT_SHIFT17
> +#define SBA_INT_MASK 0x1
> +#define SBA_RESP_SHIFT 16
> +#define SBA_RESP_MASK0x1
> +#define SBA_C_MDATA_SHIFT8
> +#define SBA_C_MDATA_MASK 0xff
> +#define SBA_CMD_SHIFT0
> +#define SBA_CMD_MASK 0xf
> +#define SBA_CMD_ZERO_ALL_BUFFERS 0x8
> +#define SBA_CMD_LOAD_BUFFER 0x9
> +#define SBA_CMD_XOR 0xa
> +#define SBA_CMD_GALOIS_XOR 0xb
> +#define SBA_CMD_ZERO_BUFFER 0x4
> +#define SBA_CMD_WRITE_BUFFER 0xc
Try using BIT and GENMAST for hardware descriptions
> +
> +/* SBA C_MDATA helper macros */
> +#define SBA_C_MDATA_LOAD_VAL(__bnum0)((__bnum0) & 0x3)
> +#define SBA_C_MDATA_WRITE_VAL(__bnum0) ((__bnum0) & 0x3)
> +#define SBA_C_MDATA_XOR_VAL(__bnum1, __bnum0)\
> + ({ u32 __v = ((__bnum0) & 0x3);\
> + __v |= ((__bnum1) & 0x3) << 2; \
> + __v;\
> + })
> +#define SBA_C_MDATA_PQ_VAL(__dnum, __bnum1, __bnum0) \
> + ({ u32 __v = ((__bnum0) & 0x3);\
> + __v |= ((__bnum1) & 0x3) << 2; \
> + __v |= ((__dnum) & 0x1f) << 5; \
> + __v;\
> + })
ah why are we usig complex macros, why can't these be simple functions..
> +#define SBA_C_MDATA_LS(__c_mdata_val)((__c_mdata_val) & 0xff)
> +#define SBA_C_MDATA_MS(__c_mdata_val)(((__c_mdata_val) >> 8) & 0x3)
> +
> +/* Driver helper macros */
> +#define to_sba_request(tx) \
> + container_of(tx, struct sba_request, tx)
> +#define to_sba_device(dchan) \
> + container_of(dchan, struct sba_device, dma_chan)
> +
> +enum sba_request_state {
> + SBA_REQUEST_STATE_FREE = 1,
> + SBA_REQUEST_STATE_ALLOCED = 2,
> + SBA_REQUEST_STATE_PENDING = 3,
> + SBA_REQUEST_STATE_ACTIVE = 4,
> + SBA_REQUEST_STATE_COMPLETED = 5,
> + SBA_REQUEST_STATE_ABORTED = 6,
whats up with a very funny indentation setting, we use 8 chars.
Please re-read the Documentation/process/coding-style.rst
> +static int sba_alloc_chan_resources(struct dma_chan *dchan)
> +{
> + /*
> + * We only have one channel so we have pre-alloced
> + * channel resources. Over here we just return number
> + * of free request.
> + */
> + return sba_free_request_count(to_sba_device(dchan));
> +}
essentially you are not doing much, so you can skip it. Its an optional
call.
> +static void sba_free_chan_resources(struct dma_chan *dchan)
> +{
> + /*
> + * Channel resources are pre-alloced so we just free-up
> + * whatever we can so that we can re-use pre-alloced
> + * channel resources next time.
> + */
> + sba_cleanup_inflight_requests(to_sba_device(dchan));
well this one checks for pending requests as well, which shouldn't be there
when freeing a channel, something seems not quite right here..
> +static int sba_send_mbox_request(struct sba_device *sba,
> + struct sba_request *req)
> +{
> + int mchans_idx, ret = 0;
> +
> + /* Select mailbox channel in round-robin fashion */
> + mchans_idx = atomic_inc_return(&sba->mchans_current);
> + mchans_idx = mchans_idx % sba->mchans_count;
> +
> + /* Send batch message for the request */
> + req->bmsg.batch.msgs_queued = 0;
> + ret = mbox_send_mes
Re: pciehp is broken from 4.10-rc1
On Sat, Feb 4, 2017 at 8:22 PM, Yinghai Lu wrote: > On Sat, Feb 4, 2017 at 3:34 PM, Lukas Wunner wrote: >> On Sat, Feb 04, 2017 at 01:44:34PM -0800, Yinghai Lu wrote: >>> On Sat, Feb 4, 2017 at 10:56 AM, Lukas Wunner wrote: >>> > On Sat, Feb 04, 2017 at 09:12:54AM +0100, Lukas Wunner wrote: >>> > Section 6.7.3.4 of the PCIe Base spec seems to support the theory above, >>> > so here's a tentative patch. >>> > >>> > >>> > -- >8 -- >>> > Subject: [PATCH] PCI: pciehp: Don't enable PME on runtime suspend >>> >>> it works: >> >> Thanks a lot for the report and for testing the patch! > > Wait, Commit 68db9bc still has problem with another server (skylake > based), and this patch does not help. > > > sca05-0a81fd8d:~ # echo 0 > /sys/bus/pci/slots/11/power > [ 362.721197] pci_hotplug: power_write_file: power = 0 > [ 362.726887] pciehp :b3:00.0:pcie004: pciehp_get_power_status: > SLOTCTRL a8 value read 11f1 > [ 362.736431] pciehp :b3:00.0:pcie004: pciehp_unconfigure_device: > domain:bus:dev = :b4:00 > [ 362.746160] mlx4_core :b4:00.0: PME# disabled > [ 364.494033] pcieport :b3:00.0: root_bridge ACPI_HANDLE > 9e56b8811550 : pci:b3 > [ 364.503274] pcieport :b3:00.0: pciehp is native > [ 364.508863] pci :b4:00.0: freeing pci_dev info > [ 364.514718] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 > from Slot Status > [ 364.523443] pciehp :b3:00.0:pcie004: pciehp_power_off_slot: > SLOTCTRL a8 write cmd 400 > [ 364.587047] pciehp :b3:00.0:pcie004: pending interrupts 0x0108 > from Slot Status > [ 364.595592] pciehp :b3:00.0:pcie004: Slot(11): Link Down > [ 364.602325] pciehp :b3:00.0:pcie004: Slot(11): Link Down event > ignored; already powering off > [ 365.568415] pciehp :b3:00.0:pcie004: pciehp_green_led_off: > SLOTCTRL a8 write cmd 300 > [ 365.569338] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 > from Slot Status > > sca05-0a81fd8d:~ # echo 1 > /sys/bus/pci/slots/11/power > [ 375.376609] pci_hotplug: power_write_file: power = 1 > [ 375.382175] pciehp :b3:00.0:pcie004: pciehp_get_power_status: > SLOTCTRL a8 value read 17f1 > [ 375.392695] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 > from Slot Status > [ 375.401370] pciehp :b3:00.0:pcie004: pciehp_power_on_slot: > SLOTCTRL a8 write cmd 0 > [ 375.410231] pciehp :b3:00.0:pcie004: pciehp_green_led_blink: > SLOTCTRL a8 write cmd 200 > [ 375.411071] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 > from Slot Status > [ 375.445222] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 > from Slot Status > [ 377.00] pciehp :b3:00.0:pcie004: Data Link Layer Link > Active not set in 1000 msec > [ 378.960364] pci :b4:00.0 id reading try 50 times with interval > 20 ms to get > [ 378.969406] pciehp :b3:00.0:pcie004: pciehp_check_link_status: > lnk_status = 5001 > [ 378.978059] pciehp :b3:00.0:pcie004: link training error: status 0x5001 > [ 378.985834] pciehp :b3:00.0:pcie004: Failed to check link status > [ 378.987185] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 > from Slot Status > [ 378.987253] pciehp :b3:00.0:pcie004: pciehp_power_off_slot: > SLOTCTRL a8 write cmd 400 > [ 380.000409] pciehp :b3:00.0:pcie004: pciehp_green_led_off: > SLOTCTRL a8 write cmd 300 > [ 380.000674] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 > from Slot Status > [ 380.018020] pciehp :b3:00.0:pcie004: > pciehp_set_attention_status: SLOTCTRL a8 write cmd 40 > [ 380.019053] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 > from Slot Status > -bash: echo: write error: Operation not permitted > > revert commit 68db9bc, also make it working again. output after reverting 68db9bc sca05-0a81fd8d:~ # echo 0 > /sys/bus/pci/slots/11/power [ 359.966115] pci_hotplug: power_write_file: power = 0 [ 359.971759] pciehp :b3:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 11f1 [ 359.981284] pciehp :b3:00.0:pcie004: pciehp_unconfigure_device: domain:bus:dev = :b4:00 [ 359.991017] mlx4_core :b4:00.0: PME# disabled [ 361.579571] pci :b4:00.0: freeing pci_dev info [ 361.585390] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from Slot Status [ 361.594116] pciehp :b3:00.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 write cmd 400 [ 361.657705] pciehp :b3:00.0:pcie004: pending interrupts 0x0108 from Slot Status [ 361.666268] pciehp :b3:00.0:pcie004: Slot(11): Link Down [ 361.673076] pciehp :b3:00.0:pcie004: Slot(11): Link Down event ignored; already powering off [ 362.621894] pciehp :b3:00.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 write cmd 300 [ 362.622499] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from Slot Status sca05-0a81fd8d:~ # sca05-0a81fd8d:~ # echo 1 > /sys/bus/pci/slots/11/power [ 368.797970] pci_hotplug: power_write_file: power = 1 [ 368.803544] pciehp :b3:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 valu
Re: [PATCH v9 2/3] MAINTAINERS: add zx2967 watchdog controller driver to ARM ZTE architecture
Hi Guenter, On Sat, Feb 04, 2017 at 08:29:27PM -0800, Guenter Roeck wrote: > Yes. One of the problems is that the patch doesn't apply to my tree > (which is based on v4.10-rc3), and it doesn't have a common anchestor, > meaning it is most likely not based on mainline. I would prefer to avoid > conflicts with the arm tree if possible. Understood. You only need to handle patch #1 and #3, and we will sort out MAINTAINERS update separately. Thanks. Shawn
Re: [PATCH v9 2/3] MAINTAINERS: add zx2967 watchdog controller driver to ARM ZTE architecture
On 02/04/2017 07:45 PM, Shawn Guo wrote: Hi Baoyou, On Sun, Feb 05, 2017 at 10:36:38AM +0800, Baoyou Xie wrote: On 5 February 2017 at 08:05, Guenter Roeck wrote: On 02/03/2017 05:34 PM, Baoyou Xie wrote: Add the zx2967 watchdog controller driver as maintained by ARM ZTE architecture maintainers, as they're parts of the core IP. Signed-off-by: Baoyou Xie Reviewed-by: Guenter Roeck I assume you'll submit this patch through the arm tree ? Could you please submit all three patches through your tree? Thanks a lot :) Patch #2 is the only one that Guenter is concerned about, as there are other subsystem related updates on the file. I think Guenter's suggestion is good, i.e. we have patch #1 and #3 go upstream through watchdog tree, and later we update MAINTAINERS as needed via arm-soc tree. Yes. One of the problems is that the patch doesn't apply to my tree (which is based on v4.10-rc3), and it doesn't have a common anchestor, meaning it is most likely not based on mainline. I would prefer to avoid conflicts with the arm tree if possible. Guenter
Re: pciehp is broken from 4.10-rc1
On Sat, Feb 4, 2017 at 3:34 PM, Lukas Wunner wrote: > On Sat, Feb 04, 2017 at 01:44:34PM -0800, Yinghai Lu wrote: >> On Sat, Feb 4, 2017 at 10:56 AM, Lukas Wunner wrote: >> > On Sat, Feb 04, 2017 at 09:12:54AM +0100, Lukas Wunner wrote: >> > Section 6.7.3.4 of the PCIe Base spec seems to support the theory above, >> > so here's a tentative patch. >> > >> > >> > -- >8 -- >> > Subject: [PATCH] PCI: pciehp: Don't enable PME on runtime suspend >> >> it works: > > Thanks a lot for the report and for testing the patch! Wait, Commit 68db9bc still has problem with another server (skylake based), and this patch does not help. sca05-0a81fd8d:~ # echo 0 > /sys/bus/pci/slots/11/power [ 362.721197] pci_hotplug: power_write_file: power = 0 [ 362.726887] pciehp :b3:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 11f1 [ 362.736431] pciehp :b3:00.0:pcie004: pciehp_unconfigure_device: domain:bus:dev = :b4:00 [ 362.746160] mlx4_core :b4:00.0: PME# disabled [ 364.494033] pcieport :b3:00.0: root_bridge ACPI_HANDLE 9e56b8811550 : pci:b3 [ 364.503274] pcieport :b3:00.0: pciehp is native [ 364.508863] pci :b4:00.0: freeing pci_dev info [ 364.514718] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from Slot Status [ 364.523443] pciehp :b3:00.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 write cmd 400 [ 364.587047] pciehp :b3:00.0:pcie004: pending interrupts 0x0108 from Slot Status [ 364.595592] pciehp :b3:00.0:pcie004: Slot(11): Link Down [ 364.602325] pciehp :b3:00.0:pcie004: Slot(11): Link Down event ignored; already powering off [ 365.568415] pciehp :b3:00.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 write cmd 300 [ 365.569338] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from Slot Status sca05-0a81fd8d:~ # echo 1 > /sys/bus/pci/slots/11/power [ 375.376609] pci_hotplug: power_write_file: power = 1 [ 375.382175] pciehp :b3:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 17f1 [ 375.392695] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from Slot Status [ 375.401370] pciehp :b3:00.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8 write cmd 0 [ 375.410231] pciehp :b3:00.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 write cmd 200 [ 375.411071] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from Slot Status [ 375.445222] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from Slot Status [ 377.00] pciehp :b3:00.0:pcie004: Data Link Layer Link Active not set in 1000 msec [ 378.960364] pci :b4:00.0 id reading try 50 times with interval 20 ms to get [ 378.969406] pciehp :b3:00.0:pcie004: pciehp_check_link_status: lnk_status = 5001 [ 378.978059] pciehp :b3:00.0:pcie004: link training error: status 0x5001 [ 378.985834] pciehp :b3:00.0:pcie004: Failed to check link status [ 378.987185] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from Slot Status [ 378.987253] pciehp :b3:00.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 write cmd 400 [ 380.000409] pciehp :b3:00.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 write cmd 300 [ 380.000674] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from Slot Status [ 380.018020] pciehp :b3:00.0:pcie004: pciehp_set_attention_status: SLOTCTRL a8 write cmd 40 [ 380.019053] pciehp :b3:00.0:pcie004: pending interrupts 0x0010 from Slot Status -bash: echo: write error: Operation not permitted revert commit 68db9bc, also make it working again. Thanks Yinghai
Re: [PATCH v2 2/2] arm: dts: mt2701: add nor flash node
On Wed, 2017-01-25 at 11:38 +0800, Guochun Mao wrote:
> Add Mediatek nor flash node.
>
> Signed-off-by: Guochun Mao
> ---
> arch/arm/boot/dts/mt2701-evb.dts | 25 +
> arch/arm/boot/dts/mt2701.dtsi| 12
> 2 files changed, 37 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
> b/arch/arm/boot/dts/mt2701-evb.dts
> index 082ca88..85e5ae8 100644
> --- a/arch/arm/boot/dts/mt2701-evb.dts
> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> @@ -24,6 +24,31 @@
> };
> };
>
> +&nor_flash {
> + pinctrl-names = "default";
> + pinctrl-0 = <&nor_pins_default>;
> + status = "okay";
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + };
> +};
> +
> +&pio {
> + nor_pins_default: nor {
> + pins1 {
> + pinmux = ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + drive-strength = ;
> + bias-pull-up;
> + };
> + };
> +};
> +
> &uart0 {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index bdf8954..1eefce4 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -227,6 +227,18 @@
> status = "disabled";
> };
>
> + nor_flash: spi@11014000 {
> + compatible = "mediatek,mt2701-nor",
> + "mediatek,mt8173-nor";
> + reg = <0 0x11014000 0 0xe0>;
> + clocks = <&pericfg CLK_PERI_FLASH>,
> + <&topckgen CLK_TOP_FLASH_SEL>;
> + clock-names = "spi", "sf";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> mmsys: syscon@1400 {
> compatible = "mediatek,mt2701-mmsys", "syscon";
> reg = <0 0x1400 0 0x1000>;
Hi,
mtk-quadspi.txt had been updated as suggested.
Is there suggestion about this patch?
Thanks.
BR,
Guochun
[PATCH v5 6/6] drm/rockchip/dsi: add dw-mipi power domain support
Reference the power domain incase dw-mipi power down when
in use.
Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 35f22bc..d263352 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -293,6 +294,7 @@ struct dw_mipi_dsi {
struct clk *pclk;
struct clk *phy_cfg_clk;
+ int dpms_mode;
unsigned int lane_mbps; /* per lane */
u32 channel;
u32 lanes;
@@ -969,6 +971,9 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder
*encoder)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
+ if (dsi->dpms_mode != DRM_MODE_DPMS_ON)
+ return;
+
if (clk_prepare_enable(dsi->pclk)) {
dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
return;
@@ -980,7 +985,9 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder
*encoder)
drm_panel_unprepare(dsi->panel);
dw_mipi_dsi_disable(dsi);
+ pm_runtime_put(dsi->dev);
clk_disable_unprepare(dsi->pclk);
+ dsi->dpms_mode = DRM_MODE_DPMS_OFF;
}
static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
@@ -990,11 +997,15 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 val;
+ if (dsi->dpms_mode == DRM_MODE_DPMS_ON)
+ return;
+
if (clk_prepare_enable(dsi->pclk)) {
dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
return;
}
+ pm_runtime_get_sync(dsi->dev);
dw_mipi_dsi_init(dsi);
dw_mipi_dsi_dpi_config(dsi);
dw_mipi_dsi_packet_handler_config(dsi);
@@ -1030,6 +1041,7 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi->dev, "vop %s output to dsi0\n", (mux) ? "LIT" : "BIG");
+ dsi->dpms_mode = DRM_MODE_DPMS_ON;
}
static int
@@ -1198,6 +1210,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
dsi->dev = dev;
dsi->pdata = pdata;
+ dsi->dpms_mode = DRM_MODE_DPMS_OFF;
ret = rockchip_mipi_parse_dt(dsi);
if (ret)
@@ -1278,6 +1291,8 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
dev_set_drvdata(dev, dsi);
+ pm_runtime_enable(dev);
+
dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
dsi->dsi_host.dev = dev;
ret = mipi_dsi_host_register(&dsi->dsi_host);
@@ -1300,6 +1315,7 @@ static void dw_mipi_dsi_unbind(struct device *dev, struct
device *master,
struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
mipi_dsi_host_unregister(&dsi->dsi_host);
+ pm_runtime_disable(dev);
clk_disable_unprepare(dsi->pllref_clk);
}
--
2.6.3
[PATCH v5 5/6] dt-bindings: add power domain node for dw-mipi-rockchip
Signed-off-by: Chris Zhong Acked-by: Rob Herring --- Changes in v5: None Changes in v4: None Changes in v3: None .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 0f82568..188f6f7 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -15,6 +15,9 @@ Required properties: - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. +Optional properties: +- power-domains: a phandle to mipi dsi power domain node. + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt [2] Documentation/devicetree/bindings/media/video-interfaces.txt -- 2.6.3
[PATCH v5 4/6] drm/rockchip/dsi: remove mode_valid function
The MIPI DSI do not need check the validity of resolution, the max
resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
here.
Signed-off-by: Chris Zhong
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 --
1 file changed, 39 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 89a8941..35f22bc 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -278,8 +278,6 @@ struct dw_mipi_dsi_plat_data {
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
- enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
- struct drm_display_mode *mode);
};
struct dw_mipi_dsi {
@@ -1081,23 +1079,8 @@ static int dw_mipi_dsi_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(dsi->panel);
}
-static enum drm_mode_status dw_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- struct dw_mipi_dsi *dsi = con_to_dsi(connector);
-
- enum drm_mode_status mode_status = MODE_OK;
-
- if (dsi->pdata->mode_valid)
- mode_status = dsi->pdata->mode_valid(connector, mode);
-
- return mode_status;
-}
-
static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs = {
.get_modes = dw_mipi_dsi_connector_get_modes,
- .mode_valid = dw_mipi_dsi_mode_valid,
};
static void dw_mipi_dsi_drm_connector_destroy(struct drm_connector *connector)
@@ -1168,33 +1151,11 @@ static int rockchip_mipi_parse_dt(struct dw_mipi_dsi
*dsi)
return 0;
}
-static enum drm_mode_status rk3288_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- /*
-* The VID_PKT_SIZE field in the DSI_VID_PKT_CFG
-* register is 11-bit.
-*/
- if (mode->hdisplay > 0x7ff)
- return MODE_BAD_HVALUE;
-
- /*
-* The V_ACTIVE_LINES field in the DSI_VTIMING_CFG
-* register is 11-bit.
-*/
- if (mode->vdisplay > 0x7ff)
- return MODE_BAD_VVALUE;
-
- return MODE_OK;
-}
-
static struct dw_mipi_dsi_plat_data rk3288_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3288_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3288_DSI1_SEL_VOP_LIT,
.grf_switch_reg = RK3288_GRF_SOC_CON6,
.max_data_lanes = 4,
- .mode_valid = rk3288_mipi_dsi_mode_valid,
};
static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
--
2.6.3
[PATCH v5 2/6] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi
The vopb/vopl switch register of RK3399 mipi is different from RK3288,
the default setting for mipi dsi mode is different too, so add a
of_device_id structure to distinguish them, and make sure set the
correct mode before mipi phy init.
Signed-off-by: Chris Zhong
Signed-off-by: Mark Yao
---
Changes in v5:
- check the error of phy_cfg_clk in dw_mipi_dsi_bind
Changes in v4:
- remove the unrelated change
Changes in v3:
- base on John Keeping's patch series
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 75 +-
1 file changed, 65 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 45af890..7d337e2 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -29,9 +29,17 @@
#define DRIVER_NAME"dw-mipi-dsi"
-#define GRF_SOC_CON60x025c
-#define DSI0_SEL_VOP_LIT(1 << 6)
-#define DSI1_SEL_VOP_LIT(1 << 9)
+#define RK3288_GRF_SOC_CON60x025c
+#define RK3288_DSI0_SEL_VOP_LITBIT(6)
+#define RK3288_DSI1_SEL_VOP_LITBIT(9)
+
+#define RK3399_GRF_SOC_CON19 0x6250
+#define RK3399_DSI0_SEL_VOP_LITBIT(0)
+#define RK3399_DSI1_SEL_VOP_LITBIT(4)
+
+/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
+#define RK3399_GRF_SOC_CON22 0x6258
+#define RK3399_GRF_DSI_MODE0x
#define DSI_VERSION0x00
#define DSI_PWR_UP 0x04
@@ -265,6 +273,11 @@ enum {
};
struct dw_mipi_dsi_plat_data {
+ u32 dsi0_en_bit;
+ u32 dsi1_en_bit;
+ u32 grf_switch_reg;
+ u32 grf_dsi0_mode;
+ u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
struct drm_display_mode *mode);
@@ -281,6 +294,7 @@ struct dw_mipi_dsi {
struct clk *pllref_clk;
struct clk *pclk;
+ struct clk *phy_cfg_clk;
unsigned int lane_mbps; /* per lane */
u32 channel;
@@ -426,6 +440,14 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLR);
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_UNTESTCLR);
+ if (dsi->phy_cfg_clk) {
+ ret = clk_prepare_enable(dsi->phy_cfg_clk);
+ if (ret) {
+ dev_err(dsi->dev, "Failed to enable phy_cfg_clk\n");
+ return ret;
+ }
+ }
+
dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
VCO_RANGE_CON_SEL(vco) |
VCO_IN_CAP_CON_LOW |
@@ -479,17 +501,19 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
if (ret < 0) {
dev_err(dsi->dev, "failed to wait for phy lock state\n");
- return ret;
+ goto phy_init_end;
}
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
val, val & STOP_STATE_CLK_LANE, 1000,
PHY_STATUS_TIMEOUT_US);
- if (ret < 0) {
+ if (ret < 0)
dev_err(dsi->dev,
"failed to wait for phy clk lane stop state\n");
- return ret;
- }
+
+phy_init_end:
+ if (dsi->phy_cfg_clk)
+ clk_disable_unprepare(dsi->phy_cfg_clk);
return ret;
}
@@ -965,6 +989,7 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder
*encoder)
static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
+ const struct dw_mipi_dsi_plat_data *pdata = dsi->pdata;
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 val;
@@ -985,6 +1010,10 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
dw_mipi_dsi_dphy_interface_config(dsi);
dw_mipi_dsi_clear_err(dsi);
+ if (pdata->grf_dsi0_mode_reg)
+ regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
+pdata->grf_dsi0_mode);
+
dw_mipi_dsi_phy_init(dsi);
dw_mipi_dsi_wait_for_two_frames(dsi);
@@ -998,11 +1027,11 @@ static void dw_mipi_dsi_encoder_enable(struct
drm_encoder *encoder)
clk_disable_unprepare(dsi->pclk);
if (mux)
- val = DSI0_SEL_VOP_LIT | (DSI0_SEL_VOP_LIT << 16);
+ val = pdata->dsi0_en_bit | (pdata->dsi0_en_bit << 16);
else
- val = DSI0_SEL_VOP_LIT << 16;
+ val = pdata->dsi0_en_bit << 16;
- regmap_write(dsi->grf_regmap, GRF_SOC_CON6, val);
+ regmap_write(dsi->grf_regmap, pdata->grf_switch_r
[PATCH v5 0/6] Rockchip dw-mipi-dsi driver
Hi all This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of RK3399 is almost the same as RK3288, except a little bit of difference in phy clock controlling and port id selection register. These patches add RK3399 support and the power domain support. And these patches base on John Keeping's series[0], it fixes many bugs, they have been tested on rk3288 evb board. [0]: [01/26] https://patchwork.kernel.org/patch/9340213 [02/26] https://patchwork.kernel.org/patch/9340145 [03/26] https://patchwork.kernel.org/patch/9340235 [04/26] https://patchwork.kernel.org/patch/9340123 [05/26] https://patchwork.kernel.org/patch/9340161 [06/26] https://patchwork.kernel.org/patch/9340203 [07/26] https://patchwork.kernel.org/patch/9340229 [08/26] https://patchwork.kernel.org/patch/9340131 [09/26] https://patchwork.kernel.org/patch/9340191 [10/26] https://patchwork.kernel.org/patch/9340175 [11/26] https://patchwork.kernel.org/patch/9340237 [12/26] https://patchwork.kernel.org/patch/9340207 [13/26] https://patchwork.kernel.org/patch/9340233 [14/26] https://patchwork.kernel.org/patch/9340205 [15/26] https://patchwork.kernel.org/patch/9340189 [16/26] https://patchwork.kernel.org/patch/9340143 [17/26] https://patchwork.kernel.org/patch/9340117 [18/26] https://patchwork.kernel.org/patch/9340193 [19/26] https://patchwork.kernel.org/patch/9340151 [20/26] https://patchwork.kernel.org/patch/9340183 [23/26] https://patchwork.kernel.org/patch/9340173 [24/26] https://patchwork.kernel.org/patch/9340251 [25/26] https://patchwork.kernel.org/patch/9340127 [26/26] https://patchwork.kernel.org/patch/9340139 Changes in v5: - check the error of phy_cfg_clk in dw_mipi_dsi_bind Changes in v4: - remove the unrelated change Changes in v3: - base on John Keeping's patch series Chris Zhong (6): dt-bindings: add rk3399 support for dw-mipi-rockchip drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi drm/rockchip/dsi: dw-mipi: correct the coding style drm/rockchip/dsi: remove mode_valid function dt-bindings: add power domain node for dw-mipi-rockchip drm/rockchip/dsi: add dw-mipi power domain support .../display/rockchip/dw_mipi_dsi_rockchip.txt | 7 +- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 163 - 2 files changed, 103 insertions(+), 67 deletions(-) -- 2.6.3
[PATCH v5 1/6] dt-bindings: add rk3399 support for dw-mipi-rockchip
The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has additional phy config clock. Signed-off-by: Chris Zhong Acked-by: Rob Herring --- Changes in v5: None Changes in v4: None Changes in v3: None .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 1753f0c..0f82568 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -5,10 +5,12 @@ Required properties: - #address-cells: Should be <1>. - #size-cells: Should be <0>. - compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi". + "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi". - reg: Represent the physical address range of the controller. - interrupts: Represent the controller's interrupt to the CPU(s). - clocks, clock-names: Phandles to the controller's pll reference - clock(ref) and APB clock(pclk), as described in [1]. + clock(ref) and APB clock(pclk). For RK3399, a phy config clock + (phy_cfg) is additional required. As described in [1]. - rockchip,grf: this soc should set GRF regs to mux vopl/vopb. - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. -- 2.6.3
[PATCH v5 3/6] drm/rockchip/dsi: dw-mipi: correct the coding style
correct the coding style, according the checkpatch scripts
Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 7d337e2..89a8941 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -157,7 +157,6 @@
#define LPRX_TO_CNT(p) ((p) & 0x)
#define DSI_BTA_TO_CNT 0x8c
-
#define DSI_LPCLK_CTRL 0x94
#define AUTO_CLKLANE_CTRL BIT(1)
#define PHY_TXREQUESTCLKHS BIT(0)
@@ -223,11 +222,11 @@
#define HSFREQRANGE_SEL(val) (((val) & 0x3f) << 1)
-#define INPUT_DIVIDER(val) ((val - 1) & 0x7f)
+#define INPUT_DIVIDER(val) (((val) - 1) & 0x7f)
#define LOW_PROGRAM_EN 0
#define HIGH_PROGRAM_ENBIT(7)
-#define LOOP_DIV_LOW_SEL(val) ((val - 1) & 0x1f)
-#define LOOP_DIV_HIGH_SEL(val) (((val - 1) >> 5) & 0x1f)
+#define LOOP_DIV_LOW_SEL(val) (((val) - 1) & 0x1f)
+#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
#define PLL_LOOP_DIV_ENBIT(5)
#define PLL_INPUT_DIV_EN BIT(4)
@@ -370,6 +369,7 @@ static inline struct dw_mipi_dsi *encoder_to_dsi(struct
drm_encoder *encoder)
{
return container_of(encoder, struct dw_mipi_dsi, encoder);
}
+
static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
{
writel(val, dsi->base + reg);
@@ -381,7 +381,7 @@ static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
}
static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi *dsi, u8 test_code,
-u8 test_data)
+ u8 test_data)
{
/*
* With the falling edge on TESTCLK, the TESTDIN[7:0] signal content
@@ -496,7 +496,6 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |
PHY_UNRSTZ | PHY_UNSHUTDOWNZ);
-
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
if (ret < 0) {
@@ -572,7 +571,7 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
if (device->lanes > dsi->pdata->max_data_lanes) {
dev_err(dsi->dev, "the number of data lanes(%u) is too many\n",
- device->lanes);
+ device->lanes);
return -EINVAL;
}
@@ -960,8 +959,8 @@ static void dw_mipi_dsi_clear_err(struct dw_mipi_dsi *dsi)
}
static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
@@ -1063,7 +1062,7 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder
*encoder,
return 0;
}
-static struct drm_encoder_helper_funcs
+static const struct drm_encoder_helper_funcs
dw_mipi_dsi_encoder_helper_funcs = {
.enable = dw_mipi_dsi_encoder_enable,
.mode_set = dw_mipi_dsi_encoder_mode_set,
@@ -1071,7 +1070,7 @@ dw_mipi_dsi_encoder_helper_funcs = {
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
};
-static struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
+static const struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
@@ -1107,7 +1106,7 @@ static void dw_mipi_dsi_drm_connector_destroy(struct
drm_connector *connector)
drm_connector_cleanup(connector);
}
-static struct drm_connector_funcs dw_mipi_dsi_atomic_connector_funcs = {
+static const struct drm_connector_funcs dw_mipi_dsi_atomic_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = dw_mipi_dsi_drm_connector_destroy,
@@ -1117,7 +1116,7 @@ static struct drm_connector_funcs
dw_mipi_dsi_atomic_connector_funcs = {
};
static int dw_mipi_dsi_register(struct drm_device *drm,
- struct dw_mipi_dsi *dsi)
+ struct dw_mipi_dsi *dsi)
{
struct drm_encoder *encoder = &dsi->encoder;
struct drm_connector *connector = &dsi->connector;
@@ -1138,14 +1137,14 @@ static int dw_mipi_dsi_register(struct drm_device *drm,
drm_encoder_helper_add(&dsi->encoder,
&dw_mipi_dsi_encoder_helper_funcs);
ret = drm_encoder_init(drm, &dsi->encoder, &dw_m
Re: [PATCH v9 2/3] MAINTAINERS: add zx2967 watchdog controller driver to ARM ZTE architecture
Hi Baoyou, On Sun, Feb 05, 2017 at 10:36:38AM +0800, Baoyou Xie wrote: > On 5 February 2017 at 08:05, Guenter Roeck wrote: > > > On 02/03/2017 05:34 PM, Baoyou Xie wrote: > > > >> Add the zx2967 watchdog controller driver as maintained by ARM ZTE > >> architecture maintainers, as they're parts of the core IP. > >> > >> Signed-off-by: Baoyou Xie > >> > > > > Reviewed-by: Guenter Roeck > > > > I assume you'll submit this patch through the arm tree ? > > > Could you please submit all three patches through your tree? Thanks a lot > :) Patch #2 is the only one that Guenter is concerned about, as there are other subsystem related updates on the file. I think Guenter's suggestion is good, i.e. we have patch #1 and #3 go upstream through watchdog tree, and later we update MAINTAINERS as needed via arm-soc tree. Shawn
Re: [PATCH v3 3/5] drm/rockchip/dsi: remove mode_valid function
On 02/02/2017 02:12 AM, Sean Paul wrote:
On Tue, Jan 24, 2017 at 10:27:27AM +0800, Chris Zhong wrote:
Hi Sean
On 01/24/2017 01:48 AM, Sean Paul wrote:
On Fri, Jan 20, 2017 at 06:10:49PM +0800, Chris Zhong wrote:
The MIPI DSI do not need check the validity of resolution, the max
resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
here.
Does vop actually enforce this, though? I see that mode_config.max_width is
4096, but there is no bounds checking in mode_fixup().
The connector is currently rejecting everything greater than 2047. So I think
you're going to regress behavior here.
Sean
The mipi controller has not this width limit, it depend the VOP,
such as RK3399, VOP_LIT only support 2560,
but VOP_BIG support 4K. So this driver should check the width here.
I don't see anything in the vop driver that rejects large modes for little vop.
So, while I agree the check shouldn't be here, you should move it to where it
should be instead of removing it entirely.
Sean
drm_mode_validate_size will check the dev->mode_config.max_width and
dev->mode_config.max_height, these 2 value come from
rockchip_drm_mode_config_init,
currently, they are both 4096. So you are right, drm driver does not
distinguish
between vop lit and big.
I think Mark Yao already have a local solution, and he will post it soon.
Signed-off-by: Chris Zhong
---
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 --
1 file changed, 39 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index a93ce97..6f0e252 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -278,8 +278,6 @@ struct dw_mipi_dsi_plat_data {
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
- enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
- struct drm_display_mode *mode);
};
struct dw_mipi_dsi {
@@ -1081,23 +1079,8 @@ static int dw_mipi_dsi_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(dsi->panel);
}
-static enum drm_mode_status dw_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- struct dw_mipi_dsi *dsi = con_to_dsi(connector);
-
- enum drm_mode_status mode_status = MODE_OK;
-
- if (dsi->pdata->mode_valid)
- mode_status = dsi->pdata->mode_valid(connector, mode);
-
- return mode_status;
-}
-
static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs =
{
.get_modes = dw_mipi_dsi_connector_get_modes,
- .mode_valid = dw_mipi_dsi_mode_valid,
};
static void dw_mipi_dsi_drm_connector_destroy(struct drm_connector *connector)
@@ -1168,33 +1151,11 @@ static int rockchip_mipi_parse_dt(struct dw_mipi_dsi
*dsi)
return 0;
}
-static enum drm_mode_status rk3288_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- /*
-* The VID_PKT_SIZE field in the DSI_VID_PKT_CFG
-* register is 11-bit.
-*/
- if (mode->hdisplay > 0x7ff)
- return MODE_BAD_HVALUE;
-
- /*
-* The V_ACTIVE_LINES field in the DSI_VTIMING_CFG
-* register is 11-bit.
-*/
- if (mode->vdisplay > 0x7ff)
- return MODE_BAD_VVALUE;
-
- return MODE_OK;
-}
-
static struct dw_mipi_dsi_plat_data rk3288_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3288_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3288_DSI1_SEL_VOP_LIT,
.grf_switch_reg = RK3288_GRF_SOC_CON6,
.max_data_lanes = 4,
- .mode_valid = rk3288_mipi_dsi_mode_valid,
};
static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
--
2.6.3
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH 0/1] add multiple clock handling for dwc2 driver
The original posting on Jan 19th have not received any responses, so I resend them. The Current default dwc2 just handle one clock named otg, however, it may have two or more clock need to manage for some new SoCs(such as RK3328), so this adds change clk to clk's array of dwc2_hsotg to handle more clocks operation. Frank Wang (1): usb: dwc2: add multiple clock handling drivers/usb/dwc2/core.h | 5 - drivers/usb/dwc2/platform.c | 39 ++- 2 files changed, 30 insertions(+), 14 deletions(-) -- 1.9.1
[RESEND PATCH 1/1] usb: dwc2: add multiple clock handling
Originally, dwc2 just handle one clock named otg, however, it may have
two or more clock need to manage for some new SoCs, so this adds
change clk to clk's array of dwc2_hsotg to handle more clocks operation.
Signed-off-by: Frank Wang
---
drivers/usb/dwc2/core.h | 5 -
drivers/usb/dwc2/platform.c | 39 ++-
2 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1a7e830..d10a466 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -121,6 +121,9 @@ static inline void dwc2_writel(u32 value, void __iomem
*addr)
/* Maximum number of Endpoints/HostChannels */
#define MAX_EPS_CHANNELS 16
+/* Maximum number of dwc2 clocks */
+#define DWC2_MAX_CLKS 3
+
/* dwc2-hsotg declarations */
static const char * const dwc2_hsotg_supply_names[] = {
"vusb_d", /* digital USB supply, 1.2V */
@@ -913,7 +916,7 @@ struct dwc2_hsotg {
spinlock_t lock;
void *priv;
int irq;
- struct clk *clk;
+ struct clk *clks[DWC2_MAX_CLKS];
struct reset_control *reset;
unsigned int queuing_high_bandwidth:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 9564bc7..795fc43b 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -123,17 +123,20 @@ static int dwc2_get_dr_mode(struct dwc2_hsotg *hsotg)
static int __dwc2_lowlevel_hw_enable(struct dwc2_hsotg *hsotg)
{
struct platform_device *pdev = to_platform_device(hsotg->dev);
- int ret;
+ int clk, ret;
ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
hsotg->supplies);
if (ret)
return ret;
- if (hsotg->clk) {
- ret = clk_prepare_enable(hsotg->clk);
- if (ret)
+ for (clk = 0; clk < DWC2_MAX_CLKS && hsotg->clks[clk]; clk++) {
+ ret = clk_prepare_enable(hsotg->clks[clk]);
+ if (ret) {
+ while (--clk >= 0)
+ clk_disable_unprepare(hsotg->clks[clk]);
return ret;
+ }
}
if (hsotg->uphy) {
@@ -168,7 +171,7 @@ int dwc2_lowlevel_hw_enable(struct dwc2_hsotg *hsotg)
static int __dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
{
struct platform_device *pdev = to_platform_device(hsotg->dev);
- int ret = 0;
+ int clk, ret = 0;
if (hsotg->uphy) {
usb_phy_shutdown(hsotg->uphy);
@@ -182,8 +185,9 @@ static int __dwc2_lowlevel_hw_disable(struct dwc2_hsotg
*hsotg)
if (ret)
return ret;
- if (hsotg->clk)
- clk_disable_unprepare(hsotg->clk);
+ for (clk = DWC2_MAX_CLKS - 1; clk >= 0; clk--)
+ if (hsotg->clks[clk])
+ clk_disable_unprepare(hsotg->clks[clk]);
ret = regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies),
hsotg->supplies);
@@ -209,7 +213,7 @@ int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
{
- int i, ret;
+ int i, clk, ret;
hsotg->reset = devm_reset_control_get_optional(hsotg->dev, "dwc2");
if (IS_ERR(hsotg->reset)) {
@@ -282,11 +286,20 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
hsotg->phyif = GUSBCFG_PHYIF8;
}
- /* Clock */
- hsotg->clk = devm_clk_get(hsotg->dev, "otg");
- if (IS_ERR(hsotg->clk)) {
- hsotg->clk = NULL;
- dev_dbg(hsotg->dev, "cannot get otg clock\n");
+ /* Clocks */
+ for (clk = 0; clk < DWC2_MAX_CLKS; clk++) {
+ hsotg->clks[clk] = of_clk_get(hsotg->dev->of_node, clk);
+ if (IS_ERR(hsotg->clks[clk])) {
+ ret = PTR_ERR(hsotg->clks[clk]);
+ if (ret == -EPROBE_DEFER) {
+ while (--clk >= 0)
+ clk_put(hsotg->clks[clk]);
+ return ret;
+ }
+
+ hsotg->clks[clk] = NULL;
+ break;
+ }
}
/* Regulators */
--
1.9.1
Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call
On Sat, Feb 04, 2017 at 11:11:27PM +0100, Miklos Szeredi wrote: > Well, it's not historical; at least not yet. The deadlock is there > alright: mmap fuse file to addr; read byte from mapped page -> page > locked; this triggeres read request served in same process but > separate thread; write addr-headerlen to fuse dev; trying to lock same > page -> deadlock. Let me see if I got it straight - you have the same fuse file mmapped in two processes, one of them being fuse server (either sharing the entire address space, or the same area mapped in both). Another process faults the sucker in; filemap_fault() locks the page and goes fuse_readpage() -> fuse_do_readpage() -> fuse_send_read() -> -> fuse_request_send() -> __fuse_request_send() which puts request into queue and goes to sleep in request_wait_answer(). Eventually, read() on /dev/fuse (or splice(), whatever) by server picks that request and reply is formed and fed back into /dev/fuse. There we (in fuse_do_dev_write()) call copy_out_args(), which tries to copy into our (still locked) page a piece of data coming from server-supplied iovec. As it is, you are calling get_user_pages_fast(), triggering handle_mm_fault(). Since that malicous FPOS of a server tried to feed you the _same_ mmapped file, you hit a deadlock. In server's context. Correct? Convoluted, but possible. But. Why the hell do we care whether that deadlock hits in get_user_pages_fast() or in copy_from_user()? Put it another way, what difference does it make whether we take that fault with or without FR_LOCKED in req->flags? > The deadlock can be broken by aborting or force unmounting: return > error for original read request; page unlocked; device write can get > page lock and return. > > The reason we need to prohibit pagefault while copying is that when > request is aborted and the caller returns the memory in the request > may become invalid (e.g. data from stack). ??? IDGI. Your request is marked aborted and should presumably fail, so that when request_wait_answer() wakes up and finds it screwed, fuse_readpage() would just return an error and filemap_fault() will return VM_FAULT_SIGBUS, with page left not uptodate and _not_ inserted into page tables. What's leaking where?
scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file or directory
Hi Emese, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: a572a1b999489efb591287632279c6c9eca3e4ed commit: 543c37cb165049c3be24a0d4733e67caa2b33eef Add sancov plugin date: 8 months ago config: x86_64-randconfig-in0-02050939 (attached as .config) compiler: gcc-4.6 (Debian 4.6.4-7) 4.6.4 reproduce: git checkout 543c37cb165049c3be24a0d4733e67caa2b33eef # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: -fsanitize=kernel-address is not supported by compiler scripts/Makefile.gcc-plugins:17: warning: cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is not supported by compiler ++(scripts/gcc-plugin.sh:2): main(): dirname scripts/gcc-plugin.sh +(scripts/gcc-plugin.sh:2): main(): srctree=scripts ++(scripts/gcc-plugin.sh:3): main(): gcc-4.6 -print-file-name=plugin +(scripts/gcc-plugin.sh:3): main(): gccplugins_dir=plugin ++(scripts/gcc-plugin.sh:12): main(): gcc-4.6 -E -x c++ - -o /dev/null -Iscripts/gcc-plugins -Iplugin/include +(scripts/gcc-plugin.sh:12): main(): plugincc='In file included from :1:0: >> scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file >> or directory compilation terminated.' +(scripts/gcc-plugin.sh:14): main(): '[' 1 -ne 0 ']' +(scripts/gcc-plugin.sh:16): main(): exit 1 scripts/Makefile.gcc-plugins:30: warning: your gcc installation does not support plugins, perhaps the necessary headers are missing? Makefile:677: Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: -fsanitize=kernel-address is not supported by compiler In file included from scripts/gcc-plugins/sancov_plugin.c:22:0: >> scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file >> or directory #include "bversion.h" ^ compilation terminated. In file included from scripts/gcc-plugins/cyc_complexity_plugin.c:21:0: >> scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file >> or directory #include "bversion.h" ^ compilation terminated. make[2]: *** [scripts/gcc-plugins/cyc_complexity_plugin.o] Error 1 make[2]: *** [scripts/gcc-plugins/sancov_plugin.o] Error 1 make[2]: Target '__build' not remade because of errors. make[1]: *** [gcc-plugins] Error 2 make[1]: Target 'prepare' not remade because of errors. make: *** [sub-make] Error 2 vim +4 scripts/gcc-plugins/gcc-common.h 6b90bd4b Emese Revfy 2016-05-24 1 #ifndef GCC_COMMON_H_INCLUDED 6b90bd4b Emese Revfy 2016-05-24 2 #define GCC_COMMON_H_INCLUDED 6b90bd4b Emese Revfy 2016-05-24 3 6b90bd4b Emese Revfy 2016-05-24 @4 #include "bversion.h" 6b90bd4b Emese Revfy 2016-05-24 5 #if BUILDING_GCC_VERSION >= 6000 6b90bd4b Emese Revfy 2016-05-24 6 #include "gcc-plugin.h" 6b90bd4b Emese Revfy 2016-05-24 7 #else :: The code at line 4 was first introduced by commit :: 6b90bd4ba40b38dc13c2782469c1c77e4ed79915 GCC plugin infrastructure :: TO: Emese Revfy :: CC: Michal Marek --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 4/5] Input: xpad - restore LED state after device resume
On 02/04/2017 05:17 PM, kbuild test robot wrote: > Hi Cameron, > > [auto build test ERROR on input/next] > [also build test ERROR on v4.10-rc6 next-20170203] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Cameron-Gutman/Correctly-support-some-quirky-Xbox-One-pads/20170205-083659 > base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next > config: x86_64-randconfig-x016-201706 (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce: > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >drivers/input/joystick/xpad.c: In function 'xpad_resume': >>> drivers/input/joystick/xpad.c:1700:10: error: 'struct usb_xpad' has no >>> member named 'led' > if (xpad->led) > ^~ >>> drivers/input/joystick/xpad.c:1701:3: error: implicit declaration of >>> function 'xpad_send_led_command' [-Werror=implicit-function-declaration] > xpad_send_led_command(xpad, xpad->led->led_cdev.brightness); > ^ >drivers/input/joystick/xpad.c:1701:35: error: 'struct usb_xpad' has no > member named 'led' > xpad_send_led_command(xpad, xpad->led->led_cdev.brightness); > ^~ >cc1: some warnings being treated as errors Whoops, missed a CONFIG_JOYSTICK_XPAD_LEDS guard around that. I'll send a v2 in the next day or two, incorporating this fix plus any review comments made in the meantime. > > vim +1700 drivers/input/joystick/xpad.c > > 1694retval = xpad_start_xbox_one(xpad); > 1695} > 1696mutex_unlock(&input->mutex); > 1697} > 1698 > 1699/* LED state is lost across resume, so resend the last > command */ >> 1700 if (xpad->led) >> 1701 xpad_send_led_command(xpad, >> xpad->led->led_cdev.brightness); > 1702 > 1703return retval; > 1704} > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation > Regards, Cameron
Re: [PATCH v4 6/8] ARM: dts: sun8i: Add audio codec, dai and card for A33
Hi Mylène, [auto build test ERROR on asoc/for-next] [also build test ERROR on v4.10-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Myl-ne-Josserand/Add-sun8i-A33-audio-driver/20170202-173022 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next config: arm-vf610m4_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): >> ERROR: Input tree has errors, aborting (use -f to force output) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: Regression on next-20170203 spi/for-next 3f87493930a0f qemu on x86_64
On 02/04/2017 12:05 PM, Luis R. Rodriguez wrote: I could not boot next-20170203 on my x86_64 qemu instance. It stalls at: [0.015549] CPU: Physical Processor ID: 0 [0.015842] mce: CPU supports 10 MCE banks [0.016032] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0 [0.016393] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 [0.016871] Freeing SMP alternatives memory: 24K [0.017710] ftrace: allocating 25888 entries in 102 pages [0.024102] smpboot: Max logical packages: 4 [0.024524] x2apic enabled [0.024851] Switched APIC routing to physical x2apic. [0.025755] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 There may be a possible problem or change in the timer code. For the most part the "kvm64" cpu works for me, but I saw this once: smpboot: Max logical packages: 1 ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A ... . (found apic 0 pin 2) ... ... failed. ...trying to set up timer as Virtual Wire IRQ... . failed. ...trying to set up timer as ExtINT IRQ... . failed :(. Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option. The "normal" log with -next looks as follows: smpboot: Max logical packages: 4 ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A ... . (found apic 0 pin 2) ... ... failed. ...trying to set up timer as Virtual Wire IRQ... . failed. ...trying to set up timer as ExtINT IRQ... . works. Upstream (v4.10-rc6-193-ga572a1b99948), the same command yields no error at all: ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 smpboot: CPU0: Intel Common KVM processor (family: 0xf, model: 0x6, stepping: 0x1) The "new" error message is also seen with other CPUs, not just with "kvm64". I am using qemu 2.8. Maybe we should try to figure out where the new error messages come from ? Thanks, Guenter
Re: [PATCH 4/5] Input: xpad - restore LED state after device resume
Hi Cameron, [auto build test ERROR on input/next] [also build test ERROR on v4.10-rc6 next-20170203] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Cameron-Gutman/Correctly-support-some-quirky-Xbox-One-pads/20170205-083659 base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next config: x86_64-randconfig-x016-201706 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/input/joystick/xpad.c: In function 'xpad_resume': >> drivers/input/joystick/xpad.c:1700:10: error: 'struct usb_xpad' has no >> member named 'led' if (xpad->led) ^~ >> drivers/input/joystick/xpad.c:1701:3: error: implicit declaration of >> function 'xpad_send_led_command' [-Werror=implicit-function-declaration] xpad_send_led_command(xpad, xpad->led->led_cdev.brightness); ^ drivers/input/joystick/xpad.c:1701:35: error: 'struct usb_xpad' has no member named 'led' xpad_send_led_command(xpad, xpad->led->led_cdev.brightness); ^~ cc1: some warnings being treated as errors vim +1700 drivers/input/joystick/xpad.c 1694 retval = xpad_start_xbox_one(xpad); 1695 } 1696 mutex_unlock(&input->mutex); 1697 } 1698 1699 /* LED state is lost across resume, so resend the last command */ > 1700 if (xpad->led) > 1701 xpad_send_led_command(xpad, > xpad->led->led_cdev.brightness); 1702 1703 return retval; 1704 } --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"
On 02/04/2017 01:32 PM, Dmitry Osipenko wrote: On 04.02.2017 21:41, Larry Finger wrote: On 02/04/2017 10:58 AM, Dmitry Osipenko wrote: Seems the problem is caused by rtl92c_dm_*() casting .priv to "struct rtl_pci_priv", while it is "struct rtl_usb_priv". Those routines are shared by rtl8192ce and rtl8192cu, thus we need to make that difference in cast to be immaterial. I think we need to move "struct bt_coexist_info" to the beginning of both rtlpci_priv and rtl_usb_priv. Then it should not matter. I do not have a gcc version new enough to turn KASAN testing on, thus the attached patch is only compile tested. Does it fix the problem? Thank you for the patch, it indeed fixes the bug. I noticed that struct rtl_priv contains .btcoexist, isn't it duplicated in the struct rtl_pci_priv? Thanks for testing. When I submit the patch, is it OK to cite your reporting and testing? Yes, the bt_coexist_info structure is in two different places. I will change the code in rtl8192c-common and rtl8192ce to use only the one in rtlpriv. That should satisfy the problem you reported, as well as clean up the code. Thanks again, Larry
Re: [PATCH 1/2] watchdog: sama5d4: Cache MR instead of a partial config
On 01/30/2017 09:18 AM, Alexandre Belloni wrote:
.config is used to cache a part of WDT_MR at probe time and is not used
afterwards. Instead of doing that, actually cache MR and avoid reading it
every time it is modified.
Signed-off-by: Alexandre Belloni
Reviewed-by: Guenter Roeck
[ hoping that you'll remember to fix the problem in the set_timeout function ]
---
drivers/watchdog/sama5d4_wdt.c | 45 ++
1 file changed, 19 insertions(+), 26 deletions(-)
diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
index a49634cdc1cc..6dd07bef515a 100644
--- a/drivers/watchdog/sama5d4_wdt.c
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -28,7 +28,7 @@
struct sama5d4_wdt {
struct watchdog_device wdd;
void __iomem*reg_base;
- u32 config;
+ u32 mr;
};
static int wdt_timeout = WDT_DEFAULT_TIMEOUT;
@@ -53,11 +53,9 @@ MODULE_PARM_DESC(nowayout,
static int sama5d4_wdt_start(struct watchdog_device *wdd)
{
struct sama5d4_wdt *wdt = watchdog_get_drvdata(wdd);
- u32 reg;
- reg = wdt_read(wdt, AT91_WDT_MR);
- reg &= ~AT91_WDT_WDDIS;
- wdt_write(wdt, AT91_WDT_MR, reg);
+ wdt->mr &= ~AT91_WDT_WDDIS;
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr);
return 0;
}
@@ -65,11 +63,9 @@ static int sama5d4_wdt_start(struct watchdog_device *wdd)
static int sama5d4_wdt_stop(struct watchdog_device *wdd)
{
struct sama5d4_wdt *wdt = watchdog_get_drvdata(wdd);
- u32 reg;
- reg = wdt_read(wdt, AT91_WDT_MR);
- reg |= AT91_WDT_WDDIS;
- wdt_write(wdt, AT91_WDT_MR, reg);
+ wdt->mr |= AT91_WDT_WDDIS;
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr);
return 0;
}
@@ -88,14 +84,12 @@ static int sama5d4_wdt_set_timeout(struct watchdog_device
*wdd,
{
struct sama5d4_wdt *wdt = watchdog_get_drvdata(wdd);
u32 value = WDT_SEC2TICKS(timeout);
- u32 reg;
- reg = wdt_read(wdt, AT91_WDT_MR);
- reg &= ~AT91_WDT_WDV;
- reg &= ~AT91_WDT_WDD;
- reg |= AT91_WDT_SET_WDV(value);
- reg |= AT91_WDT_SET_WDD(value);
- wdt_write(wdt, AT91_WDT_MR, reg);
+ wdt->mr &= ~AT91_WDT_WDV;
+ wdt->mr &= ~AT91_WDT_WDD;
+ wdt->mr |= AT91_WDT_SET_WDV(value);
+ wdt->mr |= AT91_WDT_SET_WDD(value);
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr);
wdd->timeout = timeout;
@@ -132,19 +126,19 @@ static int of_sama5d4_wdt_init(struct device_node *np,
struct sama5d4_wdt *wdt)
{
const char *tmp;
- wdt->config = AT91_WDT_WDDIS;
+ wdt->mr = AT91_WDT_WDDIS;
if (!of_property_read_string(np, "atmel,watchdog-type", &tmp) &&
!strcmp(tmp, "software"))
- wdt->config |= AT91_WDT_WDFIEN;
+ wdt->mr |= AT91_WDT_WDFIEN;
else
- wdt->config |= AT91_WDT_WDRSTEN;
+ wdt->mr |= AT91_WDT_WDRSTEN;
if (of_property_read_bool(np, "atmel,idle-halt"))
- wdt->config |= AT91_WDT_WDIDLEHLT;
+ wdt->mr |= AT91_WDT_WDIDLEHLT;
if (of_property_read_bool(np, "atmel,dbg-halt"))
- wdt->config |= AT91_WDT_WDDBGHLT;
+ wdt->mr |= AT91_WDT_WDDBGHLT;
return 0;
}
@@ -163,11 +157,10 @@ static int sama5d4_wdt_init(struct sama5d4_wdt *wdt)
reg &= ~AT91_WDT_WDDIS;
wdt_write(wdt, AT91_WDT_MR, reg);
- reg = wdt->config;
- reg |= AT91_WDT_SET_WDD(value);
- reg |= AT91_WDT_SET_WDV(value);
+ wdt->mr |= AT91_WDT_SET_WDD(value);
+ wdt->mr |= AT91_WDT_SET_WDV(value);
- wdt_write(wdt, AT91_WDT_MR, reg);
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr);
return 0;
}
@@ -211,7 +204,7 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
return ret;
}
- if ((wdt->config & AT91_WDT_WDFIEN) && irq) {
+ if ((wdt->mr & AT91_WDT_WDFIEN) && irq) {
ret = devm_request_irq(&pdev->dev, irq, sama5d4_wdt_irq_handler,
IRQF_SHARED | IRQF_IRQPOLL |
IRQF_NO_SUSPEND, pdev->name, pdev);
Re: [PATCH] xen-netfront: Improve error handling during initialization
From: Ross Lagerwall Date: Wed, 1 Feb 2017 15:50:22 + > * Delay timer creation so that if initializing a queue fails, the timer > has not been setup yet. setup_timer() doesn't do anything that must be "undone" if an error occurs and we have to cleanup. It just assigns some values to some timer struct fields, that's it. Therefore this change is extraneous and unnecessary.
Re: Linux 4.9.7
On Saturday, February 4, 2017 2:59:05 AM EST, Greg KH wrote: On Fri, Feb 03, 2017 at 11:07:08PM -0500, Ed Tomlinson wrote: Hi, Any reports of 4.9.7 breaking X? I run arch and keep it up to date. With todays updates and 4.9.7 built here X will not start kde correctly. Reverting to 4.9.6 fixes things. Config is the same for both builds. I have three btrfs patches and the BFQ 4.9.0-v8r7 ... There was a report of a PCI issue affecting 4.9.6, and the fix for that should be hitting Linus's tree soon (if it's not there already), but I haven't heard anything about problems with 4.9.7. Like the others said, if you could use 'git bisect' to track down the offending problem, that would be wonderful. Greg Looks like the original 4.9.7 build here must have failed in some wierd way. I've run the bisect twice and its good till the end. Sorry for the noise, Ed
[PATCH 4/5] Input: xpad - restore LED state after device resume
The state of pad LEDs can be inconsistent when the system is
woken up after sleep. Rather than leaving the controllers blinking,
let's resend the last LED command to Xbox 360 pads on resume.
Since Xbox One pads stop flashing only when reinitialized, we'll
send them the initialization packet so they calm down too.
Signed-off-by: Cameron Gutman
---
drivers/input/joystick/xpad.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 13f298d..1179266 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -1683,11 +1683,23 @@ static int xpad_resume(struct usb_interface *intf)
retval = xpad360w_start_input(xpad);
} else {
mutex_lock(&input->mutex);
- if (input->users)
+ if (input->users) {
retval = xpad_start_input(xpad);
+ } else if (xpad->xtype == XTYPE_XBOXONE) {
+ /*
+* Even if there are no users, we'll send Xbox One pads
+* the startup sequence so they don't sit there and
+* blink until somebody opens the input device again.
+*/
+ retval = xpad_start_xbox_one(xpad);
+ }
mutex_unlock(&input->mutex);
}
+ /* LED state is lost across resume, so resend the last command */
+ if (xpad->led)
+ xpad_send_led_command(xpad, xpad->led->led_cdev.brightness);
+
return retval;
}
--
2.9.3
[PATCH 3/5] Input: xpad - send rumble on Xbox One init to fix PowerA pads
Some PowerA pads require a rumble packet to start sending
input reports.
Signed-off-by: Cameron Gutman
---
drivers/input/joystick/xpad.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 3f19f32b..13f298d 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -358,6 +358,13 @@ static const struct xpad_output_packet xone_init_pkt[] = {
* or later firmware installed (or present from the factory).
*/
{{0x05, 0x20, 0x00, 0x01, 0x00}, 5, true},
+
+ /*
+* A rumble packet is required for some PowerA pads to start
+* sending input reports. One of those pads is (0x24c6:0x543a).
+*/
+ {{0x09, 0x00, 0x00, 0x09, 0x00, 0x0F, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00}, 13, true},
};
#define XPAD_OUT_CMD_IDX 0
--
2.9.3
[PATCH 2/5] Input: xpad - add init packet for Hori and Titanfall 2 pads
Without sending this packet, the Titanfall 2 pad (0x0e6f:0x0165)
continuously attempts to handshake with the PC and never sends
any input reports.
The Hori gamepad (0x0f0d:0x0067) analog sticks don't work if
this isn't sent, though other buttons do work without it.
Signed-off-by: Cameron Gutman
---
drivers/input/joystick/xpad.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 6f07b5b..3f19f32b 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -346,6 +346,14 @@ struct xpad_output_packet {
/* Sequence numbers will be added before the packets are sent */
static const struct xpad_output_packet xone_init_pkt[] = {
/*
+* This packet is required for the Titanfall 2 Xbox One pads
+* (0x0e6f:0x0165) to finish initialization and for Hori pads
+* (0x0f0d:0x0067) to make the analog sticks work.
+*/
+ {{0x01, 0x20, 0x00, 0x09, 0x00, 0x04, 0x20, 0x3a,
+ 0x00, 0x00, 0x00, 0x80, 0x00}, 13, true},
+
+ /*
* This packet is required for all Xbox One pads with 2015
* or later firmware installed (or present from the factory).
*/
--
2.9.3
[PATCH 5/5] Input: xpad - fix stuck mode button on Xbox One S pad
The Xbox One S requires an ack to its mode button report
otherwise it continuously retransmits the report. This
makes the mode button appear to be stuck down after it
is pressed for the first time.
Signed-off-by: Cameron Gutman
---
drivers/input/joystick/xpad.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 1179266..eb01c54 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -414,6 +414,7 @@ struct usb_xpad {
static int xpad_init_input(struct usb_xpad *xpad);
static void xpad_deinit_input(struct usb_xpad *xpad);
+static void xpadone_ack_mode_report(struct usb_xpad *xpad, u8 seq_num);
/*
* xpad_process_packet
@@ -647,6 +648,14 @@ static void xpadone_process_packet(struct usb_xpad *xpad,
u16 cmd, unsigned char
/* the xbox button has its own special report */
if (data[0] == 0X07) {
+ /*
+* The Xbox One S controller requires these reports to be
+* acked otherwise it continues sending them forever and
+* won't report further mode button events.
+*/
+ if (data[1] == 0x30)
+ xpadone_ack_mode_report(xpad, data[2]);
+
input_report_key(dev, BTN_MODE, data[4] & 0x01);
input_sync(dev);
return;
@@ -983,6 +992,30 @@ static int xpad_start_xbox_one(struct usb_xpad *xpad)
return retval;
}
+static void xpadone_ack_mode_report(struct usb_xpad *xpad, u8 seq_num)
+{
+ unsigned long flags;
+ struct xpad_output_packet *packet =
+ &xpad->out_packets[XPAD_OUT_CMD_IDX];
+ static const u8 mode_report_ack[] = {
+ 0x01, 0x20, 0x00, 0x09, 0x00, 0x07, 0x20, 0x02,
+ 0x00, 0x00, 0x00, 0x00, 0x00
+ };
+
+ spin_lock_irqsave(&xpad->odata_lock, flags);
+
+ packet->len = sizeof(mode_report_ack);
+ memcpy(packet->data, mode_report_ack, packet->len);
+ packet->data[2] = seq_num;
+ packet->pending = true;
+
+ /* Reset the sequence so we send out the ack now */
+ xpad->last_out_packet = -1;
+ xpad_try_sending_next_out_packet(xpad);
+
+ spin_unlock_irqrestore(&xpad->odata_lock, flags);
+}
+
#ifdef CONFIG_JOYSTICK_XPAD_FF
static int xpad_play_effect(struct input_dev *dev, void *data, struct
ff_effect *effect)
{
--
2.9.3
[PATCH 0/5] Correctly support some quirky Xbox One pads
There are a bunch of quirky Xbox One pads that depend on weird initialization things that the Microsoft pads don't. In this series, I've incorporated quirk handling from Valve's Steam Link driver[0] and the 360Controller project[1] for macOS. Patches 1 - 3 are split that way in case 2 or 3 introduce regressions that need to be bisected. The new packet in patch 2 has been in Pavel's xpad repository[2] for a little over a month without complaints, and patch 3 just sends a rumble packet on init, so I don't expect regressions. Patch 2 was tested by a GitHub user with a Hori pad[3]. I've tested patch 3 on a previously non-working PowerA pad that I got my hands on. I folded Patch 4 into this series as it was previously submitted alone. It is unchanged from its original submission. Patch 5 was a patch I had previously dropped from a previous series, but it turns out to still be needed for Xbox One S pads on the latest firmware. It has also been in Pavel's repository for months without complaints. [0]: https://github.com/ValveSoftware/steamlink-sdk/blob/master/kernel/drivers/input/joystick/xpad.c [1]: https://github.com/360Controller/360Controller [2]: https://github.com/paroj/xpad [3]: https://github.com/paroj/xpad/issues/59 Cameron Gutman (5): Input: xpad - use a packet array to start Xbox One pads Input: xpad - add init packet for Hori and Titanfall 2 pads Input: xpad - send rumble on Xbox One init to fix PowerA pads Input: xpad - restore LED state after device resume Input: xpad - fix stuck mode button on Xbox One S pad drivers/input/joystick/xpad.c | 102 -- 1 file changed, 88 insertions(+), 14 deletions(-) -- 2.9.3
[PATCH 1/5] Input: xpad - use a packet array to start Xbox One pads
This is preparatory work for supporting some 3rd party
pads that need more initialization packets than just
one. No initialization behavior change expected.
Signed-off-by: Cameron Gutman
---
drivers/input/joystick/xpad.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 247fd3a..6f07b5b 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -343,6 +343,15 @@ struct xpad_output_packet {
bool pending;
};
+/* Sequence numbers will be added before the packets are sent */
+static const struct xpad_output_packet xone_init_pkt[] = {
+ /*
+* This packet is required for all Xbox One pads with 2015
+* or later firmware installed (or present from the factory).
+*/
+ {{0x05, 0x20, 0x00, 0x01, 0x00}, 5, true},
+};
+
#define XPAD_OUT_CMD_IDX 0
#define XPAD_OUT_FF_IDX1
#define XPAD_OUT_LED_IDX (1 + IS_ENABLED(CONFIG_JOYSTICK_XPAD_FF))
@@ -373,6 +382,7 @@ struct usb_xpad {
struct xpad_output_packet out_packets[XPAD_NUM_OUT_PACKETS];
int last_out_packet;
+ int init_seq;
#if defined(CONFIG_JOYSTICK_XPAD_LEDS)
struct xpad_led *led;
@@ -742,8 +752,19 @@ static void xpad_irq_in(struct urb *urb)
static bool xpad_prepare_next_out_packet(struct usb_xpad *xpad)
{
struct xpad_output_packet *pkt, *packet = NULL;
+ const struct xpad_output_packet *init_packet;
int i;
+ if (xpad->xtype == XTYPE_XBOXONE && xpad->init_seq <
ARRAY_SIZE(xone_init_pkt)) {
+ init_packet = &xone_init_pkt[xpad->init_seq++];
+ memcpy(xpad->odata, init_packet->data, init_packet->len);
+ xpad->irq_out->transfer_buffer_length = init_packet->len;
+
+ /* Update packet with current sequence number */
+ xpad->odata[2] = xpad->odata_serial++;
+ return true;
+ }
+
for (i = 0; i < XPAD_NUM_OUT_PACKETS; i++) {
if (++xpad->last_out_packet >= XPAD_NUM_OUT_PACKETS)
xpad->last_out_packet = 0;
@@ -929,24 +950,17 @@ static int xpad_inquiry_pad_presence(struct usb_xpad
*xpad)
static int xpad_start_xbox_one(struct usb_xpad *xpad)
{
- struct xpad_output_packet *packet =
- &xpad->out_packets[XPAD_OUT_CMD_IDX];
unsigned long flags;
int retval;
spin_lock_irqsave(&xpad->odata_lock, flags);
- /* Xbox one controller needs to be initialized. */
- packet->data[0] = 0x05;
- packet->data[1] = 0x20;
- packet->data[2] = xpad->odata_serial++; /* packet serial */
- packet->data[3] = 0x01; /* rumble bit enable? */
- packet->data[4] = 0x00;
- packet->len = 5;
- packet->pending = true;
-
- /* Reset the sequence so we send out start packet first */
- xpad->last_out_packet = -1;
+ /*
+* Begin the init sequence by attempting to send a packet.
+* We will cycle through the init packet sequence before
+* sending any packets from the output ring.
+*/
+ xpad->init_seq = 0;
retval = xpad_try_sending_next_out_packet(xpad);
spin_unlock_irqrestore(&xpad->odata_lock, flags);
--
2.9.3
Re: [PATCH] somedriver: remove the initialization of static pointers.
On Sat, Feb 04, 2017 at 08:39:21PM +0100, AbdAllah-MEZITI wrote: > In C a static pointer will be initialized to NULL (e.g: draft C99 standard > $6.7.8): > "If an object that has static storage duration is not initialized > explicitly, then: > __ if it has pointer type, it is initialized to a null pointer;" > > Signed-off-by: AbdAllah-MEZITI Your subject is very odd :( And is that the correct spelling of your name that you use for legal documents? If not, please fix up when you resend this. Also, fix the line-wrapping of your changelog, and the C99 standard is not a "draft" anymore, it was released in 1999 :) thanks, greg k-h
Re: [v2,6/6] watchdog: ts4600: add driver for TS-4600 watchdog
On Fri, Feb 03, 2017 at 02:47:29PM -0500, Sebastien Bourdelin wrote:
> This watchdog is instantiated in a FPGA and can only be access using a
> GPIOs bit-banged bus, called the NBUS by Technologic Systems.
> The watchdog is made of only one register, called the feed register.
> Writing to this register will re-arm the watchdog for a given time (and
> enable it if it was disable). It can be disabled by writing a special
> value into it.
> ---
> Changes v1 -> v2:
> - rebase on master
> - retrieve the ts_nbus instantiated by the parent node (suggested by
> Linus Walleij)
> - rename the wdt by watchdog in the device tree and in the
> documentation (suggested by Rob Herring)
> - add a dependency to the TS_NBUS driver in the Kconfig (suggested by
> Guenter Roeck)
> - simplify the set_timeout function (suggested by Guenter Roeck)
> - use the max_hw_heartbeat_ms callback instead of the max_timeout
> callback (suggested by Guenter Roeck)
>
> Signed-off-by: Sebastien Bourdelin
> ---
> .../devicetree/bindings/watchdog/ts4600-wdt.txt| 16 ++
> arch/arm/boot/dts/imx28-ts4600-common.dtsi | 5 +
> drivers/watchdog/Kconfig | 11 ++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/ts4600_wdt.c | 217
> +
> 5 files changed, 250 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
> create mode 100644 drivers/watchdog/ts4600_wdt.c
>
> diff --git a/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
> b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
> new file mode 100644
> index ..7de00ceae341
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
> @@ -0,0 +1,16 @@
> +TS-4600 Technologic Systems Watchdog
> +
> +Required properties:
> +- compatible: must be "technologic,ts4600-wdt"
> +- reg: offset to the FPGA's watchdog register
> +
> +Optional property:
> +- timeout-sec: contains the watchdog timeout in seconds.
> +
> +Example:
> +
> +watchdog {
> + compatible = "technologic,ts4600-wdt";
> + reg = <0x2a>;
> + timeout-sec = <10>;
> +};
> diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> index c6282d5479de..092c2eed0fe7 100644
> --- a/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> +++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> @@ -116,6 +116,11 @@
> ts-strobe-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
> ts-ale-gpios= <&gpio0 26 GPIO_ACTIVE_HIGH>;
> ts-rdy-gpios= <&gpio0 21 GPIO_ACTIVE_HIGH>;
> +
> + watchdog@2a {
> + compatible = "technologic,ts4600-wdt";
> + reg = <0x2a>;
> + };
> };
>
> };
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index acb00b53a520..ab1355eefad1 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -500,6 +500,17 @@ config NUC900_WATCHDOG
> To compile this driver as a module, choose M here: the
> module will be called nuc900_wdt.
>
> +config TS4600_WATCHDOG
> + tristate "TS-4600 Watchdog"
> + depends on TS_NBUS
> + depends on HAS_IOMEM && OF
> + depends on SOC_IMX28 || COMPILE_TEST
> + select WATCHDOG_CORE
> + help
> + Technologic Systems TS-4600 has watchdog timer implemented in
> + an external FPGA. Say Y here if you want to support for the
> + watchdog timer on TS-4600 board.
> +
> config TS4800_WATCHDOG
> tristate "TS-4800 Watchdog"
> depends on HAS_IOMEM && OF
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 0c3d35e3c334..d5e164d2b4cd 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
> obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
> obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
> obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
> +obj-$(CONFIG_TS4600_WATCHDOG) += ts4600_wdt.o
> obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
> obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
> obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
> diff --git a/drivers/watchdog/ts4600_wdt.c b/drivers/watchdog/ts4600_wdt.c
> new file mode 100644
> index ..d7bf6cc04986
> --- /dev/null
> +++ b/drivers/watchdog/ts4600_wdt.c
> @@ -0,0 +1,217 @@
> +/*
> + * Watchdog driver for TS-4600 based boards
> + *
> + * Copyright (c) 2016 - Savoir-faire Linux
> + * Author: Sebastien Bourdelin
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * The watchdog on the TS-4600 based boards is in an FPGA and can only be
> + * accessed using a GPIO bit-banged bus called the NBUS by Technologic
> Systems.
> + *
Re: [PATCH v9 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family
On 02/03/2017 05:34 PM, Baoyou Xie wrote:
This patch adds watchdog controller driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie
Reviewed-by: Guenter Roeck
---
drivers/watchdog/Kconfig | 10 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/zx2967_wdt.c | 291 ++
3 files changed, 302 insertions(+)
create mode 100644 drivers/watchdog/zx2967_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index acb00b5..05093a2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -714,6 +714,16 @@ config ASPEED_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called aspeed_wdt.
+config ZX2967_WATCHDOG
+ tristate "ZTE zx2967 SoCs watchdog support"
+ depends on ARCH_ZX
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the watchdog timer
+ in ZTE zx2967 SoCs.
+ To compile this driver as a module, choose M here: the
+ module will be called zx2967_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0c3d35e..bf2d296 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
+obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/zx2967_wdt.c b/drivers/watchdog/zx2967_wdt.c
new file mode 100644
index 000..e290d5a
--- /dev/null
+++ b/drivers/watchdog/zx2967_wdt.c
@@ -0,0 +1,291 @@
+/*
+ * watchdog driver for ZTE's zx2967 family
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ZX2967_WDT_CFG_REG 0x4
+#define ZX2967_WDT_LOAD_REG0x8
+#define ZX2967_WDT_REFRESH_REG 0x18
+#define ZX2967_WDT_START_REG 0x1c
+
+#define ZX2967_WDT_REFRESH_MASKGENMASK(5, 0)
+
+#define ZX2967_WDT_CFG_DIV(n) n) & 0xff) - 1) << 8)
+#define ZX2967_WDT_START_EN0x1
+
+/*
+ * Hardware magic number.
+ * When watchdog reg is written, the lowest 16 bits are valid, but
+ * the highest 16 bits should be always this number.
+ */
+#define ZX2967_WDT_WRITEKEY(0x1234 << 16)
+#define ZX2967_WDT_VAL_MASKGENMASK(15, 0)
+
+#define ZX2967_WDT_DIV_DEFAULT 16
+#define ZX2967_WDT_DEFAULT_TIMEOUT 32
+#define ZX2967_WDT_MIN_TIMEOUT 1
+#define ZX2967_WDT_MAX_TIMEOUT 524
+#define ZX2967_WDT_MAX_COUNT 0x
+
+#define ZX2967_WDT_CLK_FREQ0x8000
+
+#define ZX2967_WDT_FLAG_REBOOT_MON BIT(0)
+
+struct zx2967_wdt {
+ struct watchdog_device wdt_device;
+ void __iomem*reg_base;
+ struct clk *clock;
+};
+
+static inline u32 zx2967_wdt_readl(struct zx2967_wdt *wdt, u16 reg)
+{
+ return readl_relaxed(wdt->reg_base + reg);
+}
+
+static inline void zx2967_wdt_writel(struct zx2967_wdt *wdt, u16 reg, u32 val)
+{
+ writel_relaxed(val | ZX2967_WDT_WRITEKEY, wdt->reg_base + reg);
+}
+
+static void zx2967_wdt_refresh(struct zx2967_wdt *wdt)
+{
+ u32 val;
+
+ val = zx2967_wdt_readl(wdt, ZX2967_WDT_REFRESH_REG);
+ /*
+* Bit 4-5, 1 and 2: refresh config info
+* Bit 2-3, 1 and 2: refresh counter
+* Bit 0-1, 1 and 2: refresh int-value
+* we shift each group value between 1 and 2 to refresh all data.
+*/
+ val ^= ZX2967_WDT_REFRESH_MASK;
+ zx2967_wdt_writel(wdt, ZX2967_WDT_REFRESH_REG,
+ val & ZX2967_WDT_VAL_MASK);
+}
+
+static int
+zx2967_wdt_set_timeout(struct watchdog_device *wdd, unsigned int timeout)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+ unsigned int divisor = ZX2967_WDT_DIV_DEFAULT;
+ u32 count;
+
+ count = timeout * ZX2967_WDT_CLK_FREQ;
+ if (count > divisor * ZX2967_WDT_MAX_COUNT)
+ divisor = DIV_ROUND_UP(count, ZX2967_WDT_MAX_COUNT);
+ count = DIV_ROUND_UP(count, divisor);
+ zx2967_wdt_writel(wdt, ZX2967_WDT_CFG_REG,
+ ZX2967_WDT_CFG_DIV(divisor) & ZX2967_WDT_VAL_MASK);
+ zx2967_wdt_writel(wdt, ZX2967_WDT_LOAD_REG,
+ count & ZX2967_WDT_VAL_MASK);
+ zx2967_wdt_refresh(wdt);
+ wdd->timeout = (count * divisor) / ZX2967_WDT_CLK_FREQ;
+
+ return 0;
+}
+
+static void __zx2967_wdt_start(struct zx2967_wdt *wdt)
+{
+ u32 val;
Re: [PATCH v9 2/3] MAINTAINERS: add zx2967 watchdog controller driver to ARM ZTE architecture
On 02/03/2017 05:34 PM, Baoyou Xie wrote: Add the zx2967 watchdog controller driver as maintained by ARM ZTE architecture maintainers, as they're parts of the core IP. Signed-off-by: Baoyou Xie Reviewed-by: Guenter Roeck I assume you'll submit this patch through the arm tree ? Guenter --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index edfdea3..275c434 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1990,11 +1990,13 @@ F: drivers/clk/zte/ F: drivers/reset/reset-zx2967.c F: drivers/soc/zte/ F: drivers/thermal/zx* +F: drivers/watchdog/zx2967_wdt.c F: Documentation/devicetree/bindings/arm/zte.txt F: Documentation/devicetree/bindings/clock/zx296702-clk.txt F: Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt F: Documentation/devicetree/bindings/soc/zte/ F: Documentation/devicetree/bindings/thermal/zx* +F: Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt F: include/dt-bindings/soc/zx*.h ARM/ZYNQ ARCHITECTURE
Re: [PATCH v9 1/3] dt: bindings: add documentation for zx2967 family watchdog controller
On 02/03/2017 05:34 PM, Baoyou Xie wrote:
This patch adds dt-binding documentation for zx2967 family
watchdog controller.
Signed-off-by: Baoyou Xie
Acked-by: Rob Herring
Reviewed-by: Guenter Roeck
---
.../bindings/watchdog/zte,zx2967-wdt.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
new file mode 100644
index 000..06ce677
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
@@ -0,0 +1,32 @@
+ZTE zx2967 Watchdog timer
+
+Required properties:
+
+- compatible : should be one of the following.
+ * zte,zx296718-wdt
+- reg : Specifies base physical address and size of the registers.
+- clocks : Pairs of phandle and specifier referencing the controller's clocks.
+- resets : Reference to the reset controller controlling the watchdog
+ controller.
+
+Optional properties:
+
+- timeout-sec : Contains the watchdog timeout in seconds.
+- zte,wdt-reset-sysctrl : Directs how to reset system by the watchdog.
+ if we don't want to restart system when watchdog been triggered,
+ it's not required, vice versa.
+ It should include following fields.
+ * phandle of aon-sysctrl.
+ * offset of register that be written, should be 0xb0.
+ * configure value that be written to aon-sysctrl.
+ * bit mask, corresponding bits will be affected.
+
+Example:
+
+wdt: watchdog@1465000 {
+ compatible = "zte,zx296718-wdt";
+ reg = <0x1465000 0x1000>;
+ clocks = <&topcrm WDT_WCLK>;
+ resets = <&toprst 35>;
+ zte,wdt-reset-sysctrl = <&aon_sysctrl 0xb0 1 0x115>;
+};
Re: [PATCH 2/2] watchdog: sama5d4: Implement resume hook
On 01/30/2017 09:18 AM, Alexandre Belloni wrote:
When resuming for the deepest state on sama5d2, it is necessary to restore
MR as the registers are lost.
Signed-off-by: Alexandre Belloni
---
drivers/watchdog/sama5d4_wdt.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
index 6dd07bef515a..de8ff10a032e 100644
--- a/drivers/watchdog/sama5d4_wdt.c
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -258,11 +258,28 @@ static const struct of_device_id sama5d4_wdt_of_match[] =
{
};
MODULE_DEVICE_TABLE(of, sama5d4_wdt_of_match);
+#ifdef CONFIG_PM_SLEEP
+static int sama5d4_wdt_resume(struct device *dev)
+{
+ struct sama5d4_wdt *wdt = dev_get_drvdata(dev);
+
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr & ~AT91_WDT_WDDIS);
+ if (wdt->mr & AT91_WDT_WDDIS)
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr);
+
+ return 0;
+}
+#endif
+
First time I ever see a system which doesn't need a matching suspend function.
I assume that isn't needed. With that,
Reviewed-by: Guenter Roeck
Thanks,
Guenter
+static SIMPLE_DEV_PM_OPS(sama5d4_wdt_pm_ops, NULL,
+sama5d4_wdt_resume);
+
static struct platform_driver sama5d4_wdt_driver = {
.probe = sama5d4_wdt_probe,
.remove = sama5d4_wdt_remove,
.driver = {
.name = "sama5d4_wdt",
+ .pm = &sama5d4_wdt_pm_ops,
.of_match_table = sama5d4_wdt_of_match,
}
};
Re: [PATCH] hwmon: (w83791d) Make use of hwmon_device_register_with_groups
On 02/04/2017 03:12 PM, Alexey Khoroshilov wrote:
There is no remove of w83791d_group_fanpwm45 sysfs group.
Fix the problem by switching to hwmon_device_register_with_groups().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/hwmon/w83791d.c | 40 +++-
1 file changed, 15 insertions(+), 25 deletions(-)
diff --git a/drivers/hwmon/w83791d.c b/drivers/hwmon/w83791d.c
index 001df856913f..14a19396785e 100644
--- a/drivers/hwmon/w83791d.c
+++ b/drivers/hwmon/w83791d.c
@@ -1211,7 +1211,7 @@ static DEVICE_ATTR(vrm, S_IRUGO | S_IWUSR, show_vrm_reg,
store_vrm_reg);
&sda_temp_beep[X].dev_attr.attr,\
&sda_temp_alarm[X].dev_attr.attr
-static struct attribute *w83791d_attributes[] = {
+static struct attribute *w83791d_attrs[] = {
IN_UNIT_ATTRS(0),
IN_UNIT_ATTRS(1),
IN_UNIT_ATTRS(2),
@@ -1248,16 +1248,14 @@ static struct attribute *w83791d_attributes[] = {
NULL
};
-static const struct attribute_group w83791d_group = {
- .attrs = w83791d_attributes,
-};
+ATTRIBUTE_GROUPS(w83791d);
/*
* Separate group of attributes for fan/pwm 4-5. Their pins can also be
* in use for GPIO in which case their sysfs-interface should not be made
* available
*/
-static struct attribute *w83791d_attributes_fanpwm45[] = {
+static struct attribute *w83791d_attrs_fanpwm45[] = {
FAN_UNIT_ATTRS(3),
FAN_UNIT_ATTRS(4),
&sda_pwm[3].dev_attr.attr,
@@ -1266,7 +1264,13 @@ static struct attribute *w83791d_attributes_fanpwm45[] =
{
};
static const struct attribute_group w83791d_group_fanpwm45 = {
- .attrs = w83791d_attributes_fanpwm45,
+ .attrs = w83791d_attrs_fanpwm45,
+};
+
+static const struct attribute_group *w83791d_groups_fanpwm45[] = {
+ &w83791d_group,
+ &w83791d_group_fanpwm45,
+ NULL
};
static int w83791d_detect_subclients(struct i2c_client *client)
@@ -1376,6 +1380,7 @@ static int w83791d_probe(struct i2c_client *client,
struct device *dev = &client->dev;
int i, err;
u8 has_fanpwm45;
+ const struct attribute_group **groups;
#ifdef DEBUG
int val1;
@@ -1406,34 +1411,20 @@ static int w83791d_probe(struct i2c_client *client,
for (i = 0; i < NUMBER_OF_FANIN; i++)
data->fan_min[i] = w83791d_read(client, W83791D_REG_FAN_MIN[i]);
- /* Register sysfs hooks */
- err = sysfs_create_group(&client->dev.kobj, &w83791d_group);
- if (err)
- goto error3;
-
/* Check if pins of fan/pwm 4-5 are in use as GPIO */
has_fanpwm45 = w83791d_read(client, W83791D_REG_GPIO) & 0x10;
- if (has_fanpwm45) {
- err = sysfs_create_group(&client->dev.kobj,
-&w83791d_group_fanpwm45);
- if (err)
- goto error4;
- }
+ groups = has_fanpwm45 ? w83791d_groups_fanpwm45 : w83791d_groups;
/* Everything is ready, now register the working device */
- data->hwmon_dev = hwmon_device_register(dev);
+ data->hwmon_dev = hwmon_device_register_with_groups(dev, "w83791d",
+ NULL, groups);
The new API attaches the hwmon attributes to the hwmon device, not to the
i2c device. This means that one has to use dev_get_drvdata() in the
access functions, and store the i2c device in the local data structure
(here: struct w83791d_data). Also, one has to pass the local data
structure as argument to hwmon_device_register_with_groups().
You did not do any of that, which makes me wonder if you tested this
code. Unless I am really missing something, it should crash quite nicely
if you load the driver on a system with this chip and try to access
any of the attributes.
Guenter
if (IS_ERR(data->hwmon_dev)) {
err = PTR_ERR(data->hwmon_dev);
- goto error5;
+ goto error3;
}
return 0;
-error5:
- if (has_fanpwm45)
- sysfs_remove_group(&client->dev.kobj, &w83791d_group_fanpwm45);
-error4:
- sysfs_remove_group(&client->dev.kobj, &w83791d_group);
error3:
if (data->lm75[0] != NULL)
i2c_unregister_device(data->lm75[0]);
@@ -1447,7 +1438,6 @@ static int w83791d_remove(struct i2c_client *client)
struct w83791d_data *data = i2c_get_clientdata(client);
hwmon_device_unregister(data->hwmon_dev);
- sysfs_remove_group(&client->dev.kobj, &w83791d_group);
if (data->lm75[0] != NULL)
i2c_unregister_device(data->lm75[0]);
Re: [PATCH linux v5 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
On 01/31/2017 07:43 AM, eaja...@linux.vnet.ibm.com wrote: From: "Edward A. James" Add core support for polling the OCC for it's sensor data and parsing that data into sensor-specific information. Signed-off-by: Edward A. James Signed-off-by: Andrew Jeffery --- Documentation/hwmon/occ| 40 MAINTAINERS| 7 + drivers/hwmon/Kconfig | 2 + drivers/hwmon/Makefile | 1 + drivers/hwmon/occ/Kconfig | 15 ++ drivers/hwmon/occ/Makefile | 1 + drivers/hwmon/occ/occ.c| 470 + drivers/hwmon/occ/occ.h| 80 drivers/hwmon/occ/scom.h | 47 + 9 files changed, 663 insertions(+) create mode 100644 Documentation/hwmon/occ create mode 100644 drivers/hwmon/occ/Kconfig create mode 100644 drivers/hwmon/occ/Makefile create mode 100644 drivers/hwmon/occ/occ.c create mode 100644 drivers/hwmon/occ/occ.h create mode 100644 drivers/hwmon/occ/scom.h diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ new file mode 100644 index 000..79d1642 --- /dev/null +++ b/Documentation/hwmon/occ @@ -0,0 +1,40 @@ +Kernel driver occ += + +Supported chips: + * ASPEED AST2400 + * ASPEED AST2500 + +Please note that the chip must be connected to a POWER8 or POWER9 processor +(see the BMC - Host Communications section). + +Author: Eddie James + +Description +--- + +This driver implements support for the OCC (On-Chip Controller) on the IBM +POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The +OCC is an embedded processor that provides real time power and thermal +monitoring. + +This driver provides an interface on a BMC to poll OCC sensor data, set user +power caps, and perform some basic OCC error handling. + +Currently, all versions of the OCC support four types of sensor data: power, +temperature, frequency, and "caps," which indicate limits and thresholds used +internally on the OCC. + +BMC - Host Communications +- + +For the POWER8 application, the BMC can communicate with the P8 over I2C bus. +However, to access the OCC register space, any data transfer must use a SCOM +operation. SCOM is a procedure to initiate a data transfer, typically of 8 +bytes. SCOMs consist of writing a 32-bit command register and then +reading/writing two 32-bit data registers. This driver implements these +SCOM operations over I2C bus in order to communicate with the OCC. + +For the POWER9 application, the BMC can communicate with the P9 over FSI bus +and SBE engine. Once again, SCOM operations are required. This driver will +implement SCOM ops over FSI/SBE. This will require the FSI driver. diff --git a/MAINTAINERS b/MAINTAINERS index 5f10c28..193a13b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9128,6 +9128,13 @@ T: git git://linuxtv.org/media_tree.git S: Maintained F: drivers/media/i2c/ov7670.c +ON-CHIP CONTROLLER HWMON DRIVER +M: Eddie James +L: linux-hw...@vger.kernel.org +S: Maintained +F: Documentation/hwmon/occ +F: drivers/hwmon/occ/ + ONENAND FLASH DRIVER M: Kyungmin Park L: linux-...@lists.infradead.org diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 190d270..e80ca81 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -1240,6 +1240,8 @@ config SENSORS_NSA320 This driver can also be built as a module. If so, the module will be called nsa320-hwmon. +source drivers/hwmon/occ/Kconfig + config SENSORS_PCF8591 tristate "Philips PCF8591 ADC/DAC" depends on I2C diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index d2cb7e8..c7ec5d4 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -169,6 +169,7 @@ obj-$(CONFIG_SENSORS_WM831X)+= wm831x-hwmon.o obj-$(CONFIG_SENSORS_WM8350) += wm8350-hwmon.o obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o +obj-$(CONFIG_SENSORS_PPC_OCC) += occ/ obj-$(CONFIG_PMBUS)+= pmbus/ ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig new file mode 100644 index 000..cdb64a7 --- /dev/null +++ b/drivers/hwmon/occ/Kconfig @@ -0,0 +1,15 @@ +# +# On Chip Controller configuration +# + +menuconfig SENSORS_PPC_OCC + bool "PPC On-Chip Controller" + help + If you say yes here you get support to monitor Power CPU + sensors via the On-Chip Controller (OCC). + + Generally this is used by management controllers such as a BMC + on an OpenPower system. + + This driver can also be built as a module. If so, the module + will be called occ. diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile new file mode 100644 index 000..93cb52f --- /dev/null +++ b/drivers/hwmon/occ/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o diff --git a/drivers/hwmon/occ/occ.c b/drivers/hwmon/occ/occ.c new file mode 100644 index 000..cb9f916 ---
Re: Regression on next-20170203 spi/for-next 3f87493930a0f qemu on x86_64
Hi all, On Sun, 5 Feb 2017 10:17:29 +1100 Stephen Rothwell wrote: > > On Sat, 4 Feb 2017 12:05:42 -0800 "Luis R. Rodriguez" > wrote: > > > > though so it seems something with my configuration and boot. I > > bisected next-20170203 between its latest commit and v4.10-rc6 and > > ended up with this bad commit: > > > > 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 > > > > $ git show 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 > > commit 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 > > Merge: 7c3b1edeee66 3f87493930a0 > > Author: Stephen Rothwell > > Date: Fri Feb 3 12:30:38 2017 +1100 > > > > Merge remote-tracking branch 'spi/for-next' > > > > I have checked Next/SHA1s and it shows: > > > > mcgrof@piggy ~/linux-next (git::original)$ grep spi Next/SHA1s > > spi-nordc12bcccadafb5441170e6b7c8a438c91d4f385b > > spi3f87493930a0f934549b04e100ecc2110e4f1efd > > hwspinlockbd5717a4632cdecafe82d03de7dcb3b1876e2828 > > > > The commit 3f87493930a0f934549b04e100ecc2110e4f1efd then seems to be > > what I need to test. I have cloned Mark's spi tree and just tried to > > boot the for-next branch (on v4.10-rc1) on > > 3f87493930a0f934549b04e100ecc2110e4f1efd, and it boots successfully. > > This would lead me to believe this issue might be related to the merge > > conflict resolution done by Stephen, but wanted to check and ask. > > Perhaps there might be some specific tests I can run. > > OK, it is possible that the merge is actually incorrect. I did *not* > do any manual resolution of that merge and git only reported an > automatic resolution in file drivers/spi/spi-bcm-qspi.c (which looks ok > from a quick glance). > > It is always possible that there is some semantic conflict that git > won't see and didn;t also involve a syntactic conflict or a build > failure. e.g. the internal semantics of a function changes on one side > of the merge but a new usage expecting the old semantics is introduced > on the other side. Just to mention, there was no change to the spi tree between next-20170202 and next-20170203. I assume that next-20170202 is fine? If so, you could try bisecting with next-20170202 as good and 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 as bad. I have no idea if that sort of bisec will even work, though. Or if commit 8cfb3801a57a (the merge of the spi tree in next-20170202) is fine, then you could try using that as your starting good (that will remove a lot of next-20170202). -- Cheers, Stephen Rothwell
[tip:x86/cpufeature] x86/cpufeature: Enable RING3MWAIT for Knights Mill
Commit-ID: 4d8bb00604b182b62e7786bae0e58e0befeeff85
Gitweb: http://git.kernel.org/tip/4d8bb00604b182b62e7786bae0e58e0befeeff85
Author: Piotr Luc
AuthorDate: Fri, 20 Jan 2017 14:22:37 +0100
Committer: Thomas Gleixner
CommitDate: Sun, 5 Feb 2017 00:19:52 +0100
x86/cpufeature: Enable RING3MWAIT for Knights Mill
Enable ring 3 MONITOR/MWAIT for Intel Xeon Phi codenamed Knights Mill. We
can't guarantee that this (KNM) will be the last CPU model that needs this
hack. But, we do recognize that this is far from optimal, and there is an
effort to ensure we don't keep doing extending this hack forever.
Signed-off-by: Piotr Luc
Cc: piotr@intel.com
Cc: dave.han...@linux.intel.com
Link:
http://lkml.kernel.org/r/1484918557-15481-6-git-send-email-grzegorz.andrejc...@intel.com
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/intel.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index da2401a..a4c4ff9 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -79,8 +79,15 @@ static void probe_xeon_phi_r3mwait(struct cpuinfo_x86 *c)
* Ring 3 MONITOR/MWAIT feature cannot be detected without
* cpu model and family comparison.
*/
- if (c->x86 != 6 || c->x86_model != INTEL_FAM6_XEON_PHI_KNL)
+ if (c->x86 != 6)
return;
+ switch (c->x86_model) {
+ case INTEL_FAM6_XEON_PHI_KNL:
+ case INTEL_FAM6_XEON_PHI_KNM:
+ break;
+ default:
+ return;
+ }
if (ring3mwait_disabled) {
msr_clear_bit(MSR_MISC_FEATURE_ENABLES,
Re: Regression on next-20170203 spi/for-next 3f87493930a0f qemu on x86_64
Hi Luis, On Sat, 4 Feb 2017 12:05:42 -0800 "Luis R. Rodriguez" wrote: > > though so it seems something with my configuration and boot. I > bisected next-20170203 between its latest commit and v4.10-rc6 and > ended up with this bad commit: > > 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 > > $ git show 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 > commit 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 > Merge: 7c3b1edeee66 3f87493930a0 > Author: Stephen Rothwell > Date: Fri Feb 3 12:30:38 2017 +1100 > > Merge remote-tracking branch 'spi/for-next' > > I have checked Next/SHA1s and it shows: > > mcgrof@piggy ~/linux-next (git::original)$ grep spi Next/SHA1s > spi-nordc12bcccadafb5441170e6b7c8a438c91d4f385b > spi3f87493930a0f934549b04e100ecc2110e4f1efd > hwspinlockbd5717a4632cdecafe82d03de7dcb3b1876e2828 > > The commit 3f87493930a0f934549b04e100ecc2110e4f1efd then seems to be > what I need to test. I have cloned Mark's spi tree and just tried to > boot the for-next branch (on v4.10-rc1) on > 3f87493930a0f934549b04e100ecc2110e4f1efd, and it boots successfully. > This would lead me to believe this issue might be related to the merge > conflict resolution done by Stephen, but wanted to check and ask. > Perhaps there might be some specific tests I can run. OK, it is possible that the merge is actually incorrect. I did *not* do any manual resolution of that merge and git only reported an automatic resolution in file drivers/spi/spi-bcm-qspi.c (which looks ok from a quick glance). It is always possible that there is some semantic conflict that git won't see and didn;t also involve a syntactic conflict or a build failure. e.g. the internal semantics of a function changes on one side of the merge but a new usage expecting the old semantics is introduced on the other side. -- Cheers, Stephen Rothwell
[PATCH] libnvdimm, pfn: fix memmap reservation size versus 4K alignment
When vmemmap_populate() allocates space for the memmap it does so in 2MB
sized chunks. The libnvdimm-pfn driver incorrectly accounts for this
when the alignment of the device is set to 4K. When this happens we
trigger memory allocation failures in altmap_alloc_block_buf() and
trigger warnings of the form:
WARNING: CPU: 0 PID: 3376 at arch/x86/mm/init_64.c:656
arch_add_memory+0xe4/0xf0
[..]
Call Trace:
dump_stack+0x86/0xc3
__warn+0xcb/0xf0
warn_slowpath_null+0x1d/0x20
arch_add_memory+0xe4/0xf0
devm_memremap_pages+0x29b/0x4e0
Fixes: 315c562536c4 ("libnvdimm, pfn: add 'align' attribute, default to
HPAGE_SIZE")
Cc:
Signed-off-by: Dan Williams
---
drivers/nvdimm/pfn_devs.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index a2ac9e641aa9..6c033c9a2f06 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -627,15 +627,12 @@ static int nd_pfn_init(struct nd_pfn *nd_pfn)
size = resource_size(&nsio->res);
npfns = (size - start_pad - end_trunc - SZ_8K) / SZ_4K;
if (nd_pfn->mode == PFN_MODE_PMEM) {
- unsigned long memmap_size;
-
/*
* vmemmap_populate_hugepages() allocates the memmap array in
* HPAGE_SIZE chunks.
*/
- memmap_size = ALIGN(64 * npfns, HPAGE_SIZE);
- offset = ALIGN(start + SZ_8K + memmap_size + dax_label_reserve,
- nd_pfn->align) - start;
+ offset = ALIGN(start + SZ_8K + 64 * npfns + dax_label_reserve,
+ max(nd_pfn->align, HPAGE_SIZE)) - start;
} else if (nd_pfn->mode == PFN_MODE_RAM)
offset = ALIGN(start + SZ_8K + dax_label_reserve,
nd_pfn->align) - start;
[PATCH] hwmon: (w83791d) Make use of hwmon_device_register_with_groups
There is no remove of w83791d_group_fanpwm45 sysfs group.
Fix the problem by switching to hwmon_device_register_with_groups().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/hwmon/w83791d.c | 40 +++-
1 file changed, 15 insertions(+), 25 deletions(-)
diff --git a/drivers/hwmon/w83791d.c b/drivers/hwmon/w83791d.c
index 001df856913f..14a19396785e 100644
--- a/drivers/hwmon/w83791d.c
+++ b/drivers/hwmon/w83791d.c
@@ -1211,7 +1211,7 @@ static DEVICE_ATTR(vrm, S_IRUGO | S_IWUSR, show_vrm_reg,
store_vrm_reg);
&sda_temp_beep[X].dev_attr.attr,\
&sda_temp_alarm[X].dev_attr.attr
-static struct attribute *w83791d_attributes[] = {
+static struct attribute *w83791d_attrs[] = {
IN_UNIT_ATTRS(0),
IN_UNIT_ATTRS(1),
IN_UNIT_ATTRS(2),
@@ -1248,16 +1248,14 @@ static struct attribute *w83791d_attributes[] = {
NULL
};
-static const struct attribute_group w83791d_group = {
- .attrs = w83791d_attributes,
-};
+ATTRIBUTE_GROUPS(w83791d);
/*
* Separate group of attributes for fan/pwm 4-5. Their pins can also be
* in use for GPIO in which case their sysfs-interface should not be made
* available
*/
-static struct attribute *w83791d_attributes_fanpwm45[] = {
+static struct attribute *w83791d_attrs_fanpwm45[] = {
FAN_UNIT_ATTRS(3),
FAN_UNIT_ATTRS(4),
&sda_pwm[3].dev_attr.attr,
@@ -1266,7 +1264,13 @@ static struct attribute *w83791d_attributes_fanpwm45[] =
{
};
static const struct attribute_group w83791d_group_fanpwm45 = {
- .attrs = w83791d_attributes_fanpwm45,
+ .attrs = w83791d_attrs_fanpwm45,
+};
+
+static const struct attribute_group *w83791d_groups_fanpwm45[] = {
+ &w83791d_group,
+ &w83791d_group_fanpwm45,
+ NULL
};
static int w83791d_detect_subclients(struct i2c_client *client)
@@ -1376,6 +1380,7 @@ static int w83791d_probe(struct i2c_client *client,
struct device *dev = &client->dev;
int i, err;
u8 has_fanpwm45;
+ const struct attribute_group **groups;
#ifdef DEBUG
int val1;
@@ -1406,34 +1411,20 @@ static int w83791d_probe(struct i2c_client *client,
for (i = 0; i < NUMBER_OF_FANIN; i++)
data->fan_min[i] = w83791d_read(client, W83791D_REG_FAN_MIN[i]);
- /* Register sysfs hooks */
- err = sysfs_create_group(&client->dev.kobj, &w83791d_group);
- if (err)
- goto error3;
-
/* Check if pins of fan/pwm 4-5 are in use as GPIO */
has_fanpwm45 = w83791d_read(client, W83791D_REG_GPIO) & 0x10;
- if (has_fanpwm45) {
- err = sysfs_create_group(&client->dev.kobj,
-&w83791d_group_fanpwm45);
- if (err)
- goto error4;
- }
+ groups = has_fanpwm45 ? w83791d_groups_fanpwm45 : w83791d_groups;
/* Everything is ready, now register the working device */
- data->hwmon_dev = hwmon_device_register(dev);
+ data->hwmon_dev = hwmon_device_register_with_groups(dev, "w83791d",
+ NULL, groups);
if (IS_ERR(data->hwmon_dev)) {
err = PTR_ERR(data->hwmon_dev);
- goto error5;
+ goto error3;
}
return 0;
-error5:
- if (has_fanpwm45)
- sysfs_remove_group(&client->dev.kobj, &w83791d_group_fanpwm45);
-error4:
- sysfs_remove_group(&client->dev.kobj, &w83791d_group);
error3:
if (data->lm75[0] != NULL)
i2c_unregister_device(data->lm75[0]);
@@ -1447,7 +1438,6 @@ static int w83791d_remove(struct i2c_client *client)
struct w83791d_data *data = i2c_get_clientdata(client);
hwmon_device_unregister(data->hwmon_dev);
- sysfs_remove_group(&client->dev.kobj, &w83791d_group);
if (data->lm75[0] != NULL)
i2c_unregister_device(data->lm75[0]);
--
2.7.4
Re: [PATCH] shm: Fix unlikely() test of info->seals to test only for WRITE and GROW
On Fri, 3 Feb 2017, Steven Rostedt (VMware) wrote:
> From: "Steven Rostedt (VMware)"
>
> Running my likely/unlikely profiler, I discovered that the test in
> shmem_write_begin() that tests for info->seals as unlikely, is
> always incorrect. This is because shmem_get_inode() sets info->seals to
> have F_SEAL_SEAL set by default, and it is unlikely to be cleared when
> shmem_write_begin() is called. Thus, the if statement is very likely.
>
> But as the if statement block only cares about F_SEAL_WRITE and
> F_SEAL_GROW, change the test to only test those two bits.
>
> Signed-off-by: Steven Rostedt (VMware)
Acked-by: Hugh Dickins
> ---
> mm/shmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index bb53285..ef4cdbb 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -2194,7 +2194,7 @@ shmem_write_begin(struct file *file, struct
> address_space *mapping,
> pgoff_t index = pos >> PAGE_SHIFT;
>
> /* i_mutex is held by caller */
> - if (unlikely(info->seals)) {
> + if (unlikely(info->seals & (F_SEAL_WRITE | F_SEAL_GROW))) {
> if (info->seals & F_SEAL_WRITE)
> return -EPERM;
> if ((info->seals & F_SEAL_GROW) && pos + len > inode->i_size)
> --
> 2.9.3
Re: [PATCH net-next 5/9] sunvnet: add memory barrier before check for tx enable
On 2/3/2017 2:11 PM, Eric Dumazet wrote: Transmit completion might happen on another cpu, regardless of ldom. Therefore you need smp_rmb() here ( like mellanox/mlx4/en_tx.c) , or even smp_mb() as bnx2x does. dma_rmb() is never used in this context. In that case, it looks like there are a couple other similar issues in this code that need attention, that cropped up when the new dma_*mb() interface was added. I'll see what I can do with those as well. The comments and code a few lines above, some of DaveM's original driver code, seem to dissuade us from the SMP version and originally used the bare wmb(). Perhaps the bare rmb() should be used here? Again, I suppose it doesn't matter much as it looks like they all boil down to the same bit of asm, at least on sparc, which is all that matters for this driver. Thanks, sln
[PATCH] net: intel: i40evf: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c | 31 +--
1 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
b/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
index 272d600..122efbd 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
@@ -64,51 +64,50 @@ struct i40evf_stats {
(I40EVF_GLOBAL_STATS_LEN + I40EVF_QUEUE_STATS_LEN(_dev))
/**
- * i40evf_get_settings - Get Link Speed and Duplex settings
+ * i40evf_get_link_ksettings - Get Link Speed and Duplex settings
* @netdev: network interface device structure
- * @ecmd: ethtool command
+ * @cmd: ethtool command
*
* Reports speed/duplex settings. Because this is a VF, we don't know what
* kind of link we really have, so we fake it.
**/
-static int i40evf_get_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int i40evf_get_link_ksettings(struct net_device *netdev,
+struct ethtool_link_ksettings *cmd)
{
struct i40evf_adapter *adapter = netdev_priv(netdev);
- ecmd->supported = 0;
- ecmd->autoneg = AUTONEG_DISABLE;
- ecmd->transceiver = XCVR_DUMMY1;
- ecmd->port = PORT_NONE;
+ ethtool_link_ksettings_zero_link_mode(cmd, supported);
+ cmd->base.autoneg = AUTONEG_DISABLE;
+ cmd->base.port = PORT_NONE;
/* Set speed and duplex */
switch (adapter->link_speed) {
case I40E_LINK_SPEED_40GB:
- ethtool_cmd_speed_set(ecmd, SPEED_4);
+ cmd->base.speed = SPEED_4;
break;
case I40E_LINK_SPEED_25GB:
#ifdef SPEED_25000
- ethtool_cmd_speed_set(ecmd, SPEED_25000);
+ cmd->base.speed = SPEED_25000;
#else
netdev_info(netdev,
"Speed is 25G, display not supported by this
version of ethtool.\n");
#endif
break;
case I40E_LINK_SPEED_20GB:
- ethtool_cmd_speed_set(ecmd, SPEED_2);
+ cmd->base.speed = SPEED_2;
break;
case I40E_LINK_SPEED_10GB:
- ethtool_cmd_speed_set(ecmd, SPEED_1);
+ cmd->base.speed = SPEED_1;
break;
case I40E_LINK_SPEED_1GB:
- ethtool_cmd_speed_set(ecmd, SPEED_1000);
+ cmd->base.speed = SPEED_1000;
break;
case I40E_LINK_SPEED_100MB:
- ethtool_cmd_speed_set(ecmd, SPEED_100);
+ cmd->base.speed = SPEED_100;
break;
default:
break;
}
- ecmd->duplex = DUPLEX_FULL;
+ cmd->base.duplex = DUPLEX_FULL;
return 0;
}
@@ -643,7 +642,6 @@ static int i40evf_set_rxfh(struct net_device *netdev, const
u32 *indir,
}
static const struct ethtool_ops i40evf_ethtool_ops = {
- .get_settings = i40evf_get_settings,
.get_drvinfo= i40evf_get_drvinfo,
.get_link = ethtool_op_get_link,
.get_ringparam = i40evf_get_ringparam,
@@ -663,6 +661,7 @@ static int i40evf_set_rxfh(struct net_device *netdev, const
u32 *indir,
.set_rxfh = i40evf_set_rxfh,
.get_channels = i40evf_get_channels,
.get_rxfh_key_size = i40evf_get_rxfh_key_size,
+ .get_link_ksettings = i40evf_get_link_ksettings,
};
/**
--
1.7.4.4
[PATCH] netfilter: xt_hashlimit: Fix integer divide round to zero.
Diving the divider by the multiplier before applying to the input.
When this would "divide by zero", divide the multiplier by the divider
first then multiply the input by this value.
Currently user2creds outputs zero when input value is bigger than the
number of slices and lower than scale.
This as then user input is applied an integer divide operation to
a number greater than itself (scale).
That rounds up to zero, then we mulitply zero by the credits slice size.
iptables -t filter -I INPUT --protocol tcp --match hashlimit
--hashlimit 40/second --hashlimit-burst 20 --hashlimit-mode srcip
--hashlimit-name syn-flood --jump RETURN
thus trigger the overflow detection code:
xt_hashlimit: overflow, try lower: 25000/20
(25000 as hashlimit avd and 20 the burst)
Here:
134217 slices of (HZ * CREDITS_PER_JIFFY) size.
50 is user input value
100 is XT_HASHLIMIT_SCALE_v2
gives: 0 as user2creds output
Setting burst to "1" typically solve the issue ...
but setting it to "40" does too !
This is on 32bit arch calling into revision 2 of hashlimit.
Signed-off-by: Alban Browaeys
---
net/netfilter/xt_hashlimit.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 10063408141d..df75ad643eef 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -463,21 +463,19 @@ static u32 xt_hashlimit_len_to_chunks(u32 len)
/* Precision saver. */
static u64 user2credits(u64 user, int revision)
{
+ /* Avoid overflow: divide the constant operands first */
if (revision == 1) {
- /* If multiplying would overflow... */
- if (user > 0x / (HZ*CREDITS_PER_JIFFY_v1))
- /* Divide first. */
- return div64_u64(user, XT_HASHLIMIT_SCALE)
- * HZ * CREDITS_PER_JIFFY_v1;
+ return div64_u64(user, div64_u64(XT_HASHLIMIT_SCALE,
+ HZ * CREDITS_PER_JIFFY_v1));
- return div64_u64(user * HZ * CREDITS_PER_JIFFY_v1,
+ return user * div64_u64(HZ * CREDITS_PER_JIFFY_v1,
XT_HASHLIMIT_SCALE);
} else {
- if (user > 0xULL / (HZ*CREDITS_PER_JIFFY))
- return div64_u64(user, XT_HASHLIMIT_SCALE_v2)
- * HZ * CREDITS_PER_JIFFY;
+ if (XT_HASHLIMIT_SCALE_v2 >= HZ * CREDITS_PER_JIFFY)
+ return div64_u64(user, div64_u64(XT_HASHLIMIT_SCALE_v2,
+ HZ * CREDITS_PER_JIFFY));
- return div64_u64(user * HZ * CREDITS_PER_JIFFY,
+ return user * div64_u64(HZ * CREDITS_PER_JIFFY,
XT_HASHLIMIT_SCALE_v2);
}
}
--
2.11.0
Re: [PATCH] devicetree: Add video bus switch
Hi Pavel,
On Sat, Feb 04, 2017 at 10:56:10PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > > +Required properties
> > > > > +===
> > > > > +
> > > > > +compatible : must contain "video-bus-switch"
> > > >
> > > > How generic is this? Should we have e.g. nokia,video-bus-switch? And if
> > > > so,
> > > > change the file name accordingly.
> > >
> > > Generic for "single GPIO controls the switch", AFAICT. But that should
> > > be common enough...
> >
> > Um, yes. Then... how about: video-bus-switch-gpio? No Nokia prefix.
>
> Ok, done. I also fixed the english a bit.
>
> > > > > +reg : The interface:
> > > > > + 0 - port for image signal processor
> > > > > + 1 - port for first camera sensor
> > > > > + 2 - port for second camera sensor
> > > >
> > > > I'd say this must be pretty much specific to the one in N900. You could
> > > > have
> > > > more ports. Or you could say that ports beyond 0 are camera sensors. I
> > > > guess
> > > > this is good enough for now though, it can be changed later on with the
> > > > source if a need arises.
> > >
> > > Well, I'd say that selecting between two sensors is going to be the
> > > common case. If someone needs more than two, it will no longer be
> > > simple GPIO, so we'll have some fixing to do.
> >
> > It could be two GPIOs --- that's how the GPIO I2C mux works.
> >
> > But I'd be surprised if someone ever uses something like that
> > again. ;-)
>
> I'd say.. lets handle that when we see hardware like that.
Yes. :-)
>
> > > > Btw. was it still considered a problem that the endpoint properties for
> > > > the
> > > > sensors can be different? With the g_routing() pad op which is to be
> > > > added,
> > > > the ISP driver (should actually go to a framework somewhere) could
> > > > parse the
> > > > graph and find the proper endpoint there.
> > >
> > > I don't know about g_routing. I added g_endpoint_config method that
> > > passes the configuration, and that seems to work for me.
> > >
> > > I don't see g_routing in next-20170201 . Is there place to look?
> >
> > I think there was a patch by Laurent to LMML quite some time ago. I suppose
> > that set will be repicked soonish.
> >
> > I don't really object using g_endpoint_config() as a temporary solution; I'd
> > like to have Laurent's opinion on that though. Another option is to wait,
> > but we've already waited a looong time (as in total).
>
> Laurent, do you have some input here? We have simple "2 cameras
> connected to one signal processor" situation here. We need some way of
> passing endpoint configuration from the sensors through the switch. I
> did this:
>
> > > @@ -415,6 +416,8 @@ struct v4l2_subdev_video_ops {
> > > const struct v4l2_mbus_config *cfg);
> > > int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
> > >unsigned int *size);
> > > + int (*g_endpoint_config)(struct v4l2_subdev *sd,
> > > + struct v4l2_of_endpoint *cfg);
>
> Google of g_routing tells me:
>
> 9) Highly reconfigurable hardware - Julien Beraud
>
> - 44 sub-devices connected with an interconnect.
> - As long as formats match, any sub-device could be connected to any
> - other sub-device through a link.
> - The result is 44 * 44 links at worst.
> - A switch sub-device proposed as the solution to model the
> - interconnect. The sub-devices are connected to the switch
> - sub-devices through the hardware links that connect to the
> - interconnect.
> - The switch would be controlled through new IOCTLs S_ROUTING and
> - G_ROUTING.
> - Patches available:
> http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
>
> but the patches are from 2005. So I guess I'll need some guidance here...
Yeah, that's where it began (2015?), but right now I can only suggest to
wait until there's more. My estimate is within next couple of weeks /
months. But it won't be years.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call
On Sat, Feb 4, 2017 at 8:26 PM, Al Viro wrote: > On Sat, Feb 04, 2017 at 03:08:42AM +, Al Viro wrote: > What am I missing here? Looks like those checks in fuse_copy_page() are > dead code... They had been there since the initial merge, but AFAICS > they were just as useless in 2.6.14. Rudiments of some prehistorical stuff > that never had been cleaned out, perhaps? Yep, that one is probably historical. I'll double check to make sure, though. Thanks, Miklos
Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call
On Sat, Feb 4, 2017 at 4:08 AM, Al Viro wrote:
> On Thu, Feb 02, 2017 at 09:51:25AM +, Al Viro wrote:
>
>> * fuse_copy_fill(). I'm not at all sure that iov_iter_get_pages()
>> is a good idea there - fuse_copy_do() could bloody well just use
>> copy_{to,from}_iter().
>
> Miklos, could you explain why does lock_request() prohibit page faults until
> the matching unlock_request()? All it does is setting FR_LOCKED on
> our request and the only thing that even looks at that is fuse_abort_conn(),
> which doesn't (AFAICS) wait for anything.
>
> Where does the deadlock come from, and if it's not a deadlock - what is
> it? Or is that comment stale since "fuse: simplify request abort"?
Well, it's not historical; at least not yet. The deadlock is there
alright: mmap fuse file to addr; read byte from mapped page -> page
locked; this triggeres read request served in same process but
separate thread; write addr-headerlen to fuse dev; trying to lock same
page -> deadlock.
The deadlock can be broken by aborting or force unmounting: return
error for original read request; page unlocked; device write can get
page lock and return.
The reason we need to prohibit pagefault while copying is that when
request is aborted and the caller returns the memory in the request
may become invalid (e.g. data from stack).
Another solution would be to copy all data and keep a ref on the copy
by the request even after being aborted. This is the plan for the
future.
Thanks,
Miklos
Re: [PATCH] devicetree: Add video bus switch
Hi!
> > > > +Required properties
> > > > +===
> > > > +
> > > > +compatible : must contain "video-bus-switch"
> > >
> > > How generic is this? Should we have e.g. nokia,video-bus-switch? And if
> > > so,
> > > change the file name accordingly.
> >
> > Generic for "single GPIO controls the switch", AFAICT. But that should
> > be common enough...
>
> Um, yes. Then... how about: video-bus-switch-gpio? No Nokia prefix.
Ok, done. I also fixed the english a bit.
> > > > +reg: The interface:
> > > > + 0 - port for image signal processor
> > > > + 1 - port for first camera sensor
> > > > + 2 - port for second camera sensor
> > >
> > > I'd say this must be pretty much specific to the one in N900. You could
> > > have
> > > more ports. Or you could say that ports beyond 0 are camera sensors. I
> > > guess
> > > this is good enough for now though, it can be changed later on with the
> > > source if a need arises.
> >
> > Well, I'd say that selecting between two sensors is going to be the
> > common case. If someone needs more than two, it will no longer be
> > simple GPIO, so we'll have some fixing to do.
>
> It could be two GPIOs --- that's how the GPIO I2C mux works.
>
> But I'd be surprised if someone ever uses something like that
> again. ;-)
I'd say.. lets handle that when we see hardware like that.
> > > Btw. was it still considered a problem that the endpoint properties for
> > > the
> > > sensors can be different? With the g_routing() pad op which is to be
> > > added,
> > > the ISP driver (should actually go to a framework somewhere) could parse
> > > the
> > > graph and find the proper endpoint there.
> >
> > I don't know about g_routing. I added g_endpoint_config method that
> > passes the configuration, and that seems to work for me.
> >
> > I don't see g_routing in next-20170201 . Is there place to look?
>
> I think there was a patch by Laurent to LMML quite some time ago. I suppose
> that set will be repicked soonish.
>
> I don't really object using g_endpoint_config() as a temporary solution; I'd
> like to have Laurent's opinion on that though. Another option is to wait,
> but we've already waited a looong time (as in total).
Laurent, do you have some input here? We have simple "2 cameras
connected to one signal processor" situation here. We need some way of
passing endpoint configuration from the sensors through the switch. I
did this:
> > @@ -415,6 +416,8 @@ struct v4l2_subdev_video_ops {
> > const struct v4l2_mbus_config *cfg);
> > int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
> >unsigned int *size);
> > + int (*g_endpoint_config)(struct v4l2_subdev *sd,
> > + struct v4l2_of_endpoint *cfg);
Google of g_routing tells me:
9) Highly reconfigurable hardware - Julien Beraud
- 44 sub-devices connected with an interconnect.
- As long as formats match, any sub-device could be connected to any
- other sub-device through a link.
- The result is 44 * 44 links at worst.
- A switch sub-device proposed as the solution to model the
- interconnect. The sub-devices are connected to the switch
- sub-devices through the hardware links that connect to the
- interconnect.
- The switch would be controlled through new IOCTLs S_ROUTING and
- G_ROUTING.
- Patches available:
http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
but the patches are from 2005. So I guess I'll need some guidance here...
> I'll reply to the other patch containing the code.
Ok, thanks.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] iio: adc: handle unknow of_device_id data
On 02/04/2017 10:44 PM, Arnd Bergmann wrote: > On Sat, Feb 4, 2017 at 10:11 PM, Marek Vasut wrote: >> On 02/03/2017 06:01 PM, Arnd Bergmann wrote: >>> diff --git a/drivers/iio/adc/rcar-gyroadc.c b/drivers/iio/adc/rcar-gyroadc.c >>> index 0c44f72c32a8..331ff9a673be 100644 >>> --- a/drivers/iio/adc/rcar-gyroadc.c >>> +++ b/drivers/iio/adc/rcar-gyroadc.c >>> @@ -336,7 +336,7 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev >>> *indio_dev) >>> struct device_node *child; >>> struct regulator *vref; >>> unsigned int reg; >>> - unsigned int adcmode, childmode; >>> + unsigned int adcmode = -1, childmode; >>> unsigned int sample_width; >>> unsigned int num_channels; >>> int ret, first = 1; >>> @@ -366,6 +366,9 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev >>> *indio_dev) >>> channels = rcar_gyroadc_iio_channels_3; >>> num_channels = >>> ARRAY_SIZE(rcar_gyroadc_iio_channels_3); >>> break; >>> + default: >>> + dev_err(dev, "unknown device type"); >> >> Is this verbose output really needed ? > > I don't care much either way, I was just trying to follow what the function > does > for the other failure cases. We can probably drop it though, as this > would indicate > a bug in the driver implementation, while the others are about > incorrect DT data. I don't really want to pester you too much with minor details, let's wait for JIC's opinion. If you're resending, please add my Ack, otherwise consider this patch: Acked-by: Marek Vasut -- Best regards, Marek Vasut
RE: [tip:x86/cpufeature] x86/cpufeature: Enable RING3MWAIT for Knights Mill
Hi Thomas, It looks like there is a typo with the line with 'break' - it should be semicolon there. Could you fix it, please? Thx, Piotr > > Signed-off-by: Piotr Luc > Cc: piotr@intel.com > Cc: dave.han...@linux.intel.com > Link: http://lkml.kernel.org/r/1484918557-15481-6-git-send-email- > grzegorz.andrejc...@intel.com > Signed-off-by: Thomas Gleixner > ... > + case INTEL_FAM6_XEON_PHI_KNL: > + case INTEL_FAM6_XEON_PHI_KNM: > + break: > + default: ...
Re: [PATCH] iio: adc: handle unknow of_device_id data
On Sat, Feb 4, 2017 at 10:11 PM, Marek Vasut wrote: > On 02/03/2017 06:01 PM, Arnd Bergmann wrote: >> diff --git a/drivers/iio/adc/rcar-gyroadc.c b/drivers/iio/adc/rcar-gyroadc.c >> index 0c44f72c32a8..331ff9a673be 100644 >> --- a/drivers/iio/adc/rcar-gyroadc.c >> +++ b/drivers/iio/adc/rcar-gyroadc.c >> @@ -336,7 +336,7 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev >> *indio_dev) >> struct device_node *child; >> struct regulator *vref; >> unsigned int reg; >> - unsigned int adcmode, childmode; >> + unsigned int adcmode = -1, childmode; >> unsigned int sample_width; >> unsigned int num_channels; >> int ret, first = 1; >> @@ -366,6 +366,9 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev >> *indio_dev) >> channels = rcar_gyroadc_iio_channels_3; >> num_channels = ARRAY_SIZE(rcar_gyroadc_iio_channels_3); >> break; >> + default: >> + dev_err(dev, "unknown device type"); > > Is this verbose output really needed ? I don't care much either way, I was just trying to follow what the function does for the other failure cases. We can probably drop it though, as this would indicate a bug in the driver implementation, while the others are about incorrect DT data. Arnd
Re: [PATCH] Documentation: devicetree: Add PHY no lane swap binding
Le 02/04/17 à 09:23, Andrew Lunn a écrit : > On Sat, Feb 04, 2017 at 04:47:47PM +0100, Lukasz Majewski wrote: >> Add the documentation to avoid PHY lane swapping. This is a boolean >> entry to notify the phy device drivers that the TX/RX lanes NO need > > that the TX/RX lanes should not be swapped. > >> to be swapped. >> The use case for this binding mostly happens after wrong HW >> configuration of PHY IC during bootstrap. >> >> Signed-off-by: Lukasz Majewski >> --- >> Documentation/devicetree/bindings/net/phy.txt | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/phy.txt >> b/Documentation/devicetree/bindings/net/phy.txt >> index fb5056b..5e25bc9 100644 >> --- a/Documentation/devicetree/bindings/net/phy.txt >> +++ b/Documentation/devicetree/bindings/net/phy.txt >> @@ -39,6 +39,10 @@ Optional Properties: >> - enet-phy-lane-swap: If set, indicates the PHY will swap the TX/RX lanes to >>compensate for the board being designed with the lanes swapped. >> >> +- enet-phy-lane-no-swap: If set, indicates that PHY will disable swap of the >> + TX/RX lanes. This binding allows the PHY to work correcly after e.g. wrong >> + bootstrap configuration caused by issues in PCB layout design. s/binding/property/ >> + > > We are leaving it undefined what it means if neither > enet-phy-lane-no-swap nor enet-phy-lane-swap properties are present. > Do we want to define this? That the swap should be left untouched by > the driver? Since this is a description of the hardware, absence of a properties should mean that the driver is at freedom to either keep the hardware defaults, or come up with its own settings that are sensible for that particular PHY device. What would you see clarified here? -- Florian
Re: [PATCH] mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy
On 02/03/2017 10:49 AM, Arnd Bergmann wrote:
> kernelci.org reports a warning for this driver, as it copies a local
> variable into a 'const char *' string:
>
> drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of
> 'strncpy' discards 'const' qualifier from pointer target type
> [-Wdiscarded-qualifiers]
>
> Using kstrndup() simplifies the code and avoids the warning.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Marek Vasut
> ---
> drivers/mtd/maps/pmcmsp-flash.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/maps/pmcmsp-flash.c b/drivers/mtd/maps/pmcmsp-flash.c
> index f9fa3fad728e..2051f28ddac6 100644
> --- a/drivers/mtd/maps/pmcmsp-flash.c
> +++ b/drivers/mtd/maps/pmcmsp-flash.c
> @@ -139,15 +139,13 @@ static int __init init_msp_flash(void)
> }
>
> msp_maps[i].bankwidth = 1;
> - msp_maps[i].name = kmalloc(7, GFP_KERNEL);
> + msp_maps[i].name = kstrndup(flash_name, 7, GFP_KERNEL);
> if (!msp_maps[i].name) {
> iounmap(msp_maps[i].virt);
> kfree(msp_parts[i]);
> goto cleanup_loop;
> }
>
> - msp_maps[i].name = strncpy(msp_maps[i].name, flash_name, 7);
> -
> for (j = 0; j < pcnt; j++) {
> part_name[5] = '0' + i;
> part_name[7] = '0' + j;
>
--
Best regards,
Marek Vasut
Re: [PATCH] iio: adc: handle unknow of_device_id data
On 02/03/2017 06:01 PM, Arnd Bergmann wrote:
> If we get an unknown 'childmode' value, a number of variables are not
> initialized properly:
>
> drivers/iio/adc/rcar-gyroadc.c: In function 'rcar_gyroadc_probe':
> drivers/iio/adc/rcar-gyroadc.c:390:5: error: 'num_channels' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/iio/adc/rcar-gyroadc.c:426:22: error: 'sample_width' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/iio/adc/rcar-gyroadc.c:428:23: error: 'channels' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>
> The driver is currently correct, but handling this properly is more robust
> for possible modifications.
Yeah, the OF match will make sure this case is never triggered.
But then again, it triggers kernel ci, so it should be fixed.
Thanks for the patch :)
> There is also a false-positive warning about adcmode being possibly
> uninitialized,
> but that cannot happen as we also check the 'first' flag:
>
> drivers/iio/adc/rcar-gyroadc.c:398:26: error: 'adcmode' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>
> This adds an initialization for 'adcmode' and bails out for any unknown
> childmode.
>
> Fixes: 059c53b32329 ("iio: adc: Add Renesas GyroADC driver")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/iio/adc/rcar-gyroadc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/rcar-gyroadc.c b/drivers/iio/adc/rcar-gyroadc.c
> index 0c44f72c32a8..331ff9a673be 100644
> --- a/drivers/iio/adc/rcar-gyroadc.c
> +++ b/drivers/iio/adc/rcar-gyroadc.c
> @@ -336,7 +336,7 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev
> *indio_dev)
> struct device_node *child;
> struct regulator *vref;
> unsigned int reg;
> - unsigned int adcmode, childmode;
> + unsigned int adcmode = -1, childmode;
> unsigned int sample_width;
> unsigned int num_channels;
> int ret, first = 1;
> @@ -366,6 +366,9 @@ static int rcar_gyroadc_parse_subdevs(struct iio_dev
> *indio_dev)
> channels = rcar_gyroadc_iio_channels_3;
> num_channels = ARRAY_SIZE(rcar_gyroadc_iio_channels_3);
> break;
> + default:
> + dev_err(dev, "unknown device type");
Is this verbose output really needed ?
> + return -EINVAL;
> }
>
> /*
>
--
Best regards,
Marek Vasut
Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup
On Sat, Feb 4, 2017 at 1:04 PM, James Bottomley
wrote:
> On Sat, 2017-02-04 at 12:37 -0800, Dan Williams wrote:
>> On Sat, Feb 4, 2017 at 12:36 PM, Dan Williams <
>> dan.j.willi...@intel.com> wrote:
>> > On Fri, Feb 3, 2017 at 11:09 PM, kernel test robot
>> > wrote:
>> > >
>> > > FYI, we noticed the following commit:
>> > >
>> > > commit: 0dba1314d4f81115dce711292ec7981d17231064 ("scsi, block:
>> > > fix duplicate bdi name registration crashes")
>> > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block
>> > > .git for-4.11/next
>> > >
>> > > in testcase: boot
>> > >
>> > > on test machine: qemu-system-i386 -enable-kvm -cpu
>> > > Haswell,+smep,+smap -m 360M
>> > >
>> > > caused below changes (please refer to attached dmesg/kmsg for
>> > > entire log/backtrace):
>> > >
>> > >
>> > > +--++
>> > > +
>> > > > | efa7c9f97e |
>> > > > 0dba1314d4 |
>> > > +--++
>> > > +
>> > > > boot_successes | 0 | 0
>> > > > |
>> > > > boot_failures| 6 | 6
>> > > > |
>> > > > WARNING:at_include/linux/kref.h:#kobject_get | 6 | 6
>> > > > |
>> > > > BUG:workqueue_lockup-pool| 2 |
>> > > > |
>> > > > WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup| 0 | 6
>> > > > |
>> > > +--++
>> > > +
>> > >
>> > >
>> > >
>> > > [8.820258] [ cut here ]
>> > > [8.821188] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31
>> > > sysfs_warn_dup+0x58/0x70
>> > > [8.822994] sysfs: cannot create duplicate filename
>> > > '/class/scsi_disk/0:0:0:0'
>> > > [8.824567] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
>> > > 4.10.0-rc5-00097-g0dba131 #1
>> > > [8.826275] Hardware name: QEMU Standard PC (i440FX + PIIX,
>> > > 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
>> > > [8.828156] Call Trace:
>> > > [8.828851] dump_stack+0x79/0xa4
>> > > [8.829628] __warn+0xd2/0xf0
>> > > [8.830372] ? sysfs_warn_dup+0x58/0x70
>> > > [8.831211] warn_slowpath_fmt+0x36/0x40
>> > > [8.832054] sysfs_warn_dup+0x58/0x70
>> > > [8.832865] sysfs_do_create_link_sd+0x9e/0xb0
>> > > [8.833844] sysfs_create_link+0x20/0x40
>> > > [8.834714] device_add+0x218/0x610
>> > > [8.835511] ? kvasprintf_const+0x49/0x60
>> > > [8.836352] ? kobject_set_name_vargs+0x62/0x80
>> > > [8.837253] sd_probe+0x31a/0x390
>> > > [8.838027] ? _raw_spin_unlock+0x1d/0x30
>> > > [8.838884] driver_probe_device+0x190/0x4a0
>> > > [8.839751] __device_attach_driver+0x6f/0x100
>> > > [8.840736] ? klist_next+0x6e/0x100
>> > > [8.841538] ? __driver_attach+0xf0/0xf0
>> > > [8.842383] bus_for_each_drv+0x47/0x80
>> > > [8.843226] __device_attach+0xa8/0x120
>> > > [8.844062] ? __driver_attach+0xf0/0xf0
>> > > [8.844902] device_initial_probe+0xd/0x10
>> > > [8.845754] bus_probe_device+0x77/0x80
>> > > [8.846593] device_add+0x320/0x610
>> > > [8.847387] scsi_sysfs_add_sdev+0x85/0x2b0
>> > > [8.848246] ? scsi_attach_vpd+0x1f9/0x210
>> > > [8.849103] scsi_probe_and_add_lun+0xd44/0xe70
>> > > [8.850021] __scsi_scan_target+0xd8/0x690
>> > > [8.850918] ? __pm_runtime_resume+0x37/0x80
>> > > [8.852124] scsi_scan_channel+0x8f/0xb0
>> > > [8.852977] scsi_scan_host_selected+0x100/0x180
>> > > [8.853885] do_scsi_scan_host+0x8a/0x90
>> > > [8.854733] scsi_scan_host+0x15a/0x1a0
>> > > [8.855562] sdebug_driver_probe+0x14f/0x3d0
>> > > [8.856435] ? _raw_spin_unlock+0x1d/0x30
>> > > [8.857270] ? devices_kset_move_last+0x71/0xc0
>> > > [8.858170] ? sysfs_create_link+0x20/0x40
>> > > [8.859057] driver_probe_device+0xd4/0x4a0
>> > > [8.859924] __device_attach_driver+0x6f/0x100
>> > > [8.860814] ? klist_next+0x6e/0x100
>> > > [8.861619] ? __driver_attach+0xf0/0xf0
>> > > [8.862470] bus_for_each_drv+0x47/0x80
>> > > [8.863298] __device_attach+0xa8/0x120
>> > > [8.864131] ? __driver_attach+0xf0/0xf0
>> > > [8.864975] device_initial_probe+0xd/0x10
>> > > [8.865831] bus_probe_device+0x77/0x80
>> > > [8.866704] device_add+0x320/0x610
>> > > [8.867497] ? pm_runtime_init+0xea/0xf0
>> > > [8.868326] device_register+0x12/0x20
>> > > [8.869146] sdebug_add_adapter+0xda/0x1e0
>> > > [8.870002] ? driver_register+0x83/0xe0
>> > > [8.870847] scsi_debug_init+0x5a0/0x6eb
>> > > [8.871686] ? kobject_uevent+0xa/0x10
>> > > [8.872507] ? driver_register+0x83/0xe0
>> > > [8.873336] ? scsi_register_driver+0xf/0x20
>> > > [8.874218] ? init_ch_module+0x9d/0x9d
>> > > [8.875088] do_one_initcall+0x7b/0x132
>> > > [
Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup
On Sat, 2017-02-04 at 12:37 -0800, Dan Williams wrote:
> On Sat, Feb 4, 2017 at 12:36 PM, Dan Williams <
> dan.j.willi...@intel.com> wrote:
> > On Fri, Feb 3, 2017 at 11:09 PM, kernel test robot
> > wrote:
> > >
> > > FYI, we noticed the following commit:
> > >
> > > commit: 0dba1314d4f81115dce711292ec7981d17231064 ("scsi, block:
> > > fix duplicate bdi name registration crashes")
> > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block
> > > .git for-4.11/next
> > >
> > > in testcase: boot
> > >
> > > on test machine: qemu-system-i386 -enable-kvm -cpu
> > > Haswell,+smep,+smap -m 360M
> > >
> > > caused below changes (please refer to attached dmesg/kmsg for
> > > entire log/backtrace):
> > >
> > >
> > > +--++
> > > +
> > > > | efa7c9f97e |
> > > > 0dba1314d4 |
> > > +--++
> > > +
> > > > boot_successes | 0 | 0
> > > > |
> > > > boot_failures| 6 | 6
> > > > |
> > > > WARNING:at_include/linux/kref.h:#kobject_get | 6 | 6
> > > > |
> > > > BUG:workqueue_lockup-pool| 2 |
> > > > |
> > > > WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup| 0 | 6
> > > > |
> > > +--++
> > > +
> > >
> > >
> > >
> > > [8.820258] [ cut here ]
> > > [8.821188] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31
> > > sysfs_warn_dup+0x58/0x70
> > > [8.822994] sysfs: cannot create duplicate filename
> > > '/class/scsi_disk/0:0:0:0'
> > > [8.824567] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
> > > 4.10.0-rc5-00097-g0dba131 #1
> > > [8.826275] Hardware name: QEMU Standard PC (i440FX + PIIX,
> > > 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
> > > [8.828156] Call Trace:
> > > [8.828851] dump_stack+0x79/0xa4
> > > [8.829628] __warn+0xd2/0xf0
> > > [8.830372] ? sysfs_warn_dup+0x58/0x70
> > > [8.831211] warn_slowpath_fmt+0x36/0x40
> > > [8.832054] sysfs_warn_dup+0x58/0x70
> > > [8.832865] sysfs_do_create_link_sd+0x9e/0xb0
> > > [8.833844] sysfs_create_link+0x20/0x40
> > > [8.834714] device_add+0x218/0x610
> > > [8.835511] ? kvasprintf_const+0x49/0x60
> > > [8.836352] ? kobject_set_name_vargs+0x62/0x80
> > > [8.837253] sd_probe+0x31a/0x390
> > > [8.838027] ? _raw_spin_unlock+0x1d/0x30
> > > [8.838884] driver_probe_device+0x190/0x4a0
> > > [8.839751] __device_attach_driver+0x6f/0x100
> > > [8.840736] ? klist_next+0x6e/0x100
> > > [8.841538] ? __driver_attach+0xf0/0xf0
> > > [8.842383] bus_for_each_drv+0x47/0x80
> > > [8.843226] __device_attach+0xa8/0x120
> > > [8.844062] ? __driver_attach+0xf0/0xf0
> > > [8.844902] device_initial_probe+0xd/0x10
> > > [8.845754] bus_probe_device+0x77/0x80
> > > [8.846593] device_add+0x320/0x610
> > > [8.847387] scsi_sysfs_add_sdev+0x85/0x2b0
> > > [8.848246] ? scsi_attach_vpd+0x1f9/0x210
> > > [8.849103] scsi_probe_and_add_lun+0xd44/0xe70
> > > [8.850021] __scsi_scan_target+0xd8/0x690
> > > [8.850918] ? __pm_runtime_resume+0x37/0x80
> > > [8.852124] scsi_scan_channel+0x8f/0xb0
> > > [8.852977] scsi_scan_host_selected+0x100/0x180
> > > [8.853885] do_scsi_scan_host+0x8a/0x90
> > > [8.854733] scsi_scan_host+0x15a/0x1a0
> > > [8.855562] sdebug_driver_probe+0x14f/0x3d0
> > > [8.856435] ? _raw_spin_unlock+0x1d/0x30
> > > [8.857270] ? devices_kset_move_last+0x71/0xc0
> > > [8.858170] ? sysfs_create_link+0x20/0x40
> > > [8.859057] driver_probe_device+0xd4/0x4a0
> > > [8.859924] __device_attach_driver+0x6f/0x100
> > > [8.860814] ? klist_next+0x6e/0x100
> > > [8.861619] ? __driver_attach+0xf0/0xf0
> > > [8.862470] bus_for_each_drv+0x47/0x80
> > > [8.863298] __device_attach+0xa8/0x120
> > > [8.864131] ? __driver_attach+0xf0/0xf0
> > > [8.864975] device_initial_probe+0xd/0x10
> > > [8.865831] bus_probe_device+0x77/0x80
> > > [8.866704] device_add+0x320/0x610
> > > [8.867497] ? pm_runtime_init+0xea/0xf0
> > > [8.868326] device_register+0x12/0x20
> > > [8.869146] sdebug_add_adapter+0xda/0x1e0
> > > [8.870002] ? driver_register+0x83/0xe0
> > > [8.870847] scsi_debug_init+0x5a0/0x6eb
> > > [8.871686] ? kobject_uevent+0xa/0x10
> > > [8.872507] ? driver_register+0x83/0xe0
> > > [8.873336] ? scsi_register_driver+0xf/0x20
> > > [8.874218] ? init_ch_module+0x9d/0x9d
> > > [8.875088] do_one_initcall+0x7b/0x132
> > > [8.875918] ? kernel_init_freeable+0xe7/0x188
> > > [8.876807] kernel_init_freeable+0x10a/0x188
> > > [8.877690] ? rest_init+0xb0/0xb
[PATCH] net: intel: i40e: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 224 ++--
1 files changed, 133 insertions(+), 91 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index cc1465a..011f0b8 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -387,7 +387,7 @@ static void i40e_phy_type_to_ethtool(struct i40e_pf *pf,
u32 *supported,
*
**/
static void i40e_get_settings_link_up(struct i40e_hw *hw,
- struct ethtool_cmd *ecmd,
+ struct ethtool_link_ksettings *cmd,
struct net_device *netdev,
struct i40e_pf *pf)
{
@@ -395,70 +395,76 @@ static void i40e_get_settings_link_up(struct i40e_hw *hw,
u32 link_speed = hw_link_info->link_speed;
u32 e_advertising = 0x0;
u32 e_supported = 0x0;
+ u32 supported, advertising;
+
+ ethtool_convert_link_mode_to_legacy_u32(&supported,
+ cmd->link_modes.supported);
+ ethtool_convert_link_mode_to_legacy_u32(&advertising,
+ cmd->link_modes.advertising);
/* Initialize supported and advertised settings based on phy settings */
switch (hw_link_info->phy_type) {
case I40E_PHY_TYPE_40GBASE_CR4:
case I40E_PHY_TYPE_40GBASE_CR4_CU:
- ecmd->supported = SUPPORTED_Autoneg |
+ supported = SUPPORTED_Autoneg |
SUPPORTED_4baseCR4_Full;
- ecmd->advertising = ADVERTISED_Autoneg |
+ advertising = ADVERTISED_Autoneg |
ADVERTISED_4baseCR4_Full;
break;
case I40E_PHY_TYPE_XLAUI:
case I40E_PHY_TYPE_XLPPI:
case I40E_PHY_TYPE_40GBASE_AOC:
- ecmd->supported = SUPPORTED_4baseCR4_Full;
+ supported = SUPPORTED_4baseCR4_Full;
break;
case I40E_PHY_TYPE_40GBASE_SR4:
- ecmd->supported = SUPPORTED_4baseSR4_Full;
+ supported = SUPPORTED_4baseSR4_Full;
break;
case I40E_PHY_TYPE_40GBASE_LR4:
- ecmd->supported = SUPPORTED_4baseLR4_Full;
+ supported = SUPPORTED_4baseLR4_Full;
break;
case I40E_PHY_TYPE_10GBASE_SR:
case I40E_PHY_TYPE_10GBASE_LR:
case I40E_PHY_TYPE_1000BASE_SX:
case I40E_PHY_TYPE_1000BASE_LX:
- ecmd->supported = SUPPORTED_1baseT_Full;
+ supported = SUPPORTED_1baseT_Full;
if (hw_link_info->module_type[2] &
I40E_MODULE_TYPE_1000BASE_SX ||
hw_link_info->module_type[2] &
I40E_MODULE_TYPE_1000BASE_LX) {
- ecmd->supported |= SUPPORTED_1000baseT_Full;
+ supported |= SUPPORTED_1000baseT_Full;
if (hw_link_info->requested_speeds &
I40E_LINK_SPEED_1GB)
- ecmd->advertising |= ADVERTISED_1000baseT_Full;
+ advertising |= ADVERTISED_1000baseT_Full;
}
if (hw_link_info->requested_speeds & I40E_LINK_SPEED_10GB)
- ecmd->advertising |= ADVERTISED_1baseT_Full;
+ advertising |= ADVERTISED_1baseT_Full;
break;
case I40E_PHY_TYPE_10GBASE_T:
case I40E_PHY_TYPE_1000BASE_T:
case I40E_PHY_TYPE_100BASE_TX:
- ecmd->supported = SUPPORTED_Autoneg |
+ supported = SUPPORTED_Autoneg |
SUPPORTED_1baseT_Full |
SUPPORTED_1000baseT_Full |
SUPPORTED_100baseT_Full;
- ecmd->advertising = ADVERTISED_Autoneg;
+ advertising = ADVERTISED_Autoneg;
if (hw_link_info->requested_speeds & I40E_LINK_SPEED_10GB)
- ecmd->advertising |= ADVERTISED_1baseT_Full;
+ advertising |= ADVERTISED_1baseT_Full;
if (hw_link_info->requested_speeds & I40E_LINK_SPEED_1GB)
- ecmd->advertising |= ADVERTISED_1000baseT_Full;
+ advertising |= ADVERTISED_1000baseT_Full;
if (hw_link_info->requested_speeds & I40E_LINK_SPEED_100MB)
- ecmd->advertising |= ADVERTISED_100baseT_Full;
+ advertising |= ADVERTISED_100base
[PATCH net-next v5 1/4] net: dsa: Rename and export dev_to_net_device()
In preparation for using this function in net/dsa/dsa2.c, rename the function
to make its scope DSA specific, and export it.
Signed-off-by: Florian Fainelli
---
include/net/dsa.h | 1 +
net/dsa/dsa.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 2cb77e64d648..4327b0b03293 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -428,6 +428,7 @@ struct dsa_switch_driver {
void register_switch_driver(struct dsa_switch_driver *type);
void unregister_switch_driver(struct dsa_switch_driver *type);
struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev);
+struct net_device *dsa_dev_to_net_device(struct device *dev);
static inline bool dsa_uses_tagged_protocol(struct dsa_switch_tree *dst)
{
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 619e57a44d1d..5a5f79bbda6f 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -486,7 +486,7 @@ struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev)
}
EXPORT_SYMBOL_GPL(dsa_host_dev_to_mii_bus);
-static struct net_device *dev_to_net_device(struct device *dev)
+struct net_device *dsa_dev_to_net_device(struct device *dev)
{
struct device *d;
@@ -503,6 +503,7 @@ static struct net_device *dev_to_net_device(struct device
*dev)
return NULL;
}
+EXPORT_SYMBOL_GPL(dsa_dev_to_net_device);
#ifdef CONFIG_OF
static int dsa_of_setup_routing_table(struct dsa_platform_data *pd,
@@ -811,7 +812,7 @@ static int dsa_probe(struct platform_device *pdev)
dev = pd->of_netdev;
dev_hold(dev);
} else {
- dev = dev_to_net_device(pd->netdev);
+ dev = dsa_dev_to_net_device(pd->netdev);
}
if (dev == NULL) {
ret = -EPROBE_DEFER;
--
2.9.3
[PATCH net-next v5 4/4] ARM: orion: Register DSA switch as a MDIO device
Utilize the ability to pass board specific MDIO bus information towards a
particular MDIO device thus allowing us to provide the per-port switch layout
to the Marvell 88E6XXX switch driver.
Since we would end-up with conflicting registration paths, do not register the
"dsa" platform device anymore.
Note that the MDIO devices registered by code in net/dsa/dsa2.c does not
parse a dsa_platform_data, but directly take a dsa_chip_data (specific
to a single switch chip), so we update the different call sites to pass
this structure down to orion_ge00_switch_init().
Signed-off-by: Florian Fainelli
---
arch/arm/mach-orion5x/common.c | 2 +-
arch/arm/mach-orion5x/common.h | 4 ++--
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 7 +--
arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 7 +--
arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c | 7 +--
arch/arm/mach-orion5x/wnr854t-setup.c| 2 +-
arch/arm/mach-orion5x/wrt350n-v2-setup.c | 7 +--
arch/arm/plat-orion/common.c | 25 +++--
arch/arm/plat-orion/include/plat/common.h| 4 ++--
9 files changed, 29 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 04910764c385..83a7ec4c16d0 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -105,7 +105,7 @@ void __init orion5x_eth_init(struct
mv643xx_eth_platform_data *eth_data)
/*
* Ethernet switch
/
-void __init orion5x_eth_switch_init(struct dsa_platform_data *d)
+void __init orion5x_eth_switch_init(struct dsa_chip_data *d)
{
orion_ge00_switch_init(d);
}
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index 8a4115bd441d..efeffc6b4ebb 100644
--- a/arch/arm/mach-orion5x/common.h
+++ b/arch/arm/mach-orion5x/common.h
@@ -3,7 +3,7 @@
#include
-struct dsa_platform_data;
+struct dsa_chip_data;
struct mv643xx_eth_platform_data;
struct mv_sata_platform_data;
@@ -41,7 +41,7 @@ void orion5x_setup_wins(void);
void orion5x_ehci0_init(void);
void orion5x_ehci1_init(void);
void orion5x_eth_init(struct mv643xx_eth_platform_data *eth_data);
-void orion5x_eth_switch_init(struct dsa_platform_data *d);
+void orion5x_eth_switch_init(struct dsa_chip_data *d);
void orion5x_i2c_init(void);
void orion5x_sata_init(struct mv_sata_platform_data *sata_data);
void orion5x_spi_init(void);
diff --git a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
index dccadf68ea2b..a3c1336d30c9 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
@@ -101,11 +101,6 @@ static struct dsa_chip_data
rd88f5181l_fxo_switch_chip_data = {
.port_names[7] = "lan3",
};
-static struct dsa_platform_data __initdata rd88f5181l_fxo_switch_plat_data = {
- .nr_chips = 1,
- .chip = &rd88f5181l_fxo_switch_chip_data,
-};
-
static void __init rd88f5181l_fxo_init(void)
{
/*
@@ -120,7 +115,7 @@ static void __init rd88f5181l_fxo_init(void)
*/
orion5x_ehci0_init();
orion5x_eth_init(&rd88f5181l_fxo_eth_data);
- orion5x_eth_switch_init(&rd88f5181l_fxo_switch_plat_data);
+ orion5x_eth_switch_init(&rd88f5181l_fxo_switch_chip_data);
orion5x_uart0_init();
mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
diff --git a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
index affe5ec825de..252efe29bd1a 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
@@ -102,11 +102,6 @@ static struct dsa_chip_data rd88f5181l_ge_switch_chip_data
= {
.port_names[7] = "lan3",
};
-static struct dsa_platform_data __initdata rd88f5181l_ge_switch_plat_data = {
- .nr_chips = 1,
- .chip = &rd88f5181l_ge_switch_chip_data,
-};
-
static struct i2c_board_info __initdata rd88f5181l_ge_i2c_rtc = {
I2C_BOARD_INFO("ds1338", 0x68),
};
@@ -125,7 +120,7 @@ static void __init rd88f5181l_ge_init(void)
*/
orion5x_ehci0_init();
orion5x_eth_init(&rd88f5181l_ge_eth_data);
- orion5x_eth_switch_init(&rd88f5181l_ge_switch_plat_data);
+ orion5x_eth_switch_init(&rd88f5181l_ge_switch_chip_data);
orion5x_i2c_init();
orion5x_uart0_init();
diff --git a/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
b/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
index 67ee8571b03c..f4f1dbe1d91d 100644
--- a/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
@@ -40,11 +40,6 @@ static struct dsa_chip_data rd88f6183ap_ge_switch_chip_data
= {
.port_names[5] = "cpu",
};
-static struct dsa_platform_data __in
[PATCH net-next v5 3/4] net: phy: Allow pre-declaration of MDIO devices
Allow board support code to collect pre-declarations for MDIO devices by
registering them with mdiobus_register_board_info(). SPI and I2C buses
have a similar feature, we were missing this for MDIO devices, but this
is particularly useful for e.g: MDIO-connected switches which need to
provide their port layout (often board-specific) to a MDIO Ethernet
switch driver.
Signed-off-by: Florian Fainelli
---
drivers/net/phy/Makefile | 3 +-
drivers/net/phy/mdio-boardinfo.c | 86
drivers/net/phy/mdio-boardinfo.h | 19 +
drivers/net/phy/mdio_bus.c | 4 ++
drivers/net/phy/mdio_device.c| 11 +
include/linux/mdio.h | 3 ++
include/linux/mod_devicetable.h | 1 +
include/linux/phy.h | 19 +
8 files changed, 145 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/phy/mdio-boardinfo.c
create mode 100644 drivers/net/phy/mdio-boardinfo.h
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 356859ac7c18..407b0b601ea8 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -1,6 +1,7 @@
# Makefile for Linux PHY drivers and MDIO bus drivers
-libphy-y := phy.o phy_device.o mdio_bus.o mdio_device.o
+libphy-y := phy.o phy_device.o mdio_bus.o mdio_device.o \
+ mdio-boardinfo.o
libphy-$(CONFIG_SWPHY) += swphy.o
libphy-$(CONFIG_LED_TRIGGER_PHY) += phy_led_triggers.o
diff --git a/drivers/net/phy/mdio-boardinfo.c b/drivers/net/phy/mdio-boardinfo.c
new file mode 100644
index ..6b988f77da08
--- /dev/null
+++ b/drivers/net/phy/mdio-boardinfo.c
@@ -0,0 +1,86 @@
+/*
+ * mdio-boardinfo - Collect pre-declarations for MDIO devices
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "mdio-boardinfo.h"
+
+static LIST_HEAD(mdio_board_list);
+static DEFINE_MUTEX(mdio_board_lock);
+
+/**
+ * mdiobus_setup_mdiodev_from_board_info - create and setup MDIO devices
+ * from pre-collected board specific MDIO information
+ * @mdiodev: MDIO device pointer
+ * Context: can sleep
+ */
+void mdiobus_setup_mdiodev_from_board_info(struct mii_bus *bus)
+{
+ struct mdio_board_entry *be;
+ struct mdio_device *mdiodev;
+ struct mdio_board_info *bi;
+ int ret;
+
+ mutex_lock(&mdio_board_lock);
+ list_for_each_entry(be, &mdio_board_list, list) {
+ bi = &be->board_info;
+
+ if (strcmp(bus->id, bi->bus_id))
+ continue;
+
+ mdiodev = mdio_device_create(bus, bi->mdio_addr);
+ if (IS_ERR(mdiodev))
+ continue;
+
+ strncpy(mdiodev->modalias, bi->modalias,
+ sizeof(mdiodev->modalias));
+ mdiodev->bus_match = mdio_device_bus_match;
+ mdiodev->dev.platform_data = (void *)bi->platform_data;
+
+ ret = mdio_device_register(mdiodev);
+ if (ret) {
+ mdio_device_free(mdiodev);
+ continue;
+ }
+ }
+ mutex_unlock(&mdio_board_lock);
+}
+
+/**
+ * mdio_register_board_info - register MDIO devices for a given board
+ * @info: array of devices descriptors
+ * @n: number of descriptors provided
+ * Context: can sleep
+ *
+ * The board info passed can be marked with __initdata but be pointers
+ * such as platform_data etc. are copied as-is
+ */
+int mdiobus_register_board_info(const struct mdio_board_info *info,
+ unsigned int n)
+{
+ struct mdio_board_entry *be;
+ unsigned int i;
+
+ be = kcalloc(n, sizeof(*be), GFP_KERNEL);
+ if (!be)
+ return -ENOMEM;
+
+ for (i = 0; i < n; i++, be++, info++) {
+ memcpy(&be->board_info, info, sizeof(*info));
+ mutex_lock(&mdio_board_lock);
+ list_add_tail(&be->list, &mdio_board_list);
+ mutex_unlock(&mdio_board_lock);
+ }
+
+ return 0;
+}
diff --git a/drivers/net/phy/mdio-boardinfo.h b/drivers/net/phy/mdio-boardinfo.h
new file mode 100644
index ..00f98163e90e
--- /dev/null
+++ b/drivers/net/phy/mdio-boardinfo.h
@@ -0,0 +1,19 @@
+/*
+ * mdio-boardinfo.h - board info interface internal to the mdio_bus
+ * component
+ */
+
+#ifndef __MDIO_BOARD_INFO_H
+#define __MDIO_BOARD_INFO_H
+
+#include
+#include
+
+struct mdio_board_entry {
+ struct list_headlist;
+ struct mdio_board_info board_info;
+};
+
+void mdiobus_setup_mdiodev_from_board_info(struct mii_bus *bus);
+
+#endif /* __MDIO_BOARD_INFO_H */
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net
[PATCH net-next v5 0/4] net: dsa: Support for pdata in dsa2
Hi all, This is not exactly new, and was sent before, although back then, I did not have an user of the pre-declared MDIO board information, but now we do. Note that I have additional changes queued up to have b53 register platform data for MIPS bcm47xx and bcm63xx. Yes I know that we should have the Orion platforms eventually be converted to Device Tree, but until that happens, I don't want any remaining users of the old "dsa" platform device (hence the previous DTS submissions for ARM/mvebu) and, there will be platforms out there that most likely won't never see DT coming their way (BCM47xx is almost 100% sure, BCM63xx maybe not in a distant future). We would probably want the whole series to be merged via David Miller's tree to simplify things. Thanks! Changes in v5: - dropped changes to drivers/base/ because after more than a month, we cannot get any answer from Greg KH - rebased against latest net-next/master Changes in v4: - Changed device_find_class() to device_find_in_class_name() - Added kerneldoc above device_find_in_class_name() to explain what it does and the calling convention regarding device reference counts - Changed dev_to_net_device to device_to_net_device() added comments about what it does and the caller conventions regarding reference counts Changes in v3: - Tested EPROBE_DEFER from a mockup MDIO/DSA switch driver and everything is fine, once the driver finally probes we have access to platform data as expected - added comment above dsa_port_is_valid() that port->name is mandatory for platform data cases - added an extra check in dsa_parse_member() for a NULL pdata pointer - fixed a bunch of checkpatch errors and warnings Changes in v2: - Rebased against latest net-next/master - Moved dev_find_class() to device_find_class() into drivers/base/core.c - Moved dev_to_net_device into net/core/dev.c - Utilize dsa_chip_data directly instead of dsa_platform_data - Augmented dsa_chip_data to be multi-CPU port ready Changes from last submission (few months back): - rebased against latest net-next - do not introduce dsa2_platform_data which was overkill and was meant to allow us to do exaclty the same things with platform data and Device Tree we use the existing dsa_platform_data instead - properly register MDIO devices when the MDIO bus is registered and associate platform_data with them - add a change to the Orion platform code to demonstrate how this can be used Thank you Florian Fainelli (4): net: dsa: Rename and export dev_to_net_device() net: dsa: Add support for platform data net: phy: Allow pre-declaration of MDIO devices ARM: orion: Register DSA switch as a MDIO device arch/arm/mach-orion5x/common.c | 2 +- arch/arm/mach-orion5x/common.h | 4 +- arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 7 +- arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 7 +- arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c | 7 +- arch/arm/mach-orion5x/wnr854t-setup.c| 2 +- arch/arm/mach-orion5x/wrt350n-v2-setup.c | 7 +- arch/arm/plat-orion/common.c | 25 +-- arch/arm/plat-orion/include/plat/common.h| 4 +- drivers/net/phy/Makefile | 3 +- drivers/net/phy/mdio-boardinfo.c | 86 ++ drivers/net/phy/mdio-boardinfo.h | 19 + drivers/net/phy/mdio_bus.c | 4 ++ drivers/net/phy/mdio_device.c| 11 +++ include/linux/mdio.h | 3 + include/linux/mod_devicetable.h | 1 + include/linux/phy.h | 19 + include/net/dsa.h| 7 ++ net/dsa/dsa.c| 5 +- net/dsa/dsa2.c | 102 ++- 20 files changed, 268 insertions(+), 57 deletions(-) create mode 100644 drivers/net/phy/mdio-boardinfo.c create mode 100644 drivers/net/phy/mdio-boardinfo.h -- 2.9.3
[PATCH net-next v5 2/4] net: dsa: Add support for platform data
Allow drivers to use the new DSA API with platform data. Most of the
code in net/dsa/dsa2.c does not rely so much on device_nodes and can get
the same information from platform_data instead.
We purposely do not support distributed configurations with platform
data, so drivers should be providing a pointer to a 'struct
dsa_chip_data' structure if they wish to communicate per-port layout.
Multiple CPUs port could potentially be supported and dsa_chip_data is
extended to receive up to one reference to an upstream network device
per port described by a dsa_chip_data structure.
dsa_dev_to_net_device() increments the network device's reference count,
so we intentionally call dev_put() to be consistent with the DT-enabled
path, until we have a generic notifier based solution.
Signed-off-by: Florian Fainelli
---
include/net/dsa.h | 6
net/dsa/dsa2.c| 102 --
2 files changed, 90 insertions(+), 18 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 4327b0b03293..4449f22c64ba 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -44,6 +44,11 @@ struct dsa_chip_data {
struct device *host_dev;
int sw_addr;
+ /*
+* Reference to network devices
+*/
+ struct device *netdev[DSA_MAX_PORTS];
+
/* set to size of eeprom if supported by the switch */
int eeprom_len;
@@ -166,6 +171,7 @@ struct dsa_mall_tc_entry {
struct dsa_port {
struct dsa_switch *ds;
unsigned intindex;
+ const char *name;
struct net_device *netdev;
struct device_node *dn;
unsigned intageing_time;
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 9f8cc26be9ea..3a7631f63638 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -78,19 +78,28 @@ static void dsa_dst_del_ds(struct dsa_switch_tree *dst,
kref_put(&dst->refcount, dsa_free_dst);
}
+/* For platform data configurations, we need to have a valid name argument to
+ * differentiate a disabled port from an enabled one
+ */
static bool dsa_port_is_valid(struct dsa_port *port)
{
- return !!port->dn;
+ return !!(port->dn || port->name);
}
static bool dsa_port_is_dsa(struct dsa_port *port)
{
- return !!of_parse_phandle(port->dn, "link", 0);
+ if (port->name && !strcmp(port->name, "dsa"))
+ return true;
+ else
+ return !!of_parse_phandle(port->dn, "link", 0);
}
static bool dsa_port_is_cpu(struct dsa_port *port)
{
- return !!of_parse_phandle(port->dn, "ethernet", 0);
+ if (port->name && !strcmp(port->name, "cpu"))
+ return true;
+ else
+ return !!of_parse_phandle(port->dn, "ethernet", 0);
}
static bool dsa_ds_find_port_dn(struct dsa_switch *ds,
@@ -250,10 +259,11 @@ static void dsa_cpu_port_unapply(struct dsa_port *port,
u32 index,
static int dsa_user_port_apply(struct dsa_port *port, u32 index,
struct dsa_switch *ds)
{
- const char *name;
+ const char *name = port->name;
int err;
- name = of_get_property(port->dn, "label", NULL);
+ if (port->dn)
+ name = of_get_property(port->dn, "label", NULL);
if (!name)
name = "eth%d";
@@ -438,11 +448,16 @@ static int dsa_cpu_parse(struct dsa_port *port, u32 index,
struct net_device *ethernet_dev;
struct device_node *ethernet;
- ethernet = of_parse_phandle(port->dn, "ethernet", 0);
- if (!ethernet)
- return -EINVAL;
+ if (port->dn) {
+ ethernet = of_parse_phandle(port->dn, "ethernet", 0);
+ if (!ethernet)
+ return -EINVAL;
+ ethernet_dev = of_find_net_device_by_node(ethernet);
+ } else {
+ ethernet_dev = dsa_dev_to_net_device(ds->cd->netdev[index]);
+ dev_put(ethernet_dev);
+ }
- ethernet_dev = of_find_net_device_by_node(ethernet);
if (!ethernet_dev)
return -EPROBE_DEFER;
@@ -545,6 +560,33 @@ static int dsa_parse_ports_dn(struct device_node *ports,
struct dsa_switch *ds)
return 0;
}
+static int dsa_parse_ports(struct dsa_chip_data *cd, struct dsa_switch *ds)
+{
+ bool valid_name_found = false;
+ unsigned int i;
+
+ for (i = 0; i < DSA_MAX_PORTS; i++) {
+ if (!cd->port_names[i])
+ continue;
+
+ ds->ports[i].name = cd->port_names[i];
+
+ /* Initialize enabled_port_mask now for drv->setup()
+* to have access to a correct value, just like what
+* net/dsa/dsa.c::dsa_switch_setup_one does.
+*/
+ if (!dsa_port_is_cpu(&ds->ports[i]))
+ ds->enabled_port_mask |= 1 << i;
+
+ valid_name_found = true;
+
[PATCH net-next v5 0/4] net: dsa: Support for pdata in dsa2
Hi all, This is not exactly new, and was sent before, although back then, I did not have an user of the pre-declared MDIO board information, but now we do. Note that I have additional changes queued up to have b53 register platform data for MIPS bcm47xx and bcm63xx. Yes I know that we should have the Orion platforms eventually be converted to Device Tree, but until that happens, I don't want any remaining users of the old "dsa" platform device (hence the previous DTS submissions for ARM/mvebu) and, there will be platforms out there that most likely won't never see DT coming their way (BCM47xx is almost 100% sure, BCM63xx maybe not in a distant future). We would probably want the whole series to be merged via David Miller's tree to simplify things. Thanks! Changes in v5: - dropped changes to drivers/base/ because after more than a month, we cannot get any answer from Greg KH Changes in v4: - Changed device_find_class() to device_find_in_class_name() - Added kerneldoc above device_find_in_class_name() to explain what it does and the calling convention regarding device reference counts - Changed dev_to_net_device to device_to_net_device() added comments about what it does and the caller conventions regarding reference counts Changes in v3: - Tested EPROBE_DEFER from a mockup MDIO/DSA switch driver and everything is fine, once the driver finally probes we have access to platform data as expected - added comment above dsa_port_is_valid() that port->name is mandatory for platform data cases - added an extra check in dsa_parse_member() for a NULL pdata pointer - fixed a bunch of checkpatch errors and warnings Changes in v2: - Rebased against latest net-next/master - Moved dev_find_class() to device_find_class() into drivers/base/core.c - Moved dev_to_net_device into net/core/dev.c - Utilize dsa_chip_data directly instead of dsa_platform_data - Augmented dsa_chip_data to be multi-CPU port ready Changes from last submission (few months back): - rebased against latest net-next - do not introduce dsa2_platform_data which was overkill and was meant to allow us to do exaclty the same things with platform data and Device Tree we use the existing dsa_platform_data instead - properly register MDIO devices when the MDIO bus is registered and associate platform_data with them - add a change to the Orion platform code to demonstrate how this can be used Thank you Florian Fainelli (4): net: dsa: Rename and export dev_to_net_device() net: dsa: Add support for platform data net: phy: Allow pre-declaration of MDIO devices ARM: orion: Register DSA switch as a MDIO device arch/arm/mach-orion5x/common.c | 2 +- arch/arm/mach-orion5x/common.h | 4 +- arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c | 7 +- arch/arm/mach-orion5x/rd88f5181l-ge-setup.c | 7 +- arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c | 7 +- arch/arm/mach-orion5x/wnr854t-setup.c| 2 +- arch/arm/mach-orion5x/wrt350n-v2-setup.c | 7 +- arch/arm/plat-orion/common.c | 25 +-- arch/arm/plat-orion/include/plat/common.h| 4 +- drivers/net/phy/Makefile | 3 +- drivers/net/phy/mdio-boardinfo.c | 86 ++ drivers/net/phy/mdio-boardinfo.h | 19 + drivers/net/phy/mdio_bus.c | 4 ++ drivers/net/phy/mdio_device.c| 11 +++ include/linux/mdio.h | 3 + include/linux/mod_devicetable.h | 1 + include/linux/phy.h | 19 + include/net/dsa.h| 7 ++ net/dsa/dsa.c| 5 +- net/dsa/dsa2.c | 102 ++- 20 files changed, 268 insertions(+), 57 deletions(-) create mode 100644 drivers/net/phy/mdio-boardinfo.c create mode 100644 drivers/net/phy/mdio-boardinfo.h -- 2.9.3
Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup
On Sat, Feb 4, 2017 at 12:36 PM, Dan Williams wrote:
> On Fri, Feb 3, 2017 at 11:09 PM, kernel test robot
> wrote:
>>
>> FYI, we noticed the following commit:
>>
>> commit: 0dba1314d4f81115dce711292ec7981d17231064 ("scsi, block: fix
>> duplicate bdi name registration crashes")
>> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
>> for-4.11/next
>>
>> in testcase: boot
>>
>> on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m
>> 360M
>>
>> caused below changes (please refer to attached dmesg/kmsg for entire
>> log/backtrace):
>>
>>
>> +--+++
>> | | efa7c9f97e | 0dba1314d4 |
>> +--+++
>> | boot_successes | 0 | 0 |
>> | boot_failures| 6 | 6 |
>> | WARNING:at_include/linux/kref.h:#kobject_get | 6 | 6 |
>> | BUG:workqueue_lockup-pool| 2 ||
>> | WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup| 0 | 6 |
>> +--+++
>>
>>
>>
>> [8.820258] [ cut here ]
>> [8.821188] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31
>> sysfs_warn_dup+0x58/0x70
>> [8.822994] sysfs: cannot create duplicate filename
>> '/class/scsi_disk/0:0:0:0'
>> [8.824567] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
>> 4.10.0-rc5-00097-g0dba131 #1
>> [8.826275] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> 1.9.3-20161025_171302-gandalf 04/01/2014
>> [8.828156] Call Trace:
>> [8.828851] dump_stack+0x79/0xa4
>> [8.829628] __warn+0xd2/0xf0
>> [8.830372] ? sysfs_warn_dup+0x58/0x70
>> [8.831211] warn_slowpath_fmt+0x36/0x40
>> [8.832054] sysfs_warn_dup+0x58/0x70
>> [8.832865] sysfs_do_create_link_sd+0x9e/0xb0
>> [8.833844] sysfs_create_link+0x20/0x40
>> [8.834714] device_add+0x218/0x610
>> [8.835511] ? kvasprintf_const+0x49/0x60
>> [8.836352] ? kobject_set_name_vargs+0x62/0x80
>> [8.837253] sd_probe+0x31a/0x390
>> [8.838027] ? _raw_spin_unlock+0x1d/0x30
>> [8.838884] driver_probe_device+0x190/0x4a0
>> [8.839751] __device_attach_driver+0x6f/0x100
>> [8.840736] ? klist_next+0x6e/0x100
>> [8.841538] ? __driver_attach+0xf0/0xf0
>> [8.842383] bus_for_each_drv+0x47/0x80
>> [8.843226] __device_attach+0xa8/0x120
>> [8.844062] ? __driver_attach+0xf0/0xf0
>> [8.844902] device_initial_probe+0xd/0x10
>> [8.845754] bus_probe_device+0x77/0x80
>> [8.846593] device_add+0x320/0x610
>> [8.847387] scsi_sysfs_add_sdev+0x85/0x2b0
>> [8.848246] ? scsi_attach_vpd+0x1f9/0x210
>> [8.849103] scsi_probe_and_add_lun+0xd44/0xe70
>> [8.850021] __scsi_scan_target+0xd8/0x690
>> [8.850918] ? __pm_runtime_resume+0x37/0x80
>> [8.852124] scsi_scan_channel+0x8f/0xb0
>> [8.852977] scsi_scan_host_selected+0x100/0x180
>> [8.853885] do_scsi_scan_host+0x8a/0x90
>> [8.854733] scsi_scan_host+0x15a/0x1a0
>> [8.855562] sdebug_driver_probe+0x14f/0x3d0
>> [8.856435] ? _raw_spin_unlock+0x1d/0x30
>> [8.857270] ? devices_kset_move_last+0x71/0xc0
>> [8.858170] ? sysfs_create_link+0x20/0x40
>> [8.859057] driver_probe_device+0xd4/0x4a0
>> [8.859924] __device_attach_driver+0x6f/0x100
>> [8.860814] ? klist_next+0x6e/0x100
>> [8.861619] ? __driver_attach+0xf0/0xf0
>> [8.862470] bus_for_each_drv+0x47/0x80
>> [8.863298] __device_attach+0xa8/0x120
>> [8.864131] ? __driver_attach+0xf0/0xf0
>> [8.864975] device_initial_probe+0xd/0x10
>> [8.865831] bus_probe_device+0x77/0x80
>> [8.866704] device_add+0x320/0x610
>> [8.867497] ? pm_runtime_init+0xea/0xf0
>> [8.868326] device_register+0x12/0x20
>> [8.869146] sdebug_add_adapter+0xda/0x1e0
>> [8.870002] ? driver_register+0x83/0xe0
>> [8.870847] scsi_debug_init+0x5a0/0x6eb
>> [8.871686] ? kobject_uevent+0xa/0x10
>> [8.872507] ? driver_register+0x83/0xe0
>> [8.873336] ? scsi_register_driver+0xf/0x20
>> [8.874218] ? init_ch_module+0x9d/0x9d
>> [8.875088] do_one_initcall+0x7b/0x132
>> [8.875918] ? kernel_init_freeable+0xe7/0x188
>> [8.876807] kernel_init_freeable+0x10a/0x188
>> [8.877690] ? rest_init+0xb0/0xb0
>> [8.878482] kernel_init+0xb/0x100
>> [8.879262] ? schedule_tail+0xc/0x70
>> [8.880076] ? rest_init+0xb0/0xb0
>> [8.880861] ret_from_fork+0x21/0x2c
>> [8.881688] ---[ end trace 62a20110376b9cdf ]---
>>
>>
>> To reproduce:
>>
>> git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>> cd lkp-tests
>> bin/lkp qemu -k job-script # job-script is attached in
>> this email
>
> These r
Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup
On Fri, Feb 3, 2017 at 11:09 PM, kernel test robot
wrote:
>
> FYI, we noticed the following commit:
>
> commit: 0dba1314d4f81115dce711292ec7981d17231064 ("scsi, block: fix duplicate
> bdi name registration crashes")
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
> for-4.11/next
>
> in testcase: boot
>
> on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
> +--+++
> | | efa7c9f97e | 0dba1314d4 |
> +--+++
> | boot_successes | 0 | 0 |
> | boot_failures| 6 | 6 |
> | WARNING:at_include/linux/kref.h:#kobject_get | 6 | 6 |
> | BUG:workqueue_lockup-pool| 2 ||
> | WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup| 0 | 6 |
> +--+++
>
>
>
> [8.820258] [ cut here ]
> [8.821188] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31
> sysfs_warn_dup+0x58/0x70
> [8.822994] sysfs: cannot create duplicate filename
> '/class/scsi_disk/0:0:0:0'
> [8.824567] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
> 4.10.0-rc5-00097-g0dba131 #1
> [8.826275] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.9.3-20161025_171302-gandalf 04/01/2014
> [8.828156] Call Trace:
> [8.828851] dump_stack+0x79/0xa4
> [8.829628] __warn+0xd2/0xf0
> [8.830372] ? sysfs_warn_dup+0x58/0x70
> [8.831211] warn_slowpath_fmt+0x36/0x40
> [8.832054] sysfs_warn_dup+0x58/0x70
> [8.832865] sysfs_do_create_link_sd+0x9e/0xb0
> [8.833844] sysfs_create_link+0x20/0x40
> [8.834714] device_add+0x218/0x610
> [8.835511] ? kvasprintf_const+0x49/0x60
> [8.836352] ? kobject_set_name_vargs+0x62/0x80
> [8.837253] sd_probe+0x31a/0x390
> [8.838027] ? _raw_spin_unlock+0x1d/0x30
> [8.838884] driver_probe_device+0x190/0x4a0
> [8.839751] __device_attach_driver+0x6f/0x100
> [8.840736] ? klist_next+0x6e/0x100
> [8.841538] ? __driver_attach+0xf0/0xf0
> [8.842383] bus_for_each_drv+0x47/0x80
> [8.843226] __device_attach+0xa8/0x120
> [8.844062] ? __driver_attach+0xf0/0xf0
> [8.844902] device_initial_probe+0xd/0x10
> [8.845754] bus_probe_device+0x77/0x80
> [8.846593] device_add+0x320/0x610
> [8.847387] scsi_sysfs_add_sdev+0x85/0x2b0
> [8.848246] ? scsi_attach_vpd+0x1f9/0x210
> [8.849103] scsi_probe_and_add_lun+0xd44/0xe70
> [8.850021] __scsi_scan_target+0xd8/0x690
> [8.850918] ? __pm_runtime_resume+0x37/0x80
> [8.852124] scsi_scan_channel+0x8f/0xb0
> [8.852977] scsi_scan_host_selected+0x100/0x180
> [8.853885] do_scsi_scan_host+0x8a/0x90
> [8.854733] scsi_scan_host+0x15a/0x1a0
> [8.855562] sdebug_driver_probe+0x14f/0x3d0
> [8.856435] ? _raw_spin_unlock+0x1d/0x30
> [8.857270] ? devices_kset_move_last+0x71/0xc0
> [8.858170] ? sysfs_create_link+0x20/0x40
> [8.859057] driver_probe_device+0xd4/0x4a0
> [8.859924] __device_attach_driver+0x6f/0x100
> [8.860814] ? klist_next+0x6e/0x100
> [8.861619] ? __driver_attach+0xf0/0xf0
> [8.862470] bus_for_each_drv+0x47/0x80
> [8.863298] __device_attach+0xa8/0x120
> [8.864131] ? __driver_attach+0xf0/0xf0
> [8.864975] device_initial_probe+0xd/0x10
> [8.865831] bus_probe_device+0x77/0x80
> [8.866704] device_add+0x320/0x610
> [8.867497] ? pm_runtime_init+0xea/0xf0
> [8.868326] device_register+0x12/0x20
> [8.869146] sdebug_add_adapter+0xda/0x1e0
> [8.870002] ? driver_register+0x83/0xe0
> [8.870847] scsi_debug_init+0x5a0/0x6eb
> [8.871686] ? kobject_uevent+0xa/0x10
> [8.872507] ? driver_register+0x83/0xe0
> [8.873336] ? scsi_register_driver+0xf/0x20
> [8.874218] ? init_ch_module+0x9d/0x9d
> [8.875088] do_one_initcall+0x7b/0x132
> [8.875918] ? kernel_init_freeable+0xe7/0x188
> [8.876807] kernel_init_freeable+0x10a/0x188
> [8.877690] ? rest_init+0xb0/0xb0
> [8.878482] kernel_init+0xb/0x100
> [8.879262] ? schedule_tail+0xc/0x70
> [8.880076] ? rest_init+0xb0/0xb0
> [8.880861] ret_from_fork+0x21/0x2c
> [8.881688] ---[ end trace 62a20110376b9cdf ]---
>
>
> To reproduce:
>
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k job-script # job-script is attached in
> this email
These reproduction steps don't work for me. I also notice that 0day
is picking up on a later error, the real error is that we register to
scsi devices with the same name:
Re: [PATCH] gpio: aspeed: Remove dependence on GPIOF_* macros
On Thu, Feb 2, 2017 at 5:28 AM, Andrew Jeffery wrote:
> 1736f75d35e47409ad776273133d0f558a4c8253 is a (v2) patch which had
> unresolved review comments[1]. Address the comments by removing the use
> of macros from the consumer header (this patch represents the diff
> between v2 and v3[2]).
>
> [1] https://lkml.org/lkml/2017/1/26/337
> [2] https://lkml.org/lkml/2017/1/26/786
>
> Fixes: 1736f75d35e4 ("gpio: aspeed: Add banks Y, Z, AA, AB and AC")
> Signed-off-by: Andrew Jeffery
Patch applied with Joel's ACK.
Thank you for just tirelessly fixing my mistakes, I owe you one.
Yours,
Linus Walleij
Re: [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge
Hi Rob,
On Sat, Feb 4, 2017 at 1:36 AM, Rob Herring wrote:
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_out.c
> b/drivers/gpu/drm/mxsfb/mxsfb_out.c
> index fa8d17399407..f7d729aa09bd 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_out.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_out.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -82,20 +83,15 @@ static const struct drm_connector_funcs
> mxsfb_panel_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static int mxsfb_attach_endpoint(struct drm_device *drm,
> -const struct of_endpoint *ep)
> +int mxsfb_create_output(struct drm_device *drm)
> {
> struct mxsfb_drm_private *mxsfb = drm->dev_private;
> - struct device_node *np;
> struct drm_panel *panel;
> - int ret = -EPROBE_DEFER;
> -
> - np = of_graph_get_remote_port_parent(ep->local_node);
> - panel = of_drm_find_panel(np);
> - of_node_put(np);
> + int ret;
>
> - if (!panel)
> - return -EPROBE_DEFER;
> + ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, &panel,
> NULL);
> + if (ret)
> + return ret;
I fixed some build issues of this series and I am trying to use it
with the mxsfb drm driver.
I would like to add bridge support for this driver, so that I can use
the TDA19988 HDMI bridge on a imx6sx-udoo-neo-full board.
My dts looks like this:
--- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
@@ -185,6 +185,41 @@
};
};
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ clock-frequency = <10>;
+ status = "okay";
+
+ hdmi-transmitter@70 {
+ compatible = "nxp,tda998x";
+ reg = <0x70>;
+ pinctrl-0 = <&pinctrl_hdmi>;
+ pinctrl-names = "default";
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&clks IMX6SX_CLK_CKO2>;
+
+ port {
+ tda998x_input: endpoint {
+ remote-endpoint = <&lcdif1_output>;
+ };
+ };
+ };
+};
+
+&lcdif1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd>;
+ status = "okay";
+
+ port {
+ lcdif1_output: endpoint {
+ remote-endpoint = <&tda998x_input>;
+ };
+ };
+};
and I changed it to:
ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, &panel, &bridge);
,but drm_of_find_panel_or_bridge() always returns -EPROBE_DEFER.
Shouldn't it be able to find the bridge chip in this case? Any ideas
of what it is missing?
Thanks
Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)
On Fri, 2017-02-03 at 18:36 -0600, Trevor Cordes wrote: > On 2017-02-01 Michal Hocko wrote: > > On Wed 01-02-17 03:29:28, Trevor Cordes wrote: > > > On 2017-01-30 Michal Hocko wrote: > > > > [...] > > > > Testing with Valinall rc6 released just yesterday would be a > > > > good > > > > fit. There are some more fixes sitting on mmotm on top and > > > > maybe > > > > we want some of them in finall 4.10. Anyway all those pending > > > > changes should be merged in the next merge window - aka 4.11 > > > > > > After 30 hours of running vanilla 4.10.0-rc6, the box started to > > > go > > > bonkers at 3am, so vanilla does not fix the bug :-( But, the bug > > > hit differently this time, the box just bogged down like crazy > > > and > > > gave really weird top output. Starting nano would take 10s, then > > > would run full speed, then when saving a file would take 5s. > > > Starting any prog not in cache took equally as long. > > > > Could you try with to_test/linus-tree/oom_hickups branch on the > > same > > git tree? I have cherry-picked "mm, vmscan: consider eligible zones > > in > > get_scan_count" which might be the missing part. > > I ran to_test/linus-tree/oom_hickups branch (4.10.0-rc6+) for 50 > hours > and it does NOT have the bug! No problems at all so far. > > So I think whatever to_test/linus-tree/oom_hickups has that since-4.9 > has that vanilla 4.10-rc6 does *not* have is indeed the fix. > > For my reference, and I know you guys aren't distro-specific, what is > the best way to get this fix into Fedora 24 (currently 4.9)? Can it > be > backported or made as a patch they can apply to 4.9? Or 4.10? The best way would be to open a Fedora bug, and CC me on it :) -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
Regression on next-20170203 spi/for-next 3f87493930a0f qemu on x86_64
I could not boot next-20170203 on my x86_64 qemu instance. It stalls at: [0.015549] CPU: Physical Processor ID: 0 [0.015842] mce: CPU supports 10 MCE banks [0.016032] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0 [0.016393] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 [0.016871] Freeing SMP alternatives memory: 24K [0.017710] ftrace: allocating 25888 entries in 102 pages [0.024102] smpboot: Max logical packages: 4 [0.024524] x2apic enabled [0.024851] Switched APIC routing to physical x2apic. [0.025755] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 This is no different than a functional boot, it just stalls. I see it next-20170203 booted and worked on other qemu instances elsewhere though so it seems something with my configuration and boot. I bisected next-20170203 between its latest commit and v4.10-rc6 and ended up with this bad commit: 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 $ git show 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 commit 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 Merge: 7c3b1edeee66 3f87493930a0 Author: Stephen Rothwell Date: Fri Feb 3 12:30:38 2017 +1100 Merge remote-tracking branch 'spi/for-next' I have checked Next/SHA1s and it shows: mcgrof@piggy ~/linux-next (git::original)$ grep spi Next/SHA1s spi-nordc12bcccadafb5441170e6b7c8a438c91d4f385b spi3f87493930a0f934549b04e100ecc2110e4f1efd hwspinlockbd5717a4632cdecafe82d03de7dcb3b1876e2828 The commit 3f87493930a0f934549b04e100ecc2110e4f1efd then seems to be what I need to test. I have cloned Mark's spi tree and just tried to boot the for-next branch (on v4.10-rc1) on 3f87493930a0f934549b04e100ecc2110e4f1efd, and it boots successfully. This would lead me to believe this issue might be related to the merge conflict resolution done by Stephen, but wanted to check and ask. Perhaps there might be some specific tests I can run. The qemu instance I am using: /usr/local/bin/qemu-system-x86_64 -cpu kvm64 -enable-kvm -m 4096 -smp 4 -netdev vde,sock=/var/run/qemu-vde.ctl,group=kvm,mode=0660,id=vde0 -device e1000,netdev=vde0,mac=52:54:00:12:34:84 -hda /opt/qemu/debian-x86_64.qcow2 -hdb /opt/qemu/linux-next.qcow2 -monitor pty -serial stdio -chardev pty,id=ttyS1 -device isa-serial,chardev=ttyS1 -chardev pty,id=ttyS2 -device isa-serial,chardev=ttyS2 -nographic -boot order=d Luis
Re: [PATCH v2 4/5] iio: trigger: add support for STM32 EXTI triggers
On Sat, Feb 4, 2017 at 12:39 PM, Jonathan Cameron wrote:
> On 03/02/17 19:40, Linus Walleij wrote:
>>> + if (ret) {
>>> + dev_err(&pdev->dev, "request IRQ %d failed\n", irq);
>>> + return ret;
>>> + }
>>
>> Here you need some elaborate trigger edge handling.
>>
>> The flags that you define as "0" here, how do we say that we
>> want to handle rising or falling edges, for example?
>>
>> I think you might want to establish these DT properties for
>> GPIO triggers:
>>
>> gpio-trigger-rising-edge;
>> gpio-trigger-falling-edge;
>>
>> Then:
>>
>> int irq_flags = 0;
>>
>> if (of_property_read_bool(np, "gpio-trigger-rising-edge")
>>irq_flags |= IRQF_TRIGGER_RISING;
>> else if (of_property_read_bool(np, "gpio-trigger-falling-edge")
>>irq_flags |= IRQF_TRIGGER_FALLING;
>
> Should this not all be part of the interrupt specification rather
> than down here in the specific driver?
I might be thinking a bit too generic here actually.
I was thinking we need to support something that has
gpio-controller; so a consumer can get a GPIO line reference
but would not also be an interrupt-controller; so it can't
serve interrupts through the device tree bindings but
may still do so from the driver using gpiolibs .to_irq().
So the specifier would need to come in someplace else.
But I think that is maybe not at all realistic.
If there is an interrupt trigger, that can be used with
a gpio-controller that is also an interrupt-controller,
that should be fine, and then we can use the standard
DT bindings to specify the interrupt type.
Yours,
Linus Walleij
