* [PATCH 2/3] aspeed/pinctrl: Fix simultaneous RS-232 / PWM and DVO outputs on AST2500 devices
From: Ryan Chen @ 2019-05-02 3:06 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <f35bf045-48e4-432f-8239-29f8f6746158@www.fastmail.com>
>On Thu, 2 May 2019, at 08:20, Timothy Pearson wrote:
> There appears to be a small error in the pinmux table on pages 130 and
> 131 of the AST2500 datasheet v1.6. Specifically, the COND2
> requirement used to mux the surrounding pins to DVI was inadvertently
> replicated to pins V1, W1, V2, and W2 in the table, which do not
> incorporate DVI functionality.
>
> As a result of this error, both serial TX lines and the PWM 0/1
> outputs were overriding the VPO pinmux settings when VPO was enabled
> in the pinmux hogs.
>
> This patch has been verified to function on Blackbird hardware. Both
> serial TXD pins and PWM0/PWM1 were functionally tested with SCU94[1:0]
> set to 0x1.
Hello Tim.
The AST2500 pwm0/1 configure need following condition, the SCU94[1:0] is 0x1, it should not work.
Could you help confirm it?
v2 : pwm 0 : scu88[0] = 1 & scu 94[1:0] = 0 & scu90[5] = 0
w2 : pwm 1 : scu88[1] = 1 & scu 94[1:0] = 0 & scu90[5] = 0
> Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
> ---
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> index 187abd7693cf..6f357a11e89a 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> @@ -696,14 +696,14 @@ FUNC_GROUP_DECL(NRTS1, P3); #define V1 94
> #define V1_DESC SIG_DESC_SET(SCU84, 22)
> SIG_EXPR_LIST_DECL_SINGLE(DASHV1, DASHV1, VPIRSVD_DESC, V1_DESC);
> -SIG_EXPR_LIST_DECL_SINGLE(TXD1, TXD1, V1_DESC, COND2);
> +SIG_EXPR_LIST_DECL_SINGLE(TXD1, TXD1, V1_DESC);
> MS_PIN_DECL(V1, GPIOL6, DASHV1, TXD1); FUNC_GROUP_DECL(TXD1, V1);
>
> #define W1 95
> #define W1_DESC SIG_DESC_SET(SCU84, 23)
> SIG_EXPR_LIST_DECL_SINGLE(DASHW1, DASHW1, VPIRSVD_DESC, W1_DESC);
> -SIG_EXPR_LIST_DECL_SINGLE(RXD1, RXD1, W1_DESC, COND2);
> +SIG_EXPR_LIST_DECL_SINGLE(RXD1, RXD1, W1_DESC);
> MS_PIN_DECL(W1, GPIOL7, DASHW1, RXD1); FUNC_GROUP_DECL(RXD1, W1);
>
> @@ -766,14 +766,14 @@ FUNC_GROUP_DECL(RXD2, T5); #define V2 104
> #define V2_DESC SIG_DESC_SET(SCU88, 0)
> SIG_EXPR_LIST_DECL_SINGLE(DASHN0, DASHN0, VPIRSVD_DESC, V2_DESC);
> -SIG_EXPR_LIST_DECL_SINGLE(PWM0, PWM0, V2_DESC, COND2);
> +SIG_EXPR_LIST_DECL_SINGLE(PWM0, PWM0, V2_DESC);
> MS_PIN_DECL(V2, GPION0, DASHN0, PWM0); FUNC_GROUP_DECL(PWM0, V2);
>
> #define W2 105
> #define W2_DESC SIG_DESC_SET(SCU88, 1)
> SIG_EXPR_LIST_DECL_SINGLE(DASHN1, DASHN1, VPIRSVD_DESC, W2_DESC);
> -SIG_EXPR_LIST_DECL_SINGLE(PWM1, PWM1, W2_DESC, COND2);
> +SIG_EXPR_LIST_DECL_SINGLE(PWM1, PWM1, W2_DESC);
> MS_PIN_DECL(W2, GPION1, DASHN1, PWM1); FUNC_GROUP_DECL(PWM1, W2);
>>This looks reasonable to me. I'd like Ryan to chime in though.
>>Ryan, can you confirm the datasheet needs correction here?
>>Tim: You need to send these to a broader audience than the linux-aspeed@ list. Please use ./scripts/get_maintainer.pl to >>determine the appropriate people to send to. This at least needs to go to Linus Walleij, who maintains pinctrl.
>
> --
> 2.11.0
>
>
^ permalink raw reply
* Re: [PATCH 2/3] aspeed/pinctrl: Fix simultaneous RS-232 / PWM and DVO outputs on AST2500 devices
From: Andrew Jeffery @ 2019-05-02 2:05 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <1890791123.3393899.1556750986902.JavaMail.zimbra@raptorengineeringinc.com>
On Thu, 2 May 2019, at 08:20, Timothy Pearson wrote:
> There appears to be a small error in the pinmux table on pages 130 and
> 131 of the AST2500 datasheet v1.6. Specifically, the COND2 requirement
> used to mux the surrounding pins to DVI was inadvertently replicated to
> pins V1, W1, V2, and W2 in the table, which do not incorporate DVI
> functionality.
>
> As a result of this error, both serial TX lines and the PWM 0/1 outputs
> were overriding the VPO pinmux settings when VPO was enabled in the
> pinmux hogs.
>
> This patch has been verified to function on Blackbird hardware. Both
> serial TXD pins and PWM0/PWM1 were functionally tested with SCU94[1:0]
> set to 0x1.
>
> Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
> ---
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> index 187abd7693cf..6f357a11e89a 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> @@ -696,14 +696,14 @@ FUNC_GROUP_DECL(NRTS1, P3);
> #define V1 94
> #define V1_DESC SIG_DESC_SET(SCU84, 22)
> SIG_EXPR_LIST_DECL_SINGLE(DASHV1, DASHV1, VPIRSVD_DESC, V1_DESC);
> -SIG_EXPR_LIST_DECL_SINGLE(TXD1, TXD1, V1_DESC, COND2);
> +SIG_EXPR_LIST_DECL_SINGLE(TXD1, TXD1, V1_DESC);
> MS_PIN_DECL(V1, GPIOL6, DASHV1, TXD1);
> FUNC_GROUP_DECL(TXD1, V1);
>
> #define W1 95
> #define W1_DESC SIG_DESC_SET(SCU84, 23)
> SIG_EXPR_LIST_DECL_SINGLE(DASHW1, DASHW1, VPIRSVD_DESC, W1_DESC);
> -SIG_EXPR_LIST_DECL_SINGLE(RXD1, RXD1, W1_DESC, COND2);
> +SIG_EXPR_LIST_DECL_SINGLE(RXD1, RXD1, W1_DESC);
> MS_PIN_DECL(W1, GPIOL7, DASHW1, RXD1);
> FUNC_GROUP_DECL(RXD1, W1);
>
> @@ -766,14 +766,14 @@ FUNC_GROUP_DECL(RXD2, T5);
> #define V2 104
> #define V2_DESC SIG_DESC_SET(SCU88, 0)
> SIG_EXPR_LIST_DECL_SINGLE(DASHN0, DASHN0, VPIRSVD_DESC, V2_DESC);
> -SIG_EXPR_LIST_DECL_SINGLE(PWM0, PWM0, V2_DESC, COND2);
> +SIG_EXPR_LIST_DECL_SINGLE(PWM0, PWM0, V2_DESC);
> MS_PIN_DECL(V2, GPION0, DASHN0, PWM0);
> FUNC_GROUP_DECL(PWM0, V2);
>
> #define W2 105
> #define W2_DESC SIG_DESC_SET(SCU88, 1)
> SIG_EXPR_LIST_DECL_SINGLE(DASHN1, DASHN1, VPIRSVD_DESC, W2_DESC);
> -SIG_EXPR_LIST_DECL_SINGLE(PWM1, PWM1, W2_DESC, COND2);
> +SIG_EXPR_LIST_DECL_SINGLE(PWM1, PWM1, W2_DESC);
> MS_PIN_DECL(W2, GPION1, DASHN1, PWM1);
> FUNC_GROUP_DECL(PWM1, W2);
This looks reasonable to me. I'd like Ryan to chime in though.
Ryan, can you confirm the datasheet needs correction here?
Tim: You need to send these to a broader audience than the linux-aspeed@
list. Please use ./scripts/get_maintainer.pl to determine the appropriate
people to send to. This at least needs to go to Linus Walleij, who maintains
pinctrl.
Andrew
>
> --
> 2.11.0
>
>
^ permalink raw reply
* Re: [PATCH 1/3] drm/aspeed: Preserve DVO configuration bits during initialization
From: Andrew Jeffery @ 2019-05-02 1:57 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <1681003008.3393892.1556750962226.JavaMail.zimbra@raptorengineeringinc.com>
On Thu, 2 May 2019, at 08:19, Timothy Pearson wrote:
> GFX064 contains DVO enable and mode bits. These are hardware specific,
> configured
> via the pinmux from the DT, and should not be cleared during startup.
>
> Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
> ---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> index 713a3975852b..1a7a9a000e2e 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> @@ -98,6 +98,7 @@ static int aspeed_gfx_load(struct drm_device *drm)
> struct aspeed_gfx *priv;
> struct resource *res;
> int ret;
> + u32 reg;
>
> priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> @@ -146,7 +147,9 @@ static int aspeed_gfx_load(struct drm_device *drm)
>
> /* Sanitize control registers */
> writel(0, priv->base + CRT_CTRL1);
> - writel(0, priv->base + CRT_CTRL2);
> + /* Preserve CRT_CTRL2[7:6] (DVO configuration) */
> + reg = readl(priv->base + CRT_CTRL2) & 0xc0;
I'd prefer we go the route of adding #defines for each bit, then OR'ing them
to create an appropriate mask. This seems a little opaque, even if we have
the comment.
> + writel(reg, priv->base + CRT_CTRL2);
>
> aspeed_gfx_setup_mode_config(drm);
>
> --
> 2.11.0
>
>
^ permalink raw reply
* [PATCH 3/3] aspeed/pinctrl: Fix simultaneous DVO and serial outputs on AST2500 devices
From: Timothy Pearson @ 2019-05-01 22:50 UTC (permalink / raw)
To: linux-aspeed
There appears to be a significant error in the pinmux table starting on
page 127 of the AST2500 datasheet v1.6. Specifically, the COND2 (DVO)
requirement is incorrectly applied to multiple digital video input (DVI)
muxed pins, and no DVI-specific condition is provided. This results in
the serial devices incorrectly overriding the DVO pinmuxes and disabling
the DVO pins.
Create a new condition code (COND6) for DVI enable, and update the most
seriously affected pins to use the new condition code.
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 6f357a11e89a..676f90d3c5f3 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -29,6 +29,7 @@
#define COND1 { ASPEED_IP_SCU, SCU90, BIT(6), 0, 0 }
#define COND2 { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
+#define COND6 { ASPEED_IP_SCU, SCU90, GENMASK(5, 4), 0, 0 }
/* LHCR0 is offset from the end of the H8S/2168-compatible registers */
#define LHCR0 0x20
@@ -660,8 +661,8 @@ SSSF_PIN_DECL(T2, GPIOL0, NCTS1, SIG_DESC_SET(SCU84, 16));
#define T1 89
#define T1_DESC SIG_DESC_SET(SCU84, 17)
-SIG_EXPR_LIST_DECL_SINGLE(VPIDE, VPI24, VPI_24_RSVD_DESC, T1_DESC, COND2);
-SIG_EXPR_LIST_DECL_SINGLE(NDCD1, NDCD1, T1_DESC, COND2);
+SIG_EXPR_LIST_DECL_SINGLE(VPIDE, VPI24, VPI_24_RSVD_DESC, T1_DESC, COND6);
+SIG_EXPR_LIST_DECL_SINGLE(NDCD1, NDCD1, T1_DESC, COND6);
MS_PIN_DECL(T1, GPIOL1, VPIDE, NDCD1);
FUNC_GROUP_DECL(NDCD1, T1);
@@ -674,22 +675,22 @@ FUNC_GROUP_DECL(NDSR1, U1);
#define U2 91
#define U2_DESC SIG_DESC_SET(SCU84, 19)
-SIG_EXPR_LIST_DECL_SINGLE(VPIHS, VPI24, VPI_24_RSVD_DESC, U2_DESC, COND2);
-SIG_EXPR_LIST_DECL_SINGLE(NRI1, NRI1, U2_DESC, COND2);
+SIG_EXPR_LIST_DECL_SINGLE(VPIHS, VPI24, VPI_24_RSVD_DESC, U2_DESC, COND6);
+SIG_EXPR_LIST_DECL_SINGLE(NRI1, NRI1, U2_DESC, COND6);
MS_PIN_DECL(U2, GPIOL3, VPIHS, NRI1);
FUNC_GROUP_DECL(NRI1, U2);
#define P4 92
#define P4_DESC SIG_DESC_SET(SCU84, 20)
-SIG_EXPR_LIST_DECL_SINGLE(VPIVS, VPI24, VPI_24_RSVD_DESC, P4_DESC, COND2);
-SIG_EXPR_LIST_DECL_SINGLE(NDTR1, NDTR1, P4_DESC, COND2);
+SIG_EXPR_LIST_DECL_SINGLE(VPIVS, VPI24, VPI_24_RSVD_DESC, P4_DESC, COND6);
+SIG_EXPR_LIST_DECL_SINGLE(NDTR1, NDTR1, P4_DESC, COND6);
MS_PIN_DECL(P4, GPIOL4, VPIVS, NDTR1);
FUNC_GROUP_DECL(NDTR1, P4);
#define P3 93
#define P3_DESC SIG_DESC_SET(SCU84, 21)
-SIG_EXPR_LIST_DECL_SINGLE(VPICLK, VPI24, VPI_24_RSVD_DESC, P3_DESC, COND2);
-SIG_EXPR_LIST_DECL_SINGLE(NRTS1, NRTS1, P3_DESC, COND2);
+SIG_EXPR_LIST_DECL_SINGLE(VPICLK, VPI24, VPI_24_RSVD_DESC, P3_DESC, COND6);
+SIG_EXPR_LIST_DECL_SINGLE(NRTS1, NRTS1, P3_DESC, COND6);
MS_PIN_DECL(P3, GPIOL5, VPICLK, NRTS1);
FUNC_GROUP_DECL(NRTS1, P3);
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] aspeed/pinctrl: Fix simultaneous RS-232 / PWM and DVO outputs on AST2500 devices
From: Timothy Pearson @ 2019-05-01 22:49 UTC (permalink / raw)
To: linux-aspeed
There appears to be a small error in the pinmux table on pages 130 and
131 of the AST2500 datasheet v1.6. Specifically, the COND2 requirement
used to mux the surrounding pins to DVI was inadvertently replicated to
pins V1, W1, V2, and W2 in the table, which do not incorporate DVI
functionality.
As a result of this error, both serial TX lines and the PWM 0/1 outputs
were overriding the VPO pinmux settings when VPO was enabled in the
pinmux hogs.
This patch has been verified to function on Blackbird hardware. Both
serial TXD pins and PWM0/PWM1 were functionally tested with SCU94[1:0]
set to 0x1.
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 187abd7693cf..6f357a11e89a 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -696,14 +696,14 @@ FUNC_GROUP_DECL(NRTS1, P3);
#define V1 94
#define V1_DESC SIG_DESC_SET(SCU84, 22)
SIG_EXPR_LIST_DECL_SINGLE(DASHV1, DASHV1, VPIRSVD_DESC, V1_DESC);
-SIG_EXPR_LIST_DECL_SINGLE(TXD1, TXD1, V1_DESC, COND2);
+SIG_EXPR_LIST_DECL_SINGLE(TXD1, TXD1, V1_DESC);
MS_PIN_DECL(V1, GPIOL6, DASHV1, TXD1);
FUNC_GROUP_DECL(TXD1, V1);
#define W1 95
#define W1_DESC SIG_DESC_SET(SCU84, 23)
SIG_EXPR_LIST_DECL_SINGLE(DASHW1, DASHW1, VPIRSVD_DESC, W1_DESC);
-SIG_EXPR_LIST_DECL_SINGLE(RXD1, RXD1, W1_DESC, COND2);
+SIG_EXPR_LIST_DECL_SINGLE(RXD1, RXD1, W1_DESC);
MS_PIN_DECL(W1, GPIOL7, DASHW1, RXD1);
FUNC_GROUP_DECL(RXD1, W1);
@@ -766,14 +766,14 @@ FUNC_GROUP_DECL(RXD2, T5);
#define V2 104
#define V2_DESC SIG_DESC_SET(SCU88, 0)
SIG_EXPR_LIST_DECL_SINGLE(DASHN0, DASHN0, VPIRSVD_DESC, V2_DESC);
-SIG_EXPR_LIST_DECL_SINGLE(PWM0, PWM0, V2_DESC, COND2);
+SIG_EXPR_LIST_DECL_SINGLE(PWM0, PWM0, V2_DESC);
MS_PIN_DECL(V2, GPION0, DASHN0, PWM0);
FUNC_GROUP_DECL(PWM0, V2);
#define W2 105
#define W2_DESC SIG_DESC_SET(SCU88, 1)
SIG_EXPR_LIST_DECL_SINGLE(DASHN1, DASHN1, VPIRSVD_DESC, W2_DESC);
-SIG_EXPR_LIST_DECL_SINGLE(PWM1, PWM1, W2_DESC, COND2);
+SIG_EXPR_LIST_DECL_SINGLE(PWM1, PWM1, W2_DESC);
MS_PIN_DECL(W2, GPION1, DASHN1, PWM1);
FUNC_GROUP_DECL(PWM1, W2);
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] drm/aspeed: Preserve DVO configuration bits during initialization
From: Timothy Pearson @ 2019-05-01 22:49 UTC (permalink / raw)
To: linux-aspeed
GFX064 contains DVO enable and mode bits. These are hardware specific, configured
via the pinmux from the DT, and should not be cleared during startup.
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index 713a3975852b..1a7a9a000e2e 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -98,6 +98,7 @@ static int aspeed_gfx_load(struct drm_device *drm)
struct aspeed_gfx *priv;
struct resource *res;
int ret;
+ u32 reg;
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -146,7 +147,9 @@ static int aspeed_gfx_load(struct drm_device *drm)
/* Sanitize control registers */
writel(0, priv->base + CRT_CTRL1);
- writel(0, priv->base + CRT_CTRL2);
+ /* Preserve CRT_CTRL2[7:6] (DVO configuration) */
+ reg = readl(priv->base + CRT_CTRL2) & 0xc0;
+ writel(reg, priv->base + CRT_CTRL2);
aspeed_gfx_setup_mode_config(drm);
--
2.11.0
^ permalink raw reply related
* [PATCH] misc: aspeed-lpc-ctrl: Correct return values
From: Vijay Khemka @ 2019-05-01 22:38 UTC (permalink / raw)
To: linux-aspeed
Corrected some of return values with appropriate meanings.
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
drivers/misc/aspeed-lpc-ctrl.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-ctrl.c
index 332210e06e98..97ae341109d5 100644
--- a/drivers/misc/aspeed-lpc-ctrl.c
+++ b/drivers/misc/aspeed-lpc-ctrl.c
@@ -68,7 +68,6 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file, unsigned int cmd,
unsigned long param)
{
struct aspeed_lpc_ctrl *lpc_ctrl = file_aspeed_lpc_ctrl(file);
- struct device *dev = file->private_data;
void __user *p = (void __user *)param;
struct aspeed_lpc_ctrl_mapping map;
u32 addr;
@@ -93,8 +92,8 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file, unsigned int cmd,
/* If memory-region is not described in device tree */
if (!lpc_ctrl->mem_size) {
- dev_err(dev, "Didn't find reserved memory\n");
- return -EINVAL;
+ pr_err("aspeed_lpc_ctrl: ioctl: Didn't find reserved memory\n");
+ return -ENXIO;
}
map.size = lpc_ctrl->mem_size;
@@ -134,16 +133,16 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file, unsigned int cmd,
if (map.window_type == ASPEED_LPC_CTRL_WINDOW_FLASH) {
if (!lpc_ctrl->pnor_size) {
- dev_err(dev, "Didn't find host pnor flash\n");
- return -EINVAL;
+ pr_err("aspeed_lpc_ctrl: ioctl: Didn't find host pnor flash\n");
+ return -ENXIO;
}
addr = lpc_ctrl->pnor_base;
size = lpc_ctrl->pnor_size;
} else if (map.window_type == ASPEED_LPC_CTRL_WINDOW_MEMORY) {
/* If memory-region is not described in device tree */
if (!lpc_ctrl->mem_size) {
- dev_err(dev, "Didn't find reserved memory\n");
- return -EINVAL;
+ pr_err("aspeed_lpc_ctrl: ioctl: Didn't find reserved memory\n");
+ return -ENXIO;
}
addr = lpc_ctrl->mem_base;
size = lpc_ctrl->mem_size;
@@ -239,7 +238,7 @@ static int aspeed_lpc_ctrl_probe(struct platform_device *pdev)
of_node_put(node);
if (rc) {
dev_err(dev, "Couldn't address to resource for reserved memory\n");
- return -ENOMEM;
+ return -ENXIO;
}
lpc_ctrl->mem_size = resource_size(&resm);
--
2.17.1
^ permalink raw reply related
* [PATCH] misc: aspeed-lpc-ctrl: make parameter optional
From: Vijay Khemka @ 2019-05-01 22:34 UTC (permalink / raw)
To: linux-aspeed
Makiing memory-region and flash as optional parameter in device
tree if user needs to use these parameter through ioctl then
need to define in devicetree.
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
drivers/misc/aspeed-lpc-ctrl.c | 58 +++++++++++++++++++++-------------
1 file changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-ctrl.c
index a024f8042259..332210e06e98 100644
--- a/drivers/misc/aspeed-lpc-ctrl.c
+++ b/drivers/misc/aspeed-lpc-ctrl.c
@@ -68,6 +68,7 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file, unsigned int cmd,
unsigned long param)
{
struct aspeed_lpc_ctrl *lpc_ctrl = file_aspeed_lpc_ctrl(file);
+ struct device *dev = file->private_data;
void __user *p = (void __user *)param;
struct aspeed_lpc_ctrl_mapping map;
u32 addr;
@@ -90,6 +91,12 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file, unsigned int cmd,
if (map.window_id != 0)
return -EINVAL;
+ /* If memory-region is not described in device tree */
+ if (!lpc_ctrl->mem_size) {
+ dev_err(dev, "Didn't find reserved memory\n");
+ return -EINVAL;
+ }
+
map.size = lpc_ctrl->mem_size;
return copy_to_user(p, &map, sizeof(map)) ? -EFAULT : 0;
@@ -126,9 +133,18 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file, unsigned int cmd,
return -EINVAL;
if (map.window_type == ASPEED_LPC_CTRL_WINDOW_FLASH) {
+ if (!lpc_ctrl->pnor_size) {
+ dev_err(dev, "Didn't find host pnor flash\n");
+ return -EINVAL;
+ }
addr = lpc_ctrl->pnor_base;
size = lpc_ctrl->pnor_size;
} else if (map.window_type == ASPEED_LPC_CTRL_WINDOW_MEMORY) {
+ /* If memory-region is not described in device tree */
+ if (!lpc_ctrl->mem_size) {
+ dev_err(dev, "Didn't find reserved memory\n");
+ return -EINVAL;
+ }
addr = lpc_ctrl->mem_base;
size = lpc_ctrl->mem_size;
} else {
@@ -196,17 +212,17 @@ static int aspeed_lpc_ctrl_probe(struct platform_device *pdev)
if (!lpc_ctrl)
return -ENOMEM;
+ /* If flash is described in device tree then store */
node = of_parse_phandle(dev->of_node, "flash", 0);
if (!node) {
- dev_err(dev, "Didn't find host pnor flash node\n");
- return -ENODEV;
- }
-
- rc = of_address_to_resource(node, 1, &resm);
- of_node_put(node);
- if (rc) {
- dev_err(dev, "Couldn't address to resource for flash\n");
- return rc;
+ dev_dbg(dev, "Didn't find host pnor flash node\n");
+ } else {
+ rc = of_address_to_resource(node, 1, &resm);
+ of_node_put(node);
+ if (rc) {
+ dev_err(dev, "Couldn't address to resource for flash\n");
+ return rc;
+ }
}
lpc_ctrl->pnor_size = resource_size(&resm);
@@ -214,22 +230,22 @@ static int aspeed_lpc_ctrl_probe(struct platform_device *pdev)
dev_set_drvdata(&pdev->dev, lpc_ctrl);
+ /* If memory-region is described in device tree then store */
node = of_parse_phandle(dev->of_node, "memory-region", 0);
if (!node) {
- dev_err(dev, "Didn't find reserved memory\n");
- return -EINVAL;
- }
+ dev_dbg(dev, "Didn't find reserved memory\n");
+ } else {
+ rc = of_address_to_resource(node, 0, &resm);
+ of_node_put(node);
+ if (rc) {
+ dev_err(dev, "Couldn't address to resource for reserved memory\n");
+ return -ENOMEM;
+ }
- rc = of_address_to_resource(node, 0, &resm);
- of_node_put(node);
- if (rc) {
- dev_err(dev, "Couldn't address to resource for reserved memory\n");
- return -ENOMEM;
+ lpc_ctrl->mem_size = resource_size(&resm);
+ lpc_ctrl->mem_base = resm.start;
}
- lpc_ctrl->mem_size = resource_size(&resm);
- lpc_ctrl->mem_base = resm.start;
-
lpc_ctrl->regmap = syscon_node_to_regmap(
pdev->dev.parent->of_node);
if (IS_ERR(lpc_ctrl->regmap)) {
@@ -258,8 +274,6 @@ static int aspeed_lpc_ctrl_probe(struct platform_device *pdev)
goto err;
}
- dev_info(dev, "Loaded at %pr\n", &resm);
-
return 0;
err:
--
2.17.1
^ permalink raw reply related
* [PATCH v2] misc: aspeed-lpc-ctrl: make parameter optional
From: Vijay Khemka @ 2019-05-01 22:22 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20190501064501.GA20816@kroah.com>
Let me send both patches.
?On 4/30/19, 11:45 PM, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org> wrote:
On Wed, May 01, 2019 at 05:55:07AM +0000, Joel Stanley wrote:
> On Fri, 18 Jan 2019 at 20:12, Vijay Khemka <vijaykhemka@fb.com> wrote:
> >
> > Hi Andrew,
> > Thanks for this review, I will have a follow up patch for this return values.
>
> Did you send a follow up patch to fix the return values?
>
> Greg, is there any reason why you did not merge this one? 5.2 will
> have device trees that depend on this patch's behavior.
No idea, if it needs to be applied, please resend.
thanks,
greg k-h
^ permalink raw reply
* [PATCH 1/6] thermal: Introduce devm_thermal_of_cooling_device_register
From: Guenter Roeck @ 2019-05-01 16:48 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <1555617500-10862-2-git-send-email-linux@roeck-us.net>
On Thu, Apr 18, 2019 at 12:58:15PM -0700, Guenter Roeck wrote:
> thermal_of_cooling_device_register() and thermal_cooling_device_register()
> are typically called from driver probe functions, and
> thermal_cooling_device_unregister() is called from remove functions. This
> makes both a perfect candidate for device managed functions.
>
> Introduce devm_thermal_of_cooling_device_register(). This function can
> also be used to replace thermal_cooling_device_register() by passing a NULL
> pointer as device node. The new function requires both struct device *
> and struct device_node * as parameters since the struct device_node *
> parameter is not always identical to dev->of_node.
>
> Don't introduce a device managed remove function since it is not needed
> at this point.
>
Any feedback / thoughts / comments ?
Thanks,
Guenter
^ permalink raw reply
* [PATCH v2] misc: aspeed-lpc-ctrl: make parameter optional
From: Greg Kroah-Hartman @ 2019-05-01 6:45 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <CACPK8Xdgv1YVgeykf0grSpR3LXTGa45hoBwZVq+zWgR0anhmTg@mail.gmail.com>
On Wed, May 01, 2019 at 05:55:07AM +0000, Joel Stanley wrote:
> On Fri, 18 Jan 2019 at 20:12, Vijay Khemka <vijaykhemka@fb.com> wrote:
> >
> > Hi Andrew,
> > Thanks for this review, I will have a follow up patch for this return values.
>
> Did you send a follow up patch to fix the return values?
>
> Greg, is there any reason why you did not merge this one? 5.2 will
> have device trees that depend on this patch's behavior.
No idea, if it needs to be applied, please resend.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2] misc: aspeed-lpc-ctrl: make parameter optional
From: Joel Stanley @ 2019-05-01 5:55 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <DCD8D2E5-DB18-427C-AA8F-18289E9AB0AB@fb.com>
On Fri, 18 Jan 2019 at 20:12, Vijay Khemka <vijaykhemka@fb.com> wrote:
>
> Hi Andrew,
> Thanks for this review, I will have a follow up patch for this return values.
Did you send a follow up patch to fix the return values?
Greg, is there any reason why you did not merge this one? 5.2 will
have device trees that depend on this patch's behavior.
Cheers,
Joel
> ?On 1/17/19, 8:58 PM, "Andrew Jeffery" <andrew@aj.id.au> wrote:
>
> Hi Vijay,
>
> Thanks for doing the work to fix the driver. Some minor queries/points
> below.
>
> On Thu, 17 Jan 2019, at 08:31, Vijay Khemka wrote:
> > Makiing memory-region and flash as optional parameter in device
> > tree if user needs to use these parameter through ioctl then
> > need to define in devicetree.
> >
> > Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
> > ---
> > drivers/misc/aspeed-lpc-ctrl.c | 58 +++++++++++++++++++++-------------
> > 1 file changed, 36 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-
> > ctrl.c
> > index a024f8042259..332210e06e98 100644
> > --- a/drivers/misc/aspeed-lpc-ctrl.c
> > +++ b/drivers/misc/aspeed-lpc-ctrl.c
> > @@ -68,6 +68,7 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file,
> > unsigned int cmd,
> > unsigned long param)
> > {
> > struct aspeed_lpc_ctrl *lpc_ctrl = file_aspeed_lpc_ctrl(file);
> > + struct device *dev = file->private_data;
> > void __user *p = (void __user *)param;
> > struct aspeed_lpc_ctrl_mapping map;
> > u32 addr;
> > @@ -90,6 +91,12 @@ static long aspeed_lpc_ctrl_ioctl(struct file *file,
> > unsigned int cmd,
> > if (map.window_id != 0)
> > return -EINVAL;
> >
> > + /* If memory-region is not described in device tree */
> > + if (!lpc_ctrl->mem_size) {
> > + dev_err(dev, "Didn't find reserved memory\n");
> > + return -EINVAL;
>
> I feel like EINVAL isn't quite right - it's pretty generic, and the parameter
> value changes its validity with the devicetree context. My gut instinct
> would be to use EINVAL for parameter values that violate assumptions
> of the driver rather than violate configuration of the driver. Maybe ENXIO
> ("No such device or address") is an improvement: "I can't map that device
> because there's no such device or address"?
>
> > + }
> > +
> > map.size = lpc_ctrl->mem_size;
> >
> > return copy_to_user(p, &map, sizeof(map)) ? -EFAULT : 0;
> > @@ -126,9 +133,18 @@ static long aspeed_lpc_ctrl_ioctl(struct file
> > *file, unsigned int cmd,
> > return -EINVAL;
> >
> > if (map.window_type == ASPEED_LPC_CTRL_WINDOW_FLASH) {
> > + if (!lpc_ctrl->pnor_size) {
> > + dev_err(dev, "Didn't find host pnor flash\n");
> > + return -EINVAL;
>
> See the error code discussion above. Also, this is userspace's error not
> the kernel's, so I think dev_err() is a bit harsh. Probably best to just let
> userspace log the error if it thinks the it is concerning.
>
> > + }
> > addr = lpc_ctrl->pnor_base;
> > size = lpc_ctrl->pnor_size;
> > } else if (map.window_type == ASPEED_LPC_CTRL_WINDOW_MEMORY) {
> > + /* If memory-region is not described in device tree */
> > + if (!lpc_ctrl->mem_size) {
> > + dev_err(dev, "Didn't find reserved memory\n");
> > + return -EINVAL;
>
> as above.
>
> > + }
> > addr = lpc_ctrl->mem_base;
> > size = lpc_ctrl->mem_size;
> > } else {
> > @@ -196,17 +212,17 @@ static int aspeed_lpc_ctrl_probe(struct
> > platform_device *pdev)
> > if (!lpc_ctrl)
> > return -ENOMEM;
> >
> > + /* If flash is described in device tree then store */
> > node = of_parse_phandle(dev->of_node, "flash", 0);
> > if (!node) {
> > - dev_err(dev, "Didn't find host pnor flash node\n");
> > - return -ENODEV;
> > - }
> > -
> > - rc = of_address_to_resource(node, 1, &resm);
> > - of_node_put(node);
> > - if (rc) {
> > - dev_err(dev, "Couldn't address to resource for flash\n");
> > - return rc;
> > + dev_dbg(dev, "Didn't find host pnor flash node\n");
> > + } else {
> > + rc = of_address_to_resource(node, 1, &resm);
> > + of_node_put(node);
> > + if (rc) {
> > + dev_err(dev, "Couldn't address to resource for flash\n");
> > + return rc;
> > + }
> > }
> >
> > lpc_ctrl->pnor_size = resource_size(&resm);
> > @@ -214,22 +230,22 @@ static int aspeed_lpc_ctrl_probe(struct
> > platform_device *pdev)
> >
> > dev_set_drvdata(&pdev->dev, lpc_ctrl);
> >
> > + /* If memory-region is described in device tree then store */
> > node = of_parse_phandle(dev->of_node, "memory-region", 0);
> > if (!node) {
> > - dev_err(dev, "Didn't find reserved memory\n");
> > - return -EINVAL;
> > - }
> > + dev_dbg(dev, "Didn't find reserved memory\n");
> > + } else {
> > + rc = of_address_to_resource(node, 0, &resm);
> > + of_node_put(node);
> > + if (rc) {
> > + dev_err(dev, "Couldn't address to resource for reserved memory\n");
> > + return -ENOMEM;
>
> Wow, I think this is an abuse of ENOMEM. Its description is "Out of memory"
> which doesn't really reflect the problem here.
>
> Not really your fault though, maybe we'll fix that with some follow-up patches.
>
> Cheers,
>
> Andrew
>
> > + }
> >
> > - rc = of_address_to_resource(node, 0, &resm);
> > - of_node_put(node);
> > - if (rc) {
> > - dev_err(dev, "Couldn't address to resource for reserved memory\n");
> > - return -ENOMEM;
> > + lpc_ctrl->mem_size = resource_size(&resm);
> > + lpc_ctrl->mem_base = resm.start;
> > }
> >
> > - lpc_ctrl->mem_size = resource_size(&resm);
> > - lpc_ctrl->mem_base = resm.start;
> > -
> > lpc_ctrl->regmap = syscon_node_to_regmap(
> > pdev->dev.parent->of_node);
> > if (IS_ERR(lpc_ctrl->regmap)) {
> > @@ -258,8 +274,6 @@ static int aspeed_lpc_ctrl_probe(struct
> > platform_device *pdev)
> > goto err;
> > }
> >
> > - dev_info(dev, "Loaded at %pr\n", &resm);
> > -
> > return 0;
> >
> > err:
> > --
> > 2.17.1
> >
>
>
^ permalink raw reply
* [PATCH dev-5.0 v3] ARM: dts: aspeed: Add Swift BMC machine
From: Adriana Kobylak @ 2019-04-29 21:08 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <5bbc8649-5a38-fe38-9a97-9c4ec582b511@linux.ibm.com>
From: Adriana Kobylak <anoo@us.ibm.com>
The Swift BMC is an ASPEED ast2500 based BMC that is part of
a Power9 server. This adds the device tree description for
most upstream components.
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/aspeed-bmc-opp-swift.dts | 828 +++++++++++++++++++++++++++++
2 files changed, 829 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-swift.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bd40148..b82a24d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1244,6 +1244,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-opp-lanyang.dtb \
aspeed-bmc-opp-palmetto.dtb \
aspeed-bmc-opp-romulus.dtb \
+ aspeed-bmc-opp-swift.dtb \
aspeed-bmc-opp-witherspoon.dtb \
aspeed-bmc-opp-zaius.dtb \
aspeed-bmc-portwell-neptune.dtb \
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-swift.dts b/arch/arm/boot/dts/aspeed-bmc-opp-swift.dts
new file mode 100644
index 0000000..8d44e3c
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-swift.dts
@@ -0,0 +1,828 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+#include "aspeed-g5.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/leds/leds-pca955x.h>
+
+/ {
+ model = "Swift BMC";
+ compatible = "ibm,swift-bmc", "aspeed,ast2500";
+
+ chosen {
+ stdout-path = &uart5;
+ bootargs = "console=ttyS4,115200 earlyprintk";
+ };
+
+ memory at 80000000 {
+ reg = <0x80000000 0x20000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ flash_memory: region at 98000000 {
+ no-map;
+ reg = <0x98000000 0x04000000>; /* 64M */
+ };
+
+ gfx_memory: framebuffer {
+ size = <0x01000000>;
+ alignment = <0x01000000>;
+ compatible = "shared-dma-pool";
+ reusable;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ air-water {
+ label = "air-water";
+ gpios = <&gpio ASPEED_GPIO(B, 5) GPIO_ACTIVE_LOW>;
+ linux,code = <ASPEED_GPIO(B, 5)>;
+ };
+
+ checkstop {
+ label = "checkstop";
+ gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
+ linux,code = <ASPEED_GPIO(J, 2)>;
+ };
+
+ ps0-presence {
+ label = "ps0-presence";
+ gpios = <&gpio ASPEED_GPIO(R, 7) GPIO_ACTIVE_LOW>;
+ linux,code = <ASPEED_GPIO(R, 7)>;
+ };
+
+ ps1-presence {
+ label = "ps1-presence";
+ gpios = <&gpio ASPEED_GPIO(N, 0) GPIO_ACTIVE_LOW>;
+ linux,code = <ASPEED_GPIO(N, 0)>;
+ };
+
+ oppanel-presence {
+ label = "oppanel-presence";
+ gpios = <&gpio ASPEED_GPIO(A, 7) GPIO_ACTIVE_LOW>;
+ linux,code = <ASPEED_GPIO(A, 7)>;
+ };
+
+ opencapi-riser-presence {
+ label = "opencapi-riser-presence";
+ gpios = <&gpio ASPEED_GPIO(I, 0) GPIO_ACTIVE_LOW>;
+ linux,code = <ASPEED_GPIO(I, 0)>;
+ };
+ };
+
+ iio-hwmon-battery {
+ compatible = "iio-hwmon";
+ io-channels = <&adc 12>;
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <1000>;
+
+ scm0-presence {
+ label = "scm0-presence";
+ gpios = <&pca9552 6 GPIO_ACTIVE_LOW>;
+ linux,code = <6>;
+ };
+
+ scm1-presence {
+ label = "scm1-presence";
+ gpios = <&pca9552 7 GPIO_ACTIVE_LOW>;
+ linux,code = <7>;
+ };
+
+ cpu0vrm-presence {
+ label = "cpu0vrm-presence";
+ gpios = <&pca9552 12 GPIO_ACTIVE_LOW>;
+ linux,code = <12>;
+ };
+
+ cpu1vrm-presence {
+ label = "cpu1vrm-presence";
+ gpios = <&pca9552 13 GPIO_ACTIVE_LOW>;
+ linux,code = <13>;
+ };
+
+ fan0-presence {
+ label = "fan0-presence";
+ gpios = <&pca0 5 GPIO_ACTIVE_LOW>;
+ linux,code = <5>;
+ };
+
+ fan1-presence {
+ label = "fan1-presence";
+ gpios = <&pca0 6 GPIO_ACTIVE_LOW>;
+ linux,code = <6>;
+ };
+
+ fan2-presence {
+ label = "fan2-presence";
+ gpios = <&pca0 7 GPIO_ACTIVE_LOW>;
+ linux,code = <7>;
+ };
+
+ fan3-presence {
+ label = "fan3-presence";
+ gpios = <&pca0 8 GPIO_ACTIVE_LOW>;
+ linux,code = <8>;
+ };
+
+ fanboost-presence {
+ label = "fanboost-presence";
+ gpios = <&pca0 9 GPIO_ACTIVE_LOW>;
+ linux,code = <9>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ fan0 {
+ retain-state-shutdown;
+ default-state = "keep";
+ gpios = <&pca0 0 GPIO_ACTIVE_LOW>;
+ };
+
+ fan1 {
+ retain-state-shutdown;
+ default-state = "keep";
+ gpios = <&pca0 1 GPIO_ACTIVE_LOW>;
+ };
+
+ fan2 {
+ retain-state-shutdown;
+ default-state = "keep";
+ gpios = <&pca0 2 GPIO_ACTIVE_LOW>;
+ };
+
+ fan3 {
+ retain-state-shutdown;
+ default-state = "keep";
+ gpios = <&pca0 3 GPIO_ACTIVE_LOW>;
+ };
+
+ fanboost {
+ retain-state-shutdown;
+ default-state = "keep";
+ gpios = <&pca0 4 GPIO_ACTIVE_LOW>;
+ };
+
+ front-fault {
+ retain-state-shutdown;
+ default-state = "keep";
+ gpios = <&pca1 2 GPIO_ACTIVE_LOW>;
+ };
+
+ front-power {
+ retain-state-shutdown;
+ default-state = "keep";
+ gpios = <&pca1 3 GPIO_ACTIVE_LOW>;
+ };
+
+ front-id {
+ retain-state-shutdown;
+ default-state = "keep";
+ gpios = <&pca1 0 GPIO_ACTIVE_LOW>;
+ };
+
+ rear-fault {
+ gpios = <&gpio ASPEED_GPIO(N, 2) GPIO_ACTIVE_LOW>;
+ };
+
+ rear-id {
+ gpios = <&gpio ASPEED_GPIO(N, 4) GPIO_ACTIVE_LOW>;
+ };
+
+ rear-power {
+ gpios = <&gpio ASPEED_GPIO(N, 3) GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ fsi: gpio-fsi {
+ compatible = "fsi-master-gpio", "fsi-master";
+ #address-cells = <2>;
+ #size-cells = <0>;
+ no-gpio-delays;
+
+ clock-gpios = <&gpio ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
+ data-gpios = <&gpio ASPEED_GPIO(E, 0) GPIO_ACTIVE_HIGH>;
+ mux-gpios = <&gpio ASPEED_GPIO(P, 4) GPIO_ACTIVE_HIGH>;
+ enable-gpios = <&gpio ASPEED_GPIO(P, 0) GPIO_ACTIVE_HIGH>;
+ trans-gpios = <&gpio ASPEED_GPIO(P, 3) GPIO_ACTIVE_HIGH>;
+ };
+
+ iio-hwmon-dps310 {
+ compatible = "iio-hwmon";
+ io-channels = <&dps 0>;
+ };
+
+};
+
+&fmc {
+ status = "okay";
+
+ flash at 0 {
+ status = "okay";
+ label = "bmc";
+ m25p,fast-read;
+ spi-max-frequency = <100000000>;
+ partitions {
+ #address-cells = < 1 >;
+ #size-cells = < 1 >;
+ compatible = "fixed-partitions";
+ u-boot at 0 {
+ reg = < 0 0x60000 >;
+ label = "u-boot";
+ };
+ u-boot-env at 60000 {
+ reg = < 0x60000 0x20000 >;
+ label = "u-boot-env";
+ };
+ obmc-ubi at 80000 {
+ reg = < 0x80000 0x7F80000>;
+ label = "obmc-ubi";
+ };
+ };
+ };
+
+ flash at 1 {
+ status = "okay";
+ label = "alt-bmc";
+ m25p,fast-read;
+ spi-max-frequency = <100000000>;
+ partitions {
+ #address-cells = < 1 >;
+ #size-cells = < 1 >;
+ compatible = "fixed-partitions";
+ u-boot at 0 {
+ reg = < 0 0x60000 >;
+ label = "alt-u-boot";
+ };
+ u-boot-env at 60000 {
+ reg = < 0x60000 0x20000 >;
+ label = "alt-u-boot-env";
+ };
+ obmc-ubi at 80000 {
+ reg = < 0x80000 0x7F80000>;
+ label = "alt-obmc-ubi";
+ };
+ };
+ };
+};
+
+&spi1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spi1_default>;
+
+ flash at 0 {
+ status = "okay";
+ label = "pnor";
+ m25p,fast-read;
+ spi-max-frequency = <100000000>;
+ };
+};
+
+&uart1 {
+ /* Rear RS-232 connector */
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_txd1_default
+ &pinctrl_rxd1_default
+ &pinctrl_nrts1_default
+ &pinctrl_ndtr1_default
+ &pinctrl_ndsr1_default
+ &pinctrl_ncts1_default
+ &pinctrl_ndcd1_default
+ &pinctrl_nri1_default>;
+};
+
+&uart2 {
+ /* APSS */
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_txd2_default &pinctrl_rxd2_default>;
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&lpc_ctrl {
+ status = "okay";
+ memory-region = <&flash_memory>;
+ flash = <&spi1>;
+};
+
+&mbox {
+ status = "okay";
+};
+
+&mac0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rmii1_default>;
+ use-ncsi;
+};
+
+&i2c2 {
+ status = "okay";
+
+ /* MUX ->
+ * Samtec 1
+ * Samtec 2
+ */
+};
+
+&i2c3 {
+ status = "okay";
+
+ max31785 at 52 {
+ compatible = "maxim,max31785a";
+ reg = <0x52>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fan at 0 {
+ compatible = "pmbus-fan";
+ reg = <0>;
+ tach-pulses = <2>;
+ maxim,fan-rotor-input = "tach";
+ maxim,fan-pwm-freq = <25000>;
+ maxim,fan-no-watchdog;
+ maxim,fan-no-fault-ramp;
+ maxim,fan-ramp = <2>;
+ maxim,fan-fault-pin-mon;
+ };
+
+ fan at 1 {
+ compatible = "pmbus-fan";
+ reg = <1>;
+ tach-pulses = <2>;
+ maxim,fan-rotor-input = "tach";
+ maxim,fan-pwm-freq = <25000>;
+ maxim,fan-no-watchdog;
+ maxim,fan-no-fault-ramp;
+ maxim,fan-ramp = <2>;
+ maxim,fan-fault-pin-mon;
+ };
+
+ fan at 2 {
+ compatible = "pmbus-fan";
+ reg = <2>;
+ tach-pulses = <2>;
+ maxim,fan-rotor-input = "tach";
+ maxim,fan-pwm-freq = <25000>;
+ maxim,fan-no-watchdog;
+ maxim,fan-no-fault-ramp;
+ maxim,fan-ramp = <2>;
+ maxim,fan-fault-pin-mon;
+ };
+
+ fan at 3 {
+ compatible = "pmbus-fan";
+ reg = <3>;
+ tach-pulses = <2>;
+ maxim,fan-rotor-input = "tach";
+ maxim,fan-pwm-freq = <25000>;
+ maxim,fan-no-watchdog;
+ maxim,fan-no-fault-ramp;
+ maxim,fan-ramp = <2>;
+ maxim,fan-fault-pin-mon;
+ };
+
+ fan at 4 {
+ compatible = "pmbus-fan";
+ reg = <4>;
+ tach-pulses = <2>;
+ maxim,fan-rotor-input = "tach";
+ maxim,fan-pwm-freq = <25000>;
+ maxim,fan-no-watchdog;
+ maxim,fan-no-fault-ramp;
+ maxim,fan-ramp = <2>;
+ maxim,fan-fault-pin-mon;
+ };
+ };
+
+ pca0: pca9552 at 60 {
+ compatible = "nxp,pca9552";
+ reg = <0x60>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio at 0 {
+ reg = <0>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 1 {
+ reg = <1>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 2 {
+ reg = <2>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 3 {
+ reg = <3>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 4 {
+ reg = <4>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 5 {
+ reg = <5>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 6 {
+ reg = <6>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 7 {
+ reg = <7>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 8 {
+ reg = <8>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 9 {
+ reg = <9>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 10 {
+ reg = <10>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 11 {
+ reg = <11>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 12 {
+ reg = <12>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 13 {
+ reg = <13>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 14 {
+ reg = <14>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 15 {
+ reg = <15>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+ };
+
+ power-supply at 68 {
+ compatible = "ibm,cffps1";
+ reg = <0x68>;
+ };
+
+ eeprom at 50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
+
+ power-supply at 69 {
+ compatible = "ibm,cffps1";
+ reg = <0x69>;
+ };
+
+ eeprom at 51 {
+ compatible = "atmel,24c64";
+ reg = <0x51>;
+ };
+};
+
+&i2c7 {
+ status = "okay";
+
+ dps: dps310 at 76 {
+ compatible = "infineon,dps310";
+ reg = <0x76>;
+ #io-channel-cells = <0>;
+ };
+
+ tmp275 at 48 {
+ compatible = "ti,tmp275";
+ reg = <0x48>;
+ };
+
+ si7021a20 at 20 {
+ compatible = "si,si7021a20";
+ reg = <0x20>;
+ };
+
+ eeprom at 50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
+
+ pca1: pca9551 at 60 {
+ compatible = "nxp,pca9551";
+ reg = <0x60>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio at 0 {
+ reg = <0>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 1 {
+ reg = <1>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 2 {
+ reg = <2>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 3 {
+ reg = <3>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 4 {
+ reg = <4>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 5 {
+ reg = <5>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 6 {
+ reg = <6>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 7 {
+ reg = <7>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+ };
+};
+
+&i2c8 {
+ status = "okay";
+
+ pca9552: pca9552 at 60 {
+ compatible = "nxp,pca9552";
+ reg = <0x60>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names = "PS_SMBUS_RESET_N", "APSS_RESET_N",
+ "GPU0_TH_OVERT_N_BUFF", "GPU1_TH_OVERT_N_BUFF",
+ "GPU2_TH_OVERT_N_BUFF", "GPU3_TH_OVERT_N_BUFF",
+ "P9_SCM0_PRES", "P9_SCM1_PRES",
+ "GPU0_PWR_GOOD_BUFF", "GPU1_PWR_GOOD_BUFF",
+ "GPU2_PWR_GOOD_BUFF", "GPU3_PWR_GOOD_BUFF",
+ "PRESENT_VRM_CP0_N", "PRESENT_VRM_CP1_N",
+ "12V_BREAKER_FLT_N", "THROTTLE_UNLATCHED_N";
+
+ gpio at 0 {
+ reg = <0>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 1 {
+ reg = <1>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 2 {
+ reg = <2>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 3 {
+ reg = <3>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 4 {
+ reg = <4>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 5 {
+ reg = <5>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 6 {
+ reg = <6>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 7 {
+ reg = <7>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 8 {
+ reg = <8>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 9 {
+ reg = <9>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 10 {
+ reg = <10>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 11 {
+ reg = <11>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 12 {
+ reg = <12>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 13 {
+ reg = <13>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 14 {
+ reg = <14>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+
+ gpio at 15 {
+ reg = <15>;
+ type = <PCA955X_TYPE_GPIO>;
+ };
+ };
+
+ rtc at 32 {
+ compatible = "epson,rx8900";
+ reg = <0x32>;
+ };
+
+ eeprom at 51 {
+ compatible = "atmel,24c64";
+ reg = <0x51>;
+ };
+
+ ucd90160 at 64 {
+ compatible = "ti,ucd90160";
+ reg = <0x64>;
+ };
+};
+
+&i2c9 {
+ status = "okay";
+
+ eeprom at 50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
+
+ tmp423a at 4c {
+ compatible = "ti,tmp423";
+ reg = <0x4c>;
+ };
+
+ ir35221 at 71 {
+ compatible = "infineon,ir35221";
+ reg = <0x71>;
+ };
+
+ ir35221 at 72 {
+ compatible = "infineon,ir35221";
+ reg = <0x72>;
+ };
+};
+
+&i2c10 {
+ status = "okay";
+
+ eeprom at 50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
+
+ tmp423a at 4c {
+ compatible = "ti,tmp423";
+ reg = <0x4c>;
+ };
+
+ ir35221 at 71 {
+ compatible = "infineon,ir35221";
+ reg = <0x71>;
+ };
+
+ ir35221 at 72 {
+ compatible = "infineon,ir35221";
+ reg = <0x72>;
+ };
+};
+
+&i2c11 {
+ /* MUX
+ * -> PCIe Slot 0
+ * -> PCIe Slot 1
+ * -> PCIe Slot 2
+ * -> PCIe Slot 3
+ */
+ status = "okay";
+};
+
+&i2c12 {
+ status = "okay";
+
+ tmp275 at 48 {
+ compatible = "ti,tmp275";
+ reg = <0x48>;
+ };
+
+ tmp275 at 4a {
+ compatible = "ti,tmp275";
+ reg = <0x4a>;
+ };
+};
+
+&i2c13 {
+ status = "okay";
+};
+
+&vuart {
+ status = "okay";
+};
+
+&gfx {
+ status = "okay";
+ memory-region = <&gfx_memory>;
+};
+
+&pinctrl {
+ aspeed,external-nodes = <&gfx &lhc>;
+};
+
+&wdt1 {
+ aspeed,reset-type = "none";
+ aspeed,external-signal;
+ aspeed,ext-push-pull;
+ aspeed,ext-active-high;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdtrst1_default>;
+};
+
+&wdt2 {
+ aspeed,alt-boot;
+};
+
+&ibt {
+ status = "okay";
+};
+
+&adc {
+ status = "okay";
+};
+
+#include "ibm-power9-dual.dtsi"
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2] soc: add aspeed folder and misc drivers
From: Patrick Venture @ 2019-04-29 19:40 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <CAO=notwU7LzEiBmzb6AJrgP3RGXE+66OwZVU8CqVE6RSKRvo1w@mail.gmail.com>
On Mon, Apr 29, 2019 at 12:35 PM Patrick Venture <venture@google.com> wrote:
>
> On Mon, Apr 29, 2019 at 12:27 PM Olof Johansson <olof@lixom.net> wrote:
> >
> > On Mon, Apr 29, 2019 at 10:12 AM Patrick Venture <venture@google.com> wrote:
> > >
> > > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof@lixom.net> wrote:
> > > >
> > > > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@google.com> wrote:
> > > > > > >
> > > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@google.com> wrote:
> > > > > > > >
> > > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > > > currently present into this folder. These drivers are not generic part
> > > > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > > > >
> > > > > > > > Signed-off-by: Patrick Venture <venture@google.com>
> > > > > > >
> > > > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > > > >
> > > > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > > > Makefile is followed.
> > > > >
> > > > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > > > maintainers are free to take this.
> > > > >
> > > > > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > >
> > > > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > > > across, I already applied the first.
> > >
> > > I think the issue here was that I added to the CC list another email
> > > and so you may see the v2 without that mailing list, and a v2 with it
> > > --
> > >
> > > Does this require a v3? I honestly didn't think so, but this was the
> > > first time I had to add more people without needing other changes.
> >
> > Well, v2 doesn't build. I'll fix it up locally by adding an 'endmenu'
> > to drivers/soc/aspeed/Kconfig. But... brings up questions how this was
> > tested before submitting?
Thanks for fixing this for me, and I apologize for the nuisance of it.
>
> That's a lost change issue. I'll try to be more diligent in the
> future. My dev workspace is disconnected from the kernel used for
> upstreaming patches, so if i make a change in one it isn't always
> reflected in the other. I'm working on rectifying the underlying
> build space issue to let me use the same repo.
>
> >
> > scripts/kconfig/conf --allnoconfig Kconfig
> > drivers/soc/Kconfig:24: 'menu' in different file than 'menu'
> > drivers/soc/aspeed/Kconfig:1: location of the 'menu'
> > drivers/Kconfig:233: 'menu' in different file than 'menu'
> > drivers/soc/aspeed/Kconfig:1: location of the 'menu'
> > <none>:34: syntax error
> >
> > > >
> > > > Patrick: Follow up with incremental patch in case there's any difference.
> > > > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > > > you respin patches without following up on the previous version. Thanks!
> > >
> > > w.r.t this patch series. I found an issue with v1, and released a v2
> > > with the detail of what changed. I thought that was the correct
> > > approach. I apologize for creating extra work, that's something
> > > nobody needs.
> >
> > It's ok to submit newer versions, but it's convenient when they get
> > threaded also in non-gmail mail readers (by using in-reply-to).
>
> Roger that.
>
> >
> >
> > -Olof
^ permalink raw reply
* [PATCH v2] soc: add aspeed folder and misc drivers
From: Patrick Venture @ 2019-04-29 19:35 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <CAOesGMipoKED=XLg+VtEVG0Os_MUzsPgOfBFJ+qoJs_fNmP+3g@mail.gmail.com>
On Mon, Apr 29, 2019 at 12:27 PM Olof Johansson <olof@lixom.net> wrote:
>
> On Mon, Apr 29, 2019 at 10:12 AM Patrick Venture <venture@google.com> wrote:
> >
> > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof@lixom.net> wrote:
> > >
> > > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@google.com> wrote:
> > > > > >
> > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@google.com> wrote:
> > > > > > >
> > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > > currently present into this folder. These drivers are not generic part
> > > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > > >
> > > > > > > Signed-off-by: Patrick Venture <venture@google.com>
> > > > > >
> > > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > > >
> > > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > > Makefile is followed.
> > > >
> > > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > > maintainers are free to take this.
> > > >
> > > > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >
> > > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > > across, I already applied the first.
> >
> > I think the issue here was that I added to the CC list another email
> > and so you may see the v2 without that mailing list, and a v2 with it
> > --
> >
> > Does this require a v3? I honestly didn't think so, but this was the
> > first time I had to add more people without needing other changes.
>
> Well, v2 doesn't build. I'll fix it up locally by adding an 'endmenu'
> to drivers/soc/aspeed/Kconfig. But... brings up questions how this was
> tested before submitting?
That's a lost change issue. I'll try to be more diligent in the
future. My dev workspace is disconnected from the kernel used for
upstreaming patches, so if i make a change in one it isn't always
reflected in the other. I'm working on rectifying the underlying
build space issue to let me use the same repo.
>
> scripts/kconfig/conf --allnoconfig Kconfig
> drivers/soc/Kconfig:24: 'menu' in different file than 'menu'
> drivers/soc/aspeed/Kconfig:1: location of the 'menu'
> drivers/Kconfig:233: 'menu' in different file than 'menu'
> drivers/soc/aspeed/Kconfig:1: location of the 'menu'
> <none>:34: syntax error
>
> > >
> > > Patrick: Follow up with incremental patch in case there's any difference.
> > > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > > you respin patches without following up on the previous version. Thanks!
> >
> > w.r.t this patch series. I found an issue with v1, and released a v2
> > with the detail of what changed. I thought that was the correct
> > approach. I apologize for creating extra work, that's something
> > nobody needs.
>
> It's ok to submit newer versions, but it's convenient when they get
> threaded also in non-gmail mail readers (by using in-reply-to).
Roger that.
>
>
> -Olof
^ permalink raw reply
* [PATCH v2] soc: add aspeed folder and misc drivers
From: Olof Johansson @ 2019-04-29 19:27 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <CAO=notwewAeeLz=LsOcSj=DakLGW0KjeDHALP5Nv2ckgkRqnFA@mail.gmail.com>
On Mon, Apr 29, 2019 at 10:12 AM Patrick Venture <venture@google.com> wrote:
>
> On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof@lixom.net> wrote:
> >
> > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@google.com> wrote:
> > > > >
> > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@google.com> wrote:
> > > > > >
> > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > currently present into this folder. These drivers are not generic part
> > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > >
> > > > > > Signed-off-by: Patrick Venture <venture@google.com>
> > > > >
> > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > >
> > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > Makefile is followed.
> > >
> > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > maintainers are free to take this.
> > >
> > > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > across, I already applied the first.
>
> I think the issue here was that I added to the CC list another email
> and so you may see the v2 without that mailing list, and a v2 with it
> --
>
> Does this require a v3? I honestly didn't think so, but this was the
> first time I had to add more people without needing other changes.
Well, v2 doesn't build. I'll fix it up locally by adding an 'endmenu'
to drivers/soc/aspeed/Kconfig. But... brings up questions how this was
tested before submitting?
scripts/kconfig/conf --allnoconfig Kconfig
drivers/soc/Kconfig:24: 'menu' in different file than 'menu'
drivers/soc/aspeed/Kconfig:1: location of the 'menu'
drivers/Kconfig:233: 'menu' in different file than 'menu'
drivers/soc/aspeed/Kconfig:1: location of the 'menu'
<none>:34: syntax error
> >
> > Patrick: Follow up with incremental patch in case there's any difference.
> > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > you respin patches without following up on the previous version. Thanks!
>
> w.r.t this patch series. I found an issue with v1, and released a v2
> with the detail of what changed. I thought that was the correct
> approach. I apologize for creating extra work, that's something
> nobody needs.
It's ok to submit newer versions, but it's convenient when they get
threaded also in non-gmail mail readers (by using in-reply-to).
-Olof
^ permalink raw reply
* [PATCH v2] soc: add aspeed folder and misc drivers
From: Patrick Venture @ 2019-04-29 17:22 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <CAOesGMjShorZmVeLL1nJNPVOP+vNTVzcA=arU3qW8ZUDYCtjaQ@mail.gmail.com>
On Mon, Apr 29, 2019 at 10:19 AM Olof Johansson <olof@lixom.net> wrote:
>
> On Mon, Apr 29, 2019 at 10:16 AM Patrick Venture <venture@google.com> wrote:
> >
> > On Mon, Apr 29, 2019 at 10:13 AM Olof Johansson <olof@lixom.net> wrote:
> > >
> > > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof@lixom.net> wrote:
> > > >
> > > > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@google.com> wrote:
> > > > > > >
> > > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@google.com> wrote:
> > > > > > > >
> > > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > > > currently present into this folder. These drivers are not generic part
> > > > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > > > >
> > > > > > > > Signed-off-by: Patrick Venture <venture@google.com>
> > > > > > >
> > > > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > > > >
> > > > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > > > Makefile is followed.
> > > > >
> > > > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > > > maintainers are free to take this.
> > > > >
> > > > > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > >
> > > > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > > > across, I already applied the first.
> > > >
> > > > Patrick: Follow up with incremental patch in case there's any difference.
> > > > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > > > you respin patches without following up on the previous version. Thanks!
> > >
> > > Not only that, but subthreads were cc:d to arm at kernel.org and some
> > > were not, so I missed the overnight conversation on the topic.
> > >
> > > If this email thread is any indication of how the code will be
> > > flowing, there's definitely need for more structure. Joel, I'm hoping
> > > you'll coordinate.
> >
> > To be honest, this patchset thread was a bit less clear than anyone
> > prefers. I use get_maintainers to get the initial list, and so adding
> > arm@ or soc@ per a request tells me that perhaps those should be
> > output via that script.
>
> The tools are working as expected, we normally don't take patches
> directly to arm at kernel.org, we let them go in through platform
> maintainers who then send it on to us.
Thanks for clarifying.
>
> > >
> > > I'm with Arnd on whether the code should be in drivers/soc or not --
> > > most of it likely should not.
> >
> > I think the misc drivers for a SoC that are a single user interface
> > that is focused on the use-case that belongs to that SoC only belong
> > in soc/, while if there is something we can do in common -- different
> > story. If it makes sense to just have misc/aspeed/ instead of
> > soc/aspeed -- would that align more?
>
> Those views are how the "board file hell" started on 32-bit ARM too,
> so we're definitely hesitant to jump to that conclusion without
> knowing more about what's actually anticipated.
>
>
> Do you happen to have an estimate on what kind of drivers are
> needed/anticipated?
There is a UART routing control driver for ASPEED that spawned my push
to soc/aspeed. The advice on that thread was to put such drivers
there. There's likely to be a few more control-focused aspeed
drivers.
For Nuvoton, we definitely expect some similar LPC control drivers.
Possibly an LPC snoop driver, similar to aspeed-lpc-snoop. This
supports the idea of creating some form of bmc subsystem as suggested
above (or in a different thread).
>
>
> -Olof
^ permalink raw reply
* [PATCH v2] soc: add aspeed folder and misc drivers
From: Olof Johansson @ 2019-04-29 17:19 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <CAO=notwVyTqvxfYRU1XJTwzSNCUAMgYCVpXVvqaN62uSiWyYCQ@mail.gmail.com>
On Mon, Apr 29, 2019 at 10:16 AM Patrick Venture <venture@google.com> wrote:
>
> On Mon, Apr 29, 2019 at 10:13 AM Olof Johansson <olof@lixom.net> wrote:
> >
> > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof@lixom.net> wrote:
> > >
> > > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@google.com> wrote:
> > > > > >
> > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@google.com> wrote:
> > > > > > >
> > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > > currently present into this folder. These drivers are not generic part
> > > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > > >
> > > > > > > Signed-off-by: Patrick Venture <venture@google.com>
> > > > > >
> > > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > > >
> > > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > > Makefile is followed.
> > > >
> > > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > > maintainers are free to take this.
> > > >
> > > > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >
> > > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > > across, I already applied the first.
> > >
> > > Patrick: Follow up with incremental patch in case there's any difference.
> > > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > > you respin patches without following up on the previous version. Thanks!
> >
> > Not only that, but subthreads were cc:d to arm at kernel.org and some
> > were not, so I missed the overnight conversation on the topic.
> >
> > If this email thread is any indication of how the code will be
> > flowing, there's definitely need for more structure. Joel, I'm hoping
> > you'll coordinate.
>
> To be honest, this patchset thread was a bit less clear than anyone
> prefers. I use get_maintainers to get the initial list, and so adding
> arm@ or soc@ per a request tells me that perhaps those should be
> output via that script.
The tools are working as expected, we normally don't take patches
directly to arm at kernel.org, we let them go in through platform
maintainers who then send it on to us.
> >
> > I'm with Arnd on whether the code should be in drivers/soc or not --
> > most of it likely should not.
>
> I think the misc drivers for a SoC that are a single user interface
> that is focused on the use-case that belongs to that SoC only belong
> in soc/, while if there is something we can do in common -- different
> story. If it makes sense to just have misc/aspeed/ instead of
> soc/aspeed -- would that align more?
Those views are how the "board file hell" started on 32-bit ARM too,
so we're definitely hesitant to jump to that conclusion without
knowing more about what's actually anticipated.
Do you happen to have an estimate on what kind of drivers are
needed/anticipated?
-Olof
^ permalink raw reply
* [PATCH v2] soc: add aspeed folder and misc drivers
From: Patrick Venture @ 2019-04-29 17:16 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <CAOesGMg49z4Gip-bLK-h7+LSLa4Fu68r11gT2EV8E8xMCPGDxg@mail.gmail.com>
On Mon, Apr 29, 2019 at 10:13 AM Olof Johansson <olof@lixom.net> wrote:
>
> On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof@lixom.net> wrote:
> >
> > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@google.com> wrote:
> > > > >
> > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@google.com> wrote:
> > > > > >
> > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > > currently present into this folder. These drivers are not generic part
> > > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > > >
> > > > > > Signed-off-by: Patrick Venture <venture@google.com>
> > > > >
> > > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > > >
> > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > > Ack this version of the patchset since it changes when the soc/aspeed
> > > > Makefile is followed.
> > >
> > > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > > maintainers are free to take this.
> > >
> > > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > I'm totally confused. This is the second "PATCH v2" of this patch that I came
> > across, I already applied the first.
> >
> > Patrick: Follow up with incremental patch in case there's any difference.
> > Meanwhile, please keep in mind that you're adding a lot of work for people when
> > you respin patches without following up on the previous version. Thanks!
>
> Not only that, but subthreads were cc:d to arm at kernel.org and some
> were not, so I missed the overnight conversation on the topic.
>
> If this email thread is any indication of how the code will be
> flowing, there's definitely need for more structure. Joel, I'm hoping
> you'll coordinate.
To be honest, this patchset thread was a bit less clear than anyone
prefers. I use get_maintainers to get the initial list, and so adding
arm@ or soc@ per a request tells me that perhaps those should be
output via that script.
>
> I'm with Arnd on whether the code should be in drivers/soc or not --
> most of it likely should not.
I think the misc drivers for a SoC that are a single user interface
that is focused on the use-case that belongs to that SoC only belong
in soc/, while if there is something we can do in common -- different
story. If it makes sense to just have misc/aspeed/ instead of
soc/aspeed -- would that align more?
>
>
> -Olof
^ permalink raw reply
* [PATCH v2] soc: add aspeed folder and misc drivers
From: Olof Johansson @ 2019-04-29 17:12 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20190429165137.mwj4ehhwerunbef4@localhost>
On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof@lixom.net> wrote:
>
> On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@google.com> wrote:
> > > >
> > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@google.com> wrote:
> > > > >
> > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > currently present into this folder. These drivers are not generic part
> > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > >
> > > > > Signed-off-by: Patrick Venture <venture@google.com>
> > > >
> > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > >
> > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > Ack this version of the patchset since it changes when the soc/aspeed
> > > Makefile is followed.
> >
> > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > maintainers are free to take this.
> >
> > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> I'm totally confused. This is the second "PATCH v2" of this patch that I came
> across, I already applied the first.
>
> Patrick: Follow up with incremental patch in case there's any difference.
> Meanwhile, please keep in mind that you're adding a lot of work for people when
> you respin patches without following up on the previous version. Thanks!
Not only that, but subthreads were cc:d to arm at kernel.org and some
were not, so I missed the overnight conversation on the topic.
If this email thread is any indication of how the code will be
flowing, there's definitely need for more structure. Joel, I'm hoping
you'll coordinate.
I'm with Arnd on whether the code should be in drivers/soc or not --
most of it likely should not.
-Olof
^ permalink raw reply
* [PATCH v2] soc: add aspeed folder and misc drivers
From: Patrick Venture @ 2019-04-29 17:12 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20190429165137.mwj4ehhwerunbef4@localhost>
On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof@lixom.net> wrote:
>
> On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@google.com> wrote:
> > > >
> > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@google.com> wrote:
> > > > >
> > > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > > currently present into this folder. These drivers are not generic part
> > > > > drivers, but rather only apply to the ASPEED SoCs.
> > > > >
> > > > > Signed-off-by: Patrick Venture <venture@google.com>
> > > >
> > > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > > didn't see it on v1 before re-sending v2 to the larger audience.
> > >
> > > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > > Ack this version of the patchset since it changes when the soc/aspeed
> > > Makefile is followed.
> >
> > I have no objection for moving stuff out of drivers/misc/ so the SOC
> > maintainers are free to take this.
> >
> > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> I'm totally confused. This is the second "PATCH v2" of this patch that I came
> across, I already applied the first.
I think the issue here was that I added to the CC list another email
and so you may see the v2 without that mailing list, and a v2 with it
--
Does this require a v3? I honestly didn't think so, but this was the
first time I had to add more people without needing other changes.
>
> Patrick: Follow up with incremental patch in case there's any difference.
> Meanwhile, please keep in mind that you're adding a lot of work for people when
> you respin patches without following up on the previous version. Thanks!
w.r.t this patch series. I found an issue with v1, and released a v2
with the detail of what changed. I thought that was the correct
approach. I apologize for creating extra work, that's something
nobody needs.
>
>
> -Olof
^ permalink raw reply
* [PATCH 1/2] ARM: dts: aspeed: Add aspeed-p2a-ctrl node
From: Olof Johansson @ 2019-04-29 17:05 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20190425194853.140617-1-venture@google.com>
On Thu, Apr 25, 2019 at 12:48:53PM -0700, Patrick Venture wrote:
> Add a node for the aspeed-p2a-ctrl module. This node, when enabled will
> disable the PCI-to-AHB bridge and then allow control of this bridge via
> ioctls, and access via mmap.
>
> Signed-off-by: Patrick Venture <venture@google.com>
Patrick,
Please send these to Joel and Andrew (and cc the mailing lists). No need to
send patches that there are active maintainers for to arm at kernel.org directly.
(As a matter of fact, drivers/soc/aspeed should go through them too, even if
I applied the first patch directly just now).
-Olof
^ permalink raw reply
* [PATCH v2] soc: add aspeed folder and misc drivers
From: Olof Johansson @ 2019-04-29 16:51 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20190425172549.GA12376@kroah.com>
On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote:
> On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote:
> > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@google.com> wrote:
> > >
> > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@google.com> wrote:
> > > >
> > > > Create a SoC folder for the ASPEED parts and place the misc drivers
> > > > currently present into this folder. These drivers are not generic part
> > > > drivers, but rather only apply to the ASPEED SoCs.
> > > >
> > > > Signed-off-by: Patrick Venture <venture@google.com>
> > >
> > > Accidentally lost the Acked-by when re-sending this patchset as I
> > > didn't see it on v1 before re-sending v2 to the larger audience.
> >
> > Since there was a change between v1 and v2, Arnd, I'd appreciate you
> > Ack this version of the patchset since it changes when the soc/aspeed
> > Makefile is followed.
>
> I have no objection for moving stuff out of drivers/misc/ so the SOC
> maintainers are free to take this.
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I'm totally confused. This is the second "PATCH v2" of this patch that I came
across, I already applied the first.
Patrick: Follow up with incremental patch in case there's any difference.
Meanwhile, please keep in mind that you're adding a lot of work for people when
you respin patches without following up on the previous version. Thanks!
-Olof
^ permalink raw reply
* [PATCH v2] soc: add aspeed folder and misc drivers
From: Olof Johansson @ 2019-04-29 16:36 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <CAO=notxpGXLBPwsHAJdt8CwQMdNcCE=EeFymgxez_goaqnGoHQ@mail.gmail.com>
On Mon, Apr 22, 2019 at 12:24:28PM -0700, Patrick Venture wrote:
> On Mon, Apr 22, 2019 at 10:54 AM Patrick Venture <venture@google.com> wrote:
> >
> > Create a SoC folder for the ASPEED parts and place the misc drivers
> > currently present into this folder. These drivers are not generic part
> > drivers, but rather only apply to the ASPEED SoCs.
> >
> > Signed-off-by: Patrick Venture <venture@google.com>
> > ---
> > v2:
> > Added configuration option for ASPEED to soc/Makefile
> > ---
> > drivers/misc/Kconfig | 16 ----------------
> > drivers/misc/Makefile | 2 --
> > drivers/soc/Kconfig | 1 +
> > drivers/soc/Makefile | 1 +
> > drivers/soc/aspeed/Kconfig | 19 +++++++++++++++++++
> > drivers/soc/aspeed/Makefile | 2 ++
> > .../{misc => soc/aspeed}/aspeed-lpc-ctrl.c | 0
> > .../{misc => soc/aspeed}/aspeed-lpc-snoop.c | 0
> > 8 files changed, 23 insertions(+), 18 deletions(-)
> > create mode 100644 drivers/soc/aspeed/Kconfig
> > create mode 100644 drivers/soc/aspeed/Makefile
> > rename drivers/{misc => soc/aspeed}/aspeed-lpc-ctrl.c (100%)
> > rename drivers/{misc => soc/aspeed}/aspeed-lpc-snoop.c (100%)
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 42ab8ec92a04..b80cb6af0cb4 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -496,22 +496,6 @@ config VEXPRESS_SYSCFG
> > bus. System Configuration interface is one of the possible means
> > of generating transactions on this bus.
> >
> > -config ASPEED_LPC_CTRL
> > - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > - tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
> > - ---help---
> > - Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
> > - ioctl()s, the driver also provides a read/write interface to a BMC ram
> > - region where the host LPC read/write region can be buffered.
> > -
> > -config ASPEED_LPC_SNOOP
> > - tristate "Aspeed ast2500 HOST LPC snoop support"
> > - depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > - help
> > - Provides a driver to control the LPC snoop interface which
> > - allows the BMC to listen on and save the data written by
> > - the host to an arbitrary LPC I/O port.
> > -
> > config PCI_ENDPOINT_TEST
> > depends on PCI
> > select CRC32
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index d5b7d3404dc7..b9affcdaa3d6 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -54,8 +54,6 @@ obj-$(CONFIG_GENWQE) += genwqe/
> > obj-$(CONFIG_ECHO) += echo/
> > obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> > obj-$(CONFIG_CXL_BASE) += cxl/
> > -obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> > -obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
> > obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o
> > obj-$(CONFIG_OCXL) += ocxl/
> > obj-y += cardreader/
> > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> > index c07b4a85253f..b750a88547c7 100644
> > --- a/drivers/soc/Kconfig
> > +++ b/drivers/soc/Kconfig
> > @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
> >
> > source "drivers/soc/actions/Kconfig"
> > source "drivers/soc/amlogic/Kconfig"
> > +source "drivers/soc/aspeed/Kconfig"
> > source "drivers/soc/atmel/Kconfig"
> > source "drivers/soc/bcm/Kconfig"
> > source "drivers/soc/fsl/Kconfig"
> > diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> > index 90b686e586c6..814128fe479f 100644
> > --- a/drivers/soc/Makefile
> > +++ b/drivers/soc/Makefile
> > @@ -4,6 +4,7 @@
> > #
> >
> > obj-$(CONFIG_ARCH_ACTIONS) += actions/
> > +obj-$(CONFIG_ARCH_ASPEED) += aspeed/
> > obj-$(CONFIG_ARCH_AT91) += atmel/
> > obj-y += bcm/
> > obj-$(CONFIG_ARCH_DOVE) += dove/
> > diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
> > new file mode 100644
> > index 000000000000..457282cd1da5
> > --- /dev/null
> > +++ b/drivers/soc/aspeed/Kconfig
> > @@ -0,0 +1,19 @@
> > +menu "Aspeed SoC drivers"
> > +
> > +config ASPEED_LPC_CTRL
> > + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > + tristate "Aspeed ast2400/2500 HOST LPC to BMC bridge control"
> > + ---help---
> > + Control Aspeed ast2400/2500 HOST LPC to BMC mappings through
> > + ioctl()s, the driver also provides a read/write interface to a BMC ram
> > + region where the host LPC read/write region can be buffered.
> > +
> > +config ASPEED_LPC_SNOOP
> > + tristate "Aspeed ast2500 HOST LPC snoop support"
> > + depends on (ARCH_ASPEED || COMPILE_TEST) && REGMAP && MFD_SYSCON
> > + help
> > + Provides a driver to control the LPC snoop interface which
> > + allows the BMC to listen on and save the data written by
> > + the host to an arbitrary LPC I/O port.
> > +
> > +
> > diff --git a/drivers/soc/aspeed/Makefile b/drivers/soc/aspeed/Makefile
> > new file mode 100644
> > index 000000000000..cfaa9adc67b5
> > --- /dev/null
> > +++ b/drivers/soc/aspeed/Makefile
> > @@ -0,0 +1,2 @@
> > +obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> > +obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
> > diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
> > similarity index 100%
> > rename from drivers/misc/aspeed-lpc-ctrl.c
> > rename to drivers/soc/aspeed/aspeed-lpc-ctrl.c
> > diff --git a/drivers/misc/aspeed-lpc-snoop.c b/drivers/soc/aspeed/aspeed-lpc-snoop.c
> > similarity index 100%
> > rename from drivers/misc/aspeed-lpc-snoop.c
> > rename to drivers/soc/aspeed/aspeed-lpc-snoop.c
> > --
> > 2.21.0.593.g511ec345e18-goog
> >
>
> Fixed CC on this reply (Gmail button didn't behave as expected) and
> replied to the v2 patchset instead of accidentally the first.
Replaced v1 patch with this one. Please thread your patch series or follow up
saying they've been superceded to avoid maintainers from doing duplicate work.
> Given this patchset, I have several patches that move the drivers into
> the folder, and thought about writing it up as a series. I wanted to
> see how this patchset would do before I staged the rest -- my question
> is, should this patchset create the folder with the empty Kconfig and
> Makefile, and then have follow-on patches that provide content to
> split out the process into multiple logical steps?
What's the purpose of moving the drivers? Are they mislocated where they are
now?
It'd be useful to see an inventory of which ones they are. As mentioned on the
other reply, there's no reason to move drivers to drivers/soc just because they
happen to be an IP block on one SoC. We really prefer to have the drivers
located in the subsystems they belong.
-Olof
^ permalink raw reply
* [PATCH] soc: add aspeed folder and misc drivers
From: Olof Johansson @ 2019-04-29 16:32 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <CAK8P3a0k_8+R9FeyZsL6Egvi1Z-G0VrvR0TWXzGHryqxTr6thg@mail.gmail.com>
On Tue, Apr 23, 2019 at 10:08:11AM +0200, Arnd Bergmann wrote:
> On Mon, Apr 22, 2019 at 7:38 PM Patrick Venture <venture@google.com> wrote:
> >
> > Create a SoC folder for the ASPEED parts and place the misc drivers
> > currently present into this folder. These drivers are not generic part
> > drivers, but rather only apply to the ASPEED SoCs.
> >
> > Signed-off-by: Patrick Venture <venture@google.com>
>
> Looks ok, but please resend to arm at kernel.org or soc at kernel.org
> so we can track the submission and make sure it gets applied if
> you want this to go through the arm-soc tree.
>
> If Greg wants to pick it up, that's fine too.
>
> Either way,
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Applied to the SoC tree now.
-Olof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox