* Re: [RFC PATCH v3 6/6] of: Add plumbing for restricted DMA pool
From: Florian Fainelli @ 2021-01-12 23:48 UTC (permalink / raw)
To: Claire Chang, robh+dt, mpe, benh, paulus, joro, will,
frowand.list, konrad.wilk, boris.ostrovsky, jgross, sstabellini,
hch, m.szyprowski, robin.murphy
Cc: drinkcat, devicetree, heikki.krogerus, saravanak, peterz,
xypron.glpk, rafael.j.wysocki, linux-kernel, andriy.shevchenko,
tfiga, bgolaszewski, iommu, grant.likely, rdunlap, gregkh,
xen-devel, dan.j.williams, treding, linuxppc-dev, mingo, bauerman
In-Reply-To: <20210106034124.30560-7-tientzu@chromium.org>
On 1/5/21 7:41 PM, Claire Chang wrote:
> If a device is not behind an IOMMU, we look up the device node and set
> up the restricted DMA when the restricted-dma-pool is presented.
>
> Signed-off-by: Claire Chang <tientzu@chromium.org>
> ---
[snip]
> +int of_dma_set_restricted_buffer(struct device *dev)
> +{
> + struct device_node *node;
> + int count, i;
> +
> + if (!dev->of_node)
> + return 0;
> +
> + count = of_property_count_elems_of_size(dev->of_node, "memory-region",
> + sizeof(phandle));
You could have an early check for count < 0, along with an error
message, if that is deemed useful.
> + for (i = 0; i < count; i++) {
> + node = of_parse_phandle(dev->of_node, "memory-region", i);
> + if (of_device_is_compatible(node, "restricted-dma-pool"))
And you may want to add here an of_device_is_available(node). A platform
that provides the Device Tree firmware and try to support multiple
different SoCs may try to determine if an IOMMU is present, and if it
is, it could be marking the restriced-dma-pool region with a 'status =
"disabled"' property, or any variant of that scheme.
> + return of_reserved_mem_device_init_by_idx(
> + dev, dev->of_node, i);
This does not seem to be supporting more than one memory region, did not
you want something like instead:
ret = of_reserved_mem_device_init_by_idx(...);
if (ret)
return ret;
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index aedfaaafd3e7..e2c7409956ab 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -182,6 +182,10 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
> arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
>
> dev->dma_range_map = map;
> +
> + if (!iommu)
> + return of_dma_set_restricted_buffer(dev);
> +
> return 0;
> }
> EXPORT_SYMBOL_GPL(of_dma_configure_id);
> diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
> index d9e6a324de0a..28a2dfa197ba 100644
> --- a/drivers/of/of_private.h
> +++ b/drivers/of/of_private.h
> @@ -161,12 +161,17 @@ struct bus_dma_region;
> #if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_HAS_DMA)
> int of_dma_get_range(struct device_node *np,
> const struct bus_dma_region **map);
> +int of_dma_set_restricted_buffer(struct device *dev);
> #else
> static inline int of_dma_get_range(struct device_node *np,
> const struct bus_dma_region **map)
> {
> return -ENODEV;
> }
> +static inline int of_dma_get_restricted_buffer(struct device *dev)
> +{
> + return -ENODEV;
> +}
> #endif
>
> #endif /* _LINUX_OF_PRIVATE_H */
>
--
Florian
^ permalink raw reply
* Re: [RFC PATCH v3 4/6] swiotlb: Add restricted DMA alloc/free support.
From: Florian Fainelli @ 2021-01-12 23:41 UTC (permalink / raw)
To: Claire Chang, robh+dt, mpe, benh, paulus, joro, will,
frowand.list, konrad.wilk, boris.ostrovsky, jgross, sstabellini,
hch, m.szyprowski, robin.murphy
Cc: drinkcat, devicetree, heikki.krogerus, saravanak, peterz,
xypron.glpk, rafael.j.wysocki, linux-kernel, andriy.shevchenko,
tfiga, bgolaszewski, iommu, grant.likely, rdunlap, gregkh,
xen-devel, dan.j.williams, treding, linuxppc-dev, mingo, bauerman
In-Reply-To: <20210106034124.30560-5-tientzu@chromium.org>
On 1/5/21 7:41 PM, Claire Chang wrote:
> Add the functions, swiotlb_alloc and swiotlb_free to support the
> memory allocation from restricted DMA pool.
>
> Signed-off-by: Claire Chang <tientzu@chromium.org>
> ---
[snip]
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 30ccbc08e229..126e9b3354d6 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -137,6 +137,11 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> void *ret;
> int err;
>
> +#ifdef CONFIG_SWIOTLB
> + if (unlikely(dev->dma_io_tlb_mem))
> + return swiotlb_alloc(dev, size, dma_handle, attrs);
> +#endif
While this is potentially a hot path, I am not sure of the unkikely is
warranted, maybe best left as a plain conditional.
--
Florian
^ permalink raw reply
* Re: [RFC PATCH v3 3/6] swiotlb: Use restricted DMA pool if available
From: Florian Fainelli @ 2021-01-12 23:39 UTC (permalink / raw)
To: Claire Chang, robh+dt, mpe, benh, paulus, joro, will,
frowand.list, konrad.wilk, boris.ostrovsky, jgross, sstabellini,
hch, m.szyprowski, robin.murphy
Cc: drinkcat, devicetree, heikki.krogerus, saravanak, peterz,
xypron.glpk, rafael.j.wysocki, linux-kernel, andriy.shevchenko,
tfiga, bgolaszewski, iommu, grant.likely, rdunlap, gregkh,
xen-devel, dan.j.williams, treding, linuxppc-dev, mingo, bauerman
In-Reply-To: <20210106034124.30560-4-tientzu@chromium.org>
On 1/5/21 7:41 PM, Claire Chang wrote:
> Regardless of swiotlb setting, the restricted DMA pool is preferred if
> available.
>
> The restricted DMA pools provide a basic level of protection against
> the DMA overwriting buffer contents at unexpected times. However, to
> protect against general data leakage and system memory corruption, the
> system needs to provide a way to restrict the DMA to a predefined memory
> region.
>
> Signed-off-by: Claire Chang <tientzu@chromium.org>
You could probably split this patch into two:
- one that introduces the get_io_tlb_mem() getter, updates all callers
of is_swiotlb_buffer() to gain a 'struct device' argument
- another one that does add support for a non-default swiotlb pool and
adds dev->dma_io_tlb_mem
Other than that, LGTM!
--
Florian
^ permalink raw reply
* Re: [PATCH v4 18/21] ibmvfc: send Cancel MAD down each hw scsi channel
From: Brian King @ 2021-01-12 21:46 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, martin.petersen, linux-kernel
In-Reply-To: <20210111231225.105347-19-tyreld@linux.ibm.com>
On 1/11/21 5:12 PM, Tyrel Datwyler wrote:
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
> index b0b0212344f3..24e1278acfeb 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
> @@ -2418,18 +2418,79 @@ static struct ibmvfc_event *ibmvfc_init_tmf(struct ibmvfc_queue *queue,
> return evt;
> }
>
> -/**
> - * ibmvfc_cancel_all - Cancel all outstanding commands to the device
> - * @sdev: scsi device to cancel commands
> - * @type: type of error recovery being performed
> - *
> - * This sends a cancel to the VIOS for the specified device. This does
> - * NOT send any abort to the actual device. That must be done separately.
> - *
> - * Returns:
> - * 0 on success / other on failure
> - **/
> -static int ibmvfc_cancel_all(struct scsi_device *sdev, int type)
> +static int ibmvfc_cancel_all_mq(struct scsi_device *sdev, int type)
> +{
> + struct ibmvfc_host *vhost = shost_priv(sdev->host);
> + struct ibmvfc_event *evt, *found_evt, *temp;
> + struct ibmvfc_queue *queues = vhost->scsi_scrqs.scrqs;
> + unsigned long flags;
> + int num_hwq, i;
> + LIST_HEAD(cancelq);
> + u16 status;
> +
> + ENTER;
> + spin_lock_irqsave(vhost->host->host_lock, flags);
> + num_hwq = vhost->scsi_scrqs.active_queues;
> + for (i = 0; i < num_hwq; i++) {
> + spin_lock(queues[i].q_lock);
> + spin_lock(&queues[i].l_lock);
> + found_evt = NULL;
> + list_for_each_entry(evt, &queues[i].sent, queue_list) {
> + if (evt->cmnd && evt->cmnd->device == sdev) {
> + found_evt = evt;
> + break;
> + }
> + }
> + spin_unlock(&queues[i].l_lock);
> +
I really don't like the way the first for loop grabs all the q_locks, and then
there is a second for loop that drops all these locks... I think this code would
be cleaner if it looked like:
if (found_evt && vhost->logged_in) {
evt = ibmvfc_init_tmf(&queues[i], sdev, type);
evt->sync_iu = &queues[i].cancel_rsp;
ibmvfc_send_event(evt, vhost, default_timeout);
list_add_tail(&evt->cancel, &cancelq);
}
spin_unlock(queues[i].q_lock);
}
> + if (!found_evt)
> + continue;
> +
> + if (vhost->logged_in) {
> + evt = ibmvfc_init_tmf(&queues[i], sdev, type);
> + evt->sync_iu = &queues[i].cancel_rsp;
> + ibmvfc_send_event(evt, vhost, default_timeout);
> + list_add_tail(&evt->cancel, &cancelq);
> + }
> + }
> +
> + for (i = 0; i < num_hwq; i++)
> + spin_unlock(queues[i].q_lock);
> + spin_unlock_irqrestore(vhost->host->host_lock, flags);
> +
> + if (list_empty(&cancelq)) {
> + if (vhost->log_level > IBMVFC_DEFAULT_LOG_LEVEL)
> + sdev_printk(KERN_INFO, sdev, "No events found to cancel\n");
> + return 0;
> + }
> +
> + sdev_printk(KERN_INFO, sdev, "Cancelling outstanding commands.\n");
> +
> + list_for_each_entry_safe(evt, temp, &cancelq, cancel) {
> + wait_for_completion(&evt->comp);
> + status = be16_to_cpu(evt->queue->cancel_rsp.mad_common.status);
You probably want a list_del(&evt->cancel) here.
> + ibmvfc_free_event(evt);
> +
> + if (status != IBMVFC_MAD_SUCCESS) {
> + sdev_printk(KERN_WARNING, sdev, "Cancel failed with rc=%x\n", status);
> + switch (status) {
> + case IBMVFC_MAD_DRIVER_FAILED:
> + case IBMVFC_MAD_CRQ_ERROR:
> + /* Host adapter most likely going through reset, return success to
> + * the caller will wait for the command being cancelled to get returned
> + */
> + break;
> + default:
> + break;
I think this default break needs to be a return -EIO.
> + }
> + }
> + }
> +
> + sdev_printk(KERN_INFO, sdev, "Successfully cancelled outstanding commands\n");
> + return 0;
> +}
> +
> +static int ibmvfc_cancel_all_sq(struct scsi_device *sdev, int type)
> {
> struct ibmvfc_host *vhost = shost_priv(sdev->host);
> struct ibmvfc_event *evt, *found_evt;
> @@ -2498,6 +2559,27 @@ static int ibmvfc_cancel_all(struct scsi_device *sdev, int type)
> return 0;
> }
>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v4 01/21] ibmvfc: add vhost fields and defaults for MQ enablement
From: Brian King @ 2021-01-12 22:54 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: martin.petersen, linux-scsi, james.smart, linux-kernel, brking,
linuxppc-dev
In-Reply-To: <20210111231225.105347-2-tyreld@linux.ibm.com>
On 1/11/21 5:12 PM, Tyrel Datwyler wrote:
> Introduce several new vhost fields for managing MQ state of the adapter
> as well as initial defaults for MQ enablement.
>
> Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
> ---
> drivers/scsi/ibmvscsi/ibmvfc.c | 8 ++++++++
> drivers/scsi/ibmvscsi/ibmvfc.h | 9 +++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
> index ba95438a8912..9200fe49c57e 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
> @@ -3302,6 +3302,7 @@ static struct scsi_host_template driver_template = {
> .max_sectors = IBMVFC_MAX_SECTORS,
> .shost_attrs = ibmvfc_attrs,
> .track_queue_depth = 1,
> + .host_tagset = 1,
This doesn't seem right. You are setting host_tagset, which means you want a
shared, host wide, tag set for commands. It also means that the total
queue depth for the host is can_queue. However, it looks like you are allocating
max_requests events for each sub crq, which means you are over allocating memory.
Looking at this closer, we might have bigger problems. There is a host wide
max number of commands that the VFC host supports, which gets returned on
NPIV Login. This value can change across a live migration event.
The ibmvfc driver, which does the same thing the lpfc driver does, modifies
can_queue on the scsi_host *after* the tag set has been allocated. This looks
to be a concern with ibmvfc, not sure about lpfc, as it doesn't look like
we look at can_queue once the tag set is setup, and I'm not seeing a good way
to dynamically change the host queue depth once the tag set is setup.
Unless I'm missing something, our best options appear to either be to implement
our own host wide busy reference counting, which doesn't sound very good, or
we need to add some API to block / scsi that allows us to dynamically change
can_queue.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
From: Mark Brown @ 2021-01-12 20:44 UTC (permalink / raw)
To: Nathan Chancellor
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, Shengjiu Wang, tiwai,
perex, nicoleotsuka, festevam, linux-kernel
In-Reply-To: <20210112190921.GA3561911@ubuntu-m3-large-x86>
[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]
On Tue, Jan 12, 2021 at 12:09:21PM -0700, Nathan Chancellor wrote:
> On Tue, Jan 12, 2021 at 06:48:48PM +0000, Mark Brown wrote:
> > This is a random warning fix, why would you expect it to be sent as a
> > bug fix? This is the first indication I've seen that anyone is seeing
> > it in mainline, in general the people who report and fix warnings are
> > doing so based on -next and the patch seems to be from a month ago. I
> > don't have this in my inbox so I assume it's applied already or needs to
> > be resubmitted anyway.
> Well, I consider compiler warnings bugs. I have had plenty of my
> compiler warning patches sent as bug fixes for an -rc. Furthermore, this
> patch was sent three times by different people, that should give you some
> indication that people are tripping over it.
I really don't have that good a recall of what warning fixes people are
sending, I might notice if I get two versions of the same thing that I
look at at roughly the same time but even with a few hours between it's
most likely that I'll have completely forgotten. Warning fixes are in
general not memorable, it's not a good sign if they are. The default
assumption for any warning fix that doesn't say anything else is going
to be that either the issue or the toolchain is very new.
For any kind of fix if you think that things are in some way urgent you
should say something promptly (or provide some indication of this in the
submission if you're sending the fix yourself, such as with a fixes
tag). If nobody says anything then you should assume that nobody else
is going to be aware of any urgency and that this will affect handling.
Should it happen that things aren't flagged up then of course do so but
consider that this may well be the first time people will be aware
there's any urgency, don't assume that people will have been operating
with information they didn't have.
> The first version was sent on December 11th, it looks like your pull for
> 5.11 went on the December 14th, then the second version was applied on
> December 16th so I figured it might be destined for 5.11 but I could not
> tell (your for-next branch is a merge of your for-5.11 and for-5.12):
If it's on the for-5.11 branch then it will be for 5.11, which it must
be if it was applied then. If it was and it was applied that long ago
it'll already be queued in Takashi's tree and I guess he didn't send it
on yet.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
From: Nathan Chancellor @ 2021-01-12 19:09 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, Shengjiu Wang, tiwai,
perex, nicoleotsuka, festevam, linux-kernel
In-Reply-To: <20210112184848.GG4646@sirena.org.uk>
On Tue, Jan 12, 2021 at 06:48:48PM +0000, Mark Brown wrote:
> This is a random warning fix, why would you expect it to be sent as a
> bug fix? This is the first indication I've seen that anyone is seeing
> it in mainline, in general the people who report and fix warnings are
> doing so based on -next and the patch seems to be from a month ago. I
> don't have this in my inbox so I assume it's applied already or needs to
> be resubmitted anyway.
Well, I consider compiler warnings bugs. I have had plenty of my
compiler warning patches sent as bug fixes for an -rc. Furthermore, this
patch was sent three times by different people, that should give you some
indication that people are tripping over it.
https://lore.kernel.org/alsa-devel/X9NGQaF4pmK8oUAF@mwanda/
https://lore.kernel.org/alsa-devel/1608115464-18710-1-git-send-email-shengjiu.wang@nxp.com/
https://lore.kernel.org/alsa-devel/20201230154443.656997-1-arnd@kernel.org/
The first version was sent on December 11th, it looks like your pull for
5.11 went on the December 14th, then the second version was applied on
December 16th so I figured it might be destined for 5.11 but I could not
tell (your for-next branch is a merge of your for-5.11 and for-5.12):
https://lore.kernel.org/alsa-devel/160813397775.31838.8934909997692637790.b4-ty@kernel.org/
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
From: Mark Brown @ 2021-01-12 18:48 UTC (permalink / raw)
To: Nathan Chancellor
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, Shengjiu Wang, tiwai,
perex, nicoleotsuka, festevam, linux-kernel
In-Reply-To: <20210112181949.GA3241630@ubuntu-m3-large-x86>
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
On Tue, Jan 12, 2021 at 11:19:49AM -0700, Nathan Chancellor wrote:
Please delete unneeded context from mails when replying. Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.
> >
> > Signed-off-by: shengjiu wang <shengjiu.wang@nxp.com>
> > Reported-by: kernel test robot <lkp@intel.com>
> > ---
> I still see a warning in v5.11-rc3 that is fixed by this patch, is it
> not going in this release cycle? It is a regression fix, seems like it
> should.
This is a random warning fix, why would you expect it to be sent as a
bug fix? This is the first indication I've seen that anyone is seeing
it in mainline, in general the people who report and fix warnings are
doing so based on -next and the patch seems to be from a month ago. I
don't have this in my inbox so I assume it's applied already or needs to
be resubmitted anyway.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] tty: serial: cpm_uart: Add udbg support for enabling xmon
From: Christophe Leroy @ 2021-01-12 18:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <e4471bf81089252470efb3eed735d71a5b32adbd.1608716197.git.christophe.leroy@csgroup.eu>
Le 23/12/2020 à 10:38, Christophe Leroy a écrit :
> In order to use xmon with powerpc 8xx, the serial driver
> must provide udbg_putc() and udpb_getc().
>
> Provide them via cpm_put_poll_char() and cpm_get_poll_char().
>
> This requires CONFIG_CONSOLE_POLL.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
This patch has been merged in tty-next, it is visible in linux-next
Christophe
> ---
> drivers/tty/serial/cpm_uart/cpm_uart_core.c | 40 ++++++++++++++++++++-
> 1 file changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> index ba14ec5b9bc4..2920b9b602b3 100644
> --- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
> @@ -1145,6 +1145,32 @@ static void cpm_put_poll_char(struct uart_port *port,
> ch[0] = (char)c;
> cpm_uart_early_write(pinfo, ch, 1, false);
> }
> +
> +static struct uart_port *udbg_port;
> +
> +static void udbg_cpm_putc(char c)
> +{
> + if (c == '\n')
> + cpm_put_poll_char(udbg_port, '\r');
> + cpm_put_poll_char(udbg_port, c);
> +}
> +
> +static int udbg_cpm_getc_poll(void)
> +{
> + int c = cpm_get_poll_char(udbg_port);
> +
> + return c == NO_POLL_CHAR ? -1 : c;
> +}
> +
> +static int udbg_cpm_getc(void)
> +{
> + int c;
> +
> + while ((c = udbg_cpm_getc_poll()) == -1)
> + cpu_relax();
> + return c;
> +}
> +
> #endif /* CONFIG_CONSOLE_POLL */
>
> static const struct uart_ops cpm_uart_pops = {
> @@ -1251,7 +1277,10 @@ static int cpm_uart_init_port(struct device_node *np,
> pinfo->gpios[i] = NULL;
>
> #ifdef CONFIG_PPC_EARLY_DEBUG_CPM
> - udbg_putc = NULL;
> +#ifdef CONFIG_CONSOLE_POLL
> + if (!udbg_port)
> +#endif
> + udbg_putc = NULL;
> #endif
>
> return cpm_uart_request_port(&pinfo->port);
> @@ -1370,6 +1399,15 @@ static int __init cpm_uart_console_setup(struct console *co, char *options)
> uart_set_options(port, co, baud, parity, bits, flow);
> cpm_line_cr_cmd(pinfo, CPM_CR_RESTART_TX);
>
> +#ifdef CONFIG_CONSOLE_POLL
> + if (!udbg_port) {
> + udbg_port = &pinfo->port;
> + udbg_putc = udbg_cpm_putc;
> + udbg_getc = udbg_cpm_getc;
> + udbg_getc_poll = udbg_cpm_getc_poll;
> + }
> +#endif
> +
> return 0;
> }
>
>
^ permalink raw reply
* Re: [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
From: Nathan Chancellor @ 2021-01-12 18:19 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, perex,
nicoleotsuka, broonie, festevam, linux-kernel
In-Reply-To: <1608115464-18710-1-git-send-email-shengjiu.wang@nxp.com>
On Wed, Dec 16, 2020 at 06:44:24PM +0800, Shengjiu Wang wrote:
> From: shengjiu wang <shengjiu.wang@nxp.com>
>
> When condition ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in))
> is true, then goto fail, the uninitialized variable ret will be
> returned.
>
> Signed-off-by: shengjiu wang <shengjiu.wang@nxp.com>
> Reported-by: kernel test robot <lkp@intel.com>
> ---
> sound/soc/fsl/imx-hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
> index 2c2a76a71940..ede4a9ad1054 100644
> --- a/sound/soc/fsl/imx-hdmi.c
> +++ b/sound/soc/fsl/imx-hdmi.c
> @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
>
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> dev_err(&pdev->dev, "Invalid HDMI DAI link\n");
> + ret = -EINVAL;
> goto fail;
> }
>
> --
> 2.17.1
>
I still see a warning in v5.11-rc3 that is fixed by this patch, is it
not going in this release cycle? It is a regression fix, seems like it
should.
Cheers,
Nathan
^ permalink raw reply
* Re: [RFC PATCH v3 0/6] Restricted DMA
From: Florian Fainelli @ 2021-01-12 18:01 UTC (permalink / raw)
To: Claire Chang
Cc: heikki.krogerus, peterz, grant.likely, paulus, Frank Rowand,
mingo, Marek Szyprowski, sstabellini, Saravana Kannan,
Joerg Roedel, rafael.j.wysocki, Christoph Hellwig,
Bartosz Golaszewski, xen-devel, Thierry Reding, linux-devicetree,
will, Konrad Rzeszutek Wilk, dan.j.williams, linuxppc-dev,
Rob Herring, boris.ostrovsky, Andy Shevchenko, jgross,
Nicolas Boichat, Greg KH, rdunlap, lkml, Tomasz Figa,
list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
Robin Murphy, bauerman
In-Reply-To: <CALiNf29_PmLJTVLksSHp3NFAaL52idqehSMOtatJ=jaM2Muq1g@mail.gmail.com>
On 1/11/21 11:48 PM, Claire Chang wrote:
> On Fri, Jan 8, 2021 at 1:59 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> On 1/7/21 9:42 AM, Claire Chang wrote:
>>
>>>> Can you explain how ATF gets involved and to what extent it does help,
>>>> besides enforcing a secure region from the ARM CPU's perpsective? Does
>>>> the PCIe root complex not have an IOMMU but can somehow be denied access
>>>> to a region that is marked NS=0 in the ARM CPU's MMU? If so, that is
>>>> still some sort of basic protection that the HW enforces, right?
>>>
>>> We need the ATF support for memory MPU (memory protection unit).
>>> Restricted DMA (with reserved-memory in dts) makes sure the predefined memory
>>> region is for PCIe DMA only, but we still need MPU to locks down PCIe access to
>>> that specific regions.
>>
>> OK so you do have a protection unit of some sort to enforce which region
>> in DRAM the PCIE bridge is allowed to access, that makes sense,
>> otherwise the restricted DMA region would only be a hint but nothing you
>> can really enforce. This is almost entirely analogous to our systems then.
>
> Here is the example of setting the MPU:
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132
>
>>
>> There may be some value in standardizing on an ARM SMCCC call then since
>> you already support two different SoC vendors.
>>
>>>
>>>>
>>>> On Broadcom STB SoCs we have had something similar for a while however
>>>> and while we don't have an IOMMU for the PCIe bridge, we do have a a
>>>> basic protection mechanism whereby we can configure a region in DRAM to
>>>> be PCIe read/write and CPU read/write which then gets used as the PCIe
>>>> inbound region for the PCIe EP. By default the PCIe bridge is not
>>>> allowed access to DRAM so we must call into a security agent to allow
>>>> the PCIe bridge to access the designated DRAM region.
>>>>
>>>> We have done this using a private CMA area region assigned via Device
>>>> Tree, assigned with a and requiring the PCIe EP driver to use
>>>> dma_alloc_from_contiguous() in order to allocate from this device
>>>> private CMA area. The only drawback with that approach is that it
>>>> requires knowing how much memory you need up front for buffers and DMA
>>>> descriptors that the PCIe EP will need to process. The problem is that
>>>> it requires driver modifications and that does not scale over the number
>>>> of PCIe EP drivers, some we absolutely do not control, but there is no
>>>> need to bounce buffer. Your approach scales better across PCIe EP
>>>> drivers however it does require bounce buffering which could be a
>>>> performance hit.
>>>
>>> Only the streaming DMA (map/unmap) needs bounce buffering.
>>
>> True, and typically only on transmit since you don't really control
>> where the sk_buff are allocated from, right? On RX since you need to
>> hand buffer addresses to the WLAN chip prior to DMA, you can allocate
>> them from a pool that already falls within the restricted DMA region, right?
>>
>
> Right, but applying bounce buffering to RX will make it more secure.
> The device won't be able to modify the content after unmap. Just like what
> iommu_unmap does.
Sure, however the goals of using bounce buffering equally applies to RX
and TX in that this is the only layer sitting between a stack (block,
networking, USB, etc.) and the underlying device driver that scales well
in order to massage a dma_addr_t to be within a particular physical range.
There is however room for improvement if the drivers are willing to
change their buffer allocation strategy. When you receive Wi-Fi frames
you need to allocate buffers for the Wi-Fi device to DMA into, and that
happens ahead of the DMA transfers by the Wi-Fi device. At buffer
allocation time you could very well allocate these frames from the
restricted DMA region without having to bounce buffer them since the
host CPU is in control over where and when to DMA into.
The issue is that each network driver may implement its own buffer
allocation strategy, some may simply call netdev_alloc_skb() which gives
zero control over where the buffer comes from unless you play tricks
with NUMA node allocations and somehow declare that your restricted DMA
region is a different NUMA node. If the driver allocates pages and then
attaches a SKB to that page using build_skb(), then you have much more
control over where that page comes from, and this is where using a
device private CMA are helps, because you can just do
dma_alloc_from_contiguous() and that will ensure that the pages are
coming from your specific CMA area.
Few questions on the implementation:
- is there any warning or error being printed if the restricted DMA
region is outside of a device's DMA addressable range?
- are there are any helpful statistics that could be shown to indicate
that the restricted DMA region was sized too small, e.g.: that
allocation of a DMA buffer failed because we ran out of space in the
swiotlb pool?
>
>>> I also added alloc/free support in this series
>>> (https://lore.kernel.org/patchwork/patch/1360995/), so dma_direct_alloc() will
>>> try to allocate memory from the predefined memory region.
>>>
>>> As for the performance hit, it should be similar to the default swiotlb.
>>> Here are my experiment results. Both SoCs lack IOMMU for PCIe.
>>>
>>> PCIe wifi vht80 throughput -
>>>
>>> MTK SoC tcp_tx tcp_rx udp_tx udp_rx
>>> w/o Restricted DMA 244.1 134.66 312.56 350.79
>>> w/ Restricted DMA 246.95 136.59 363.21 351.99
>>>
>>> Rockchip SoC tcp_tx tcp_rx udp_tx udp_rx
>>> w/o Restricted DMA 237.87 133.86 288.28 361.88
>>> w/ Restricted DMA 256.01 130.95 292.28 353.19
>>
>> How come you get better throughput with restricted DMA? Is it because
>> doing DMA to/from a contiguous region allows for better grouping of
>> transactions from the DRAM controller's perspective somehow?
>
> I'm not sure, but actually, enabling the default swiotlb for wifi also helps the
> throughput a little bit for me.
OK, it would be interesting if you could get to the bottom of why
performance does increase with swiotlb.
--
Florian
^ permalink raw reply
* [patch 4/4] powerpc/mm/highmem: Use __set_pte_at() for kmap_local()
From: Thomas Gleixner @ 2021-01-12 17:01 UTC (permalink / raw)
To: LKML
Cc: Thomas Bogendoerfer, Andreas Larsson, Peter Zijlstra,
Paul Cercueil, linux-mm, sparclinux, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20210112170136.078559026@linutronix.de>
The original PowerPC highmem mapping function used __set_pte_at() to denote
that the mapping is per CPU. This got lost with the conversion to the
generic implementation.
Override the default map function.
Fixes: 47da42b27a56 ("powerpc/mm/highmem: Switch to generic kmap atomic")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/highmem.h | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/powerpc/include/asm/highmem.h
+++ b/arch/powerpc/include/asm/highmem.h
@@ -58,6 +58,8 @@ extern pte_t *pkmap_page_table;
#define flush_cache_kmaps() flush_cache_all()
+#define arch_kmap_local_set_pte(mm, vaddr, ptep, ptev) \
+ __set_pte_at(mm, vaddr, ptep, ptev, 1)
#define arch_kmap_local_post_map(vaddr, pteval) \
local_flush_tlb_page(NULL, vaddr)
#define arch_kmap_local_post_unmap(vaddr) \
^ permalink raw reply
* [patch 0/4] mm/highmem: Fix fallout from generic kmap_local conversions
From: Thomas Gleixner @ 2021-01-12 17:01 UTC (permalink / raw)
To: LKML
Cc: Thomas Bogendoerfer, Andreas Larsson, Peter Zijlstra,
Paul Cercueil, linux-mm, sparclinux, Andrew Morton, linuxppc-dev,
David S. Miller
The kmap_local conversion wreckaged sparc, mips and powerpc as it missed
some of the details in the original implementation.
The following series addresses that.
Thanks,
tglx
---
arch/mips/include/asm/highmem.h | 1 +
arch/sparc/include/asm/highmem.h | 9 +++++----
b/arch/powerpc/include/asm/highmem.h | 2 ++
mm/highmem.c | 7 ++++++-
4 files changed, 14 insertions(+), 5 deletions(-)
^ permalink raw reply
* [patch 3/4] mips/mm/highmem: Use set_pte() for kmap_local()
From: Thomas Gleixner @ 2021-01-12 17:01 UTC (permalink / raw)
To: LKML
Cc: Thomas Bogendoerfer, Andreas Larsson, Peter Zijlstra,
Paul Cercueil, linux-mm, sparclinux, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20210112170136.078559026@linutronix.de>
set_pte_at() on MIPS invokes update_cache() which might recurse into
kmap_local(). Use set_pte() like the original MIPS highmem implementation
did.
Fixes: a4c33e83bca1 ("mips/mm/highmem: Switch to generic kmap atomic")
Reported-by: Paul Cercueil <paul@crapouillou.net>
Reported-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/mips/include/asm/highmem.h | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/include/asm/highmem.h
+++ b/arch/mips/include/asm/highmem.h
@@ -51,6 +51,7 @@ extern void kmap_flush_tlb(unsigned long
#define flush_cache_kmaps() BUG_ON(cpu_has_dc_aliases)
+#define arch_kmap_local_set_pte(mm, vaddr, ptep, ptev) set_pte(ptep, ptev)
#define arch_kmap_local_post_map(vaddr, pteval) local_flush_tlb_one(vaddr)
#define arch_kmap_local_post_unmap(vaddr) local_flush_tlb_one(vaddr)
^ permalink raw reply
* [patch 1/4] sparc/mm/highmem: Flush cache and TLB
From: Thomas Gleixner @ 2021-01-12 17:01 UTC (permalink / raw)
To: LKML
Cc: Thomas Bogendoerfer, Andreas Larsson, Peter Zijlstra,
Paul Cercueil, linux-mm, sparclinux, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20210112170136.078559026@linutronix.de>
The recent conversion to the generic kmap_local infrastructure failed to
assign the proper pre/post map/unmap flush operations for sparc.
Sparc requires cache flush before map/unmap and tlb flush afterwards.
Fixes: 3293efa97807 ("sparc/mm/highmem: Switch to generic kmap atomic")
Reported-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
---
arch/sparc/include/asm/highmem.h | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/arch/sparc/include/asm/highmem.h
+++ b/arch/sparc/include/asm/highmem.h
@@ -50,10 +50,11 @@ extern pte_t *pkmap_page_table;
#define flush_cache_kmaps() flush_cache_all()
-/* FIXME: Use __flush_tlb_one(vaddr) instead of flush_cache_all() -- Anton */
-#define arch_kmap_local_post_map(vaddr, pteval) flush_cache_all()
-#define arch_kmap_local_post_unmap(vaddr) flush_cache_all()
-
+/* FIXME: Use __flush_*_one(vaddr) instead of flush_*_all() -- Anton */
+#define arch_kmap_local_pre_map(vaddr, pteval) flush_cache_all()
+#define arch_kmap_local_pre_unmap(vaddr) flush_cache_all()
+#define arch_kmap_local_post_map(vaddr, pteval) flush_tlb_all()
+#define arch_kmap_local_post_unmap(vaddr) flush_tlb_all()
#endif /* __KERNEL__ */
^ permalink raw reply
* [patch 2/4] mm/highmem: Prepare for overriding set_pte_at()
From: Thomas Gleixner @ 2021-01-12 17:01 UTC (permalink / raw)
To: LKML
Cc: Thomas Bogendoerfer, Andreas Larsson, Peter Zijlstra,
Paul Cercueil, linux-mm, sparclinux, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20210112170136.078559026@linutronix.de>
The generic kmap_local() map function uses set_pte_at(), but MIPS requires
set_pte() and PowerPC wants __set_pte_at().
Provide arch_kmap_local_set_pte() and default it to set_pte_at().
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
mm/highmem.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -473,6 +473,11 @@ static inline void *arch_kmap_local_high
}
#endif
+#ifndef arch_kmap_local_set_pte
+#define arch_kmap_local_set_pte(mm, vaddr, ptep, ptev) \
+ set_pte_at(mm, vaddr, ptep, ptev)
+#endif
+
/* Unmap a local mapping which was obtained by kmap_high_get() */
static inline bool kmap_high_unmap_local(unsigned long vaddr)
{
@@ -515,7 +520,7 @@ void *__kmap_local_pfn_prot(unsigned lon
vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
BUG_ON(!pte_none(*(kmap_pte - idx)));
pteval = pfn_pte(pfn, prot);
- set_pte_at(&init_mm, vaddr, kmap_pte - idx, pteval);
+ arch_kmap_local_set_pte(&init_mm, vaddr, kmap_pte - idx, pteval);
arch_kmap_local_post_map(vaddr, pteval);
current->kmap_ctrl.pteval[kmap_local_idx()] = pteval;
preempt_enable();
^ permalink raw reply
* Re: [PATCH v2] arch: consolidate pm_power_off callback
From: Will Deacon @ 2021-01-12 14:05 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: dalias, linux-ia64, linux-sh, linux-mips, James.Bottomley,
jcmvbkbc, paulus, linux-csky, hpa, linux-riscv, tglx, jonas,
linux-s390, sstabellini, linux-c6x-dev, ysato, linux-hexagon,
deller, x86, ley.foon.tan, mingo, geert, catalin.marinas,
linux-snps-arc, linux-xtensa, linux-pm, msalter,
jacquiot.aurelien, linux-m68k, openrisc, bp, shorne,
stefan.kristiansson, christian, chris, tsbogend, linux-parisc,
linux-kernel, linux-alpha, linuxppc-dev
In-Reply-To: <20201227140129.19932-1-info@metux.net>
On Sun, Dec 27, 2020 at 03:01:28PM +0100, Enrico Weigelt, metux IT consult wrote:
> Move the pm_power_off callback into one global place and also add an
> function for conditionally calling it (when not NULL), in order to remove
> code duplication in all individual archs.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
[...]
> diff --git a/kernel/reboot.c b/kernel/reboot.c
> index eb1b15850761..ec4cd66dd1ae 100644
> --- a/kernel/reboot.c
> +++ b/kernel/reboot.c
> @@ -53,6 +53,16 @@ int reboot_force;
> void (*pm_power_off_prepare)(void);
> EXPORT_SYMBOL_GPL(pm_power_off_prepare);
>
> +void (*pm_power_off)(void);
> +EXPORT_SYMBOL_GPL(pm_power_off);
> +
> +void do_power_off(void)
> +{
> + if (pm_power_off)
> + pm_power_off();
> +}
> +EXPORT_SYMBOL_GPL(do_power_off);
Could this just live as a static inline in pm.h to avoid having to export
the extra symbol?
Will
^ permalink raw reply
* [PATCH AUTOSEL 4.4 6/8] net: ethernet: fs_enet: Add missing MODULE_LICENSE
From: Sasha Levin @ 2021-01-12 12:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Andrew Lunn, netdev, linuxppc-dev, David S . Miller
In-Reply-To: <20210112125823.71463-1-sashal@kernel.org>
From: Michael Ellerman <mpe@ellerman.id.au>
[ Upstream commit 445c6198fe7be03b7d38e66fe8d4b3187bc251d4 ]
Since commit 1d6cd3929360 ("modpost: turn missing MODULE_LICENSE()
into error") the ppc32_allmodconfig build fails with:
ERROR: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/freescale/fs_enet/mii-fec.o
ERROR: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/freescale/fs_enet/mii-bitbang.o
Add the missing MODULE_LICENSEs to fix the build. Both files include a
copyright header indicating they are GPL v2.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c | 1 +
drivers/net/ethernet/freescale/fs_enet/mii-fec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
index 68a428de0bc0e..cfae74d8e6590 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
@@ -231,3 +231,4 @@ static struct platform_driver fs_enet_bb_mdio_driver = {
};
module_platform_driver(fs_enet_bb_mdio_driver);
+MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-fec.c b/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
index 2be383e6d2585..3b6232a6a56d6 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
@@ -232,3 +232,4 @@ static struct platform_driver fs_enet_fec_mdio_driver = {
};
module_platform_driver(fs_enet_fec_mdio_driver);
+MODULE_LICENSE("GPL");
--
2.27.0
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 2/8] ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram
From: Sasha Levin @ 2021-01-12 12:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Jakub Kicinski, netdev, linuxppc-dev,
Rasmus Villemoes
In-Reply-To: <20210112125823.71463-1-sashal@kernel.org>
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
[ Upstream commit 887078de2a23689e29d6fa1b75d7cbc544c280be ]
Table 8-53 in the QUICC Engine Reference manual shows definitions of
fields up to a size of 192 bytes, not just 128. But in table 8-111,
one does find the text
Base Address of the Global Transmitter Parameter RAM Page. [...]
The user needs to allocate 128 bytes for this page. The address must
be aligned to the page size.
I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual;
they both have this inconsistency (and the table numbers are the
same).
Adding a bit of debug printing, on my board the struct
ucc_geth_tx_global_pram is allocated at offset 0x880, while
the (opaque) ucc_geth_thread_data_tx gets allocated immediately
afterwards, at 0x900. So whatever the engine writes into the thread
data overlaps with the tail of the global tx pram (and devmem says
that something does get written during a simple ping).
I haven't observed any failure that could be attributed to this, but
it seems to be the kind of thing that would be extremely hard to
debug. So extend the struct definition so that we do allocate 192
bytes.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/freescale/ucc_geth.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
index 75f337163ce3c..1a40a5f11081b 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -580,7 +580,14 @@ struct ucc_geth_tx_global_pram {
u32 vtagtable[0x8]; /* 8 4-byte VLAN tags */
u32 tqptr; /* a base pointer to the Tx Queues Memory
Region */
- u8 res2[0x80 - 0x74];
+ u8 res2[0x78 - 0x74];
+ u64 snums_en;
+ u32 l2l3baseptr; /* top byte consists of a few other bit fields */
+
+ u16 mtu[8];
+ u8 res3[0xa8 - 0x94];
+ u32 wrrtablebase; /* top byte is reserved */
+ u8 res4[0xc0 - 0xac];
} __packed;
/* structure representing Extended Filtering Global Parameters in PRAM */
--
2.27.0
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 6/8] net: ethernet: fs_enet: Add missing MODULE_LICENSE
From: Sasha Levin @ 2021-01-12 12:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Andrew Lunn, netdev, linuxppc-dev, David S . Miller
In-Reply-To: <20210112125810.71348-1-sashal@kernel.org>
From: Michael Ellerman <mpe@ellerman.id.au>
[ Upstream commit 445c6198fe7be03b7d38e66fe8d4b3187bc251d4 ]
Since commit 1d6cd3929360 ("modpost: turn missing MODULE_LICENSE()
into error") the ppc32_allmodconfig build fails with:
ERROR: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/freescale/fs_enet/mii-fec.o
ERROR: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/freescale/fs_enet/mii-bitbang.o
Add the missing MODULE_LICENSEs to fix the build. Both files include a
copyright header indicating they are GPL v2.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c | 1 +
drivers/net/ethernet/freescale/fs_enet/mii-fec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
index 1f015edcca227..3c6fc61597f7e 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
@@ -223,3 +223,4 @@ static struct platform_driver fs_enet_bb_mdio_driver = {
};
module_platform_driver(fs_enet_bb_mdio_driver);
+MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-fec.c b/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
index a89267b94352a..fb2b0586469b2 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
@@ -224,3 +224,4 @@ static struct platform_driver fs_enet_fec_mdio_driver = {
};
module_platform_driver(fs_enet_fec_mdio_driver);
+MODULE_LICENSE("GPL");
--
2.27.0
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 2/8] ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram
From: Sasha Levin @ 2021-01-12 12:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Jakub Kicinski, netdev, linuxppc-dev,
Rasmus Villemoes
In-Reply-To: <20210112125810.71348-1-sashal@kernel.org>
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
[ Upstream commit 887078de2a23689e29d6fa1b75d7cbc544c280be ]
Table 8-53 in the QUICC Engine Reference manual shows definitions of
fields up to a size of 192 bytes, not just 128. But in table 8-111,
one does find the text
Base Address of the Global Transmitter Parameter RAM Page. [...]
The user needs to allocate 128 bytes for this page. The address must
be aligned to the page size.
I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual;
they both have this inconsistency (and the table numbers are the
same).
Adding a bit of debug printing, on my board the struct
ucc_geth_tx_global_pram is allocated at offset 0x880, while
the (opaque) ucc_geth_thread_data_tx gets allocated immediately
afterwards, at 0x900. So whatever the engine writes into the thread
data overlaps with the tail of the global tx pram (and devmem says
that something does get written during a simple ping).
I haven't observed any failure that could be attributed to this, but
it seems to be the kind of thing that would be extremely hard to
debug. So extend the struct definition so that we do allocate 192
bytes.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/freescale/ucc_geth.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
index 5da19b440a6a8..bf25e49d4fe34 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -580,7 +580,14 @@ struct ucc_geth_tx_global_pram {
u32 vtagtable[0x8]; /* 8 4-byte VLAN tags */
u32 tqptr; /* a base pointer to the Tx Queues Memory
Region */
- u8 res2[0x80 - 0x74];
+ u8 res2[0x78 - 0x74];
+ u64 snums_en;
+ u32 l2l3baseptr; /* top byte consists of a few other bit fields */
+
+ u16 mtu[8];
+ u8 res3[0xa8 - 0x94];
+ u32 wrrtablebase; /* top byte is reserved */
+ u8 res4[0xc0 - 0xac];
} __packed;
/* structure representing Extended Filtering Global Parameters in PRAM */
--
2.27.0
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 11/13] net: ethernet: fs_enet: Add missing MODULE_LICENSE
From: Sasha Levin @ 2021-01-12 12:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Andrew Lunn, netdev, linuxppc-dev, David S . Miller
In-Reply-To: <20210112125749.71193-1-sashal@kernel.org>
From: Michael Ellerman <mpe@ellerman.id.au>
[ Upstream commit 445c6198fe7be03b7d38e66fe8d4b3187bc251d4 ]
Since commit 1d6cd3929360 ("modpost: turn missing MODULE_LICENSE()
into error") the ppc32_allmodconfig build fails with:
ERROR: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/freescale/fs_enet/mii-fec.o
ERROR: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/freescale/fs_enet/mii-bitbang.o
Add the missing MODULE_LICENSEs to fix the build. Both files include a
copyright header indicating they are GPL v2.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c | 1 +
drivers/net/ethernet/freescale/fs_enet/mii-fec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
index c8e5d889bd81f..21de56345503f 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
@@ -223,3 +223,4 @@ static struct platform_driver fs_enet_bb_mdio_driver = {
};
module_platform_driver(fs_enet_bb_mdio_driver);
+MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-fec.c b/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
index 1582d82483eca..4e6a9c5d8af55 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
@@ -224,3 +224,4 @@ static struct platform_driver fs_enet_fec_mdio_driver = {
};
module_platform_driver(fs_enet_fec_mdio_driver);
+MODULE_LICENSE("GPL");
--
2.27.0
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 05/13] ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram
From: Sasha Levin @ 2021-01-12 12:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Jakub Kicinski, netdev, linuxppc-dev,
Rasmus Villemoes
In-Reply-To: <20210112125749.71193-1-sashal@kernel.org>
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
[ Upstream commit 887078de2a23689e29d6fa1b75d7cbc544c280be ]
Table 8-53 in the QUICC Engine Reference manual shows definitions of
fields up to a size of 192 bytes, not just 128. But in table 8-111,
one does find the text
Base Address of the Global Transmitter Parameter RAM Page. [...]
The user needs to allocate 128 bytes for this page. The address must
be aligned to the page size.
I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual;
they both have this inconsistency (and the table numbers are the
same).
Adding a bit of debug printing, on my board the struct
ucc_geth_tx_global_pram is allocated at offset 0x880, while
the (opaque) ucc_geth_thread_data_tx gets allocated immediately
afterwards, at 0x900. So whatever the engine writes into the thread
data overlaps with the tail of the global tx pram (and devmem says
that something does get written during a simple ping).
I haven't observed any failure that could be attributed to this, but
it seems to be the kind of thing that would be extremely hard to
debug. So extend the struct definition so that we do allocate 192
bytes.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/freescale/ucc_geth.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
index 5da19b440a6a8..bf25e49d4fe34 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -580,7 +580,14 @@ struct ucc_geth_tx_global_pram {
u32 vtagtable[0x8]; /* 8 4-byte VLAN tags */
u32 tqptr; /* a base pointer to the Tx Queues Memory
Region */
- u8 res2[0x80 - 0x74];
+ u8 res2[0x78 - 0x74];
+ u64 snums_en;
+ u32 l2l3baseptr; /* top byte consists of a few other bit fields */
+
+ u16 mtu[8];
+ u8 res3[0xa8 - 0x94];
+ u32 wrrtablebase; /* top byte is reserved */
+ u8 res4[0xc0 - 0xac];
} __packed;
/* structure representing Extended Filtering Global Parameters in PRAM */
--
2.27.0
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 13/16] net: ethernet: fs_enet: Add missing MODULE_LICENSE
From: Sasha Levin @ 2021-01-12 12:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Andrew Lunn, netdev, linuxppc-dev, David S . Miller
In-Reply-To: <20210112125725.71014-1-sashal@kernel.org>
From: Michael Ellerman <mpe@ellerman.id.au>
[ Upstream commit 445c6198fe7be03b7d38e66fe8d4b3187bc251d4 ]
Since commit 1d6cd3929360 ("modpost: turn missing MODULE_LICENSE()
into error") the ppc32_allmodconfig build fails with:
ERROR: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/freescale/fs_enet/mii-fec.o
ERROR: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/freescale/fs_enet/mii-bitbang.o
Add the missing MODULE_LICENSEs to fix the build. Both files include a
copyright header indicating they are GPL v2.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c | 1 +
drivers/net/ethernet/freescale/fs_enet/mii-fec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
index c8e5d889bd81f..21de56345503f 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
@@ -223,3 +223,4 @@ static struct platform_driver fs_enet_bb_mdio_driver = {
};
module_platform_driver(fs_enet_bb_mdio_driver);
+MODULE_LICENSE("GPL");
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-fec.c b/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
index 1582d82483eca..4e6a9c5d8af55 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
@@ -224,3 +224,4 @@ static struct platform_driver fs_enet_fec_mdio_driver = {
};
module_platform_driver(fs_enet_fec_mdio_driver);
+MODULE_LICENSE("GPL");
--
2.27.0
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 05/16] ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram
From: Sasha Levin @ 2021-01-12 12:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Jakub Kicinski, netdev, linuxppc-dev,
Rasmus Villemoes
In-Reply-To: <20210112125725.71014-1-sashal@kernel.org>
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
[ Upstream commit 887078de2a23689e29d6fa1b75d7cbc544c280be ]
Table 8-53 in the QUICC Engine Reference manual shows definitions of
fields up to a size of 192 bytes, not just 128. But in table 8-111,
one does find the text
Base Address of the Global Transmitter Parameter RAM Page. [...]
The user needs to allocate 128 bytes for this page. The address must
be aligned to the page size.
I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual;
they both have this inconsistency (and the table numbers are the
same).
Adding a bit of debug printing, on my board the struct
ucc_geth_tx_global_pram is allocated at offset 0x880, while
the (opaque) ucc_geth_thread_data_tx gets allocated immediately
afterwards, at 0x900. So whatever the engine writes into the thread
data overlaps with the tail of the global tx pram (and devmem says
that something does get written during a simple ping).
I haven't observed any failure that could be attributed to this, but
it seems to be the kind of thing that would be extremely hard to
debug. So extend the struct definition so that we do allocate 192
bytes.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/freescale/ucc_geth.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
index 5da19b440a6a8..bf25e49d4fe34 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -580,7 +580,14 @@ struct ucc_geth_tx_global_pram {
u32 vtagtable[0x8]; /* 8 4-byte VLAN tags */
u32 tqptr; /* a base pointer to the Tx Queues Memory
Region */
- u8 res2[0x80 - 0x74];
+ u8 res2[0x78 - 0x74];
+ u64 snums_en;
+ u32 l2l3baseptr; /* top byte consists of a few other bit fields */
+
+ u16 mtu[8];
+ u8 res3[0xa8 - 0x94];
+ u32 wrrtablebase; /* top byte is reserved */
+ u8 res4[0xc0 - 0xac];
} __packed;
/* structure representing Extended Filtering Global Parameters in PRAM */
--
2.27.0
^ 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