* [PATCH v2 4/7] nvme_fc: add dev_loss_tmo to controller
From: Christoph Hellwig @ 2017-10-05 8:00 UTC (permalink / raw)
In-Reply-To: <20170927045046.22238-5-jsmart2021@gmail.com>
Can you please add the dev_loss_tmo to the generic nvme_ctrl and build
the infrastructure in common code?
Then as a next step we can look into inferring it from the remote port
for FC.
^ permalink raw reply
* Linux kernel 4.13.5 released
From: Linux Kernel Distribution System @ 2017-10-05 8:00 UTC (permalink / raw)
To: linux-kernel-announce
Linux kernel version 4.13.5 is now available:
Full source: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.13.5.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.13.5.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.13.5.tar.sign
You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/linux-stable/ds/v4.13.5/v4.13.4
^ permalink raw reply
* Re: SD card reader problems on Cherry-Trail
From: Carlo Caione @ 2017-10-05 7:59 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Adrian Hunter
In-Reply-To: <CAPDyKFpoHGKGhDyYRTdWMPTxOM0GLNDQjMTDThX5mvFDyVTwnw@mail.gmail.com>
On Thu, Oct 5, 2017 at 9:52 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> + Adrian
/cut
>> - With high speed SDHC cards I get a weird behavior where apparently
>> there is no problem but it's impossible to format the card. mkfs.ext4
>> gets stuck at:
>>
>> Discarding device blocks: 4096/3778299
Just discovered that this is just reeeeeally slow, not stuck. Still
something is fishy about this.
/cut
> Looping in Adrian, as he maintains sdhci.
>
> I guess some more useful information would also be about what commit
> you are running and whether this is a regression or not.
Yeah, some more info:
- Reproduced with the latest master on linus repo (4.14.0-rc3)
- No idea if this is a regression or not. This is a new hardware we
are trying to enable and I have never seen it working fine (I should
blindly try some old kernel)
- Windows is working fine so not an HW issue
- CPU is x5-Z8350
Thanks,
--
Carlo Caione | +39.340.80.30.096 | Endless
^ permalink raw reply
* Re: [PATCH] isdn/gigaset: Convert timers to use timer_setup()
From: Paul Bolle @ 2017-10-05 7:58 UTC (permalink / raw)
To: Kees Cook
Cc: Karsten Keil, David S. Miller, Johan Hovold, gigaset307x-common,
netdev, Thomas Gleixner, linux-kernel
In-Reply-To: <20171005005212.GA23556@beast>
Hi Kees,
On Wed, 2017-10-04 at 17:52 -0700, Kees Cook wrote:
> Also uses kzmalloc to replace open-coded field assignments to NULL and zero.
If I'm allowed to whine (chances that I'm allowed to do that are not so great
as Dave tends to apply gigaset patches before I even have a chance to look at
them properly!): I'd prefer it if that was done separately in a preceding
patch. Would that bother you?
Thanks,
Paul Bolle
^ permalink raw reply
* Re: [PATCH] x86/alternatives: Fix alt_max_short macro to really be a max()
From: Mathias Krause @ 2017-10-05 7:58 UTC (permalink / raw)
To: Borislav Petkov
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Borislav Petkov,
x86-ml, linux-kernel@vger.kernel.org, Michael Matz
In-Reply-To: <20171005073809.depam2y4vw2mb5ya@pd.tnic>
On 5 October 2017 at 09:38, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Oct 04, 2017 at 08:08:12PM +0200, Mathias Krause wrote:
>> The alt_max_short() macro in asm/alternative.h does not work as
>> intended, leading to nasty bugs. E.g. alt_max_short("1", "3")
>> evaluates to 3, but alt_max_short("3", "1") evaluates to 1 -- not
>> exactly the maximum of 1 and 3.
>>
>> In fact, I had to learn it the hard way by crashing my kernel in not
>> so funny ways by attempting to make use of the ALTENATIVE_2 macro
>> with alternatives where the first one was larger than the second
>> one.
>>
>> According to [1] and commit dbe4058a6a44 ("x86/alternatives: Fix
>> ALTERNATIVE_2 padding generation properly") the right handed side
>> should read "-(-(a < b))" not "-(-(a - b))". Fix that, to make the
>> macro work as intended.
>>
>> While at it, fix up the comment regarding the additional "-", too.
>> It's not about gas' usage of s32 but brain dead logic of having a
>> "true" value of -1 for the < operator ... *sigh*
>>
>> Btw., the one in asm/alternative-asm.h is correct. And, apparently,
>> all current users of ALTERNATIVE_2() pass same sized alternatives,
>> avoiding to hit the bug.
>>
>> [1] http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax
>>
>> Fixes: dbe4058a6a44 ("x86/alternatives: Fix ALTERNATIVE_2 padding generation properly")
>> Signed-off-by: Mathias Krause <minipli@googlemail.com>
>> Cc: Borislav Petkov <bp@suse.de>
>> ---
>> arch/x86/include/asm/alternative.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
>> index c096624137ae..7c553f48f163 100644
>> --- a/arch/x86/include/asm/alternative.h
>> +++ b/arch/x86/include/asm/alternative.h
>> @@ -106,9 +106,9 @@ static inline int alternatives_text_reserved(void *start, void *end)
>> * max without conditionals. Idea adapted from:
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You did read this part, right?
Yes. But it's just wrong the way it is right now. It's a crap number
generator instead of being a "max without conditionals".
> AFAIR, gas can't stomach conditionals but I don't remember the details
> anymore.
Can't be as arch/x86/include/asm/alternative.h itself makes use of
them for the implementation of ALTERNATIVE[_2], see, e.g. __OLDINSTR()
and OLDINSTR_2().
> Could be that -1 representation of "true". Let me add Micha to
> CC.
>
> Anyway, how can I reproduce your observation? Code snippet and compiler
> pls.
Here you go:
$ cat alt_max.c
#ifdef VANILLA
# define alt_max_short(a, b) \
"((" a ") ^ (((" a ") ^ (" b ")) & -(-((" a ") - (" b ")))))"
#else
# define alt_max_short(a, b) \
"((" a ") ^ (((" a ") ^ (" b ")) & -(-((" a ") < (" b ")))))"
#endif
#define ams(a, b) \
"ams_" #a "_" #b " = " alt_max_short(#a, #b) "\n\t"
asm(ams(1, 3)
ams(3, 1)
ams(1, 6));
$ gcc -DVANILLA -c alt_max.c && nm alt_max.o
0000000000000003 a ams_1_3
0000000000000002 a ams_1_6
0000000000000001 a ams_3_1
$ gcc -c alt_max.c && nm alt_max.o
0000000000000003 a ams_1_3
0000000000000006 a ams_1_6
0000000000000003 a ams_3_1
Note not only how it gets the max(3,1) case wrong but generates even
more insane crap for max(1,6).
$ as --version | head -1
GNU assembler (GNU Binutils for Debian) 2.25
Cheers,
Mathias
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH] mm, arch: remove empty_bad_page*
From: Ingo Molnar @ 2017-10-05 7:58 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, LKML, Michal Hocko, David Howells, Jeff Dike,
linux-mips, linux-sh, Ralf Baechle, Richard Weinberger,
Rich Felker, uclinux-h8-devel, Yoshinori Sato
In-Reply-To: <20171004150045.30755-1-mhocko@kernel.org>
* Michal Hocko <mhocko@kernel.org> wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> empty_bad_page and empty_bad_pte_table seems to be a relict from old
> days which is not used by any code for a long time. I have tried to find
> when exactly but this is not really all that straightforward due to many
> code movements - traces disappear around 2.4 times.
>
> Anyway no code really references neither empty_bad_page nor
> empty_bad_pte_table. We only allocate the storage which is not used by
> anybody so remove them.
>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Rich Felker <dalias@libc.org>
> Cc: Jeff Dike <jdike@addtoit.com>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: <uclinux-h8-devel@lists.sourceforge.jp>
> Cc: <linux-mips@linux-mips.org>
> Cc: <linux-sh@vger.kernel.org>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
For the x86 bits:
Acked-by: Ingo Molnar <mingo@kernel.org>
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] mm, arch: remove empty_bad_page*
From: Ingo Molnar @ 2017-10-05 7:58 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, LKML, Michal Hocko, David Howells, Jeff Dike,
linux-mips, linux-sh, Ralf Baechle, Richard Weinberger,
Rich Felker, uclinux-h8-devel, Yoshinori Sato
In-Reply-To: <20171004150045.30755-1-mhocko@kernel.org>
* Michal Hocko <mhocko@kernel.org> wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> empty_bad_page and empty_bad_pte_table seems to be a relict from old
> days which is not used by any code for a long time. I have tried to find
> when exactly but this is not really all that straightforward due to many
> code movements - traces disappear around 2.4 times.
>
> Anyway no code really references neither empty_bad_page nor
> empty_bad_pte_table. We only allocate the storage which is not used by
> anybody so remove them.
>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Rich Felker <dalias@libc.org>
> Cc: Jeff Dike <jdike@addtoit.com>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: <uclinux-h8-devel@lists.sourceforge.jp>
> Cc: <linux-mips@linux-mips.org>
> Cc: <linux-sh@vger.kernel.org>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
For the x86 bits:
Acked-by: Ingo Molnar <mingo@kernel.org>
Thanks,
Ingo
^ permalink raw reply
* [PATCH v2 2/7] nvme_fc: change ctlr state assignments during reset/reconnect
From: Christoph Hellwig @ 2017-10-05 7:57 UTC (permalink / raw)
In-Reply-To: <20170927045046.22238-3-jsmart2021@gmail.com>
> changed = nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_LIVE);
> - WARN_ON_ONCE(!changed);
>
> ctrl->ctrl.nr_reconnects = 0;
>
> - nvme_start_ctrl(&ctrl->ctrl);
> + if (changed)
> + nvme_start_ctrl(&ctrl->ctrl);
It's just cosmetic, but can you folow the RDMA pattern here:
changed = nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_LIVE);
if (!changed) {
/* state change failure is ok if we're in DELETING state */
WARN_ON_ONCE(ctrl->ctrl.state != NVME_CTRL_DELETING);
return;
}
else the patch looks fine:
Reviewed-by: Christoph Hellwig <hch at lst.de>
^ permalink raw reply
* ✓ Fi.CI.IGT: success for igt/kms_rotation_crc: Add horizontal flip subtest.
From: Patchwork @ 2017-10-05 7:57 UTC (permalink / raw)
To: Anusha Srivatsa; +Cc: intel-gfx
In-Reply-To: <1507164223-22598-1-git-send-email-anusha.srivatsa@intel.com>
== Series Details ==
Series: igt/kms_rotation_crc: Add horizontal flip subtest.
URL : https://patchwork.freedesktop.org/series/31407/
State : success
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_300/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [BUGFIX PATCH] kprobes/x86: Remove IRQ disabling from jprobe handlers
From: Ingo Molnar @ 2017-10-05 7:57 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: mingo, x86, Steven Rostedt, linux-kernel, Peter Zijlstra,
Ananth N Mavinakayanahalli, Thomas Gleixner, H . Peter Anvin,
Paul E . McKenney, Alexei Starovoitov, Alexei Starovoitov,
Linus Torvalds
In-Reply-To: <20171004230804.9427341c928923a196c2a2b5@kernel.org>
* Masami Hiramatsu <mhiramat@kernel.org> wrote:
> On Wed, 4 Oct 2017 12:41:01 +0200
> Ingo Molnar <mingo@kernel.org> wrote:
>
> >
> > * Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > > Hmm, actually we can not disable jprobe, that has no separate Kconfig.
> > > So we need to introduce new kconfig for that.
> > >
> > > And, there are several network protocols using jprobe to trace events.
> > > (e.g. NET_DCCPPROBE and NET_TCPPROBE)
> > > I think they need to migrate to trace-event at first.
> > >
> > > So, how about below idea?
> > >
> > > 1. Introduce CONFIG_JPROBE_API which only separate jprobe general parts
> > > (no arch dependent code involves) and make it default n.
> > > 2. Mark break_handler and jprobe APIs deprecated so that no new user comes up.
> > > 3. migrate in-kernel jprobe user to trace-event or ftrace.
> > > (may take some time)
> >
> > So my suggestion would be to just return from register_jprobe() and don't register
> > anything.
>
> with CONFIG_JPROBE_API=n, is that right?
No, unconditionally off with a WARN_ON_ONCE() warning in the registry function and
the deactivation of all in-kernel uses (such as self-tests).
The point is to make people that _truly_ rely on it complain - not just make them
silently turn on a Kconfig option ...
> > Yes, there are usecases of jprobes in the kernel, but they all look
> > pretty ancient and unused.
>
> Hmm, in that case, should we also remove those users? If we disable such way
> those features are just useless.
My hypothesis is that those features are not used (hence useless), but we should
first test whether there's any reliance before we remove code.
Thanks,
Ingo
^ permalink raw reply
* [U-Boot] [PATCH 1/3] armv8: fsl-layerscape: SPL size reduction
From: Sumit Garg @ 2017-10-05 7:55 UTC (permalink / raw)
To: u-boot
In-Reply-To: <VI1PR04MB20787C4B7C13A3E92E9FEEF19A730@VI1PR04MB2078.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: York Sun
> Sent: Thursday, October 05, 2017 12:12 AM
> To: Sumit Garg <sumit.garg@nxp.com>; u-boot at lists.denx.de
> Cc: Ruchika Gupta <ruchika.gupta@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; Ashish Kumar <ashish.kumar@nxp.com>
> Subject: Re: [PATCH 1/3] armv8: fsl-layerscape: SPL size reduction
>
> On 10/03/2017 03:51 AM, Sumit Garg wrote:
> >> -----Original Message-----
> >> From: York Sun
> >> Sent: Friday, September 15, 2017 2:08 AM
> >> To: Sumit Garg <sumit.garg@nxp.com>; u-boot at lists.denx.de
> >> Cc: Ruchika Gupta <ruchika.gupta@nxp.com>; Prabhakar Kushwaha
> >> <prabhakar.kushwaha@nxp.com>
> >> Subject: Re: [PATCH 1/3] armv8: fsl-layerscape: SPL size reduction
> >>
> >> On 08/29/2017 12:01 AM, Sumit Garg wrote:
> >>> Using changes in this patch we were able to reduce approx 4k size of
> >>> u-boot-spl.bin image. Following is breif description of changes to
> >>> reduce SPL size:
> >>> 1. Compile-off mp.c and libfdt.c in case of SPL build.
> >>> 2. Keep MMU and DCACHE specific variable and functions under
> >>> CONFIG_SYS_DCACHE_OFF macro.
> >>> 3. Compile-off IFC specific funtion call "init_early_memctl_regs"
> >>> in case of SPL build.
> >>>
> >>> Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
> >>> ---
> >>>
> >>> Dependent on ls1088 base SD boot target. Also dependent on ls1088
> >>> QPSI secure boot target.
> >>
> >> I don't agree D-cache should be off for SPL boot. Please find other
> >> way to reduce SPL image size.
> >>
> >> York
> >
> > Sure, let me use GCC 6.2 to reduce SPL image size in upstream rather
> > than compiling-off D-cache code.
> >
> > But I still don't see ls1088ardb sd boot support in upstream.
> >
> > Ashish,
> >
> > By when can I expect ls1088ardb sd boot support in upstream?
> >
>
> Sumit,
>
> SD boot is not completed. I don't see RCW in the final image. Pending Ashish's
> investigation.
>
> York
I will wait for SD boot patches to be accepted in upstream. As reducing SPL size
for ls1088ardb in upstream does only makes sense once we have base platform
support merged in upstream.
Sumit
^ permalink raw reply
* Re: [PATCH net-next 01/10] net/smc: add missing dev_put
From: Ursula Braun @ 2017-10-05 7:54 UTC (permalink / raw)
To: Parav Pandit
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, linux-s390@vger.kernel.org,
jwi@linux.vnet.ibm.com, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, raspl@linux.vnet.ibm.com
In-Reply-To: <VI1PR0502MB30089D06B9C95D682E21511BD17D0@VI1PR0502MB3008.eurprd05.prod.outlook.com>
On 10/02/2017 10:36 PM, Parav Pandit wrote:
> Hi Ursula, Dave, Hans,
>
>> -----Original Message-----
>> From: linux-rdma-owner@vger.kernel.org [mailto:linux-rdma-
>> owner@vger.kernel.org] On Behalf Of Ursula Braun
>> Sent: Wednesday, September 20, 2017 6:58 AM
>> To: davem@davemloft.net
>> Cc: netdev@vger.kernel.org; linux-rdma@vger.kernel.org; linux-
>> s390@vger.kernel.org; jwi@linux.vnet.ibm.com; schwidefsky@de.ibm.com;
>> heiko.carstens@de.ibm.com; raspl@linux.vnet.ibm.com;
>> ubraun@linux.vnet.ibm.com
>> Subject: [PATCH net-next 01/10] net/smc: add missing dev_put
>>
>> From: Hans Wippel <hwippel@linux.vnet.ibm.com>
>>
>> In the infiniband part, SMC currently uses get_netdev which calls dev_hold on
>> the returned net device. However, the SMC code never calls dev_put on that net
>> device resulting in a wrong reference count.
>>
>> This patch adds a dev_put after the usage of the net device to fix the issue.
>>
>> Signed-off-by: Hans Wippel <hwippel@linux.vnet.ibm.com>
>> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
>> ---
>> net/smc/smc_ib.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/net/smc/smc_ib.c b/net/smc/smc_ib.c index
>> 547e0e113b17..0b5852299158 100644
>> --- a/net/smc/smc_ib.c
>> +++ b/net/smc/smc_ib.c
>> @@ -380,6 +380,7 @@ static int smc_ib_fill_gid_and_mac(struct smc_ib_device
>> *smcibdev, u8 ibport)
>> ndev = smcibdev->ibdev->get_netdev(smcibdev->ibdev, ibport);
>> if (ndev) {
>> memcpy(&smcibdev->mac, ndev->dev_addr, ETH_ALEN);
>> + dev_put(ndev);
>
> I am sorry for providing late comments. smc_ib_fill_gid_and_mac() is not coded correctly.
> Few fixes are needed.
> 1. ULP such as SMC should not open code/deference any function pointer like get_netdev() of the IB device.
> 2. Replace ib_query_gid(..., NULL)
> With
> ib_query_gid(..., gid_attr);
>
> Use gid_attr.ndev to get the MAC address.
> Do dev_put(gid_attr.ndev);
>
> Code should look like below,
>
> struct ib_gid_attr gid_attr;
>
> rc = ib_query_gid(..., &gid_attr);
> if (rc || !gid_addr.ndev)
> return -ENODEV;
> else
> memcpy(smcibdev->mac, ndev->dev_addr, ETH_ALEN);
> dev_put(gid_addr.ndev);
>
Thanks, Parav!
Following your fix ideas I plan to change the function into this one:
static int smc_ib_fill_gid_and_mac(struct smc_ib_device *smcibdev, u8 ibport)
{
struct ib_gid_attr gattr;
int rc;
rc = ib_query_gid(smcibdev->ibdev, ibport, 0,
&smcibdev->gid[ibport - 1], &gattr);
/* the SMC protocol requires specification of the roce MAC address;
* if net_device cannot be determined, it can be derived from gid 0
*/
if (rc)
return rc;
if (gattr.ndev) {
memcpy(&smcibdev->mac, gattr.ndev->dev_addr, ETH_ALEN);
dev_put(gattr.ndev);
} else {
memcpy(&smcibdev->mac[ibport - 1][0],
&smcibdev->gid[ibport - 1].raw[8], 3);
memcpy(&smcibdev->mac[ibport - 1][3],
&smcibdev->gid[ibport - 1].raw[13], 3);
smcibdev->mac[ibport - 1][0] &= ~0x02;
}
return 0;
}
If you agree, I will submit the corresponding patch including a
Suggested-by: Parav Pandit <parav@mellanox.com>
Regards, Ursula
^ permalink raw reply
* [PATCH v5] devtools: rework abi checker script
From: Olivier Matz @ 2017-10-05 7:53 UTC (permalink / raw)
To: dev, nhorman, bruce.richardson
In-Reply-To: <20170920091253.15794-1-olivier.matz@6wind.com>
The initial version of the script had some limitations:
- cannot work on a non-clean workspace
- environment variables are not documented
- no compilation log in case of failure
- return success even it abi is incompatible
This patch addresses these issues and rework the code.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
v4->v5:
- Add a log when shared lib has no public ABI
v3->v4:
- clarify logs on incompatible abi
- log when an error returned an error
- [really] fix the report path
- log the output of make config in the proper file
v2->v3:
- fix when not launched from dpdk root dir
- use "-Og -Wno-error" instead of "-O0"
- fix typo in commit log
v1->v2:
- use /usr/bin/env to find bash (which is required)
- fix displayed path to html reports
- reword help for -f option
devtools/validate-abi.sh | 397 ++++++++++++++++++++++++-----------------------
1 file changed, 205 insertions(+), 192 deletions(-)
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 0accc99b1..8caf43e83 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -1,7 +1,8 @@
-#!/bin/sh
+#!/usr/bin/env bash
# BSD LICENSE
#
# Copyright(c) 2015 Neil Horman. All rights reserved.
+# Copyright(c) 2017 6WIND S.A.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -27,236 +28,248 @@
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-TAG1=$1
-TAG2=$2
-TARGET=$3
-ABI_DIR=`mktemp -d -p /tmp ABI.XXXXXX`
+set -e
-usage() {
- echo "$0 <REV1> <REV2> <TARGET>"
-}
+abicheck=abi-compliance-checker
+abidump=abi-dumper
+default_dst=abi-check
+default_target=x86_64-native-linuxapp-gcc
-log() {
- local level=$1
- shift
- echo "$*"
+# trap on error
+err_report() {
+ echo "$0: error at line $1"
}
+trap 'err_report $LINENO' ERR
-validate_tags() {
+print_usage () {
+ cat <<- END_OF_HELP
+ $(basename $0) [options] <rev1> <rev2>
- if [ -z "$HASH1" ]
- then
- echo "invalid revision: $TAG1"
- return
- fi
- if [ -z "$HASH2" ]
- then
- echo "invalid revision: $TAG2"
- return
- fi
+ This script compares the ABI of 2 git revisions of the current
+ workspace. The output is a html report and a compilation log.
+
+ The objective is to make sure that applications built against
+ DSOs from the first revision can still run when executed using
+ the DSOs built from the second revision.
+
+ <rev1> and <rev2> are git commit id or tags.
+
+ Options:
+ -h show this help
+ -j <num> enable parallel compilation with <num> threads
+ -v show compilation logs on the console
+ -d <dir> change working directory (default is ${default_dst})
+ -t <target> the dpdk target to use (default is ${default_target})
+ -f overwrite existing files in destination directory
+
+ The script returns 0 on success, or the value of last failing
+ call of ${abicheck} (incompatible abi or the tool has run with errors).
+ The errors returned by ${abidump} are ignored.
+
+ END_OF_HELP
}
-validate_args() {
- if [ -z "$TAG1" ]
- then
- echo "Must Specify REV1"
- return
- fi
- if [ -z "$TAG2" ]
- then
- echo "Must Specify REV2"
- return
- fi
- if [ -z "$TARGET" ]
- then
- echo "Must Specify a build target"
+# log in the file, and on stdout if verbose
+# $1: level string
+# $2: string to be logged
+log() {
+ echo "$1: $2"
+ if [ "${verbose}" != "true" ]; then
+ echo "$1: $2" >&3
fi
}
+# launch a command and log it, taking care of surrounding spaces with quotes
+cmd() {
+ local i s whitespace ret
+ s=""
+ whitespace="[[:space:]]"
+ for i in "$@"; do
+ if [[ $i =~ $whitespace ]]; then
+ i=\"$i\"
+ fi
+ if [ -z "$s" ]; then
+ s="$i"
+ else
+ s="$s $i"
+ fi
+ done
+
+ ret=0
+ log "CMD" "$s"
+ "$@" || ret=$?
+ if [ "$ret" != "0" ]; then
+ log "CMD" "previous command returned $ret"
+ fi
+
+ return $ret
+}
-cleanup_and_exit() {
- rm -rf $ABI_DIR
- git checkout $CURRENT_BRANCH
- exit $1
+# redirect or copy stderr/stdout to a file
+# the syntax is unfamiliar, but it makes the rest of the
+# code easier to read, avoiding the use of pipes
+set_log_file() {
+ # save original stdout and stderr in fd 3 and 4
+ exec 3>&1
+ exec 4>&2
+ # create a new fd 5 that send to a file
+ exec 5> >(cat > $1)
+ # send stdout and stderr to fd 5
+ if [ "${verbose}" = "true" ]; then
+ exec 1> >(tee /dev/fd/5 >&3)
+ exec 2> >(tee /dev/fd/5 >&4)
+ else
+ exec 1>&5
+ exec 2>&5
+ fi
}
# Make sure we configure SHARED libraries
# Also turn off IGB and KNI as those require kernel headers to build
fixup_config() {
- sed -i -e"$ a\CONFIG_RTE_BUILD_SHARED_LIB=y" config/defconfig_$TARGET
- sed -i -e"$ a\CONFIG_RTE_NEXT_ABI=n" config/defconfig_$TARGET
- sed -i -e"$ a\CONFIG_RTE_EAL_IGB_UIO=n" config/defconfig_$TARGET
- sed -i -e"$ a\CONFIG_RTE_LIBRTE_KNI=n" config/defconfig_$TARGET
- sed -i -e"$ a\CONFIG_RTE_KNI_KMOD=n" config/defconfig_$TARGET
+ local conf=config/defconfig_$target
+ cmd sed -i -e"$ a\CONFIG_RTE_BUILD_SHARED_LIB=y" $conf
+ cmd sed -i -e"$ a\CONFIG_RTE_NEXT_ABI=n" $conf
+ cmd sed -i -e"$ a\CONFIG_RTE_EAL_IGB_UIO=n" $conf
+ cmd sed -i -e"$ a\CONFIG_RTE_LIBRTE_KNI=n" $conf
+ cmd sed -i -e"$ a\CONFIG_RTE_KNI_KMOD=n" $conf
}
-###########################################
-#START
-############################################
+# build dpdk for the given tag and dump abi
+# $1: hash of the revision
+gen_abi() {
+ local i
+
+ cmd git clone ${dpdkroot} ${dst}/${1}
+ cmd cd ${dst}/${1}
+
+ log "INFO" "Checking out version ${1} of the dpdk"
+ # Move to the old version of the tree
+ cmd git checkout ${1}
+
+ fixup_config
+
+ # Now configure the build
+ log "INFO" "Configuring DPDK ${1}"
+ cmd make config T=$target O=$target
+
+ # Checking abi compliance relies on using the dwarf information in
+ # the shared objects. Build with -g to include them.
+ log "INFO" "Building DPDK ${1}. This might take a moment"
+ cmd make -j$parallel O=$target V=1 EXTRA_CFLAGS="-g -Og -Wno-error" \
+ EXTRA_LDFLAGS="-g" || log "INFO" "The build failed"
+
+ # Move to the lib directory
+ cmd cd ${PWD}/$target/lib
+ log "INFO" "Collecting ABI information for ${1}"
+ for i in *.so; do
+ [ -e "$i" ] || break
+ cmd $abidump ${i} -o $dst/${1}/${i}.dump -lver ${1} || true
+ # hack to ignore empty SymbolsInfo section (no public ABI)
+ if grep -q "'SymbolInfo' => {}," $dst/${1}/${i}.dump \
+ 2> /dev/null; then
+ log "INFO" "${i} has no public ABI, remove dump file"
+ cmd rm -f $dst/${1}/${i}.dump
+ fi
+ done
+}
-#trap on ctrl-c to clean up
-trap cleanup_and_exit SIGINT
+verbose=false
+parallel=1
+dst=${default_dst}
+target=${default_target}
+force=0
+while getopts j:vd:t:fh ARG ; do
+ case $ARG in
+ j ) parallel=$OPTARG ;;
+ v ) verbose=true ;;
+ d ) dst=$OPTARG ;;
+ t ) target=$OPTARG ;;
+ f ) force=1 ;;
+ h ) print_usage ; exit 0 ;;
+ ? ) print_usage ; exit 1 ;;
+ esac
+done
+shift $(($OPTIND - 1))
-if [ -z "$DPDK_MAKE_JOBS" ]
-then
- # This counts the number of cpus on the system
- if [ -e /usr/bin/lscpu ]
- then
- DPDK_MAKE_JOBS=`lscpu -p=cpu | grep -v "#" | wc -l`
- else
- DPDK_MAKE_JOBS=1
- fi
+if [ $# != 2 ]; then
+ print_usage
+ exit 1
fi
-#Save the current branch
-CURRENT_BRANCH=`git branch | grep \* | cut -d' ' -f2`
+tag1=$1
+tag2=$2
-if [ -z "$CURRENT_BRANCH" ]
-then
- CURRENT_BRANCH=`git log --pretty=format:%H HEAD~1..HEAD`
-fi
+# convert path to absolute
+case "${dst}" in
+ /*) ;;
+ *) dst=${PWD}/${dst} ;;
+esac
+dpdkroot=$(readlink -e $(dirname $0)/..)
-if [ -n "$VERBOSE" ]
-then
- export VERBOSE=/dev/stdout
-else
- export VERBOSE=/dev/null
+if [ -e "${dst}" -a "$force" = 0 ]; then
+ echo "The ${dst} directory is not empty. Remove it, use another"
+ echo "one (-d <dir>), or force overriding (-f)"
+ exit 1
fi
-# Validate that we have all the arguments we need
-res=$(validate_args)
-if [ -n "$res" ]
-then
- echo $res
- usage
- cleanup_and_exit 1
-fi
+rm -rf ${dst}
+mkdir -p ${dst}
+set_log_file ${dst}/abi-check.log
+log "INFO" "Logs available in ${dst}/abi-check.log"
-HASH1=$(git show -s --format=%H "$TAG1" -- 2> /dev/null | tail -1)
-HASH2=$(git show -s --format=%H "$TAG2" -- 2> /dev/null | tail -1)
+command -v ${abicheck} || log "INFO" "Can't find ${abicheck} utility"
+command -v ${abidump} || log "INFO" "Can't find ${abidump} utility"
-# Make sure our tags exist
-res=$(validate_tags)
-if [ -n "$res" ]
-then
- echo $res
- cleanup_and_exit 1
-fi
+hash1=$(git show -s --format=%h "$tag1" -- 2> /dev/null | tail -1)
+hash2=$(git show -s --format=%h "$tag2" -- 2> /dev/null | tail -1)
# Make hashes available in output for non-local reference
-TAG1="$TAG1 ($HASH1)"
-TAG2="$TAG2 ($HASH2)"
-
-ABICHECK=`which abi-compliance-checker 2>/dev/null`
-if [ $? -ne 0 ]
-then
- log "INFO" "Can't find abi-compliance-checker utility"
- cleanup_and_exit 1
-fi
-
-ABIDUMP=`which abi-dumper 2>/dev/null`
-if [ $? -ne 0 ]
-then
- log "INFO" "Can't find abi-dumper utility"
- cleanup_and_exit 1
-fi
+tag1="$tag1 ($hash1)"
+tag2="$tag2 ($hash2)"
-log "INFO" "We're going to check and make sure that applications built"
-log "INFO" "against DPDK DSOs from version $TAG1 will still run when executed"
-log "INFO" "against DPDK DSOs built from version $TAG2."
-log "INFO" ""
-
-# Check to make sure we have a clean tree
-git status | grep -q clean
-if [ $? -ne 0 ]
-then
- log "WARN" "Working directory not clean, aborting"
- cleanup_and_exit 1
+if [ "$hash1" = "$hash2" ]; then
+ log "ERROR" "$tag1 and $tag2 are the same revisions"
+ exit 1
fi
-# Move to the root of the git tree
-cd $(dirname $0)/..
+cmd mkdir -p ${dst}
-log "INFO" "Checking out version $TAG1 of the dpdk"
-# Move to the old version of the tree
-git checkout $HASH1
+# dump abi for each revision
+gen_abi ${hash1}
+gen_abi ${hash2}
-fixup_config
+# compare the abi dumps
+cmd cd ${dst}
+ret=0
+list=""
+for i in ${hash2}/*.dump; do
+ name=`basename $i`
+ libname=${name%.dump}
-# Checking abi compliance relies on using the dwarf information in
-# The shared objects. Thats only included in the DSO's if we build
-# with -g
-export EXTRA_CFLAGS="$EXTRA_CFLAGS -g -O0"
-export EXTRA_LDFLAGS="$EXTRA_LDFLAGS -g"
-
-# Now configure the build
-log "INFO" "Configuring DPDK $TAG1"
-make config T=$TARGET O=$TARGET > $VERBOSE 2>&1
-
-log "INFO" "Building DPDK $TAG1. This might take a moment"
-make -j$DPDK_MAKE_JOBS O=$TARGET > $VERBOSE 2>&1
-
-if [ $? -ne 0 ]
-then
- log "INFO" "THE BUILD FAILED. ABORTING"
- cleanup_and_exit 1
-fi
+ if [ ! -f ${hash1}/$name ]; then
+ log "INFO" "$NAME does not exist in $tag1. skipping..."
+ continue
+ fi
-# Move to the lib directory
-cd $TARGET/lib
-log "INFO" "COLLECTING ABI INFORMATION FOR $TAG1"
-for i in `ls *.so`
-do
- $ABIDUMP $i -o $ABI_DIR/$i-ABI-0.dump -lver $HASH1
+ local_ret=0
+ cmd $abicheck -l $libname \
+ -old ${hash1}/$name -new ${hash2}/$name || local_ret=$?
+ if [ $local_ret != 0 ]; then
+ log "NOTICE" "$abicheck returned $local_ret"
+ ret=$local_ret
+ list="$list $libname"
+ fi
done
-cd ../..
-
-# Now clean the tree, checkout the second tag, and rebuild
-git clean -f -d
-git reset --hard
-# Move to the new version of the tree
-log "INFO" "Checking out version $TAG2 of the dpdk"
-git checkout $HASH2
-
-fixup_config
-
-# Now configure the build
-log "INFO" "Configuring DPDK $TAG2"
-make config T=$TARGET O=$TARGET > $VERBOSE 2>&1
-
-log "INFO" "Building DPDK $TAG2. This might take a moment"
-make -j$DPDK_MAKE_JOBS O=$TARGET > $VERBOSE 2>&1
-if [ $? -ne 0 ]
-then
- log "INFO" "THE BUILD FAILED. ABORTING"
- cleanup_and_exit 1
+if [ $ret != 0 ]; then
+ log "NOTICE" "ABI may be incompatible, check reports/logs for details."
+ log "NOTICE" "Incompatible list: $list"
+else
+ log "NOTICE" "No error detected, ABI is compatible."
fi
-cd $TARGET/lib
-log "INFO" "COLLECTING ABI INFORMATION FOR $TAG2"
-for i in `ls *.so`
-do
- $ABIDUMP $i -o $ABI_DIR/$i-ABI-1.dump -lver $HASH2
-done
-cd ../..
-
-# Start comparison of ABI dumps
-for i in `ls $ABI_DIR/*-1.dump`
-do
- NEWNAME=`basename $i`
- OLDNAME=`basename $i | sed -e"s/1.dump/0.dump/"`
- LIBNAME=`basename $i | sed -e"s/-ABI-1.dump//"`
-
- if [ ! -f $ABI_DIR/$OLDNAME ]
- then
- log "INFO" "$OLDNAME DOES NOT EXIST IN $TAG1. SKIPPING..."
- fi
-
- #compare the abi dumps
- $ABICHECK -l $LIBNAME -old $ABI_DIR/$OLDNAME -new $ABI_DIR/$NEWNAME
-done
+log "INFO" "Logs are in ${dst}/abi-check.log"
+log "INFO" "HTML reports are in ${dst}/compat_reports directory"
-git reset --hard
-log "INFO" "ABI CHECK COMPLETE. REPORTS ARE IN compat_report directory"
-cleanup_and_exit 0
+exit $ret
--
2.11.0
^ permalink raw reply related
* [PATCH] nvmet: bump NVMET_NR_QUEUES to 128
From: Christoph Hellwig @ 2017-10-05 7:52 UTC (permalink / raw)
In-Reply-To: <ee9de017-69e9-670e-b763-1eea73598d66@gmail.com>
On Thu, Sep 14, 2017@11:36:48AM -0700, James Smart wrote:
> On 9/14/2017 10:03 AM, Christoph Hellwig wrote:
> > This looks ok as a quick check, but any chance you could send
> > a patch to make this configurable through configfs? Preferably
> > also for the max queue size.
>
> Yep - I'll put one together
Did you get a chance to look at that?
^ permalink raw reply
* Re: [PATCH v2 0/2] kbuild: Cache exploratory calls to the compiler
From: Ingo Molnar @ 2017-10-05 7:52 UTC (permalink / raw)
To: Douglas Anderson
Cc: yamada.masahiro, mmarek, groeck, sjg, briannorris,
Marcin Nowakowski, Matthias Kaehlcke, Cao jin, Arnd Bergmann,
Mark Charlebois, linux-kbuild, linux-doc, Jonathan Corbet,
linux-kernel, James Hogan, Josh Poimboeuf
In-Reply-To: <20171004223717.3010-1-dianders@chromium.org>
* Douglas Anderson <dianders@chromium.org> wrote:
> This two-patch series attempts to speed incremental builds of the
> kernel up by a bit. How much of a speedup you get depends a lot on
> your environment, specifically the speed of your workstation and how
> fast it takes to invoke the compiler.
>
> In the Chrome OS build environment you get a really big win. For an
> incremental build (via emerge) I measured a speedup from ~1 minute to
> ~35 seconds.
Very impressive!
> [...] ...but Chrome OS calls the compiler through a number of wrapper scripts
> and also calls the kernel make at least twice for an emerge (during compile
> stage and install stage), so it's a bit of a worst case.
I don't think that's a worst case: incremental builds are very commonly used
during kernel development and kernel testing. (I'd even argue that the performnace
of incremental builds is one of the most important features of a build system.)
That it's called twice in the Chrome OS build system does not change the
proportion of the speedup.
> Perhaps a more realistic measure of the speedup others might see is
> running "time make help > /dev/null" outside of the Chrome OS build
> environment on my system. When I do this I see that it took more than
> 1.0 seconds before and less than 0.2 seconds after. So presumably
> this has the ability to shave ~0.8 seconds off an incremental build
> for most folks out there. While 0.8 seconds savings isn't huge, it
> does make incremental builds feel a lot snappier.
This is a huge deal!
FWIIW I have tested your patches and they work fine here. Here's the before/after
performance testing of various styles of build times of the scheduler.
First the true worst case is a full rebuild:
[ before ]
triton:~/tip> perf stat --null --repeat 3 --pre "make clean 2>/dev/null 2>&1" make kernel/sched/ >/dev/null
Performance counter stats for 'make kernel/sched/' (3 runs):
4.693974827 seconds time elapsed ( +- 0.05% )
[ after ]
triton:~/tip> perf stat --null --repeat 3 --pre "make clean 2>/dev/null 2>&1" make kernel/sched/ >/dev/null
Performance counter stats for 'make kernel/sched/' (3 runs):
4.391769610 seconds time elapsed ( +- 0.21% )
Still a ~6% speedup which is nice to have.
Then the best case, a fully cached rebuild of a specific subsystem - which I
personally do all the time when I don't remember whether I already built the
kernel or not:
[ before ]
triton:~/tip> taskset 1 perf stat --null --pre "sync" --repeat 10 make kernel/sched/ >/dev/null
Performance counter stats for 'make kernel/sched/' (10 runs):
0.439517157 seconds time elapsed ( +- 0.14% )
[ after ]
triton:~/tip> taskset 1 perf stat --null --pre "sync" --repeat 10 make kernel/sched/ >/dev/null
Performance counter stats for 'make kernel/sched/' (10 runs):
0.148483807 seconds time elapsed ( +- 0.57% )
A 300% speedup on my system!
So I wholeheartedly endorse the whole concept of caching build environment
invariants:
Tested-by: Ingo Molnar <mingo@kernel.org>
Thanks,
Ingo
^ permalink raw reply
* [PATCH V5] nvme-pci: add SGL support
From: Christoph Hellwig @ 2017-10-05 7:52 UTC (permalink / raw)
In-Reply-To: <1507164918-4749-2-git-send-email-ckulkarnilinux@gmail.com>
On Wed, Oct 04, 2017@05:55:18PM -0700, Chaitanya Kulkarni wrote:
> From: Chaitanya Kulkarni <chaitanya.kulkarni at wdc.com>
>
> This adds SGL support for NVMe PCIe driver, based on an earlier patch
> from Rajiv Shanmugam Madeswaran <smrajiv15 at gmail.com>. This patch
> refactors the original code and adds new module parameter sgl_threshold
> to determine whether to use SGL or PRP for IOs.
>
> The new enum controller capability constant NVME_SGL_NOT_SUPP
> definition is used to determine whether NVMe Controller supports SGL
> mode for IOs.
>
> The usage of SGLs is controlled by the sgl_threshold module parameter,
> which allows to conditionally use SGLs if average request segment size
> (avg_seg_size) is greater than sgl_threshold. In the original patch,
> the decision of using SGLs was dependent only on the IO size,
> with the new approach we consider not only IO size but also the
> number of physical segments present in the IO.
>
> We calculate avg_seg_size based on request payload bytes and number
> of physical segments present in the request.
>
> For e.g.:-
>
> 1. blk_rq_nr_phys_segments = 2 blk_rq_payload_bytes = 8k
> avg_seg_size = 4K use sgl if avg_seg_size >= sgl_threshold.
>
> 2. blk_rq_nr_phys_segments = 2 blk_rq_payload_bytes = 64k
> avg_seg_size = 32K use sgl if avg_seg_size >= sgl_threshold.
>
> 3. blk_rq_nr_phys_segments = 16 blk_rq_payload_bytes = 64k
> avg_seg_size = 4K use sgl if avg_seg_size
>
> Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni at wdc.com>
> ---
> drivers/nvme/host/pci.c | 223 ++++++++++++++++++++++++++++++++++++++++++------
> include/linux/nvme.h | 1 +
> 2 files changed, 199 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index cb73bc8..9f66f75 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -45,6 +45,8 @@
> */
> #define NVME_AQ_BLKMQ_DEPTH (NVME_AQ_DEPTH - NVME_NR_AERS)
>
> +#define SGES_PER_PAGE (PAGE_SIZE / sizeof(struct nvme_sgl_desc))
> +
> static int use_threaded_interrupts;
> module_param(use_threaded_interrupts, int, 0);
>
> @@ -57,6 +59,10 @@
> MODULE_PARM_DESC(max_host_mem_size_mb,
> "Maximum Host Memory Buffer (HMB) size per controller (in MiB)");
>
> +static unsigned int sgl_threshold = SZ_32K;
> +module_param(sgl_threshold, uint, 0644);
> +MODULE_PARM_DESC(sgl_threshold, "use SGL for I/O larger or equal to this size");
> +
> static int io_queue_depth_set(const char *val, const struct kernel_param *kp);
> static const struct kernel_param_ops io_queue_depth_ops = {
> .set = io_queue_depth_set,
> @@ -178,6 +184,7 @@ struct nvme_queue {
> struct nvme_iod {
> struct nvme_request req;
> struct nvme_queue *nvmeq;
> + bool use_sgl;
> int aborted;
> int npages; /* In the PRP list. 0 means small pool in use */
> int nents; /* Used in scatterlist */
> @@ -331,17 +338,32 @@ static int nvme_npages(unsigned size, struct nvme_dev *dev)
> return DIV_ROUND_UP(8 * nprps, PAGE_SIZE - 8);
> }
>
> +/*
> + * Calculates the number of pages needed for the SGL segments. For example a 4k
> + * page can accommodate 256 SGL descriptors.
> + */
> +static int nvme_npages_sgl(unsigned int num_seg)
> +{
> + return DIV_ROUND_UP(num_seg * sizeof(struct nvme_sgl_desc), PAGE_SIZE);
> +}
> +
> static unsigned int nvme_iod_alloc_size(struct nvme_dev *dev,
> - unsigned int size, unsigned int nseg)
> + unsigned int size, unsigned int nseg, bool use_sgl)
> {
> - return sizeof(__le64 *) * nvme_npages(size, dev) +
> - sizeof(struct scatterlist) * nseg;
> + size_t alloc_size;
> +
> + if (use_sgl)
> + alloc_size = sizeof(__le64 *) * nvme_npages_sgl(nseg);
> + else
> + alloc_size = sizeof(__le64 *) * nvme_npages(size, dev);
> +
> + return alloc_size + sizeof(struct scatterlist) * nseg;
> }
>
> -static unsigned int nvme_cmd_size(struct nvme_dev *dev)
> +static unsigned int nvme_cmd_size(struct nvme_dev *dev, bool use_sgl)
> {
> return sizeof(struct nvme_iod) +
> - nvme_iod_alloc_size(dev, NVME_INT_BYTES(dev), NVME_INT_PAGES);
> + nvme_iod_alloc_size(dev, NVME_INT_BYTES(dev), NVME_INT_PAGES, use_sgl);
> }
>
> static int nvme_admin_init_hctx(struct blk_mq_hw_ctx *hctx, void *data,
> @@ -425,10 +447,10 @@ static void __nvme_submit_cmd(struct nvme_queue *nvmeq,
> nvmeq->sq_tail = tail;
> }
>
> -static __le64 **iod_list(struct request *req)
> +static void **iod_list(struct request *req)
> {
> struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
> - return (__le64 **)(iod->sg + blk_rq_nr_phys_segments(req));
> + return (void **)(iod->sg + blk_rq_nr_phys_segments(req));
> }
>
> static blk_status_t nvme_init_iod(struct request *rq, struct nvme_dev *dev)
> @@ -438,7 +460,10 @@ static blk_status_t nvme_init_iod(struct request *rq, struct nvme_dev *dev)
> unsigned int size = blk_rq_payload_bytes(rq);
>
> if (nseg > NVME_INT_PAGES || size > NVME_INT_BYTES(dev)) {
> - iod->sg = kmalloc(nvme_iod_alloc_size(dev, size, nseg), GFP_ATOMIC);
> + size_t alloc_size = nvme_iod_alloc_size(dev, size, nseg,
> + iod->use_sgl);
> +
> + iod->sg = kmalloc(alloc_size, GFP_ATOMIC);
> if (!iod->sg)
> return BLK_STS_RESOURCE;
> } else {
> @@ -456,18 +481,29 @@ static blk_status_t nvme_init_iod(struct request *rq, struct nvme_dev *dev)
> static void nvme_free_iod(struct nvme_dev *dev, struct request *req)
> {
> struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
> - const int last_prp = dev->ctrl.page_size / 8 - 1;
> + const int last_prp = dev->ctrl.page_size / sizeof(__le64) - 1;
> + dma_addr_t dma_addr = iod->first_dma, next_dma_addr;
> int i;
> - __le64 **list = iod_list(req);
> - dma_addr_t prp_dma = iod->first_dma;
>
> if (iod->npages == 0)
> - dma_pool_free(dev->prp_small_pool, list[0], prp_dma);
> + dma_pool_free(dev->prp_small_pool, iod_list(req)[0], dma_addr);
> +
> for (i = 0; i < iod->npages; i++) {
> - __le64 *prp_list = list[i];
> - dma_addr_t next_prp_dma = le64_to_cpu(prp_list[last_prp]);
> - dma_pool_free(dev->prp_page_pool, prp_list, prp_dma);
> - prp_dma = next_prp_dma;
> + void *addr = iod_list(req)[i];
> +
> + if (iod->use_sgl) {
> + struct nvme_sgl_desc *sg_list = addr;
> +
> + next_dma_addr =
> + le64_to_cpu((sg_list[SGES_PER_PAGE - 1]).addr);
> + } else {
> + __le64 *prp_list = addr;
> +
> + next_dma_addr = le64_to_cpu(prp_list[last_prp]);
> + }
> +
> + dma_pool_free(dev->prp_page_pool, addr, dma_addr);
> + dma_addr = next_dma_addr;
> }
>
> if (iod->sg != iod->inline_sg)
> @@ -555,7 +591,8 @@ static void nvme_print_sgl(struct scatterlist *sgl, int nents)
> }
> }
>
> -static blk_status_t nvme_setup_prps(struct nvme_dev *dev, struct request *req)
> +static blk_status_t nvme_setup_prps(struct nvme_dev *dev, struct request *req,
> + struct nvme_rw_command *cmnd)
> {
> struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
> struct dma_pool *pool;
> @@ -566,14 +603,16 @@ static blk_status_t nvme_setup_prps(struct nvme_dev *dev, struct request *req)
> u32 page_size = dev->ctrl.page_size;
> int offset = dma_addr & (page_size - 1);
> __le64 *prp_list;
> - __le64 **list = iod_list(req);
> + void **list = iod_list(req);
> dma_addr_t prp_dma;
> int nprps, i;
>
> + iod->use_sgl = false;
> +
> length -= (page_size - offset);
> if (length <= 0) {
> iod->first_dma = 0;
> - return BLK_STS_OK;
> + goto done;
> }
>
> dma_len -= (page_size - offset);
> @@ -587,7 +626,7 @@ static blk_status_t nvme_setup_prps(struct nvme_dev *dev, struct request *req)
>
> if (length <= page_size) {
> iod->first_dma = dma_addr;
> - return BLK_STS_OK;
> + goto done;
> }
>
> nprps = DIV_ROUND_UP(length, page_size);
> @@ -634,6 +673,10 @@ static blk_status_t nvme_setup_prps(struct nvme_dev *dev, struct request *req)
> dma_len = sg_dma_len(sg);
> }
>
> +done:
> + cmnd->dptr.prp1 = cpu_to_le64(sg_dma_address(iod->sg));
> + cmnd->dptr.prp2 = cpu_to_le64(iod->first_dma);
> +
> return BLK_STS_OK;
>
> bad_sgl:
> @@ -643,6 +686,130 @@ static blk_status_t nvme_setup_prps(struct nvme_dev *dev, struct request *req)
> return BLK_STS_IOERR;
> }
>
> +static void nvme_pci_sgl_set_data(struct nvme_sgl_desc *sge,
> + struct scatterlist *sg)
> +{
> + sge->addr = cpu_to_le64(sg_dma_address(sg));
> + sge->length = cpu_to_le32(sg_dma_len(sg));
> + sge->type = NVME_SGL_FMT_DATA_DESC << 4;
> +}
> +
> +static void nvme_pci_sgl_set_last_seg(struct nvme_sgl_desc *sge,
> + dma_addr_t dma_addr, int entries)
> +{
> + sge->addr = cpu_to_le64(dma_addr);
> + sge->length = cpu_to_le32(entries * sizeof(struct nvme_sgl_desc));
> + sge->type = NVME_SGL_FMT_LAST_SEG_DESC << 4;
> +}
> +
> +static void nvme_pci_sgl_set_seg(struct nvme_sgl_desc *sge,
> + dma_addr_t dma_addr)
> +{
> + sge->addr = cpu_to_le64(dma_addr);
> + sge->length = cpu_to_le32(PAGE_SIZE);
> + sge->type = NVME_SGL_FMT_SEG_DESC << 4;
> +}
> +
> +static blk_status_t nvme_setup_sgls(struct nvme_dev *dev, struct request *req,
> + struct nvme_rw_command *cmd)
> +{
> + struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
> + int length = blk_rq_payload_bytes(req);
> + struct dma_pool *pool;
> + struct nvme_sgl_desc *sg_list;
> + struct scatterlist *sg = iod->sg;
> + int entries = iod->nents, i = 0;
> + dma_addr_t sgl_dma;
> +
> + iod->use_sgl = true;
> +
> + cmd->flags = NVME_CMD_SGL_METABUF; /* setting the transfer type as SGL */
> +
> + if (length == sg_dma_len(sg)) {
> + nvme_pci_sgl_set_data(&cmd->dptr.sgl, sg);
> + return BLK_STS_OK;
> + }
> +
> + if (entries <= 256 / sizeof(struct nvme_sgl_desc)) {
> + pool = dev->prp_small_pool;
> + iod->npages = 0;
> + } else {
> + pool = dev->prp_page_pool;
> + iod->npages = 1;
> + }
> +
> + sg_list = dma_pool_alloc(pool, GFP_ATOMIC, &sgl_dma);
> + if (!sg_list) {
> + iod->npages = -1;
> + return BLK_STS_RESOURCE;
> + }
> +
> + iod_list(req)[0] = sg_list;
> + iod->first_dma = sgl_dma;
> +
> + if (entries <= SGES_PER_PAGE) {
> + nvme_pci_sgl_set_last_seg(&cmd->dptr.sgl, sgl_dma, entries);
> +
> + for (i = 0; i < entries; i++) {
> + nvme_pci_sgl_set_data(&sg_list[i], sg);
> + length -= sg_dma_len(sg);
> + sg = sg_next(sg);
> + }
> +
> + WARN_ON(length > 0);
> + return BLK_STS_OK;
> + }
> +
> + nvme_pci_sgl_set_seg(&cmd->dptr.sgl, sgl_dma);
> +
> + do {
> + if (i == SGES_PER_PAGE) {
> + struct nvme_sgl_desc *old_sg_desc = sg_list;
> + struct nvme_sgl_desc *link = &old_sg_desc[i - 1];
> +
> + sg_list = dma_pool_alloc(pool, GFP_ATOMIC, &sgl_dma);
> + if (!sg_list)
> + return BLK_STS_RESOURCE;
> +
> + i = 0;
> + iod_list(req)[iod->npages++] = sg_list;
> + sg_list[i++] = *link;
> +
> + if (entries < SGES_PER_PAGE)
> + nvme_pci_sgl_set_last_seg(link, sgl_dma, entries);
> + else
> + nvme_pci_sgl_set_seg(link, sgl_dma);
> + }
> +
> + nvme_pci_sgl_set_data(&sg_list[i], sg);
> +
> + length -= sg_dma_len(sg);
> + sg = sg_next(sg);
> + entries--;
> + } while (length > 0);
> +
> + WARN_ON(entries > 0);
> + return BLK_STS_OK;
> +}
> +
> +static inline bool nvme_pci_use_sgls(struct nvme_dev *dev, struct request *req)
> +{
> + struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
> + unsigned int avg_seg_size;
> +
> + avg_seg_size = DIV_ROUND_UP(blk_rq_payload_bytes(req),
> + blk_rq_nr_phys_segments(req));
> +
> + if (dev->ctrl.sgls == NVME_CTRL_SGL_NOT_SUPP)
> + return false;
I'm alsmost tempted to drop the symbolic NVME_CTRL_SGL_NOT_SUPP name
and just opencode something like:
if (!(dev->ctrl.sgls & ((1 << 0) | (1 << 1)))
return false;
We use the raw bit values in various other places, and given how they
appear as such raw bit values in the spec that seems to be easier to
map to me than inventing some artifical name for them.
^ permalink raw reply
* Re: SD card reader problems on Cherry-Trail
From: Ulf Hansson @ 2017-10-05 7:52 UTC (permalink / raw)
To: Carlo Caione; +Cc: linux-mmc, Adrian Hunter
In-Reply-To: <CAL9uMOGXVgHP8iNdZbEWv3pSRjZ++hhswu6c+ZiPydGiw9SPEw@mail.gmail.com>
+ Adrian
On 4 October 2017 at 17:00, Carlo Caione <carlo@endlessm.com> wrote:
> Haye,
> I'm working on a Cherry-Trail laptop shipping an SDHCI controller on
> ACPI [80860F14:03].
> The problem is that on this hardware the controller seems to be
> particularly picky about the type of SD cards it likes. In particular:
>
> - With ultra high speed DDR50 SDHC cards I see no problems
> - With ultra high speed SDR104 SDHC cards as soon as the card is inserted I get:
>
> mmc2: Tuning timeout, falling back to fixed sampling clock
> mmc2: new ultra high speed SDR104 SDHC card at address 59b4
> mmcblk2: mmc2:59b4 USD00 15.0 GiB
> mmc2: Timeout waiting for hardware interrupt.
> mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
> mmc2: sdhci: Sys addr: 0x00000008 | Version: 0x00001002
> mmc2: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000008
> mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x0000003b
> mmc2: sdhci: Present: 0x01ff0001 | Host ctl: 0x00000017
> mmc2: sdhci: Power: 0x0000000f | Blk gap: 0x00000080
> mmc2: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
> mmc2: sdhci: Timeout: 0x0000000a | Int stat: 0x00000000
> mmc2: sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
> mmc2: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
> mmc2: sdhci: Caps: 0x0568c8b2 | Caps_1: 0x00000807
> mmc2: sdhci: Cmd: 0x0000123a | Max curr: 0x00000000
> mmc2: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x0077dd7f
> mmc2: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x00000000
> mmc2: sdhci: Host ctl2: 0x0000800b
> mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x335c9200
> mmc2: sdhci: ============================================
> mmcblk2: error -110 sending status command, retrying
> mmcblk2: error -110 sending status command, retrying
> mmcblk2: error -110 sending status command, aborting
>
> reading and writing is painfully slow.
>
> - With high speed SDHC cards I get a weird behavior where apparently
> there is no problem but it's impossible to format the card. mkfs.ext4
> gets stuck at:
>
> Discarding device blocks: 4096/3778299
>
> Have you ever seen something like this or any hint how to debug this mess?
Looping in Adrian, as he maintains sdhci.
I guess some more useful information would also be about what commit
you are running and whether this is a regression or not.
Kind regards
Uffe
^ permalink raw reply
* Linux kernel 4.4.90 released
From: Linux Kernel Distribution System @ 2017-10-05 7:51 UTC (permalink / raw)
To: linux-kernel-announce
Linux kernel version 4.4.90 is now available:
Full source: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.4.90.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.4.90.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.4.90.tar.sign
You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/linux-stable/ds/v4.4.90/v4.4.89
^ permalink raw reply
* Linux kernel 3.18.73 released
From: Linux Kernel Distribution System @ 2017-10-05 7:51 UTC (permalink / raw)
To: linux-kernel-announce
Linux kernel version 3.18.73 (EOL) is now available:
Full source: https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.73.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v3.x/patch-3.18.73.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.73.tar.sign
You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/linux-stable/ds/v3.18.73/v3.18.72
^ permalink raw reply
* [cip-dev] B@D support Renesas iwg20m board - issue
From: Robert Marshall @ 2017-10-05 7:51 UTC (permalink / raw)
To: cip-dev
In-Reply-To: <59CB7424.3050202@codethink.co.uk>
Morning!
Agustin Benito Bethencourt <agustin.benito@codethink.co.uk> writes:
> Hi,
>
> On 27/09/17 07:35, Daniel Sangorrin wrote:
>> Agustin, Robert:
>>
>>> -----Original Message-----
>>> From: Agustin Benito Bethencourt [mailto:agustin.benito at codethink.co.uk]
>>> Sent: Tuesday, September 26, 2017 7:34 PM
>>> To: Daniel Sangorrin; 'cip dev'
>>> Cc: 'Binh Thanh. Nguyen'; 'Chris Paterson'; 'Robert Marshall'; 'O365-Toru Oishi'
>>> Subject: Re: [cip-dev] B at D support Renesas iwg20m board - issue
>>>
>>> Hi,
>>>
>>> On 26/09/17 11:49, Daniel Sangorrin wrote:
>>>> Hi Binh, Robert, Everyone
>>>>
>>>> I have Project-X for iwg20m working with LAVA 2017.7 (boot test and a simple uname test so far).
>>>> # I will send the patches another day.
>>>>
>>>> Robert: do you have plans to update to 2017.9?
>>>
>>> We will not before ELCE. We will concentrate on properly releasing what
>>> we currently have for the event.
>>
>> Alright, then I will prepare the demo for 2017.7.
>>
>> Robert: until now I was using lava-docker, is the 2017.7 version fully working now?
>> What branch should I use?
>
> Robert is on vacation until mid next week.
>
> From what I see in the project journal and the repo, there is a merge
> request approved for lava update and local initramfs.
Yes, the initramfs and lava to 2017-7 updates are in master, lava is
working fine, remaining issues are with a recent kernelci update to which the comment
below belongs
Robert
>
> Hi comment is: "B at D still hangs at the listening on port 8888 in
> install_backend.sh and needs a manual vm restart. But once that's done
> the rest of the kernelci provisioning works. "
>
> So I assume it is almost ready for the release, which will take place
> right after he comes back.
>
> Check:
> https://gitlab.com/rajm/board-at-desk-single-dev/tree/fix-new-kernelci
>
>>
>> Another question:
>> Is it possible to upload artifacts (CIP Core's ramdisk, uImage, devicetree etc) to
>> the AWS S3 storage so that we can share the same binaries for demos etc?
>
> Yes it is. I will add you as user so you can upload them.
>
>>
>> Thanks,
>> Daniel
>>
>>>>> -----Original Message-----
>>>>> From: Binh Thanh. Nguyen [mailto:binh.nguyen.uw at rvc.renesas.com]
>>>>> Sent: Wednesday, September 20, 2017 6:30 PM
>>>>> To: Chris Paterson; Daniel Sangorrin; 'cip dev'
>>>>> Cc: O365-Toru Oishi
>>>>> Subject: RE: [cip-dev] B at D support Renesas iwg20m board - issue
>>>>>
>>>>> Hi Daniel,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Chris Paterson [mailto:Chris.Paterson2 at renesas.com]
>>>>>> Sent: Wednesday, September 20, 2017 3:29 PM
>>>>>> To: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>; Binh Thanh. Nguyen
>>>>>> <binh.nguyen.uw@rvc.renesas.com>; 'cip dev' <cip-dev@lists.cip-
>>>>>> project.org>
>>>>>> Cc: O365-Toru Oishi <toru.oishi.zj@renesas.com>
>>>>>> Subject: RE: [cip-dev] B at D support Renesas iwg20m board - issue
>>>>>>
>>>>>> Hello Daniel,
>>>>>>
>>>>>>> From: cip-dev-bounces at lists.cip-project.org [mailto:cip-dev-
>>>>>>> bounces at lists.cip-project.org] On Behalf Of Daniel Sangorrin
>>>>>>> Sent: 20 September 2017 08:14
>>>>>>>
>>>>>>> Hi Binh,
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: cip-dev-bounces at lists.cip-project.org
>>>>>>>> [mailto:cip-dev-bounces at lists.cip-project.org] On Behalf Of Daniel
>>>>>>>> Sangorrin
>>>>>>>> Sent: Wednesday, September 20, 2017 3:40 PM
>>>>>>>> To: 'Binh Thanh. Nguyen'; 'cip dev'
>>>>>>>> Cc: 'O365-Toru Oishi'
>>>>>>>> Subject: Re: [cip-dev] B at D support Renesas iwg20m board - issue
>>>>>>>>
>>>>>>>> Hi Binh,
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Binh Thanh. Nguyen [mailto:binh.nguyen.uw at rvc.renesas.com]
>>>>>>>>> Sent: Friday, September 15, 2017 8:46 PM
>>>>>>>>> To: Daniel Sangorrin; 'cip dev'
>>>>>>>>> Cc: O365-Toru Oishi
>>>>>>>>> Subject: RE: [cip-dev] B at D support Renesas iwg20m board - issue
>>>>>>>>>
>>>>>>>>> Hello Daniel,
>>>>>>>>>
>>>>>>>>> Sorry for late reply. I got few days off for some reasons.
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Daniel Sangorrin [mailto:daniel.sangorrin at toshiba.co.jp]
>>>>>>>>>> Sent: Tuesday, September 12, 2017 8:36 AM
>>>>>>>>>> To: Binh Thanh. Nguyen <binh.nguyen.uw@rvc.renesas.com>; 'cip
>>>>>> dev'
>>>>>>>>>> <cip- dev@lists.cip-project.org>
>>>>>>>>>> Cc: O365-Toru Oishi <toru.oishi.zj@renesas.com>
>>>>>>>>>> Subject: RE: [cip-dev] B at D support Renesas iwg20m board - issue
>>>>>>>>>>
>>>>>>>>>> Hi Binh,
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Binh Thanh. Nguyen
>>>>>>> [mailto:binh.nguyen.uw at rvc.renesas.com]
>>>>>>>>>>> Sent: Monday, September 11, 2017 8:00 PM
>>>>>>>>>>>> Any updates on this topic?
>>>>>>>>>>> I have no update. I was busy with other tasks with high
>>>>>>>>>>> priority. I will
>>>>>>>>>> manage to back to this task from next week.
>>>>>>>>>>> I will let you know if there is any update.
>>>>>>>>>>
>>>>>>>>>> OK, I'm working on it now. There were several problems with your
>>>>>>>>>> patches and we are upgrading to LAVA 2017.7.
>>>>>>>>>> Before you start please let me know so we don't overlap.
>>>>>>>>>
>>>>>>>>> It is great to know that. Thank you for your work on Renesas board.
>>>>>>>>> I will back to this task next week, if possible please let me know
>>>>>>>>> your
>>>>>>> status, anything need my support please let me know.
>>>>>>>>
>>>>>>>> I am preparing the board to boot from the network (tftp), both the
>>>>>>>> kernel
>>>>>>> and the Project-X file system (a ramdisk).
>>>>>>>> Currently the kernel boots fine, but no login console appears.
>>>>>>>> # Note, the same file system installed on the SD Card has no
>>>>>>>> problems
>>>>>>>>
>>>>>>>> This are a few things I had to modify:
>>>>>>>> - kernel configuration
>>>>>>>> CONFIG_BLK_DEV_RAM=y
>>>>>>>> CONFIG_BLK_DEV_RAM_COUNT=8
>>>>>>>> CONFIG_BLK_DEV_RAM_SIZE=102400
>>>>>>>>
>>>>>>>> - ramdisk
>>>>>>>> # mkdir ramdisk
>>>>>>>> # cd ramdisk/
>>>>>>>> # tar xvf ../iwg20m/core-image-minimal-iwg20m.tar.gz
>>>>>>>> # ln -s /sbin/init .
>>>>>>>> # find . | cpio --create --format='newc' > /tmp/newinitrd
>>>>>>>> # gzip /tmp/newinitrd
>>>>>>>> # mkimage -A arm -T ramdisk -C gzip -d /tmp/newinitrd.gz uRamdisk
>>>>>>>> # mv uRamdisk /var/lib/tftpboot/
>>>>>>>>
>>>>>>>> - u-boot settings
>>>>>>>> iWave-G20M > setenv ramdisk_addr 0x41000000
>>>>>>>> iWave-G20M > setenv ramdisk_file uRamdisk
>>>>>>>> iWave-G20M > setenv bootm_low 0x44000000
>>>>>>>> iWave-G20M > setenv bootm_size 0x3000000
>>>>>>>> iWave-G20M > setenv bootargs_ramdisk setenv bootargs
>>>>>>> ${bootargs_base} root=/dev/ram rootwait rw
>>>>>>>> iWave-G20M > setenv bootcmd_tftpboot 'run bootargs_ramdisk;run
>>>>>>>> fdt_check;tftpboot ${loadaddr} ${kernel};tftpboot ${fdt_addr}
>>>>>>> ${fdt_file};tftpboot ${ramdisk_addr} ${ramdisk_file};bootm ${loadaddr}
>>>>>>> ${ramdisk_addr} ${fdt_addr}'
>>>>>>>> iWave-G20M > saveenv
>>>>>>>> iWave-G20M > run bootcmd_tftpboot
>>>>>>>>
>>>>>>>> I send you the bootlog attached as well.
>>>>>>>>
>>>>>>>> If you have any hint about the possible solution please let me know.
>>>>>>>
>>>>>>> OK, I solved it.
>>>>>>> It seems that the dev folder wasn't being populated properly on the
>>>>>>> ramdisk so I made it work with mdev.
>>>>>>>
>>>>>>> Now that I have a network deployment environment I will try running a
>>>>>>> test on LAVA and see if it works this time.
>>>>>
>>>>> It is great that you could fix the issue.
>>>>> Hope that your test run well. if you meet other issue and need my support, please let me know.
>>>>>
>>>>>>
>>>>>> I'm glad that you managed to resolve the problem. Thank you for the update.
>>>>>>
>>>>>> Kind regards, Chris
>>>>>
>>>>> Best regards,
>>>>> Binh Nguyen
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cip-dev mailing list
>>>> cip-dev at lists.cip-project.org
>>>> https://lists.cip-project.org/mailman/listinfo/cip-dev
>>>>
>>>
>>> --
>>> Agustin Benito Bethencourt
>>> Principal Consultant - FOSS at Codethink
>>> agustin.benito at codethink.co.uk
>>
>>
>>
>>
^ permalink raw reply
* [PATCH] dt-bindings: pinctrl: Move mcp23s08 from gpio
From: Lars Poeschel @ 2017-10-05 7:50 UTC (permalink / raw)
To: Linus Walleij, linux-gpio, linux-kernel, Rob Herring,
Mark Rutland, devicetree
Cc: Lars Poeschel
The mcp23s08 driver was moved from gpio to pinctrl. This moves it's
devicetree binding doc as well. So driver and binding doc are in sync
again.
Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
---
.../bindings/{gpio/gpio-mcp23s08.txt => pinctrl/pinctrl-mcp23s08.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{gpio/gpio-mcp23s08.txt => pinctrl/pinctrl-mcp23s08.txt} (100%)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt
similarity index 100%
rename from Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
rename to Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt
--
2.14.2
^ permalink raw reply
* [PATCH] dt-bindings: pinctrl: Move mcp23s08 from gpio
From: Lars Poeschel @ 2017-10-05 7:50 UTC (permalink / raw)
To: Linus Walleij, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Lars Poeschel
The mcp23s08 driver was moved from gpio to pinctrl. This moves it's
devicetree binding doc as well. So driver and binding doc are in sync
again.
Signed-off-by: Lars Poeschel <poeschel-Xtl8qvBWbHwb1SvskN2V4Q@public.gmane.org>
---
.../bindings/{gpio/gpio-mcp23s08.txt => pinctrl/pinctrl-mcp23s08.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{gpio/gpio-mcp23s08.txt => pinctrl/pinctrl-mcp23s08.txt} (100%)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt
similarity index 100%
rename from Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
rename to Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [xen-unstable-smoke test] 114032: regressions - trouble: blocked/broken/fail/pass
From: osstest service owner @ 2017-10-05 7:49 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 114032 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114032/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf <job status> broken
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 113972
build-armhf 5 host-build-prep fail REGR. vs. 113972
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 1 build-check(1) blocked n/a
version targeted for testing:
xen 72b0c19a7040ab8446f16578b094fec8703f8095
baseline version:
xen dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
Last test of basis 113972 2017-10-03 21:02:43 Z 1 days
Failing since 113979 2017-10-04 00:10:13 Z 1 days 19 attempts
Testing same since 114015 2017-10-04 18:01:26 Z 0 days 7 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Bhupinder Thakur <bhupinder.thakur@linaro.org>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Juergen Gross <jgross@suse.com>
Julien Grall <julien.grall@arm.com>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Stefano Stabellini <sstabellini@kernel.org>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64 pass
build-armhf broken
build-amd64-libvirt pass
test-armhf-armhf-xl blocked
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt fail
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-job build-armhf broken
Not pushing.
(No revision log; it would be 524 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH] powerpc: Default to enabling STRICT_KERNEL_RWX
From: Christophe LEROY @ 2017-10-05 7:49 UTC (permalink / raw)
To: Kees Cook, linux-kernel; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20171005034505.GA32157@beast>
Le 05/10/2017 à 05:45, Kees Cook a écrit :
> When available, CONFIG_KERNEL_RWX should be default-enabled.
On PPC32, this option implies deactivating BATs and/or LTLB mapping of
the linear kernel address space, hence a significant performance
degradation.
So at least on PPC32, it should remain unselected by default.
Christophe
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> arch/powerpc/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 809c468edab1..9a549bbfc278 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -178,6 +178,7 @@ config PPC
> select HAVE_ARCH_TRACEHOOK
> select ARCH_HAS_STRICT_KERNEL_RWX if ((PPC_BOOK3S_64 || PPC32) && !RELOCATABLE && !HIBERNATION)
> select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
> + select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> select HAVE_CBPF_JIT if !PPC64
> select HAVE_CONTEXT_TRACKING if PPC64
> select HAVE_DEBUG_KMEMLEAK
>
^ permalink raw reply
* Re: [PATCH] arm: dts: gr-peach: Reduce extal_clk resolution
From: jacopo mondi @ 2017-10-05 7:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Simon Horman, Magnus Damm, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Chris Brandt
In-Reply-To: <CAMuHMdXOJ6V_p26ozzwzUh5a9mvH-Aeiz2MavEf22v3iB6GiKQ@mail.gmail.com>
Hi Geert
On Wed, Oct 04, 2017 at 05:54:46PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Wed, Oct 4, 2017 at 5:40 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> > The system clock described by extal_clk is reported to have a frequency
> > of 13.333 Mhz and is correctly described by gr-peach device tree.
> >
> > However, when enabling a RIIC device the following error is reported by
> > drivers/i2c/busses/i2c-riic.c
> >
> > "invalid parent clk (33332500). Must be 33325000Hz"
> >
> > As RIIC devices have a clock source obtained by dividing by 12 the
> > system clock, the resulting value is not accepted by the driver
> > (which clearly states not to support any frequency except the reported
> > 33325000Hz one).
> >
> > Hence, reduce the system clock accuracy to a value which makes
> > frequencies obtained through division accepted by RIIC driver.
> >
> > Please note that other r7s72100 boards, such as Genmai, report the same
> > "reduced accuracy" frequency, even if their external clock sources are
> > effectively 13.333Mhz as gr-peach one.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> There's no need to do this, Chris already proposed a fix, cfr.
> "[PATCH v2] i2c: riic: remove fixed clock restriction"
> (https://www.spinics.net/lists/linux-renesas-soc/msg18573.html).
Oh that's even better!
Do you see any value in augmenting the frequency resolution in Genmai
DTS then?
Thanks
j
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.