* Re: bisected: 4.18-rc* regression: x86-32 troubles (with timers?)
From: Meelis Roos @ 2018-07-24 4:47 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Arnd Bergmann, Linux Kernel list, Networking
In-Reply-To: <4a48811d-4094-ee4c-33ca-2cf0446a6313@iogearbox.net>
> > Anyway, I started compile of v4.18-rc5 that was the latest I tested,
> > with the commit in question reverted. Will see if I can test tomorrow
> > morning. But I will leave tomorrow for a week and can only test further
> > things if they happen to boot fine (no manual reboot possible for a
> > week).
>
> Ok, thanks, please keep us posted on the outcome with the revert. Right
> now I would doubt it's related resp. changes anything on the issue, but
> lets see.
v4.18-rc5 minus the patch in question worked fine on 2 bootups so it
seems to be good.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge
From: David Gibson @ 2018-07-24 4:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Cédric Le Goater, qemu-ppc, qemu-devel, Marcel Apfelbaum,
Andrea Bolognani, Michael S. Tsirkin
In-Reply-To: <f8268fd70e4e91bc6333402ac48598d39a42e38e.camel@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]
On Tue, Jul 24, 2018 at 01:49:32PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2018-07-24 at 12:14 +1000, David Gibson wrote:
> > > I don't know, is there much shared logic ? And the shared bits are the
> > > subclassing, that's handled that way...
> > >
> > > This is really a different piece of HW, a separate ICS implementation,
> > > that has its own quirks, is configured via different registers, does
> > > EOI differently etc...
> > >
> > > Even the resend stuff is done differently, the resend bitmap is
> > > actually SW visible via an IODA table.
> > >
> > > I mean, we could (maybe we do these days not sure) have an ICS
> > > superclass wrapper on the actual icp_irq() but that's really all there
> > > is to it I think.
> >
> > Hm, yeah, fair enough. I realized what I was suggesting would
> > actually need another layer of qirqs than we have, so it's not a good
> > idea after all. Ok, I'm happy proceeding with exposing icp_irq().
>
> The only idea I have if you want to keep icp_* private is to put a
> 'helper' in the ICS superclass that the subclass uses to encapsulate
> the ICP call, but at this point it's just churn.
I concur.
>
> But yeah you really don't want a layer of qirqs, it wouldn't work any
> way, it's really an ICS, it will send messages to the ICP with a XIRR
> value in them etc... just like an ICS, it's not somethign you want
> qirq's for .
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] media: staging: omap4iss: Include asm/cacheflush.h after generic includes
From: Mauro Carvalho Chehab @ 2018-07-24 3:41 UTC (permalink / raw)
To: Guenter Roeck
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Greg Kroah-Hartman,
linux-media, devel, linux-kernel, Linus Torvalds, David Miller,
Randy Dunlap
In-Reply-To: <1532381973-11856-1-git-send-email-linux@roeck-us.net>
Em Mon, 23 Jul 2018 14:39:33 -0700
Guenter Roeck <linux@roeck-us.net> escreveu:
> Including asm/cacheflush.h first results in the following build error when
> trying to build sparc32:allmodconfig.
>
> In file included from arch/sparc/include/asm/page.h:10:0,
> from arch/sparc/include/asm/string_32.h:13,
> from arch/sparc/include/asm/string.h:7,
> from include/linux/string.h:20,
> from include/linux/bitmap.h:9,
> from include/linux/cpumask.h:12,
> from arch/sparc/include/asm/smp_32.h:15,
> from arch/sparc/include/asm/smp.h:7,
> from arch/sparc/include/asm/switch_to_32.h:5,
> from arch/sparc/include/asm/switch_to.h:7,
> from arch/sparc/include/asm/ptrace.h:120,
> from arch/sparc/include/asm/thread_info_32.h:19,
> from arch/sparc/include/asm/thread_info.h:7,
> from include/linux/thread_info.h:38,
> from arch/sparc/include/asm/current.h:15,
> from include/linux/mutex.h:14,
> from include/linux/notifier.h:14,
> from include/linux/clk.h:17,
> from drivers/staging/media/omap4iss/iss_video.c:15:
> include/linux/highmem.h: In function 'clear_user_highpage':
> include/linux/highmem.h:137:31: error:
> passing argument 1 of 'sparc_flush_page_to_ram' from incompatible
> pointer type
>
> Include generic includes files first to fix the problem.
>
> Fixes: fc96d58c10162 ("[media] v4l: omap4iss: Add support for OMAP4 camera interface - Video devices")
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: David Miller <davem@davemloft.net>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/staging/media/omap4iss/iss_video.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/omap4iss/iss_video.c b/drivers/staging/media/omap4iss/iss_video.c
> index a3a83424a926..16478fe9e3f8 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -11,7 +11,6 @@
> * (at your option) any later version.
> */
>
> -#include <asm/cacheflush.h>
> #include <linux/clk.h>
> #include <linux/mm.h>
> #include <linux/pagemap.h>
> @@ -24,6 +23,8 @@
> #include <media/v4l2-ioctl.h>
> #include <media/v4l2-mc.h>
>
> +#include <asm/cacheflush.h>
> +
> #include "iss_video.h"
> #include "iss.h"
While I won't be against merging it, IMHO a better fix would be to
add the includes asm/cacheflush.h needs inside it, e. g. something
like adding:
#include <linux/highmem.h>
at the sparc32 variant of it. Btw, ./arch/sparc/include/asm/cacheflush_64.h
seems to include linux/mm.h... So, I guess the right fix would
be something like:
diff --git a/arch/sparc/include/asm/cacheflush_32.h b/arch/sparc/include/asm/cacheflush_32.h
index fb66094a2c30..daeccbdc371a 100644
--- a/arch/sparc/include/asm/cacheflush_32.h
+++ b/arch/sparc/include/asm/cacheflush_32.h
@@ -2,6 +2,8 @@
#ifndef _SPARC_CACHEFLUSH_H
#define _SPARC_CACHEFLUSH_H
+#include <linux/mm.h>
+
#include <asm/cachetlb_32.h>
#define flush_cache_all() \
Thanks,
Mauro
^ permalink raw reply related
* Re: [PATCH] iommu/arm-smmu-v3: sync the OVACKFLG to PRIQ consumer register
From: Zhongmiao @ 2018-07-24 4:44 UTC (permalink / raw)
To: Jean-Philippe Brucker, Zhangshaokun,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Leizhen (ThunderTown)
Cc: Will Deacon
Hi,
On 24/07/18 12:45, Zhongmiao wrote:
> Yeah, I haven't tested smmu eventq overflow , so i'm not sure if there is any problem with smmu eventq. However, the code shows that there is also a problem after the smmu eventq overflows. ^_^…….
>There really shouldn't be any problem with the eventq. Handling the event overflow in my patch is mostly cosmetic and can be removed. See the Event queue overflow section of the SMMUv3 specification (IHI0070B):
>"Note: In terms of delivering events, a queue in an unacknowledged overflow state does not behave any differently to normal queue state. If software were to consume events and free space but leave overflow unacknowledged, new events could be recorded."
In the smmu v3 protocol , The processing of Priq overflow is different from that of Eventq.
Thanks,
Miao
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH v4 3/3] lib/test_crc: Add test cases for crc calculation
From: Eric Biggers @ 2018-07-24 4:44 UTC (permalink / raw)
To: Coly Li
Cc: linux-kernel, linux-bcache, linux-block, Greg Kroah-Hartman,
Linus Torvalds, Thomas Gleixner, Kate Stewart, Andrew Morton,
Randy Dunlap, Andy Shevchenko, Noah Massey
In-Reply-To: <20180718165545.1622-4-colyli@suse.de>
On Thu, Jul 19, 2018 at 12:55:45AM +0800, Coly Li wrote:
> This patch adds a kernel module to test the consistency of multiple crc
> calculation in Linux kernel. It is enabled with CONFIG_TEST_CRC enabled.
>
> The test results are printed into kernel message, which look like,
>
> test_crc: crc64_be: FAILED (0x03d4d0d85685d9a1, expected 0x3d4d0d85685d9a1f)
>
> kernel 0day system has framework to check kernel message, then the above
> result can be handled by 0day system. If crc calculation inconsistency
> happens, it can be detected quite soon.
>
> lib/test_crc.c is a testing frame work for many crc consistency
> testings. For now, there is only one test caes for crc64_be().
Are you aware there's already a CRC-32 test module: CONFIG_CRC32_SELFTEST and
lib/crc32test.c? Confusingly, your patch uses a different naming convention for
the new CRC-64 one, and puts the Kconfig option in a different place, and makes
it sound like it's a generic test for all CRC implementations rather than just
the CRC-64 one. Please use the existing convention (i.e. add
CONFIG_CRC64_SELFTEST and lib/crc64test.c) unless you have a strong argument for
why it should be done differently.
(And I don't think it makes sense to combine all CRC tests into one module,
since you should be able to e.g. enable just CRC32 and CRC32_SELFTEST without
also pulling in a dependency on all the other CRC variants.)
> +/* Add your crc test cases here */
> +static void test_crc64_be(struct crc_test_record *rec)
> +{
> + u64 crc;
> +
> + crc = crc64_be(rec->initval, rec->data, sizeof(rec->data));
> + chk_and_msg(rec->name, crc, rec->expval);
> +}
> +
> +/*
> + * Set up your crc test initial data here.
> + * Do not change the existing items, they are hard coded with
> + * pre-calculated values.
> + */
> +static struct crc_test_record test_data[] = {
> + { .name = "crc64_be",
> + .data = { 0x42F0E1EBA9EA3693, 0x85E1C3D753D46D26,
> + 0xC711223CFA3E5BB5, 0x493366450E42ECDF },
> + .initval = 0x61C8864680B583EB,
> + .expval = 0xb2c863673f4292bf,
> + .handler = test_crc64_be,
> + },
> + {}
> +};
This is incorrect; the test is checksumming data that has a CPU-specific
endianness. So, it will fail on big-endian systems. The data needs to be
declared as a byte or char array instead. See e.g. what crypto/testmgr.h does
for crypto API algorithms.
Also please mark the test data structures 'const'.
- Eric
^ permalink raw reply
* Re: [PATCH v3 bpf-next 6/8] xdp: Add a flag for disabling napi_direct of xdp_return_frame in xdp_mem_info
From: Jakub Kicinski @ 2018-07-24 3:38 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Toshiaki Makita, netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <bd0c97b3-1abe-960e-bed6-d7706f0d7376@lab.ntt.co.jp>
On Tue, 24 Jul 2018 11:43:11 +0900, Toshiaki Makita wrote:
> On 2018/07/24 10:22, Jakub Kicinski wrote:
> > On Mon, 23 Jul 2018 00:13:06 +0900, Toshiaki Makita wrote:
> >> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >>
> >> We need some mechanism to disable napi_direct on calling
> >> xdp_return_frame_rx_napi() from some context.
> >> When veth gets support of XDP_REDIRECT, it will redirects packets which
> >> are redirected from other devices. On redirection veth will reuse
> >> xdp_mem_info of the redirection source device to make return_frame work.
> >> But in this case .ndo_xdp_xmit() called from veth redirection uses
> >> xdp_mem_info which is not guarded by NAPI, because the .ndo_xdp_xmit is
> >> not called directly from the rxq which owns the xdp_mem_info.
> >>
> >> This approach introduces a flag in xdp_mem_info to indicate that
> >> napi_direct should be disabled even when _rx_napi variant is used.
> >>
> >> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >
> > To be clear - you will modify flags of the original source device if it
> > ever redirected a frame to a software device like veth? Seems a bit
> > heavy handed. The xdp_return_frame_rx_napi() is only really used on
> > error paths, but still.. Also as you note the original NAPI can run
> > concurrently with your veth dest one, but also with NAPIs of other veth
> > devices, so the non-atomic xdp.rxq->mem.flags |= XDP_MEM_RF_NO_DIRECT;
> > makes me worried.
>
> xdp_mem_info is copied in xdp_frame in convert_to_xdp_frame() so the
> field is local to the frame. Changing flags affects only the frame.
> xdp.rxq is local to NAPI thread, so no worries about atomicity.
Ah, right! mem_info used to be just 8B, now it would be 12B.
Alternatively we could perhaps add this info to struct redirect_info,
through xdp_do_redirect() to avoid the per-frame cost. I'm not sure
that's better.
> > Would you mind elaborating why not handle the RX completely in the NAPI
> > context of the original device?
>
> Originally it was difficult to implement .ndo_xdp_xmit() and
> .ndo_xdp_flush() model without creating NAPI in veth. Now it is changed
> so I'm not sure how difficult it is at this point.
> But in any case I want to avoid stack inflation by veth NAPI. (Imagine
> some misconfiguration like calling XDP_TX on both side of veth...)
True :/
^ permalink raw reply
* Re: [PATCH] net: axienet: Fix double deregister of mdio
From: Shubhrajyoti Datta @ 2018-07-24 4:42 UTC (permalink / raw)
To: David Miller; +Cc: Shubhrajyoti Datta, netdev, Michal Simek, linux-kernel
In-Reply-To: <20180723.094332.1263746631250670875.davem@davemloft.net>
Hi David,
On Mon, Jul 23, 2018 at 10:13 PM, David Miller <davem@davemloft.net> wrote:
> From: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
> Date: Mon, 23 Jul 2018 14:08:47 +0530
>
>> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
>> index 16c3bfb..757a3b3 100644
>> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
>> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
>> @@ -218,6 +218,7 @@ int axienet_mdio_setup(struct axienet_local *lp, struct device_node *np)
>> ret = of_mdiobus_register(bus, np1);
>> if (ret) {
>> mdiobus_free(bus);
>> + lp->mii_bus = NULL;
>> return ret;
>> }
>
> Your patch was corrupted by your email client, in particular it has transformed TAB
> characters into SPACEs.
>
> Please fix this, email the patch to yourself as a test, and please do
> not send the patch here to the list again until you can successfully
> apply the patch you receive in that test email.
>
>> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
> This is inappropriate for postings to this mailing list, please disable this footer
> if you would like to post here.
>
> Thank you.
Apologies for the same.
Resent now .
^ permalink raw reply
* Re: [PATCH v4 net-next 2/3] rds: Enable RDS IPv6 support
From: Ka-Cheong Poon @ 2018-07-24 3:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, santosh.shilimkar, rds-devel, sowmini.varadhan
In-Reply-To: <20180723.202033.1935833384843765067.davem@davemloft.net>
On 07/24/2018 11:20 AM, David Miller wrote:
> From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> Date: Tue, 24 Jul 2018 11:18:24 +0800
>
>> On 07/24/2018 02:15 AM, David Miller wrote:
>>> From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
>>> Date: Mon, 23 Jul 2018 07:16:11 -0700
>>>
>>>> @@ -163,15 +165,29 @@ int rds_tcp_accept_one(struct socket *sock)
>>>> inet = inet_sk(new_sock->sk);
>>>> + my_addr = &new_sock->sk->sk_v6_rcv_saddr;
>>>> + peer_addr = &new_sock->sk->sk_v6_daddr,
>>>> rdsdebug("accepted tcp %pI6c:%u -> %pI6c:%u\n",
>>> Note that comma, instead of a semicolon, at the end of the peer_addr
>>> assignment.
>>> This doesn't even compile.
>>
>>
>> Strange, the compiler did not complain. Will check why's
>> that.
>
> Try allmodconfig
That catches it. Thanks!
--
K. Poon
ka-cheong.poon@oracle.com
^ permalink raw reply
* Re: [PATCH] Documentation/diff-options: explain different diff algorithms
From: Jonathan Nieder @ 2018-07-24 4:40 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
In-Reply-To: <20180724003619.185290-1-sbeller@google.com>
Hi,
Stefan Beller wrote:
> As a user I wondered what the diff algorithms are about. Offer at least
> a basic explanation on the differences of the diff algorithms.
Interesting. Let's see.
[...]
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -94,16 +94,34 @@ diff" algorithm internally.
> Choose a diff algorithm. The variants are as follows:
> +
> --
> -`default`, `myers`;;
> - The basic greedy diff algorithm. Currently, this is the default.
> `minimal`;;
> + A diff as produced by the basic greedy algorithm described in
Why this reordering?
> + link:http://www.xmailserver.org/diff2.pdf[An O(ND) Difference Algorithm and its Variations]
This URL doesn't seem likely to stay stable. Are appearances
deceiving? (Maybe so, since that's the same host as libxdiff's
homepage <http://www.xmailserver.org/xdiff-lib.html>.) It might be
worth mentioning the author and date just in case.
> - Spend extra time to make sure the smallest possible diff is
> - produced.
> +`default`, `myers`;;
> + The same algorithm as `minimal`, extended with a heuristic to
> + reduce extensive searches. Currently, this is the default.
Amusing --- this means that the Myers diff is spelled as "minimal"
instead of "myers".
> `patience`;;
> - Use "patience diff" algorithm when generating patches.
> + Use "patience diff" algorithm when generating patches. This
> + matches the longest common subsequence of unique lines on
> + both sides, recursively. It obtained its name by the way the
> + longest subsequence is found, as that is a byproduct of the
> + patience sorting algorithm. If there are no unique lines left
> + it falls back to `myers`. Empirically this algorithm produces
> + a more readable output for code, but it does not garantuee
> + the shortest output.
Probably also worth mentioning that this was invented by Bram Cohen
for the bazaar vcs.
> `histogram`;;
> - This algorithm extends the patience algorithm to "support
> - low-occurrence common elements".
> + This algorithm re-implements the `patience` algorithm with
What does reimplements mean here? Do you mean that it is a variation
on patience?
> + "support of low-occurrence common elements" and only picks
> + one element of the LCS for the recursion. It is often the
Does LCS mean longest common subsequence or longest common substring
here? Probably best to spell it out to avoid confusion.
> + fastest, but in cornercases (when there are many longest
s/cornercases/corner cases/
> + common subsequences of the same length) it produces bad
> + results as seen in:
> +
> + seq 1 100 >one
> + echo 99 > two
> + seq 1 2 98 >>two
> + git diff --no-index --histogram one two
I wonder if these details (about all the algorithms) should go in a
separate Diff Algorithms section and this section could focus on
what use cases warrant using each, referring to that section for
details. What do you think?
Thanks and hope that helps,
Jonathan
^ permalink raw reply
* [Drbd-dev] DRBD 9 on Fedora 28
From: Digimer @ 2018-07-24 4:40 UTC (permalink / raw)
To: drbd-dev
Hi all,
I'm trying to get DRBD 9 on Fedora 28 (which I'm using as a dev
platform ahead of RHEL 8 beta). The DRBD that ships with the kernel is
8.4.10.
I've been struggling to build the 9.0.15rc1 RPM without luck. I've
made a few progressions (ie: added kernel-rpm-macros, kernel-devel and
elfutils-devel to BuildRequires).
Has anyone managed to build DRBD9 on Fedora 27+? If so, would you mind
sharing the src.rpm or .spec?
Thanks!
digimer
--
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
^ permalink raw reply
* [PATCH] net: axienet: Fix double deregister of mdio
From: shubhrajyoti.datta @ 2018-07-24 4:39 UTC (permalink / raw)
To: netdev; +Cc: shubhrajyoti.datta, michal.simek, linux-kernel,
Shubhrajyoti Datta
From: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
If the registration fails then mdio_unregister is called.
However at unbind the unregister ia attempted again resulting
in the below crash
[ 73.544038] kernel BUG at drivers/net/phy/mdio_bus.c:415!
[ 73.549362] Internal error: Oops - BUG: 0 [#1] SMP
[ 73.554127] Modules linked in:
[ 73.557168] CPU: 0 PID: 2249 Comm: sh Not tainted 4.14.0 #183
[ 73.562895] Hardware name: xlnx,zynqmp (DT)
[ 73.567062] task: ffffffc879e41180 task.stack: ffffff800cbe0000
[ 73.572973] PC is at mdiobus_unregister+0x84/0x88
[ 73.577656] LR is at axienet_mdio_teardown+0x18/0x30
[ 73.582601] pc : [<ffffff80085fa4cc>] lr : [<ffffff8008616858>]
pstate: 20000145
[ 73.589981] sp : ffffff800cbe3c30
[ 73.593277] x29: ffffff800cbe3c30 x28: ffffffc879e41180
[ 73.598573] x27: ffffff8008a21000 x26: 0000000000000040
[ 73.603868] x25: 0000000000000124 x24: ffffffc879efe920
[ 73.609164] x23: 0000000000000060 x22: ffffffc879e02000
[ 73.614459] x21: ffffffc879e02800 x20: ffffffc87b0b8870
[ 73.619754] x19: ffffffc879e02800 x18: 000000000000025d
[ 73.625050] x17: 0000007f9a719ad0 x16: ffffff8008195bd8
[ 73.630345] x15: 0000007f9a6b3d00 x14: 0000000000000010
[ 73.635640] x13: 74656e7265687465 x12: 0000000000000030
[ 73.640935] x11: 0000000000000030 x10: 0101010101010101
[ 73.646231] x9 : 241f394f42533300 x8 : ffffffc8799f6e98
[ 73.651526] x7 : ffffffc8799f6f18 x6 : ffffffc87b0ba318
[ 73.656822] x5 : ffffffc87b0ba498 x4 : 0000000000000000
[ 73.662117] x3 : 0000000000000000 x2 : 0000000000000008
[ 73.667412] x1 : 0000000000000004 x0 : ffffffc8799f4000
[ 73.672708] Process sh (pid: 2249, stack limit = 0xffffff800cbe0000)
Fix the same by making the bus NULL on unregister.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
index 16c3bfb..757a3b3 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
@@ -218,6 +218,7 @@ int axienet_mdio_setup(struct axienet_local *lp, struct device_node *np)
ret = of_mdiobus_register(bus, np1);
if (ret) {
mdiobus_free(bus);
+ lp->mii_bus = NULL;
return ret;
}
return 0;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: Oleksij Rempel @ 2018-07-24 4:38 UTC (permalink / raw)
To: Vladimir Zapolskiy, Shawn Guo, Fabio Estevam, Rob Herring,
Mark Rutland, A.s. Dong, Vladimir Zapolskiy
Cc: devicetree, kernel, linux-arm-kernel, dl-linux-imx
In-Reply-To: <846bb908-f75e-1988-8f30-e49a537c7969@mleia.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1576 bytes --]
On 24.07.2018 01:31, Vladimir Zapolskiy wrote:
> Hi Oleksij,
>
> On 07/22/2018 09:39 AM, Oleksij Rempel wrote:
>> The Mailbox controller is able to send messages (up to 4 32 bit words)
>> between the endpoints.
>>
>> This driver was tested using the mailbox-test driver sending messages
>> between the Cortex-A7 and the Cortex-M4.
>>
>> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
>> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>
> [snip]
>
>> +static int imx_mu_startup(struct mbox_chan *chan)
>> +{
>> + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
>> + struct imx_mu_con_priv *cp = chan->con_priv;
>> + int ret;
>> +
>> + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL, "imx_mu_chan[%i]",
>> + cp->idx);
>> + if (!cp->irq_desc)
>> + return -ENOMEM;
>> +
>
> Again I would suggest to move this allocation to the loop in .probe function.
Why? In my case I use 2 channels. Why should I allocate 4 descriptors
for using only 2 of them?
The SCU driver will use only one channel...
> [snip]
>
>> +
>> + for (i = 0; i < IMX_MU_CHANS; i++) {
>> + struct imx_mu_con_priv *cp = &priv->con_priv[i];
>> +
>> + cp->idx = i;
>> + cp->irq = irq;
>
> ^^^^ right over here.
>
>> + priv->mbox_chans[i].con_priv = cp;
>> + }
>> +
>
> please feel free to add my technical side review tag to the next version:
>
> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
>
> FWIW I find that review comments from Lucas are pretty valid, I would
> recommend to incorporate them.
Ok
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: Oleksij Rempel @ 2018-07-24 4:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <846bb908-f75e-1988-8f30-e49a537c7969@mleia.com>
On 24.07.2018 01:31, Vladimir Zapolskiy wrote:
> Hi Oleksij,
>
> On 07/22/2018 09:39 AM, Oleksij Rempel wrote:
>> The Mailbox controller is able to send messages (up to 4 32 bit words)
>> between the endpoints.
>>
>> This driver was tested using the mailbox-test driver sending messages
>> between the Cortex-A7 and the Cortex-M4.
>>
>> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
>> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>
> [snip]
>
>> +static int imx_mu_startup(struct mbox_chan *chan)
>> +{
>> + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
>> + struct imx_mu_con_priv *cp = chan->con_priv;
>> + int ret;
>> +
>> + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL, "imx_mu_chan[%i]",
>> + cp->idx);
>> + if (!cp->irq_desc)
>> + return -ENOMEM;
>> +
>
> Again I would suggest to move this allocation to the loop in .probe function.
Why? In my case I use 2 channels. Why should I allocate 4 descriptors
for using only 2 of them?
The SCU driver will use only one channel...
> [snip]
>
>> +
>> + for (i = 0; i < IMX_MU_CHANS; i++) {
>> + struct imx_mu_con_priv *cp = &priv->con_priv[i];
>> +
>> + cp->idx = i;
>> + cp->irq = irq;
>
> ^^^^ right over here.
>
>> + priv->mbox_chans[i].con_priv = cp;
>> + }
>> +
>
> please feel free to add my technical side review tag to the next version:
>
> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
>
> FWIW I find that review comments from Lucas are pretty valid, I would
> recommend to incorporate them.
Ok
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180724/e1b3ccac/attachment.sig>
^ permalink raw reply
* [PATCH 1/5] arm: dts: aspeed: Add coprocessor interrupt controller
From: Benjamin Herrenschmidt @ 2018-07-24 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8Xe53YJ6GmEk6gyN5DNgEHn5V+CGNSKNE-MNw8Osugf2=Q@mail.gmail.com>
On Tue, 2018-07-24 at 13:59 +0930, Joel Stanley wrote:
> On 24 July 2018 at 13:54, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > Add the missing node for the CVIC (the coprocessor interrupt
> > controller) and add a label to the SRAM node so it can be
> > referenced from the board device-tree file.
> >
> > OpenBMC-Staging-Count: 1
>
> We shouldn't be putting this in upstream patches.
Ah oops, I accidentally cherry-picked it back out of your tree.
> I can drop it when I apply if there is no other review.
^ permalink raw reply
* [PATCH 1/5] arm: dts: aspeed: Add coprocessor interrupt controller
From: Benjamin Herrenschmidt @ 2018-07-24 4:36 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <CACPK8Xe53YJ6GmEk6gyN5DNgEHn5V+CGNSKNE-MNw8Osugf2=Q@mail.gmail.com>
On Tue, 2018-07-24 at 13:59 +0930, Joel Stanley wrote:
> On 24 July 2018 at 13:54, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > Add the missing node for the CVIC (the coprocessor interrupt
> > controller) and add a label to the SRAM node so it can be
> > referenced from the board device-tree file.
> >
> > OpenBMC-Staging-Count: 1
>
> We shouldn't be putting this in upstream patches.
Ah oops, I accidentally cherry-picked it back out of your tree.
> I can drop it when I apply if there is no other review.
^ permalink raw reply
* Re: [PATCH v2 1/6] net/mlx5: lay groundwork for switch offloads
From: Shahaf Shuler @ 2018-07-24 4:35 UTC (permalink / raw)
To: Stephen Hemminger, Ferruh Yigit
Cc: Adrien Mazarguil, Nélio Laranjeiro, Yongseok Koh,
dev@dpdk.org
In-Reply-To: <20180723175048.3fcdcc7f@xeon-e3>
Stephen,
Tuesday, July 24, 2018 3:51 AM, Stephen Hemminger:
> Subject: Re: [dpdk-dev] [PATCH v2 1/6] net/mlx5: lay groundwork for switch
> offloads
>
> On Mon, 23 Jul 2018 22:40:47 +0100
> Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >
> > Just to highlight this new PMD level dependency to libmnl.
> >
> > tap pmd also uses netlink and vdev_netvsc also does nl communication,
> > perhaps we can discuss unifying netlink usage around this new library.
> >
> >
>
> I am concerned that this won't work on FreeBSD and it will end up farther
> behind.
Can you elaborate? What is the reason it will not work?
^ permalink raw reply
* [PATCH 1/5] arm: dts: aspeed: Add coprocessor interrupt controller
From: Joel Stanley @ 2018-07-24 4:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724042406.15374-2-benh@kernel.crashing.org>
On 24 July 2018 at 13:54, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Add the missing node for the CVIC (the coprocessor interrupt
> controller) and add a label to the SRAM node so it can be
> referenced from the board device-tree file.
>
> OpenBMC-Staging-Count: 1
We shouldn't be putting this in upstream patches.
I can drop it when I apply if there is no other review.
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 8 +++++++-
> arch/arm/boot/dts/aspeed-g5.dtsi | 9 ++++++++-
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 75df1573380e..b1a19f99a4c9 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -92,6 +92,12 @@
> reg = <0x1e6c0080 0x80>;
> };
>
> + cvic: copro-interrupt-controller at 1e6c2000 {
> + compatible = "aspeed,ast2400-cvic", "aspeed-cvic";
> + valid-sources = <0x7fffffff>;
> + reg = <0x1e6c2000 0x80>;
> + };
> +
> mac0: ethernet at 1e660000 {
> compatible = "aspeed,ast2400-mac", "faraday,ftgmac100";
> reg = <0x1e660000 0x180>;
> @@ -161,7 +167,7 @@
> status = "disabled";
> };
>
> - sram at 1e720000 {
> + sram: sram at 1e720000 {
> compatible = "mmio-sram";
> reg = <0x1e720000 0x8000>; // 32K
> };
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 17f2714d18a7..21141ca1bfa4 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -127,6 +127,13 @@
> reg = <0x1e6c0080 0x80>;
> };
>
> + cvic: copro-interrupt-controller at 1e6c2000 {
> + compatible = "aspeed,ast2500-cvic", "aspeed-cvic";
> + valid-sources = <0xffffffff>;
> + copro-sw-interrupts = <1>;
> + reg = <0x1e6c2000 0x80>;
> + };
> +
> mac0: ethernet at 1e660000 {
> compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
> reg = <0x1e660000 0x180>;
> @@ -211,7 +218,7 @@
> status = "disabled";
> };
>
> - sram at 1e720000 {
> + sram: sram at 1e720000 {
> compatible = "mmio-sram";
> reg = <0x1e720000 0x9000>; // 36K
> };
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH 1/5] arm: dts: aspeed: Add coprocessor interrupt controller
From: Joel Stanley @ 2018-07-24 4:29 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20180724042406.15374-2-benh@kernel.crashing.org>
On 24 July 2018 at 13:54, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Add the missing node for the CVIC (the coprocessor interrupt
> controller) and add a label to the SRAM node so it can be
> referenced from the board device-tree file.
>
> OpenBMC-Staging-Count: 1
We shouldn't be putting this in upstream patches.
I can drop it when I apply if there is no other review.
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 8 +++++++-
> arch/arm/boot/dts/aspeed-g5.dtsi | 9 ++++++++-
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 75df1573380e..b1a19f99a4c9 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -92,6 +92,12 @@
> reg = <0x1e6c0080 0x80>;
> };
>
> + cvic: copro-interrupt-controller at 1e6c2000 {
> + compatible = "aspeed,ast2400-cvic", "aspeed-cvic";
> + valid-sources = <0x7fffffff>;
> + reg = <0x1e6c2000 0x80>;
> + };
> +
> mac0: ethernet at 1e660000 {
> compatible = "aspeed,ast2400-mac", "faraday,ftgmac100";
> reg = <0x1e660000 0x180>;
> @@ -161,7 +167,7 @@
> status = "disabled";
> };
>
> - sram at 1e720000 {
> + sram: sram at 1e720000 {
> compatible = "mmio-sram";
> reg = <0x1e720000 0x8000>; // 32K
> };
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 17f2714d18a7..21141ca1bfa4 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -127,6 +127,13 @@
> reg = <0x1e6c0080 0x80>;
> };
>
> + cvic: copro-interrupt-controller at 1e6c2000 {
> + compatible = "aspeed,ast2500-cvic", "aspeed-cvic";
> + valid-sources = <0xffffffff>;
> + copro-sw-interrupts = <1>;
> + reg = <0x1e6c2000 0x80>;
> + };
> +
> mac0: ethernet at 1e660000 {
> compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
> reg = <0x1e660000 0x180>;
> @@ -211,7 +218,7 @@
> status = "disabled";
> };
>
> - sram at 1e720000 {
> + sram: sram at 1e720000 {
> compatible = "mmio-sram";
> reg = <0x1e720000 0x9000>; // 36K
> };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v1 0/3] [RFC] Speeding up checkout (and merge, rebase, etc)
From: Jeff King @ 2018-07-24 4:27 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Ben Peart, Ben Peart, Git Mailing List, Junio C Hamano
In-Reply-To: <CACsJy8D-3sSnoyQZKxeLK-2RmpJSGkziAp5Gf4QpUnxwnhchSQ@mail.gmail.com>
On Mon, Jul 23, 2018 at 07:03:16PM +0200, Duy Nguyen wrote:
> > > Try bumping core.deltaBaseCacheLimit to see if that has any impact. It's
> > > 96MB by default.
> > >
> > > There may also be some possible work in making it more aggressive about
> > > storing the intermediate results. I seem to recall from past
> > > explorations that it doesn't keep everything, and I don't know if its
> > > heuristics have ever been proven sane.
>
> Could we be a bit more flexible about cache size? Say if we know
> there's 8 GB memory still available, we should be able to use like 1
> GB at least (and that's done automatically without tinkering with
> config).
I have mixed feelings on that kind of auto-scaling for caches. Git isn't
always the only program running (or maybe you even have several git
operations running at once). So in many cases you'd want a more holistic
view of the system, and what resources are available.
The OS already does OK scheduling CPU and the block cache for our mmap'd
files. I don't know if there's a way to communicate with it about this
kind of cache. I guess asking "what memory is free" is one way to do
that. But it's not always the best answer (because we might be happy
trade off some block cache, etc). On the other hand, that would always
give us a conservative value, so if we picked min(96MB, free_mem /
nr_cpu) or something, that might be an OK rule of thumb.
-Peff
^ permalink raw reply
* Re: [pull request][net-next V2 00/12] Mellanox, mlx5e updates 2018-07-18
From: David Miller @ 2018-07-24 3:23 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20180723221129.21625-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 23 Jul 2018 15:11:17 -0700
> This series includes updates for mlx5e net device driver, with a couple
> of major features and some misc updates.
>
> Please notice the mlx5-next merge patch at the beginning:
> "Merge branch 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux"
>
> For more information please see tag log below.
>
> Please pull and let me know if there's any problem.
>
> v1->v2:
> - Dropped "Support PCIe buffer congestion handling via Devlink" patches until the
> comments are addressed.
Pulled, thanks Saeed.
^ permalink raw reply
* Re: [PATCH v4 1/3] lib: add crc64 calculation routines
From: Eric Biggers @ 2018-07-24 4:26 UTC (permalink / raw)
To: Coly Li
Cc: linux-kernel, linux-bcache, linux-block, Andy Shevchenko,
Greg Kroah-Hartman, Michael Lyle, Kent Overstreet, Linus Torvalds,
Thomas Gleixner, Kate Stewart, Andrew Morton, Randy Dunlap
In-Reply-To: <20180718165545.1622-2-colyli@suse.de>
On Thu, Jul 19, 2018 at 12:55:43AM +0800, Coly Li wrote:
> This patch adds the re-write crc64 calculation routines for Linux kernel.
> The CRC64 polynomical arithmetic follows ECMA-182 specification, inspired
"polynomical" => "polynomial". Same everywhere else in the patches.
> + * crc64table[256] is the lookup table of a table-driver 64-bit CRC
"table-driver" => "table-driven"
> + * calculation, which is generated by gen_crc64table.c in kernel build
> + * time. The polynomial of crc64 arithmetic is from ECMA-182 specification
> + * as well, which is defined as,
> + *
> + * x^64 + x^62 + x^57 + x^55 + x^54 + x^53 + x^52 + x^47 + x^46 + x^45 +
> + * x^40 + x^39 + x^38 + x^37 + x^35 + x^33 + x^32 + x^31 + x^29 + x^27 +
> + * x^24 + x^23 + x^22 + x^21 + x^19 + x^17 + x^13 + x^12 + x^10 + x^9 +
> + * x^7 + x^4 + x + 1
> + *
> + * Copyright 2018 SUSE Linux.
> + * Author: Coly Li <colyli@suse.de>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include "crc64table.h"
> +
> +MODULE_DESCRIPTION("CRC64 calculations");
> +MODULE_LICENSE("GPL v2");
> +
> +/**
> + * crc64_be - Calculate bitwise big-endian ECMA-182 CRC64
> + * @crc: seed value for computation. 0 for a new CRC computing, or the
> + * previous crc64 value if computing incrementally.
"0 or (u64)~0 for a new CRC calculation". Both conventions are common in CRCs.
In fact the all-ones convention is generally considered better, because it
causes leading zeroes in the data to affect the checksum.
> + * @p: pointer to buffer over which CRC64 is run
> + * @len: length of buffer @p
> + */
> +u64 __pure crc64_be(u64 crc, const void *p, size_t len)
> +{
> + size_t i, t;
> +
> + const unsigned char *_p = p;
> +
> + for (i = 0; i < len; i++) {
> + t = ((crc >> 56) ^ (*_p++)) & 0xFF;
> + crc = crc64table[t] ^ (crc << 8);
> + }
> +
> + return crc;
> +}
> +EXPORT_SYMBOL_GPL(crc64_be);
> diff --git a/lib/gen_crc64table.c b/lib/gen_crc64table.c
> new file mode 100644
> index 000000000000..8296b0c3ea30
> --- /dev/null
> +++ b/lib/gen_crc64table.c
> @@ -0,0 +1,68 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Generate lookup table for the talbe-driven CRC64 calculation.
"talbe-driven" => "table-driven"
> + *
> + * gen_crc64table is executed in kernel build time and generates
> + * lib/crc64table.h. This header is included by lib/crc64.c for
> + * the table-driver CRC64 calculation.
"table-driver" => "table-driven"
> + *
> + * See lib/crc64.c for more information about which specification
> + * and polynomical arithmetic that gen_crc64table.c follows to
> + * generate the lookup table.
> + *
> + * Copyright 2018 SUSE Linux.
> + * Author: Coly Li <colyli@suse.de>
> + */
> +#include <inttypes.h>
> +#include <stdio.h>
> +
> +#include <linux/swab.h>
> +
> +#define CRC64_ECMA182_POLY 0x42F0E1EBA9EA3693ULL
> +
> +static int64_t crc64_table[256] = {0};
This really should be uint64_t, not int64_t.
> +
> +static void generate_crc64_table(void)
> +{
> + uint64_t i, j, c, crc;
> +
> + for (i = 0; i < 256; i++) {
> + crc = 0;
> + c = i << 56;
> +
> + for (j = 0; j < 8; j++) {
> + if ((crc ^ c) & 0x8000000000000000ULL)
> + crc = (crc << 1) ^ CRC64_ECMA182_POLY;
> + else
> + crc <<= 1;
> + c <<= 1;
> + }
> +
> + crc64_table[i] = crc;
> + }
> +}
> +
> +static void print_crc64_table(void)
> +{
> + int i;
> +
> + printf("/* this file is generated - do not edit */\n\n");
> + printf("#include <linux/types.h>\n");
> + printf("#include <linux/cache.h>\n\n");
> + printf("static const u64 ____cacheline_aligned crc64table[256] = {\n");
> + for (i = 0; i < 256; i++) {
> + printf("\t0x%016" PRIx64 "ULL", crc64_table[i]);
> + if (i & 0x1)
> + printf(",\n");
> + else
> + printf(", ");
> + }
> + printf("};\n");
> +}
> +
> +int main(int argc, char *argv[])
> +{
> + generate_crc64_table();
> + print_crc64_table();
> + return 0;
> +}
> --
> 2.17.1
>
- Eric
^ permalink raw reply
* Re: [PATCH v4 net-next 2/3] rds: Enable RDS IPv6 support
From: David Miller @ 2018-07-24 3:20 UTC (permalink / raw)
To: ka-cheong.poon; +Cc: netdev, santosh.shilimkar, rds-devel, sowmini.varadhan
In-Reply-To: <0257db98-60d4-6bca-66b5-c0bd0f63d234@oracle.com>
From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date: Tue, 24 Jul 2018 11:18:24 +0800
> On 07/24/2018 02:15 AM, David Miller wrote:
>> From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
>> Date: Mon, 23 Jul 2018 07:16:11 -0700
>>
>>> @@ -163,15 +165,29 @@ int rds_tcp_accept_one(struct socket *sock)
>>> inet = inet_sk(new_sock->sk);
>>> + my_addr = &new_sock->sk->sk_v6_rcv_saddr;
>>> + peer_addr = &new_sock->sk->sk_v6_daddr,
>>> rdsdebug("accepted tcp %pI6c:%u -> %pI6c:%u\n",
>> Note that comma, instead of a semicolon, at the end of the peer_addr
>> assignment.
>> This doesn't even compile.
>
>
> Strange, the compiler did not complain. Will check why's
> that.
Try allmodconfig
^ permalink raw reply
* freepage accounting bug with CMA/migrate isolation
From: Mike Kravetz @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-mm@kvack.org; +Cc: Vlastimil Babka, 'Joonsoo Kim', Laura Abbott
With v4.17, I can see an issue like those addressed in commits 3c605096d315
("mm/page_alloc: restrict max order of merging on isolated pageblock")
and d9dddbf55667 ("mm/page_alloc: prevent merging between isolated and
other pageblocks"). After running a CMA stress test for a while, I see:
MemTotal: 8168384 kB
MemFree: 8457232 kB
MemAvailable: 9204844 kB
If I let the test run, MemFree and MemAvailable will continue to grow.
I am certain the issue is with pageblocks of migratetype ISOLATED. If
I disable all special 'is_migrate_isolate' checks in freepage accounting,
the issue goes away. Further, I am pretty sure the issue has to do with
pageblock merging and or page orders spanning pageblocks. If I make
pageblock_order equal MAX_ORDER-1, the issue also goes away.
Just looking for suggesting in where/how to debug. I've been hacking on
this without much success.
--
Mike Kravetz
^ permalink raw reply
* [PATCH 5/5] arm: dts: aspeed: Add power9 CFAM dtsi and use it on OpenPower P9 machines
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
This provides proper chip IDs but also adds the various sub-devices
necessary for the future OCC driver among other. All the added nodes
comply with the existing upstream FSI bindings.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts | 1 +
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 2 +
.../boot/dts/aspeed-bmc-opp-witherspoon.dts | 2 +
arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 2 +
arch/arm/boot/dts/ibm-power9-cfam.dtsi | 104 ++++++++++++++++++
arch/arm/boot/dts/ibm-power9-dual.dtsi | 58 ++++++++++
6 files changed, 169 insertions(+)
create mode 100644 arch/arm/boot/dts/ibm-power9-cfam.dtsi
create mode 100644 arch/arm/boot/dts/ibm-power9-dual.dtsi
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts b/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
index d598b6391362..e744d6532cbb 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
@@ -323,3 +323,4 @@
status = "okay";
};
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 852f264b9569..ead2a84f16bd 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
@@ -282,3 +282,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
index 656036106001..33ea336f0c17 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
@@ -583,3 +583,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
index 2c5aa90a546d..05df11cacb21 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
@@ -435,3 +435,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/ibm-power9-cfam.dtsi b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
new file mode 100644
index 000000000000..5bda517f93cc
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+#define __MAKE_LABEL(p,i) p##i
+#define _MAKE_LABEL(p,i) __MAKE_LABEL(p,i)
+#define HUB_LABEL _MAKE_LABEL(fsi_hub,CFAM_CHIP_ID)
+#define I2C_LABEL(n) _MAKE_LABEL(_MAKE_LABEL(cfam,CFAM_CHIP_ID),_i2c##n)
+
+#address-cells = <1>;
+#size-cells = <1>;
+chip-id = <CFAM_CHIP_ID>;
+
+scom at 1000 {
+ compatible = "ibm,fsi2pib";
+ reg = <0x1000 0x400>;
+};
+
+i2c at 1800 {
+ compatible = "ibm,fsi-i2c-master";
+ reg = <0x1800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ I2C_LABEL(0): i2c-bus at 0 {
+ reg = <0>;
+ };
+
+ I2C_LABEL(1): i2c-bus at 1 {
+ reg = <1>;
+ };
+
+ I2C_LABEL(2): i2c-bus at 2 {
+ reg = <2>;
+ };
+
+ I2C_LABEL(3): i2c-bus at 3 {
+ reg = <3>;
+ };
+
+ I2C_LABEL(4): i2c-bus at 4 {
+ reg = <4>;
+ };
+
+ I2C_LABEL(5): i2c-bus at 5 {
+ reg = <5>;
+ };
+
+ I2C_LABEL(6): i2c-bus at 6 {
+ reg = <6>;
+ };
+
+ I2C_LABEL(7): i2c-bus at 7 {
+ reg = <7>;
+ };
+
+ I2C_LABEL(8): i2c-bus at 8 {
+ reg = <8>;
+ };
+
+ I2C_LABEL(9): i2c-bus at 9 {
+ reg = <9>;
+ };
+
+ I2C_LABEL(10): i2c-bus at 10 {
+ reg = <10>;
+ };
+
+ I2C_LABEL(11): i2c-bus at 11 {
+ reg = <11>;
+ };
+
+ I2C_LABEL(12): i2c-bus at 12 {
+ reg = <12>;
+ };
+
+ I2C_LABEL(13): i2c-bus at 13 {
+ reg = <13>;
+ };
+
+ I2C_LABEL(14): i2c-bus at 14 {
+ reg = <14>;
+ };
+};
+
+sbefifo at 2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+HUB_LABEL: hub at 3400 {
+ compatible = "fsi-master-hub";
+ reg = <0x3400 0x400>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ no-scan-on-init;
+};
+
+#undef __MAKE_LABEL
+#undef _MAKE_LABEL
+#undef HUB_LABEL
+#undef I2C_LABEL
diff --git a/arch/arm/boot/dts/ibm-power9-dual.dtsi b/arch/arm/boot/dts/ibm-power9-dual.dtsi
new file mode 100644
index 000000000000..f6a82ad43ff8
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power9-dual.dtsi
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+/* Instantiate chip 0 */
+#define CFAM_CHIP_ID 0
+&fsi {
+ cfam at 0,0 {
+ reg = <0 0>;
+ #include "ibm-power9-cfam.dtsi"
+ };
+};
+#undef CFAM_CHIP_ID
+
+/* Instantiate chip 1 */
+#define CFAM_CHIP_ID 1
+&fsi_hub0 {
+ cfam at 1,0 {
+ reg = <1 0>;
+ #include "ibm-power9-cfam.dtsi"
+ };
+};
+#undef CFAM_CHIP_ID
+
+/ {
+ aliases {
+ i2c100 = &cfam0_i2c0;
+ i2c101 = &cfam0_i2c1;
+ i2c102 = &cfam0_i2c2;
+ i2c103 = &cfam0_i2c3;
+ i2c104 = &cfam0_i2c4;
+ i2c105 = &cfam0_i2c5;
+ i2c106 = &cfam0_i2c6;
+ i2c107 = &cfam0_i2c7;
+ i2c108 = &cfam0_i2c8;
+ i2c109 = &cfam0_i2c9;
+ i2c110 = &cfam0_i2c10;
+ i2c111 = &cfam0_i2c11;
+ i2c112 = &cfam0_i2c12;
+ i2c113 = &cfam0_i2c13;
+ i2c114 = &cfam0_i2c14;
+ i2c200 = &cfam1_i2c0;
+ i2c201 = &cfam1_i2c1;
+ i2c202 = &cfam1_i2c2;
+ i2c203 = &cfam1_i2c3;
+ i2c204 = &cfam1_i2c4;
+ i2c205 = &cfam1_i2c5;
+ i2c206 = &cfam1_i2c6;
+ i2c207 = &cfam1_i2c7;
+ i2c208 = &cfam1_i2c8;
+ i2c209 = &cfam1_i2c9;
+ i2c210 = &cfam1_i2c10;
+ i2c211 = &cfam1_i2c11;
+ i2c212 = &cfam1_i2c12;
+ i2c213 = &cfam1_i2c13;
+ i2c214 = &cfam1_i2c14;
+ };
+};
+
--
2.17.1
^ permalink raw reply related
* [PATCH 5/5] arm: dts: aspeed: Add power9 CFAM dtsi and use it on OpenPower P9 machines
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
This provides proper chip IDs but also adds the various sub-devices
necessary for the future OCC driver among other. All the added nodes
comply with the existing upstream FSI bindings.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts | 1 +
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 2 +
.../boot/dts/aspeed-bmc-opp-witherspoon.dts | 2 +
arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 2 +
arch/arm/boot/dts/ibm-power9-cfam.dtsi | 104 ++++++++++++++++++
arch/arm/boot/dts/ibm-power9-dual.dtsi | 58 ++++++++++
6 files changed, 169 insertions(+)
create mode 100644 arch/arm/boot/dts/ibm-power9-cfam.dtsi
create mode 100644 arch/arm/boot/dts/ibm-power9-dual.dtsi
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts b/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
index d598b6391362..e744d6532cbb 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
@@ -323,3 +323,4 @@
status = "okay";
};
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 852f264b9569..ead2a84f16bd 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
@@ -282,3 +282,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
index 656036106001..33ea336f0c17 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
@@ -583,3 +583,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
index 2c5aa90a546d..05df11cacb21 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
@@ -435,3 +435,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/ibm-power9-cfam.dtsi b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
new file mode 100644
index 000000000000..5bda517f93cc
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+#define __MAKE_LABEL(p,i) p##i
+#define _MAKE_LABEL(p,i) __MAKE_LABEL(p,i)
+#define HUB_LABEL _MAKE_LABEL(fsi_hub,CFAM_CHIP_ID)
+#define I2C_LABEL(n) _MAKE_LABEL(_MAKE_LABEL(cfam,CFAM_CHIP_ID),_i2c##n)
+
+#address-cells = <1>;
+#size-cells = <1>;
+chip-id = <CFAM_CHIP_ID>;
+
+scom at 1000 {
+ compatible = "ibm,fsi2pib";
+ reg = <0x1000 0x400>;
+};
+
+i2c at 1800 {
+ compatible = "ibm,fsi-i2c-master";
+ reg = <0x1800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ I2C_LABEL(0): i2c-bus at 0 {
+ reg = <0>;
+ };
+
+ I2C_LABEL(1): i2c-bus at 1 {
+ reg = <1>;
+ };
+
+ I2C_LABEL(2): i2c-bus at 2 {
+ reg = <2>;
+ };
+
+ I2C_LABEL(3): i2c-bus at 3 {
+ reg = <3>;
+ };
+
+ I2C_LABEL(4): i2c-bus at 4 {
+ reg = <4>;
+ };
+
+ I2C_LABEL(5): i2c-bus at 5 {
+ reg = <5>;
+ };
+
+ I2C_LABEL(6): i2c-bus at 6 {
+ reg = <6>;
+ };
+
+ I2C_LABEL(7): i2c-bus at 7 {
+ reg = <7>;
+ };
+
+ I2C_LABEL(8): i2c-bus at 8 {
+ reg = <8>;
+ };
+
+ I2C_LABEL(9): i2c-bus at 9 {
+ reg = <9>;
+ };
+
+ I2C_LABEL(10): i2c-bus at 10 {
+ reg = <10>;
+ };
+
+ I2C_LABEL(11): i2c-bus at 11 {
+ reg = <11>;
+ };
+
+ I2C_LABEL(12): i2c-bus at 12 {
+ reg = <12>;
+ };
+
+ I2C_LABEL(13): i2c-bus at 13 {
+ reg = <13>;
+ };
+
+ I2C_LABEL(14): i2c-bus at 14 {
+ reg = <14>;
+ };
+};
+
+sbefifo at 2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+HUB_LABEL: hub at 3400 {
+ compatible = "fsi-master-hub";
+ reg = <0x3400 0x400>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ no-scan-on-init;
+};
+
+#undef __MAKE_LABEL
+#undef _MAKE_LABEL
+#undef HUB_LABEL
+#undef I2C_LABEL
diff --git a/arch/arm/boot/dts/ibm-power9-dual.dtsi b/arch/arm/boot/dts/ibm-power9-dual.dtsi
new file mode 100644
index 000000000000..f6a82ad43ff8
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power9-dual.dtsi
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+/* Instantiate chip 0 */
+#define CFAM_CHIP_ID 0
+&fsi {
+ cfam at 0,0 {
+ reg = <0 0>;
+ #include "ibm-power9-cfam.dtsi"
+ };
+};
+#undef CFAM_CHIP_ID
+
+/* Instantiate chip 1 */
+#define CFAM_CHIP_ID 1
+&fsi_hub0 {
+ cfam at 1,0 {
+ reg = <1 0>;
+ #include "ibm-power9-cfam.dtsi"
+ };
+};
+#undef CFAM_CHIP_ID
+
+/ {
+ aliases {
+ i2c100 = &cfam0_i2c0;
+ i2c101 = &cfam0_i2c1;
+ i2c102 = &cfam0_i2c2;
+ i2c103 = &cfam0_i2c3;
+ i2c104 = &cfam0_i2c4;
+ i2c105 = &cfam0_i2c5;
+ i2c106 = &cfam0_i2c6;
+ i2c107 = &cfam0_i2c7;
+ i2c108 = &cfam0_i2c8;
+ i2c109 = &cfam0_i2c9;
+ i2c110 = &cfam0_i2c10;
+ i2c111 = &cfam0_i2c11;
+ i2c112 = &cfam0_i2c12;
+ i2c113 = &cfam0_i2c13;
+ i2c114 = &cfam0_i2c14;
+ i2c200 = &cfam1_i2c0;
+ i2c201 = &cfam1_i2c1;
+ i2c202 = &cfam1_i2c2;
+ i2c203 = &cfam1_i2c3;
+ i2c204 = &cfam1_i2c4;
+ i2c205 = &cfam1_i2c5;
+ i2c206 = &cfam1_i2c6;
+ i2c207 = &cfam1_i2c7;
+ i2c208 = &cfam1_i2c8;
+ i2c209 = &cfam1_i2c9;
+ i2c210 = &cfam1_i2c10;
+ i2c211 = &cfam1_i2c11;
+ i2c212 = &cfam1_i2c12;
+ i2c213 = &cfam1_i2c13;
+ i2c214 = &cfam1_i2c14;
+ };
+};
+
--
2.17.1
^ permalink raw reply related
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.