| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 27 Mar 2020 03:02:12 +0000
From: BOUGH CHEN <haibo.chen@....com>
To: Ulf Hansson <ulf.hansson@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Arnd Bergmann <arnd@...db.de>, Christoph Hellwig <hch@....de>,
Russell King <linux@...linux.org.uk>,
Linus Walleij <linus.walleij@...aro.org>,
Vinod Koul <vkoul@...nel.org>,
Ludovic Barre <ludovic.barre@...com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>
Subject: RE: [PATCH 0/2] amba/platform: Initialize dma_parms at the bus level
> -----Original Message-----
> From: BOUGH CHEN
> Sent: 2020年3月26日 12:41
> To: Ulf Hansson <ulf.hansson@...aro.org>; Greg Kroah-Hartman
> <gregkh@...uxfoundation.org>; Rafael J . Wysocki <rafael@...nel.org>;
> linux-kernel@...r.kernel.org
> Cc: Arnd Bergmann <arnd@...db.de>; Christoph Hellwig <hch@....de>;
> Russell King <linux@...linux.org.uk>; Linus Walleij <linus.walleij@...aro.org>;
> Vinod Koul <vkoul@...nel.org>; Ludovic Barre <ludovic.barre@...com>;
> linux-arm-kernel@...ts.infradead.org; dmaengine@...r.kernel.org
> Subject: RE: [PATCH 0/2] amba/platform: Initialize dma_parms at the bus level
>
> > -----Original Message-----
> > From: Ulf Hansson <ulf.hansson@...aro.org>
> > Sent: 2020年3月25日 19:34
> > To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>; Rafael J .
> > Wysocki <rafael@...nel.org>; linux-kernel@...r.kernel.org
> > Cc: Arnd Bergmann <arnd@...db.de>; Christoph Hellwig <hch@....de>;
> > Russell King <linux@...linux.org.uk>; Linus Walleij
> > <linus.walleij@...aro.org>; Vinod Koul <vkoul@...nel.org>; BOUGH CHEN
> > <haibo.chen@....com>; Ludovic Barre <ludovic.barre@...com>;
> > linux-arm-kernel@...ts.infradead.org; dmaengine@...r.kernel.org; Ulf
> > Hansson <ulf.hansson@...aro.org>
> > Subject: [PATCH 0/2] amba/platform: Initialize dma_parms at the bus
> > level
> >
> > It's currently the amba/platform driver's responsibility to initialize
> > the pointer, dma_parms, for its corresponding struct device. The
> > benefit with this approach allows us to avoid the initialization and
> > to not waste memory for the struct device_dma_parameters, as this can
> > be decided on a case by case basis.
> >
> > However, it has turned out that this approach is not very practical.
> > Not only does it lead to open coding, but also to real errors. In
> > principle callers of
> > dma_set_max_seg_size() doesn't check the error code, but just assumes
> > it succeeds.
> >
> > For these reasons, this series initializes the dma_parms from the
> > amba/platform bus at the device registration point. This also follows
> > the way the PCI devices are being managed, see pci_device_add().
> >
> > If it turns out that this is an acceptable solution, we probably also
> > want the changes for stable, but I am not sure if it applies without conflicts.
> >
> > The series is based on v5.6-rc7.
> >
>
> Hi Ulf,
>
> Since i.MXQM SMMU related code still not upstream yet, so I apply your
> patches on our internal Linux branch based on v5.4.24, and find it do not work
> on my side. Maybe for platform core drivers, there is a gap between v5.4.24
> and v5.6-rc7 which has the impact.
> I will try to put our SMMU related code into v5.6-rc7, then do the test again.
>
>
Hi Ulf,
On the latest Linux-next branch, the top commit 89295c59c1f063b533d071ca49d0fa0c0783ca6f (tag: next-20200326), after add your two patches, I just add the simple debug code as following in the /driver/mmc/core/queue.c, but seems still not work as our expect, logically, it should work, so can you or anyone test on other platform? This seems weird.
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 25bee3daf9e2..f091280f7ffb 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -403,6 +403,13 @@ static void mmc_setup_queue(struct mmc_queue *mq, struct mmc_card *card)
blk_queue_max_segment_size(mq->queue,
round_down(host->max_seg_size, block_size));
+ pr_err("###### the max segment size is %d\n", queue_max_segment_size(mq->queue));
+ if (host->parent->dma_parms) {
+ pr_err("######### the dma parms has value\n");
+ } else if (!(host->parent->dma_parms)) {
+ pr_err("######## the dma parms is zero!!\n");
+ }
+
dma_set_max_seg_size(mmc_dev(host), queue_max_segment_size(mq->queue));
INIT_WORK(&mq->recovery_work, mmc_mq_recovery_handler);
Here is the log I got when system run, even after your patch, the dev->dma_parms is still NULL.
[ 0.989853] mmc0: new HS400 MMC card at address 0001
[ 0.995708] sdhci-esdhc-imx 30b50000.mmc: Got CD GPIO
[ 0.999374] ###### the max segment size is 65024
[ 1.008594] ######## the dma parms is zero!!
[ 1.012875] mmcblk0: mmc0:0001 IB2932 29.2 GiB
[ 1.017569] ###### the max segment size is 65024
[ 1.022195] ######## the dma parms is zero!!
[ 1.026479] mmcblk0boot0: mmc0:0001 IB2932 partition 1 4.00 MiB
[ 1.032541] ###### the max segment size is 65024
[ 1.035198] mmc1: SDHCI controller on 30b50000.mmc [30b50000.mmc] using ADMA
[ 1.037169] ######## the dma parms is zero!!
[ 1.048493] mmcblk0boot1: mmc0:0001 IB2932 partition 2 4.00 MiB
[ 1.054531] mmcblk0rpmb: mmc0:0001 IB2932 partition 3 4.00 MiB, chardev (234:0)
Regards
Haibo Chen
> Best Regards
> Haibo Chen
>
> > Kind regards
> > Ulf Hansson
> >
> > Ulf Hansson (2):
> > driver core: platform: Initialize dma_parms for platform devices
> > amba: Initialize dma_parms for amba devices
> >
> > drivers/amba/bus.c | 2 ++
> > drivers/base/platform.c | 1 +
> > include/linux/amba/bus.h | 1 +
> > include/linux/platform_device.h | 1 +
> > 4 files changed, 5 insertions(+)
> >
> > --
> > 2.20.1
Powered by blists - more mailing lists