* [[PATCH] 0/9] *** DMA support for UART in ASPEED's AST2500 ***
From: Rob Herring @ 2018-10-25 14:48 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <1539749466-3912-1-git-send-email-open.sudheer@gmail.com>
On Wed, Oct 17, 2018 at 09:40:57AM +0530, sudheer.v wrote:
> DMA controller driver and UART dma client driver for aspeed's AST2500
>
> sudheer.v (9):
We need a full name for author and Signed-off-by.
> DT-changes-for-DMA-UART-of-AST2500
> Defconfig-changes-for-DMA-UART-of-AST2500
> configuration-for-DMA-of-AST2500
> Documentation-DTbindings-DMA-controller-of-AST2500
> DMA-driver-for-AST2500
> configuration-for-DMA-UART-of-AST2500
> Documentation-DTbindings-DMA-UART-of-AST2500
> DMA-UART-Driver-for-AST2500
> updating MAINTAINERS for DMA and DMA-UART drivers of AST2500
Your commit messages need some work. Use 'git log --oneline <dir>' on
each directory for inspiration as to what the subject should be.
DT bindings specifically are "dt-bindings: <binding dir>: ..."
Rob
^ permalink raw reply
* [PATCH v8 08/12] mfd: intel-peci-client: Add PECI client MFD driver
From: Jae Hyun Yoo @ 2018-10-25 16:16 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181025053030.GD4939@dell>
On 10/24/2018 10:30 PM, Lee Jones wrote:
> On Wed, 24 Oct 2018, Jae Hyun Yoo wrote:
>> On 10/24/2018 3:59 AM, Lee Jones wrote:
>>> On Tue, 18 Sep 2018, Jae Hyun Yoo wrote:
>>>
>>>> This commit adds PECI client MFD driver.
>>>>
>>
>> <snip>
>
> [...]
>
>>>> +bool peci_temp_need_update(struct temp_data *temp)
>>>> +{
>>>> + if (temp->valid &&
>>>> + time_before(jiffies, temp->last_updated + UPDATE_INTERVAL))
>>>> + return false;
>>>> +
>>>> + return true;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(peci_temp_need_update);
>>>> +
>>>> +void peci_temp_mark_updated(struct temp_data *temp)
>>>> +{
>>>> + temp->valid = 1;
>>>> + temp->last_updated = jiffies;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(peci_temp_mark_updated);
>>>
>>> These are probably better suited as inline functions to be placed in
>>> a header file. No need to export them, since they only use their own
>>> data.
>
> Also move them into the HWMON header file.
>
> They have no business in MFD.
>
Agreed. I'll move them into the HWMON header.
> [...]
>
>>>> +int peci_client_rd_pkg_cfg_cmd(struct peci_mfd *priv, u8 mbx_idx,
>>>
>>> This is gobbledegook. What's rd? Read?
>>>
>>
>> Yes, the 'rd' means 'read'. I intended to keep command names as listed
>> in the PECI specification such as RdPkgConfig, WrPkgConfig and so on.
>> Should I change it to 'peci_client_read_package_config_command' ?
>
> I looks/reads a lot nicer, don't you think?
>
Okay. I'll change it too.
Thanks again for your review, Lee!
Jae
> [...]
>
^ permalink raw reply
* [PATCH net-next] net/ncsi: Add NCSI Mellanox OEM command
From: Vijay Khemka @ 2018-10-25 22:04 UTC (permalink / raw)
To: linux-aspeed
This patch adds OEM Mellanox commands and response handling. It also
defines OEM Get MAC Address handler to get and configure the device.
ncsi_oem_gma_handler_mlx: This handler send NCSI mellanox command for
getting mac address.
ncsi_rsp_handler_oem_mlx: This handles response received for all
mellanox OEM commands.
ncsi_rsp_handler_oem_mlx_gma: This handles get mac address response and
set it to device.
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
net/ncsi/internal.h | 5 +++++
net/ncsi/ncsi-manage.c | 25 ++++++++++++++++++++++++-
net/ncsi/ncsi-pkt.h | 9 +++++++++
net/ncsi/ncsi-rsp.c | 41 ++++++++++++++++++++++++++++++++++++++++-
4 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h
index 1dae77c54009..7f3eb1360b9b 100644
--- a/net/ncsi/internal.h
+++ b/net/ncsi/internal.h
@@ -73,10 +73,15 @@ enum {
#define NCSI_OEM_MFR_BCM_ID 0x113d
/* Broadcom specific OEM Command */
#define NCSI_OEM_BCM_CMD_GMA 0x01 /* CMD ID for Get MAC */
+/* Mellanox specific OEM Command */
+#define NCSI_OEM_MLX_CMD_GMA 0x00 /* CMD ID for Get MAC */
+#define NCSI_OEM_MLX_CMD_GMA_PARAM 0x1b /* Parameter for GMA */
/* OEM Command payload lengths*/
#define NCSI_OEM_BCM_CMD_GMA_LEN 12
+#define NCSI_OEM_MLX_CMD_GMA_LEN 8
/* Mac address offset in OEM response */
#define BCM_MAC_ADDR_OFFSET 28
+#define MLX_MAC_ADDR_OFFSET 8
struct ncsi_channel_version {
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index bfc43b28c7a6..eacb653ff987 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -675,12 +675,35 @@ static int ncsi_oem_gma_handler_bcm(struct ncsi_cmd_arg *nca)
return ret;
}
+static int ncsi_oem_gma_handler_mlx(struct ncsi_cmd_arg *nca)
+{
+ unsigned char data[NCSI_OEM_MLX_CMD_GMA_LEN];
+ int ret = 0;
+
+ nca->payload = NCSI_OEM_MLX_CMD_GMA_LEN;
+
+ memset(data, 0, NCSI_OEM_MLX_CMD_GMA_LEN);
+ *(unsigned int *)data = ntohl(NCSI_OEM_MFR_MLX_ID);
+ data[5] = NCSI_OEM_MLX_CMD_GMA;
+ data[6] = NCSI_OEM_MLX_CMD_GMA_PARAM;
+
+ nca->data = data;
+
+ ret = ncsi_xmit_cmd(nca);
+ if (ret)
+ netdev_err(nca->ndp->ndev.dev,
+ "NCSI: Failed to transmit cmd 0x%x during configure\n",
+ nca->type);
+ return ret;
+}
+
/* OEM Command handlers initialization */
static struct ncsi_oem_gma_handler {
unsigned int mfr_id;
int (*handler)(struct ncsi_cmd_arg *nca);
} ncsi_oem_gma_handlers[] = {
- { NCSI_OEM_MFR_BCM_ID, ncsi_oem_gma_handler_bcm }
+ { NCSI_OEM_MFR_BCM_ID, ncsi_oem_gma_handler_bcm },
+ { NCSI_OEM_MFR_MLX_ID, ncsi_oem_gma_handler_mlx }
};
static int ncsi_gma_handler(struct ncsi_cmd_arg *nca, unsigned int mf_id)
diff --git a/net/ncsi/ncsi-pkt.h b/net/ncsi/ncsi-pkt.h
index 4d3f06be38bd..2a6d83a596c9 100644
--- a/net/ncsi/ncsi-pkt.h
+++ b/net/ncsi/ncsi-pkt.h
@@ -165,6 +165,15 @@ struct ncsi_rsp_oem_pkt {
unsigned char data[]; /* Payload data */
};
+/* Mellanox Response Data */
+struct ncsi_rsp_oem_mlx_pkt {
+ unsigned char cmd_rev; /* Command Revision */
+ unsigned char cmd; /* Command ID */
+ unsigned char param; /* Parameter */
+ unsigned char optional; /* Optional data */
+ unsigned char data[]; /* Data */
+};
+
/* Broadcom Response Data */
struct ncsi_rsp_oem_bcm_pkt {
unsigned char ver; /* Payload Version */
diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
index 77e07ba3f493..ba9a4ba97c64 100644
--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -611,6 +611,45 @@ static int ncsi_rsp_handler_snfc(struct ncsi_request *nr)
return 0;
}
+/* Response handler for Mellanox command Get Mac Address */
+static int ncsi_rsp_handler_oem_mlx_gma(struct ncsi_request *nr)
+{
+ struct ncsi_dev_priv *ndp = nr->ndp;
+ struct net_device *ndev = ndp->ndev.dev;
+ const struct net_device_ops *ops = ndev->netdev_ops;
+ struct ncsi_rsp_oem_pkt *rsp;
+ struct sockaddr saddr;
+ int ret = 0;
+
+ /* Get the response header */
+ rsp = (struct ncsi_rsp_oem_pkt *)skb_network_header(nr->rsp);
+
+ saddr.sa_family = ndev->type;
+ ndev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+ memcpy(saddr.sa_data, &rsp->data[MLX_MAC_ADDR_OFFSET], ETH_ALEN);
+ ret = ops->ndo_set_mac_address(ndev, &saddr);
+ if (ret < 0)
+ netdev_warn(ndev, "NCSI: 'Writing mac address to device failed\n");
+
+ return ret;
+}
+
+/* Response handler for Mellanox card */
+static int ncsi_rsp_handler_oem_mlx(struct ncsi_request *nr)
+{
+ struct ncsi_rsp_oem_mlx_pkt *mlx;
+ struct ncsi_rsp_oem_pkt *rsp;
+
+ /* Get the response header */
+ rsp = (struct ncsi_rsp_oem_pkt *)skb_network_header(nr->rsp);
+ mlx = (struct ncsi_rsp_oem_mlx_pkt *)(rsp->data);
+
+ if (mlx->cmd == NCSI_OEM_MLX_CMD_GMA &&
+ mlx->param == NCSI_OEM_MLX_CMD_GMA_PARAM)
+ return ncsi_rsp_handler_oem_mlx_gma(nr);
+ return 0;
+}
+
/* Response handler for Broadcom command Get Mac Address */
static int ncsi_rsp_handler_oem_bcm_gma(struct ncsi_request *nr)
{
@@ -655,7 +694,7 @@ static struct ncsi_rsp_oem_handler {
unsigned int mfr_id;
int (*handler)(struct ncsi_request *nr);
} ncsi_rsp_oem_handlers[] = {
- { NCSI_OEM_MFR_MLX_ID, NULL },
+ { NCSI_OEM_MFR_MLX_ID, ncsi_rsp_handler_oem_mlx },
{ NCSI_OEM_MFR_BCM_ID, ncsi_rsp_handler_oem_bcm }
};
--
2.17.1
^ permalink raw reply related
* [PATCH net-next] net/ncsi: Add NCSI Mellanox OEM command
From: David Miller @ 2018-10-25 22:53 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181025220413.2936698-1-vijaykhemka@fb.com>
From: Vijay Khemka <vijaykhemka@fb.com>
Date: Thu, 25 Oct 2018 15:04:13 -0700
> This patch adds OEM Mellanox commands and response handling. It also
> defines OEM Get MAC Address handler to get and configure the device.
>
> ncsi_oem_gma_handler_mlx: This handler send NCSI mellanox command for
> getting mac address.
> ncsi_rsp_handler_oem_mlx: This handles response received for all
> mellanox OEM commands.
> ncsi_rsp_handler_oem_mlx_gma: This handles get mac address response and
> set it to device.
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
net-next is closed, please resubmit this when the net-next tree opens
back up.
Thank you.
^ permalink raw reply
* [[PATCH] 8/9] DMA-UART-Driver-for-AST2500
From: sudheer.v @ 2018-10-26 7:07 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181020162624.GC2894@vkoul-mobl>
On Sat, Oct 20, 2018 at 09:56:24PM +0530, Vinod wrote:
> On 19-10-18, 12:41, sudheer.v wrote:
> > On Fri, Oct 19, 2018 at 10:32:24AM +1100, Benjamin Herrenschmidt wrote:
> > > On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote:
> > > >
> > > > > It's not a dmaengine driver. It's a serial UART driver that happens to
> > > > > use a dedicated DMA engine.
> > > >
> > > > Then I see no reason for it to use dmaengine APIs. The framework allows
> > > > people to share a controller for many clients, but if you have dedicated
> > > > one then you may use it directly
> > >
> > > Well... the engine is shared by a few UARTs, they have dedicated rings
> > > but there's a common set of regs for interrupt handling etc.
> > >
> > > That said, I still think it could be contained within a UART driver,
> > > there's little benefit in adding the framework overhead, esp since
> > > these are really weak cores, any overhead will be felt.
> > >
> > > Ben.
> > >
> > > > > It's unclear whether it should be split into two drivers, or just have
> > > > > the serial driver directly use the dma engine since that engine is
> > > > > dedicated in HW to only work on those UARTs and nothing else...
> > > > >
> > > > > Cheers,
> > > > > Ben.
> >
> > Initially we wanted to have a single driver,
> > however we had an informal discussion with one of the maintainer
> > and based on the feedback, followed the Linux DMA and UART architecture.
> >
> > If this seperate DMA-engine driver adds more overhead than benifit,
> > we will merge them into a single UART driver and resubmitt the patches.
> > Vinod,
> > can this dma-controller driver sit under dma subsystem?.
> > or better to move it under UART framework.
>
>
> My advise would be to see what you can do with the DMA IP block. If this
> can/would be used in different places then it would make sense to do a
> dmaengine driver and solve the problem for everyone.
>
> If this is always going to be hidden behind serial then maybe it makes
> sense to be inside serial driver and not use dmaengine APIs
>
> If you decide to prefer the former case, please move it to dmaengine and
> resubmit :)
>
> HTH
> --
> ~Vinod
Hi All,
As the DMA engine is dedicated only to UART,we have decided
to rewrite the driver so that no code will come under
drivers/dma.
I will resubmitt the patches after merging dma controller
code and uart driver code.
Regards
-sudheer
^ permalink raw reply
* [[PATCH] 0/9] *** DMA support for UART in ASPEED's AST2500 ***
From: sudheer.v @ 2018-10-26 7:23 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181025144841.GA21004@bogus>
On Thu, Oct 25, 2018 at 09:48:41AM -0500, Rob Herring wrote:
> On Wed, Oct 17, 2018 at 09:40:57AM +0530, sudheer.v wrote:
> > DMA controller driver and UART dma client driver for aspeed's AST2500
> >
> > sudheer.v (9):
>
> We need a full name for author and Signed-off-by.
>
> > DT-changes-for-DMA-UART-of-AST2500
> > Defconfig-changes-for-DMA-UART-of-AST2500
> > configuration-for-DMA-of-AST2500
> > Documentation-DTbindings-DMA-controller-of-AST2500
> > DMA-driver-for-AST2500
> > configuration-for-DMA-UART-of-AST2500
> > Documentation-DTbindings-DMA-UART-of-AST2500
> > DMA-UART-Driver-for-AST2500
> > updating MAINTAINERS for DMA and DMA-UART drivers of AST2500
>
> Your commit messages need some work. Use 'git log --oneline <dir>' on
> each directory for inspiration as to what the subject should be.
>
> DT bindings specifically are "dt-bindings: <binding dir>: ..."
>
> Rob
Hi Rob,
As per the comments given by vinod and Ben,
we are planning to resubmit the patches, after merging these
two drivers (dma and uart) into single driver.
While resubmitting, will ensure patches are formatted with
proper messages, following the convention.
Regards
Sudheer
^ permalink raw reply
* [PATCH net-next] net/ncsi: Add NCSI Mellanox OEM command
From: Vijay Khemka @ 2018-10-26 17:19 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181025.155335.2132843393553452471.davem@davemloft.net>
Thanks David,
Do you have any timeline when it is going to open next or how do I know.
Regards
-Vijay
?On 10/25/18, 3:54 PM, "David Miller" <davem@davemloft.net> wrote:
From: Vijay Khemka <vijaykhemka@fb.com>
Date: Thu, 25 Oct 2018 15:04:13 -0700
> This patch adds OEM Mellanox commands and response handling. It also
> defines OEM Get MAC Address handler to get and configure the device.
>
> ncsi_oem_gma_handler_mlx: This handler send NCSI mellanox command for
> getting mac address.
> ncsi_rsp_handler_oem_mlx: This handles response received for all
> mellanox OEM commands.
> ncsi_rsp_handler_oem_mlx_gma: This handles get mac address response and
> set it to device.
>
> Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
net-next is closed, please resubmit this when the net-next tree opens
back up.
Thank you.
^ permalink raw reply
* [PATCH net-next] net/ncsi: Add NCSI Mellanox OEM command
From: David Miller @ 2018-10-26 17:36 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <F0024535-93C3-4470-98A6-F57426587474@fb.com>
From: Vijay Khemka <vijaykhemka@fb.com>
Date: Fri, 26 Oct 2018 17:19:49 +0000
> Do you have any timeline when it is going to open next or how do I
> know.
I always announce net-next openning and closing here on the list.
There is also a web site:
http://vger.kernel.org/~davem/net-next.html
Thanks.
^ permalink raw reply
* [PATCH net-next] net/ncsi: Add NCSI Mellanox OEM command
From: Vijay Khemka @ 2018-10-26 22:40 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181026.103617.373827980255084988.davem@davemloft.net>
Thanks David
?On 10/26/18, 10:36 AM, "David Miller" <davem@davemloft.net> wrote:
From: Vijay Khemka <vijaykhemka@fb.com>
Date: Fri, 26 Oct 2018 17:19:49 +0000
> Do you have any timeline when it is going to open next or how do I
> know.
I always announce net-next openning and closing here on the list.
There is also a web site:
http://vger.kernel.org/~davem/net-next.html
Thanks.
^ permalink raw reply
* [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb
From: Douglas Anderson @ 2018-10-29 18:07 UTC (permalink / raw)
To: linux-aspeed
I started out this series trying to make sysrq work over the serial
console on qcom_geni_serial, then fell into a rat's nest.
To solve the deadlock I faced when enabling sysrq I tried to borrow
code from '8250_port.c' which avoided grabbing the port lock in
console_write(). ...but since these days I try to run with lockdep on
all the time, I found it caused an annoying lockdep splat (which I
also reproduced on my rk3399 board). ...so I instead changed my
qcom_geni_serial solution to borrow code from 'msm_serial.c'
I wasn't super happy with the solution in 'msm_serial.c' though. I
don't like releasing the spinlock there. Not only is it ugly but it
means we are unlocking / re-locking _all the time_ even though sysrq
characters are rare. ...so I came up with what I think is a better
solution and then implemented it for qcom_geni_serial.
Since I had a good way to test 8250-based UARTs, I also fixed that
driver to use my new method. When doing so, I ran into a missing
msm_serial.c at all, so I didn't switch that (or all other serial
drivers for that matter) to the new method.
After fixing all the above issues, I found the next lockdep splat in
kgdb and I think I've worked around it in a good-enough way, but I'm
much less confident about this. Hopefully folks can take a look at
it.
In general, patches earlier in this series should be "less
controversial" and hopefully can land even if people don't like
patches later in the series. ;-)
Looking back, this is pretty much two series squashed that could be
treated indepdently. The first is a serial series and the second is a
kgdb series.
For all serial patches I'd expect them to go through the tty tree once
they've been reviewed.
If folks are OK w/ the 'smp' patch it probably should go in some core
kernel tree. The kgdb patch won't work without it, though, so to land
that we'd need coordination between the folks landing that and the
folks landing the 'smp' patch.
Douglas Anderson (7):
serial: qcom_geni_serial: Finish supporting sysrq
serial: core: Allow processing sysrq at port unlock time
serial: qcom_geni_serial: Process sysrq at port unlock time
serial: core: Include console.h from serial_core.h
serial: 8250: Process sysrq at port unlock time
smp: Don't yell about IRQs disabled in kgdb_roundup_cpus()
kgdb: Remove irq flags and local_irq_enable/disable from roundup
arch/arc/kernel/kgdb.c | 4 +--
arch/arm/kernel/kgdb.c | 4 +--
arch/arm64/kernel/kgdb.c | 4 +--
arch/hexagon/kernel/kgdb.c | 11 ++----
arch/mips/kernel/kgdb.c | 4 +--
arch/powerpc/kernel/kgdb.c | 2 +-
arch/sh/kernel/kgdb.c | 4 +--
arch/sparc/kernel/smp_64.c | 2 +-
arch/x86/kernel/kgdb.c | 9 ++---
drivers/tty/serial/8250/8250_aspeed_vuart.c | 6 +++-
drivers/tty/serial/8250/8250_fsl.c | 6 +++-
drivers/tty/serial/8250/8250_omap.c | 6 +++-
drivers/tty/serial/8250/8250_port.c | 8 ++---
drivers/tty/serial/qcom_geni_serial.c | 10 ++++--
include/linux/kgdb.h | 9 ++---
include/linux/serial_core.h | 38 ++++++++++++++++++++-
kernel/debug/debug_core.c | 2 +-
kernel/smp.c | 4 ++-
18 files changed, 80 insertions(+), 53 deletions(-)
--
2.19.1.568.g152ad8e336-goog
^ permalink raw reply
* [PATCH 5/7] serial: 8250: Process sysrq at port unlock time
From: Douglas Anderson @ 2018-10-29 18:07 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181029180707.207546-1-dianders@chromium.org>
Let's take advantage of the new ("serial: core: Allow processing sysrq
at port unlock time") to handle sysrqs more cleanly.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
I don't have a great way to test all 8250 variants, but I've at least
tested rk3288 / rk3399 and they seem to work. Hopefully I got the
aspeed_vuart / fsl / omap variants right (I only compile tested
those).
drivers/tty/serial/8250/8250_aspeed_vuart.c | 6 +++++-
drivers/tty/serial/8250/8250_fsl.c | 6 +++++-
drivers/tty/serial/8250/8250_omap.c | 6 +++++-
drivers/tty/serial/8250/8250_port.c | 8 +++-----
4 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 435bec40dee6..0438d9a905ce 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -5,6 +5,10 @@
* Copyright (C) 2016 Jeremy Kerr <jk@ozlabs.org>, IBM Corp.
* Copyright (C) 2006 Arnd Bergmann <arnd@arndb.de>, IBM Corp.
*/
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
#include <linux/device.h>
#include <linux/module.h>
#include <linux/of_address.h>
@@ -293,7 +297,7 @@ static int aspeed_vuart_handle_irq(struct uart_port *port)
if (lsr & UART_LSR_THRE)
serial8250_tx_chars(up);
- spin_unlock_irqrestore(&port->lock, flags);
+ uart_unlock_and_check_sysrq(port, flags);
return 1;
}
diff --git a/drivers/tty/serial/8250/8250_fsl.c b/drivers/tty/serial/8250/8250_fsl.c
index 6640a4c7ddd1..ff3dcaea5d93 100644
--- a/drivers/tty/serial/8250/8250_fsl.c
+++ b/drivers/tty/serial/8250/8250_fsl.c
@@ -1,4 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
#include <linux/serial_reg.h>
#include <linux/serial_8250.h>
@@ -54,7 +58,7 @@ int fsl8250_handle_irq(struct uart_port *port)
serial8250_tx_chars(up);
up->lsr_saved_flags = orig_lsr;
- spin_unlock_irqrestore(&up->port.lock, flags);
+ uart_unlock_and_check_sysrq(&up->port, flags);
return 1;
}
EXPORT_SYMBOL_GPL(fsl8250_handle_irq);
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index a019286f8bb6..ad7ba7d0f28d 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -8,6 +8,10 @@
*
*/
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
#include <linux/device.h>
#include <linux/io.h>
#include <linux/module.h>
@@ -1085,7 +1089,7 @@ static int omap_8250_dma_handle_irq(struct uart_port *port)
}
}
- spin_unlock_irqrestore(&port->lock, flags);
+ uart_unlock_and_check_sysrq(port, flags);
serial8250_rpm_put(up);
return 1;
}
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index f776b3eafb96..c39482b96111 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1755,7 +1755,7 @@ void serial8250_read_char(struct uart_8250_port *up, unsigned char lsr)
else if (lsr & UART_LSR_FE)
flag = TTY_FRAME;
}
- if (uart_handle_sysrq_char(port, ch))
+ if (uart_prepare_sysrq_char(port, ch))
return;
uart_insert_char(port, lsr, UART_LSR_OE, ch, flag);
@@ -1897,7 +1897,7 @@ int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
if ((!up->dma || up->dma->tx_err) && (status & UART_LSR_THRE))
serial8250_tx_chars(up);
- spin_unlock_irqrestore(&port->lock, flags);
+ uart_unlock_and_check_sysrq(port, flags);
return 1;
}
EXPORT_SYMBOL_GPL(serial8250_handle_irq);
@@ -3258,9 +3258,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
serial8250_rpm_get(up);
- if (port->sysrq)
- locked = 0;
- else if (oops_in_progress)
+ if (oops_in_progress)
locked = spin_trylock_irqsave(&port->lock, flags);
else
spin_lock_irqsave(&port->lock, flags);
--
2.19.1.568.g152ad8e336-goog
^ permalink raw reply related
* [PATCH i2c-next v8 0/5] i2c: aspeed: Add bus idle waiting logic for multi-master use cases
From: Jae Hyun Yoo @ 2018-10-29 21:14 UTC (permalink / raw)
To: linux-aspeed
In multi-master environment, this driver's master cannot know
exactly when a peer master sends data to this driver's slave so a
case can be happened that this master tries to send data through
the master_xfer function but slave data from peer master is still
being processed by this driver. To prevent state corruption in the
case, this patch adds checking code if any slave operation is
ongoing and it waits up to the bus timeout duration before starting
a master_xfer operation.
To support this change, it introduces changes on i2c-core-base to
make that able to read the bus timeout and master transfer retries
count values from device tree properties.
Please review this patch set.
Thanks,
-Jae
Changes since v7:
- Simplified the bus idle waiting logic using jiffy based timer APIs.
Changes since v6:
- Changed the 'timeout-ms' property name to 'bus-timeout-ms'.
Changes since v5:
- Changed using of property reading API to device_property_read_u32.
Changes since v4:
- Moved the property reading code into i2c-base-core and changed the
property name to 'timeout-ms'. Also, added '#retries' property reading
code.
- Changed bus busy checking logic to make that check slave_state instead
of 'Transfer Mode State Machine' reg value.
Changes since v3:
- Changed the property name to 'timeout' and made it use the
default setting in i2c-core when not specified.
Changes since v2:
- Changed the property name to 'aspeed,timeout' and made it to
update the adapter's timeout configuration.
Changes since v1:
- Changed define names of timeout related.
Jae Hyun Yoo (5):
dt-bindings: i2c: Add 'bus-timeout-ms' and '#retries' properties as
common optional
i2c: core: Add support reading of 'bus-timeout-ms' and '#retries'
properties
dt-bindings: i2c: aspeed: Add 'bus-timeout-ms' property as an optional
property
i2c: aspeed: Remove hard-coded bus timeout value setting
i2c: aspeed: Add bus idle waiting logic for multi-master use cases
.../devicetree/bindings/i2c/i2c-aspeed.txt | 3 ++
Documentation/devicetree/bindings/i2c/i2c.txt | 6 +++
drivers/i2c/busses/i2c-aspeed.c | 53 +++++++++++++------
drivers/i2c/i2c-core-base.c | 12 ++++-
4 files changed, 56 insertions(+), 18 deletions(-)
--
2.19.1
^ permalink raw reply
* [PATCH i2c-next v8 1/5] dt-bindings: i2c: Add 'bus-timeout-ms' and '#retries' properties as common optional
From: Jae Hyun Yoo @ 2018-10-29 21:14 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181029211414.20771-1-jae.hyun.yoo@linux.intel.com>
This commit adds 'bus-timeout-ms' and '#retries' properties as
common optional properties that can be used for setting 'timeout'
and 'retries' values of 'struct i2c_adapter'. With this patch, the
bus timeout value and the master transfer retries count can be set
through these properties at the registration time of an adapter.
Still the values can be set by I2C_TIMEOUT and I2C_RETRIES ioctls
on cdev at runtime too.
These properties may not be supported by all drivers. However, if
a driver wants to support one of them, it should adapt the
bindings in this document.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/i2c/i2c.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
index 11263982470e..bdead91f82a4 100644
--- a/Documentation/devicetree/bindings/i2c/i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c.txt
@@ -80,6 +80,12 @@ wants to support one of the below features, it should adapt the bindings below.
Names of map programmable addresses.
It can contain any map needing another address than default one.
+- bus-timeout-ms
+ Bus timeout in milliseconds.
+
+- #retries
+ Number of retries for master transfer.
+
Binding may contain optional "interrupts" property, describing interrupts
used by the device. I2C core will assign "irq" interrupt (or the very first
interrupt if not using interrupt names) as primary interrupt for the slave.
--
2.19.1
^ permalink raw reply related
* [PATCH i2c-next v8 2/5] i2c: core: Add support reading of 'bus-timeout-ms' and '#retries' properties
From: Jae Hyun Yoo @ 2018-10-29 21:14 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181029211414.20771-1-jae.hyun.yoo@linux.intel.com>
This commit adds support for 'bus-timeout-ms' and '#retries'
properties to set 'timeout' and 'retries' values in
'struct i2c_adapter' in case an adapter node has the properties.
Still the values can be set by I2C_TIMEOUT and I2C_RETRIES ioctls
on cdev at runtime too.
These properties may not be supported by all drivers. However, if
a driver wants to support one of them, it should adapt the
bindings in the dt-bindings document.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
---
drivers/i2c/i2c-core-base.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index dc78aa7369de..abf8e78bdb82 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1214,6 +1214,7 @@ EXPORT_SYMBOL_GPL(i2c_handle_smbus_host_notify);
static int i2c_register_adapter(struct i2c_adapter *adap)
{
int res = -EINVAL;
+ u32 bus_timeout_ms = 0;
/* Can't register until after driver model init */
if (WARN_ON(!is_registered)) {
@@ -1239,8 +1240,15 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
INIT_LIST_HEAD(&adap->userspace_clients);
/* Set default timeout to 1 second if not already set */
- if (adap->timeout == 0)
- adap->timeout = HZ;
+ if (adap->timeout == 0) {
+ device_property_read_u32(&adap->dev, "bus-timeout-ms",
+ &bus_timeout_ms);
+ adap->timeout = bus_timeout_ms ?
+ msecs_to_jiffies(bus_timeout_ms) : HZ;
+ }
+
+ /* Set retries count if it has the property setting */
+ device_property_read_u32(&adap->dev, "#retries", &adap->retries);
/* register soft irqs for Host Notify */
res = i2c_setup_host_notify_irq_domain(adap);
--
2.19.1
^ permalink raw reply related
* [PATCH i2c-next v8 3/5] dt-bindings: i2c: aspeed: Add 'bus-timeout-ms' property as an optional property
From: Jae Hyun Yoo @ 2018-10-29 21:14 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181029211414.20771-1-jae.hyun.yoo@linux.intel.com>
This commit adds 'bus-timeout-ms' property as an optional property
which can be used for setting the bus timeout value of an adapter.
With this patch, the bus timeout value can be set through this
property at the probing time of this module. Still the bus timeout
value can be set by an I2C_TIMEOUT ioctl on cdev at runtime too.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
index 8fbd8633a387..ce1f07620368 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
@@ -17,6 +17,9 @@ Optional Properties:
specified
- multi-master : states that there is another master active on this bus.
+- bus-timeout-ms: bus timeout in milliseconds defaults to 1 second when not
+ specified.
+
Example:
i2c {
--
2.19.1
^ permalink raw reply related
* [PATCH i2c-next v8 4/5] i2c: aspeed: Remove hard-coded bus timeout value setting
From: Jae Hyun Yoo @ 2018-10-29 21:14 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181029211414.20771-1-jae.hyun.yoo@linux.intel.com>
This commit removes hard-coded bus timeout value setting so that
it can be set by i2c-core-base.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
---
drivers/i2c/busses/i2c-aspeed.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index 8dc9161ced38..833b6b6a4c7e 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -930,7 +930,6 @@ static int aspeed_i2c_probe_bus(struct platform_device *pdev)
init_completion(&bus->cmd_complete);
bus->adap.owner = THIS_MODULE;
bus->adap.retries = 0;
- bus->adap.timeout = 5 * HZ;
bus->adap.algo = &aspeed_i2c_algo;
bus->adap.dev.parent = &pdev->dev;
bus->adap.dev.of_node = pdev->dev.of_node;
--
2.19.1
^ permalink raw reply related
* [PATCH i2c-next v8 5/5] i2c: aspeed: Add bus idle waiting logic for multi-master use cases
From: Jae Hyun Yoo @ 2018-10-29 21:14 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181029211414.20771-1-jae.hyun.yoo@linux.intel.com>
In multi-master environment, this driver's master cannot know
exactly when a peer master sends data to this driver's slave so a
case can be happened that this master tries to send data through
the master_xfer function but slave data from peer master is still
being processed by this driver.
To prevent any state corruption in the case, this patch adds
checking code if any slave operation is ongoing and it waits up to
the bus timeout duration before starting a master_xfer operation.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
---
drivers/i2c/busses/i2c-aspeed.c | 52 +++++++++++++++++++++++----------
1 file changed, 37 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index 833b6b6a4c7e..4e92a405210b 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -12,6 +12,7 @@
#include <linux/clk.h>
#include <linux/completion.h>
+#include <linux/delay.h>
#include <linux/err.h>
#include <linux/errno.h>
#include <linux/i2c.h>
@@ -115,6 +116,9 @@
/* 0x18 : I2CD Slave Device Address Register */
#define ASPEED_I2CD_DEV_ADDR_MASK GENMASK(6, 0)
+/* Busy checking */
+#define ASPEED_I2C_BUS_BUSY_CHECK_INTERVAL_US (10 * 1000)
+
enum aspeed_i2c_master_state {
ASPEED_I2C_MASTER_INACTIVE,
ASPEED_I2C_MASTER_START,
@@ -156,6 +160,8 @@ struct aspeed_i2c_bus {
int cmd_err;
/* Protected only by i2c_lock_bus */
int master_xfer_result;
+ /* Multi-master */
+ bool multi_master;
#if IS_ENABLED(CONFIG_I2C_SLAVE)
struct i2c_client *slave;
enum aspeed_i2c_slave_state slave_state;
@@ -596,27 +602,41 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id)
return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
}
+static int aspeed_i2c_check_bus_busy(struct aspeed_i2c_bus *bus)
+{
+ unsigned long check_started;
+
+ if (bus->multi_master) {
+ might_sleep();
+ check_started = jiffies;
+ }
+
+ for (;;) {
+ if (!(readl(bus->base + ASPEED_I2C_CMD_REG) &
+ ASPEED_I2CD_BUS_BUSY_STS) &&
+ bus->slave_state == ASPEED_I2C_SLAVE_STOP)
+ return 0;
+ if (!bus->multi_master)
+ break;
+ if (time_after(jiffies, check_started + bus->adap.timeout))
+ break;
+ usleep_range((ASPEED_I2C_BUS_BUSY_CHECK_INTERVAL_US >> 2) + 1,
+ ASPEED_I2C_BUS_BUSY_CHECK_INTERVAL_US);
+ }
+
+ return aspeed_i2c_recover_bus(bus);
+}
+
static int aspeed_i2c_master_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs, int num)
{
struct aspeed_i2c_bus *bus = i2c_get_adapdata(adap);
unsigned long time_left, flags;
- int ret = 0;
- spin_lock_irqsave(&bus->lock, flags);
- bus->cmd_err = 0;
-
- /* If bus is busy, attempt recovery. We assume a single master
- * environment.
- */
- if (readl(bus->base + ASPEED_I2C_CMD_REG) & ASPEED_I2CD_BUS_BUSY_STS) {
- spin_unlock_irqrestore(&bus->lock, flags);
- ret = aspeed_i2c_recover_bus(bus);
- if (ret)
- return ret;
- spin_lock_irqsave(&bus->lock, flags);
- }
+ if (aspeed_i2c_check_bus_busy(bus))
+ return -EAGAIN;
+ spin_lock_irqsave(&bus->lock, flags);
bus->cmd_err = 0;
bus->msgs = msgs;
bus->msgs_index = 0;
@@ -827,7 +847,9 @@ static int aspeed_i2c_init(struct aspeed_i2c_bus *bus,
if (ret < 0)
return ret;
- if (!of_property_read_bool(pdev->dev.of_node, "multi-master"))
+ if (of_property_read_bool(pdev->dev.of_node, "multi-master"))
+ bus->multi_master = true;
+ else
fun_ctrl_reg |= ASPEED_I2CD_MULTI_MASTER_DIS;
/* Enable Master Mode */
--
2.19.1
^ permalink raw reply related
* [PATCH i2c-next v8 5/5] i2c: aspeed: Add bus idle waiting logic for multi-master use cases
From: kbuild test robot @ 2018-10-29 22:49 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181029211414.20771-6-jae.hyun.yoo@linux.intel.com>
Hi Jae,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on v4.19 next-20181029]
[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/Jae-Hyun-Yoo/i2c-aspeed-Add-bus-idle-waiting-logic-for-multi-master-use-cases/20181030-051719
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=xtensa
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
In file included from include/linux/ktime.h:25,
from include/linux/rcutiny.h:28,
from include/linux/rcupdate.h:209,
from include/linux/srcu.h:33,
from include/linux/notifier.h:16,
from include/linux/clk.h:17,
from drivers/i2c/busses/i2c-aspeed.c:13:
drivers/i2c/busses/i2c-aspeed.c: In function 'aspeed_i2c_master_xfer':
>> include/linux/jiffies.h:108:15: warning: 'check_started' may be used uninitialized in this function [-Wmaybe-uninitialized]
((long)((b) - (a)) < 0))
^
drivers/i2c/busses/i2c-aspeed.c:607:16: note: 'check_started' was declared here
unsigned long check_started;
^~~~~~~~~~~~~
--
In file included from include/linux/ktime.h:25,
from include/linux/rcutiny.h:28,
from include/linux/rcupdate.h:209,
from include/linux/srcu.h:33,
from include/linux/notifier.h:16,
from include/linux/clk.h:17,
from drivers/i2c//busses/i2c-aspeed.c:13:
drivers/i2c//busses/i2c-aspeed.c: In function 'aspeed_i2c_master_xfer':
>> include/linux/jiffies.h:108:15: warning: 'check_started' may be used uninitialized in this function [-Wmaybe-uninitialized]
((long)((b) - (a)) < 0))
^
drivers/i2c//busses/i2c-aspeed.c:607:16: note: 'check_started' was declared here
unsigned long check_started;
^~~~~~~~~~~~~
vim +/check_started +108 include/linux/jiffies.h
^1da177e Linus Torvalds 2005-04-16 91
^1da177e Linus Torvalds 2005-04-16 92 /*
^1da177e Linus Torvalds 2005-04-16 93 * These inlines deal with timer wrapping correctly. You are
^1da177e Linus Torvalds 2005-04-16 94 * strongly encouraged to use them
^1da177e Linus Torvalds 2005-04-16 95 * 1. Because people otherwise forget
^1da177e Linus Torvalds 2005-04-16 96 * 2. Because if the timer wrap changes in future you won't have to
^1da177e Linus Torvalds 2005-04-16 97 * alter your driver code.
^1da177e Linus Torvalds 2005-04-16 98 *
^1da177e Linus Torvalds 2005-04-16 99 * time_after(a,b) returns true if the time a is after time b.
^1da177e Linus Torvalds 2005-04-16 100 *
^1da177e Linus Torvalds 2005-04-16 101 * Do this with "<0" and ">=0" to only test the sign of the result. A
^1da177e Linus Torvalds 2005-04-16 102 * good compiler would generate better code (and a really good compiler
^1da177e Linus Torvalds 2005-04-16 103 * wouldn't care). Gcc is currently neither.
^1da177e Linus Torvalds 2005-04-16 104 */
^1da177e Linus Torvalds 2005-04-16 105 #define time_after(a,b) \
^1da177e Linus Torvalds 2005-04-16 106 (typecheck(unsigned long, a) && \
^1da177e Linus Torvalds 2005-04-16 107 typecheck(unsigned long, b) && \
5a581b36 Paul E. McKenney 2013-07-27 @108 ((long)((b) - (a)) < 0))
^1da177e Linus Torvalds 2005-04-16 109 #define time_before(a,b) time_after(b,a)
^1da177e Linus Torvalds 2005-04-16 110
:::::: The code at line 108 was first introduced by commit
:::::: 5a581b367b5df0531265311fc681c2abd377e5e6 jiffies: Avoid undefined behavior from signed overflow
:::::: TO: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
:::::: CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 55213 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20181030/29fa56c7/attachment-0001.gz>
^ permalink raw reply
* [PATCH i2c-next v8 5/5] i2c: aspeed: Add bus idle waiting logic for multi-master use cases
From: kbuild test robot @ 2018-10-30 6:36 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181029211414.20771-6-jae.hyun.yoo@linux.intel.com>
Hi Jae,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.19 next-20181029]
[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/Jae-Hyun-Yoo/i2c-aspeed-Add-bus-idle-waiting-logic-for-multi-master-use-cases/20181030-051719
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: arm-multi_v5_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/i2c//busses/i2c-aspeed.c: In function 'aspeed_i2c_check_bus_busy':
>> drivers/i2c//busses/i2c-aspeed.c:617:12: error: 'struct aspeed_i2c_bus' has no member named 'slave_state'; did you mean 'master_state'?
bus->slave_state == ASPEED_I2C_SLAVE_STOP)
^~~~~~~~~~~
master_state
vim +617 drivers/i2c//busses/i2c-aspeed.c
604
605 static int aspeed_i2c_check_bus_busy(struct aspeed_i2c_bus *bus)
606 {
607 unsigned long check_started;
608
609 if (bus->multi_master) {
610 might_sleep();
611 check_started = jiffies;
612 }
613
614 for (;;) {
615 if (!(readl(bus->base + ASPEED_I2C_CMD_REG) &
616 ASPEED_I2CD_BUS_BUSY_STS) &&
> 617 bus->slave_state == ASPEED_I2C_SLAVE_STOP)
618 return 0;
619 if (!bus->multi_master)
620 break;
621 if (time_after(jiffies, check_started + bus->adap.timeout))
622 break;
623 usleep_range((ASPEED_I2C_BUS_BUSY_CHECK_INTERVAL_US >> 2) + 1,
624 ASPEED_I2C_BUS_BUSY_CHECK_INTERVAL_US);
625 }
626
627 return aspeed_i2c_recover_bus(bus);
628 }
629
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 30010 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20181030/2e20b451/attachment-0001.gz>
^ permalink raw reply
* [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb
From: Daniel Thompson @ 2018-10-30 11:56 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181029180707.207546-1-dianders@chromium.org>
On Mon, Oct 29, 2018 at 11:07:00AM -0700, Douglas Anderson wrote:
> Looking back, this is pretty much two series squashed that could be
> treated indepdently. The first is a serial series and the second is a
> kgdb series.
Indeed.
I couldn't work out the link between the first 5 patches and the last 2
until I read this...
Is anything in the 01->05 patch set even related to kgdb? From the stack
traces it looks to me like the lock dep warning would trigger for any
sysrq. I think separating into two threads for v2 would be sensible.
Daniel.
>
> For all serial patches I'd expect them to go through the tty tree once
> they've been reviewed.
>
> If folks are OK w/ the 'smp' patch it probably should go in some core
> kernel tree. The kgdb patch won't work without it, though, so to land
> that we'd need coordination between the folks landing that and the
> folks landing the 'smp' patch.
>
>
> Douglas Anderson (7):
> serial: qcom_geni_serial: Finish supporting sysrq
> serial: core: Allow processing sysrq at port unlock time
> serial: qcom_geni_serial: Process sysrq at port unlock time
> serial: core: Include console.h from serial_core.h
> serial: 8250: Process sysrq at port unlock time
> smp: Don't yell about IRQs disabled in kgdb_roundup_cpus()
> kgdb: Remove irq flags and local_irq_enable/disable from roundup
>
> arch/arc/kernel/kgdb.c | 4 +--
> arch/arm/kernel/kgdb.c | 4 +--
> arch/arm64/kernel/kgdb.c | 4 +--
> arch/hexagon/kernel/kgdb.c | 11 ++----
> arch/mips/kernel/kgdb.c | 4 +--
> arch/powerpc/kernel/kgdb.c | 2 +-
> arch/sh/kernel/kgdb.c | 4 +--
> arch/sparc/kernel/smp_64.c | 2 +-
> arch/x86/kernel/kgdb.c | 9 ++---
> drivers/tty/serial/8250/8250_aspeed_vuart.c | 6 +++-
> drivers/tty/serial/8250/8250_fsl.c | 6 +++-
> drivers/tty/serial/8250/8250_omap.c | 6 +++-
> drivers/tty/serial/8250/8250_port.c | 8 ++---
> drivers/tty/serial/qcom_geni_serial.c | 10 ++++--
> include/linux/kgdb.h | 9 ++---
> include/linux/serial_core.h | 38 ++++++++++++++++++++-
> kernel/debug/debug_core.c | 2 +-
> kernel/smp.c | 4 ++-
> 18 files changed, 80 insertions(+), 53 deletions(-)
>
> --
> 2.19.1.568.g152ad8e336-goog
>
^ permalink raw reply
* [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb
From: Russell King - ARM Linux @ 2018-10-30 12:31 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181030115628.eqtyqdugkpkxvyr2@holly.lan>
On Tue, Oct 30, 2018 at 11:56:28AM +0000, Daniel Thompson wrote:
> On Mon, Oct 29, 2018 at 11:07:00AM -0700, Douglas Anderson wrote:
> > Looking back, this is pretty much two series squashed that could be
> > treated indepdently. The first is a serial series and the second is a
> > kgdb series.
>
> Indeed.
>
> I couldn't work out the link between the first 5 patches and the last 2
> until I read this...
>
> Is anything in the 01->05 patch set even related to kgdb? From the stack
> traces it looks to me like the lock dep warning would trigger for any
> sysrq. I think separating into two threads for v2 would be sensible.
I'm concerned about calling smp_call_function() from IRQ context with
IRQs disabled - that will block the ability of the _calling_ CPU to
process IPIs from other CPUs in the system. If we have other CPUs
waiting on their IPIs to complete on _this_ CPU, we could end up
deadlocking while trying to grab the CSD lock.
This is the intention of warnings in smp_call_function*() - to catch
cases where deadlocks _can_ occur, but do not reliably show up.
The exceptions to the warning (disregarding oops_in_progress) are
chosen to allow IRQs-disabled calls when we're sure that the rest of
the system isn't going to be sending the calling CPU an IPI (eg,
because the CPU isn't marked online, and we only send IPIs to online
CPUs, or if we're still early in the kernel boot and hence have no
other CPUs running.) The exception is oops_in_progress, which can
occur at any time - even with the current CPU already holding some
CSD locks (eg, oops while trying to send an IPI.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb
From: Andy Shevchenko @ 2018-10-30 12:36 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181029180707.207546-1-dianders@chromium.org>
On Mon, Oct 29, 2018 at 11:07:00AM -0700, Douglas Anderson wrote:
> I started out this series trying to make sysrq work over the serial
> console on qcom_geni_serial, then fell into a rat's nest.
>
> To solve the deadlock I faced when enabling sysrq I tried to borrow
> code from '8250_port.c' which avoided grabbing the port lock in
> console_write(). ...but since these days I try to run with lockdep on
> all the time, I found it caused an annoying lockdep splat (which I
> also reproduced on my rk3399 board). ...so I instead changed my
> qcom_geni_serial solution to borrow code from 'msm_serial.c'
>
> I wasn't super happy with the solution in 'msm_serial.c' though. I
> don't like releasing the spinlock there. Not only is it ugly but it
> means we are unlocking / re-locking _all the time_ even though sysrq
> characters are rare. ...so I came up with what I think is a better
> solution and then implemented it for qcom_geni_serial.
>
> Since I had a good way to test 8250-based UARTs, I also fixed that
> driver to use my new method. When doing so, I ran into a missing
> msm_serial.c at all, so I didn't switch that (or all other serial
> drivers for that matter) to the new method.
>
> After fixing all the above issues, I found the next lockdep splat in
> kgdb and I think I've worked around it in a good-enough way, but I'm
> much less confident about this. Hopefully folks can take a look at
> it.
>
> In general, patches earlier in this series should be "less
> controversial" and hopefully can land even if people don't like
> patches later in the series. ;-)
>
> Looking back, this is pretty much two series squashed that could be
> treated indepdently. The first is a serial series and the second is a
> kgdb series.
>
> For all serial patches I'd expect them to go through the tty tree once
> they've been reviewed.
>
> If folks are OK w/ the 'smp' patch it probably should go in some core
> kernel tree. The kgdb patch won't work without it, though, so to land
> that we'd need coordination between the folks landing that and the
> folks landing the 'smp' patch.
I have got only 0/7 and 5/7, everything okay with your mail client and other tools?
>
>
> Douglas Anderson (7):
> serial: qcom_geni_serial: Finish supporting sysrq
> serial: core: Allow processing sysrq at port unlock time
> serial: qcom_geni_serial: Process sysrq at port unlock time
> serial: core: Include console.h from serial_core.h
> serial: 8250: Process sysrq at port unlock time
> smp: Don't yell about IRQs disabled in kgdb_roundup_cpus()
> kgdb: Remove irq flags and local_irq_enable/disable from roundup
>
> arch/arc/kernel/kgdb.c | 4 +--
> arch/arm/kernel/kgdb.c | 4 +--
> arch/arm64/kernel/kgdb.c | 4 +--
> arch/hexagon/kernel/kgdb.c | 11 ++----
> arch/mips/kernel/kgdb.c | 4 +--
> arch/powerpc/kernel/kgdb.c | 2 +-
> arch/sh/kernel/kgdb.c | 4 +--
> arch/sparc/kernel/smp_64.c | 2 +-
> arch/x86/kernel/kgdb.c | 9 ++---
> drivers/tty/serial/8250/8250_aspeed_vuart.c | 6 +++-
> drivers/tty/serial/8250/8250_fsl.c | 6 +++-
> drivers/tty/serial/8250/8250_omap.c | 6 +++-
> drivers/tty/serial/8250/8250_port.c | 8 ++---
> drivers/tty/serial/qcom_geni_serial.c | 10 ++++--
> include/linux/kgdb.h | 9 ++---
> include/linux/serial_core.h | 38 ++++++++++++++++++++-
> kernel/debug/debug_core.c | 2 +-
> kernel/smp.c | 4 ++-
> 18 files changed, 80 insertions(+), 53 deletions(-)
>
> --
> 2.19.1.568.g152ad8e336-goog
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] usb: gadget: aspeed-vhub: constify usb_gadget_ops structure
From: Julia Lawall @ 2018-10-30 16:19 UTC (permalink / raw)
To: linux-aspeed
The usb_gadget_ops structure can be const as it is only stored in
the ops field of a usb_gadget structure and this field is const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
index f0233912bace..6b1b16b17d7d 100644
--- a/drivers/usb/gadget/udc/aspeed-vhub/dev.c
+++ b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
@@ -438,7 +438,7 @@ static int ast_vhub_udc_stop(struct usb_gadget *gadget)
return 0;
}
-static struct usb_gadget_ops ast_vhub_udc_ops = {
+static const struct usb_gadget_ops ast_vhub_udc_ops = {
.get_frame = ast_vhub_udc_get_frame,
.wakeup = ast_vhub_udc_wakeup,
.pullup = ast_vhub_udc_pullup,
^ permalink raw reply related
* [PATCH i2c-next v9 0/5] i2c: aspeed: Add bus idle waiting logic for multi-master use cases
From: Jae Hyun Yoo @ 2018-10-30 21:09 UTC (permalink / raw)
To: linux-aspeed
In multi-master environment, this driver's master cannot know
exactly when a peer master sends data to this driver's slave so a
case can be happened that this master tries to send data through
the master_xfer function but slave data from peer master is still
being processed by this driver. To prevent state corruption in the
case, this patch adds checking code if any slave operation is
ongoing and it waits up to the bus timeout duration before starting
a master_xfer operation.
To support this change, it introduces changes on i2c-core-base to
make that able to read the bus timeout and master transfer retries
count values from device tree properties.
Please review this patch set.
Thanks,
-Jae
Changes since v8:
- Fixed a build break when CONFIG_I2C_SLAVE is not set.
Changes since v7:
- Simplified the bus idle waiting logic using jiffy based timer APIs.
Changes since v6:
- Changed the 'timeout-ms' property name to 'bus-timeout-ms'.
Changes since v5:
- Changed using of property reading API to device_property_read_u32.
Changes since v4:
- Moved the property reading code into i2c-base-core and changed the
property name to 'timeout-ms'. Also, added '#retries' property reading
code.
- Changed bus busy checking logic to make that check slave_state instead
of 'Transfer Mode State Machine' reg value.
Changes since v3:
- Changed the property name to 'timeout' and made it use the
default setting in i2c-core when not specified.
Changes since v2:
- Changed the property name to 'aspeed,timeout' and made it to
update the adapter's timeout configuration.
Changes since v1:
- Changed define names of timeout related.
Jae Hyun Yoo (5):
dt-bindings: i2c: Add 'bus-timeout-ms' and '#retries' properties as
common optional
i2c: core: Add support reading of 'bus-timeout-ms' and '#retries'
properties
dt-bindings: i2c: aspeed: Add 'bus-timeout-ms' property as an optional
property
i2c: aspeed: Remove hard-coded bus timeout value setting
i2c: aspeed: Add bus idle waiting logic for multi-master use cases
.../devicetree/bindings/i2c/i2c-aspeed.txt | 3 +
Documentation/devicetree/bindings/i2c/i2c.txt | 6 ++
drivers/i2c/busses/i2c-aspeed.c | 56 +++++++++++++------
drivers/i2c/i2c-core-base.c | 12 +++-
4 files changed, 59 insertions(+), 18 deletions(-)
--
2.19.1
^ permalink raw reply
* [PATCH i2c-next v9 1/5] dt-bindings: i2c: Add 'bus-timeout-ms' and '#retries' properties as common optional
From: Jae Hyun Yoo @ 2018-10-30 21:09 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20181030210917.32711-1-jae.hyun.yoo@linux.intel.com>
This commit adds 'bus-timeout-ms' and '#retries' properties as
common optional properties that can be used for setting 'timeout'
and 'retries' values of 'struct i2c_adapter'. With this patch, the
bus timeout value and the master transfer retries count can be set
through these properties at the registration time of an adapter.
Still the values can be set by I2C_TIMEOUT and I2C_RETRIES ioctls
on cdev at runtime too.
These properties may not be supported by all drivers. However, if
a driver wants to support one of them, it should adapt the
bindings in this document.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/i2c/i2c.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
index 11263982470e..bdead91f82a4 100644
--- a/Documentation/devicetree/bindings/i2c/i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c.txt
@@ -80,6 +80,12 @@ wants to support one of the below features, it should adapt the bindings below.
Names of map programmable addresses.
It can contain any map needing another address than default one.
+- bus-timeout-ms
+ Bus timeout in milliseconds.
+
+- #retries
+ Number of retries for master transfer.
+
Binding may contain optional "interrupts" property, describing interrupts
used by the device. I2C core will assign "irq" interrupt (or the very first
interrupt if not using interrupt names) as primary interrupt for the slave.
--
2.19.1
^ permalink raw reply related
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