* imaging services
From: Jeremy @ 2018-07-27 22:32 UTC (permalink / raw)
To: netdev
I would like to contact the person who manages your images for your
company?
We services such as background image cut out, clipping path, shadow adding
(drop shadow, reflection shadow, natural shadow, mirror effect), image
masking, product image editing.
The following are the kind of services together:
Clipping Path Service
Cut out image,Image Clipping, Clip image
Photo Masking Service
Crop image, Photo cut out
Beauty Retouching, Model retouching
We can give you editing test on your photos.
Also, we also use the most recent application as well as techniques such as
Adobe Photoshop.
Thanks,
Jeremy
^ permalink raw reply
* [PATCH] net: ethernet: realtek: r8169: Add spaces after commas coding style issue
From: Sohil Ladhani @ 2018-07-28 9:02 UTC (permalink / raw)
To: davem; +Cc: nic_swsd, netdev, linux-kernel, Sohil Ladhani
Fixed a coding style issue
Signed-off-by: Sohil Ladhani <supertakumi86@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index f4cae2be0fda..e4754f336c34 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -61,7 +61,7 @@
#define assert(expr) \
if (!(expr)) { \
printk( "Assertion failed! %s,%s,%s,line=%d\n", \
- #expr,__FILE__,__func__,__LINE__); \
+ #expr, __FILE__, __func__, __LINE__); \
}
#define dprintk(fmt, args...) \
do { printk(KERN_DEBUG PFX fmt, ## args); } while (0)
--
2.18.0
^ permalink raw reply related
* [PATCH] net: lan78xx: fix rx handling before first packet is send
From: Stefan Wahren @ 2018-07-28 7:52 UTC (permalink / raw)
To: Woojung Huh, UNGLinuxDriver, David S. Miller
Cc: Greg Kroah-Hartman, Dave Stevenson, netdev, linux-usb,
Stefan Wahren
As long the bh tasklet isn't scheduled once, no packet from the rx path
will be handled. Since the tx path also schedule the same tasklet
this situation only persits until the first packet transmission.
So fix this issue by scheduling the tasklet after link reset.
Link: https://github.com/raspberrypi/linux/issues/2617
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet")
Suggested-by: Floris Bos <bos@je-eigen-domein.nl>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
drivers/net/usb/lan78xx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index ed10d49..aeca484 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1242,6 +1242,8 @@ static int lan78xx_link_reset(struct lan78xx_net *dev)
mod_timer(&dev->stat_monitor,
jiffies + STAT_UPDATE_TIMER);
}
+
+ tasklet_schedule(&dev->bh);
}
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] qed: remove redundant functions qed_get_cm_pq_idx_rl
From: YueHaibing @ 2018-07-28 10:23 UTC (permalink / raw)
To: davem, Ariel.Elior, everest-linux-l2; +Cc: linux-kernel, netdev, YueHaibing
There are no in-tree callers of qed_get_cm_pq_idx_rl since it be there,
so it can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index e5249b4..37817b3 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -507,16 +507,6 @@ u16 qed_get_cm_pq_idx_vf(struct qed_hwfn *p_hwfn, u16 vf)
return qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_VFS) + vf;
}
-u16 qed_get_cm_pq_idx_rl(struct qed_hwfn *p_hwfn, u8 rl)
-{
- u16 max_rl = qed_init_qm_get_num_pf_rls(p_hwfn);
-
- if (rl > max_rl)
- DP_ERR(p_hwfn, "rl %d must be smaller than %d\n", rl, max_rl);
-
- return qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_RLS) + rl;
-}
-
/* Functions for creating specific types of pqs */
static void qed_init_qm_lb_pq(struct qed_hwfn *p_hwfn)
{
--
2.7.0
^ permalink raw reply related
* [PATCH net-next] act_pedit: remove unnecessary semicolon
From: YueHaibing @ 2018-07-28 10:29 UTC (permalink / raw)
To: davem, jhs, xiyou.wangcong, jiri; +Cc: linux-kernel, netdev, YueHaibing
net/sched/act_pedit.c:289:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/sched/act_pedit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
index 9ab5d81..43ba999 100644
--- a/net/sched/act_pedit.c
+++ b/net/sched/act_pedit.c
@@ -286,7 +286,7 @@ static int pedit_skb_hdr_offset(struct sk_buff *skb,
default:
ret = -EINVAL;
break;
- };
+ }
return ret;
}
--
2.7.0
^ permalink raw reply related
* [PATCH net-next] cls_bpf: Use kmemdup instead of duplicating it in cls_bpf_prog_from_ops
From: YueHaibing @ 2018-07-28 10:35 UTC (permalink / raw)
To: davem, ast, daniel, jhs, xiyou.wangcong, jiri
Cc: linux-kernel, netdev, YueHaibing
Replace calls to kmalloc followed by a memcpy with a direct call to
kmemdup.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/sched/cls_bpf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index 66e0ac9..fa6fe2f 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -349,12 +349,10 @@ static int cls_bpf_prog_from_ops(struct nlattr **tb, struct cls_bpf_prog *prog)
if (bpf_size != nla_len(tb[TCA_BPF_OPS]))
return -EINVAL;
- bpf_ops = kzalloc(bpf_size, GFP_KERNEL);
+ bpf_ops = kmemdup(nla_data(tb[TCA_BPF_OPS]), bpf_size, GFP_KERNEL);
if (bpf_ops == NULL)
return -ENOMEM;
- memcpy(bpf_ops, nla_data(tb[TCA_BPF_OPS]), bpf_size);
-
fprog_tmp.len = bpf_num_ops;
fprog_tmp.filter = bpf_ops;
--
2.7.0
^ permalink raw reply related
* [PATCH net-next] act_bpf: Use kmemdup instead of duplicating it in tcf_bpf_init_from_ops
From: YueHaibing @ 2018-07-28 10:38 UTC (permalink / raw)
To: davem, ast, daniel, jhs, xiyou.wangcong, jiri
Cc: linux-kernel, netdev, YueHaibing
Replace calls to kmalloc followed by a memcpy with a direct call to
kmemdup.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/sched/act_bpf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
index 06f743d..6203eb0 100644
--- a/net/sched/act_bpf.c
+++ b/net/sched/act_bpf.c
@@ -196,12 +196,10 @@ static int tcf_bpf_init_from_ops(struct nlattr **tb, struct tcf_bpf_cfg *cfg)
if (bpf_size != nla_len(tb[TCA_ACT_BPF_OPS]))
return -EINVAL;
- bpf_ops = kzalloc(bpf_size, GFP_KERNEL);
+ bpf_ops = kmemdup(nla_data(tb[TCA_ACT_BPF_OPS]), bpf_size, GFP_KERNEL);
if (bpf_ops == NULL)
return -ENOMEM;
- memcpy(bpf_ops, nla_data(tb[TCA_ACT_BPF_OPS]), bpf_size);
-
fprog_tmp.len = bpf_num_ops;
fprog_tmp.filter = bpf_ops;
--
2.7.0
^ permalink raw reply related
* (unknown),
From: Andrew Martinez @ 2018-07-28 10:14 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 158 bytes --]
Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere Informationen
Do you need a loan of any kind? If Yes email us now for more info
[-- Attachment #2: Type: text/html, Size: 399 bytes --]
^ permalink raw reply
* (unknown),
From: Andrew Martinez @ 2018-07-28 10:46 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 252 bytes --]
body {height: 100%; color:#000000; font-size:12pt; font-family:arial, helvetica, sans-serif;}
Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere Informationen
Do you need a loan of any kind? If Yes email us now for more info
[-- Attachment #2: Type: text/html, Size: 519 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next] net: ethernet: ti: cpsw: replace unnecessarily macroses on functions
From: Ivan Khoronzhuk @ 2018-07-28 14:41 UTC (permalink / raw)
To: Joe Perches
Cc: grygorii.strashko, davem, linux-omap, netdev, linux-kernel,
andrew
In-Reply-To: <c2b3f36b8e7e1a2799580e76f19a267351da5491.camel@perches.com>
On Fri, Jul 27, 2018 at 04:30:54PM -0700, Joe Perches wrote:
>On Sat, 2018-07-28 at 01:57 +0300, Ivan Khoronzhuk wrote:
>> Replace ugly macroses on functions.
>
>trivia:
>
>As cpsw_src_port_detect is only used once, and is a
>very small function, it might make the code more
>intelligible to just directly code it where it's used.
>
>> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
>[]
>> @@ -565,40 +565,40 @@ static const struct cpsw_stats cpsw_gstrings_ch_stats[] = {
>[]
>> +static void cpsw_src_port_detect(struct cpsw_common *cpsw, int status,
>> + struct sk_buff *skb)
>> +{
>> + if (!cpsw->data.dual_emac)
>> + return;
>> +
>> + if (CPDMA_RX_SOURCE_PORT(status) == 1)
>> + skb->dev = cpsw->slaves[0].ndev;
>> + else if (CPDMA_RX_SOURCE_PORT(status) == 2)
>> + skb->dev = cpsw->slaves[1].ndev;
>> +}
>[]
>> @@ -801,7 +801,8 @@ static void cpsw_rx_handler(void *token, int len, int status)
>> int ret = 0;
>> struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
>>
>> - cpsw_dual_emac_src_port_detect(cpsw, status, ndev, skb);
>> + cpsw_src_port_detect(cpsw, status, skb);
>
>here
Can put here, instead of function, the following:
if (cpsw->data.dual_emac) {
port = CPDMA_RX_SOURCE_PORT(status);
if (port) {
ndev = cpsw->slaves[--port].ndev;
skb->dev = ndev;
}
}
if no objection ofc.
>
>> + ndev = skb->dev;
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH net-next] sysfs: Fix regression when adding a file to an existing group
From: Heiner Kallweit @ 2018-07-28 15:47 UTC (permalink / raw)
To: Tyler Hicks, David S. Miller
Cc: Greg Kroah-Hartman, Dmitry Torokhov, linux-kernel, netdev
In-Reply-To: <1532727207-10912-1-git-send-email-tyhicks@canonical.com>
On 27.07.2018 23:33, Tyler Hicks wrote:
> Commit 5f81880d5204 ("sysfs, kobject: allow creating kobject belonging
> to arbitrary users") incorrectly changed the argument passed as the
> parent parameter when calling sysfs_add_file_mode_ns(). This caused some
> sysfs attribute files to not be added correctly to certain groups.
>
> Fixes: 5f81880d5204 ("sysfs, kobject: allow creating kobject belonging to arbitrary users")
> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
> Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
>
> Note, this was a regression exclusively in linux-next and never made it to
> Linus' tree. There's no need to queue it up for linux-stable.
>
> fs/sysfs/file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index fa46216523cf..052e5ad9a4d2 100644
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -373,7 +373,7 @@ int sysfs_add_file_to_group(struct kobject *kobj,
> return -ENOENT;
>
> kobject_get_ownership(kobj, &uid, &gid);
> - error = sysfs_add_file_mode_ns(kobj->sd, attr, false,
> + error = sysfs_add_file_mode_ns(parent, attr, false,
> attr->mode, uid, gid, NULL);
> kernfs_put(parent);
>
>
Tested-by: Heiner Kallweit <hkallweit1@gmail.com>
^ permalink raw reply
* Re: [PATCH 00/18] xfrm: Add compat layer
From: Dmitry Safonov @ 2018-07-28 16:26 UTC (permalink / raw)
To: Nathan Harold
Cc: Florian Westphal, Steffen Klassert, linux-kernel, David S. Miller,
Herbert Xu, Dmitry Safonov, netdev, Andy Lutomirski,
Ard Biesheuvel, H. Peter Anvin, Ingo Molnar, John Stultz,
Kirill A. Shutemov, Oleg Nesterov, Stephen Boyd, Steven Rostedt,
Thomas Gleixner, x86, linux-efi, Andrew Morton,
Greg Kroah-Hartman
In-Reply-To: <CADhJOfam+cY8uD4XTGvZSEFQdAgTu49G6cg6c64NJoP3bNuBmw@mail.gmail.com>
On Fri, 2018-07-27 at 09:48 -0700, Nathan Harold wrote:
> We (Android) are very interested in removing the restriction for 32-
> bit userspace processes accessing xfrm netlink on 64-bit kernels.
> IPsec support is required to pass Android conformance tests, and any
> manufacturer wishing to ship 32-bit userspace with a recent kernel
> needs out-of-tree changes (removing the compat_task check) to do so.
Glad to hear - that justify my attempts more :)
> That said, it’s not difficult to work around alignment issues
> directly in userspace, so maybe we could just remove the check and
> make this the caller's responsibility? Here’s an example of the
> workaround currently in the Android tree:
> https://android.googlesource.com/platform/system/netd/+/refs/heads/ma
> ster/server/XfrmController.h#257
We've kinda same workarounds in our userspace..
But I don't think reverting the check makes much sense - it'll make
broken compat ABI in stone.
If you're fine with disgraceful hacks and just want to get rid of
additional non-mainstream patch - you can make 64-bit syscalls from 32-
bit task (hint: examples in x86 selftests).
> We could also employ a (relatively simple) solution such as the one
> above in the uapi XFRM header itself, though it would require a
> caller to declare the target kernel ABI at compile time. Maybe that’s
> not unthinkable for an uncommon case?
Well, I think, I'll rework my patches set according to critics and
separate compat xfrm layer. I've already a selftest to check that 32/64
bit xfrm works - so the most time-taking part is done.
So, if you'll wait a week or two - you may help me to justify acception
of mainstreaming those patches.
> On Fri, Jul 27, 2018 at 7:51 AM, Dmitry Safonov <dima@arista.com>
> wrote:
> > On Fri, 2018-07-27 at 16:19 +0200, Florian Westphal wrote:
> > > Dmitry Safonov <dima@arista.com> wrote:
> > > > 1. It will double copy netlink messages, making it O(n) instead
> > of
> > > > O(1), where n - is number of bind()s.. Probably we don't care
> > much.
> > >
> > > About those bind() patches, I don't understand why they are
> > needed.
> > >
> > > Why can't you just add the compat skb to the native skb when
> > doing
> > > the multicast call?
> > >
> > > skb_shinfo(skb)->frag_list = compat_skb;
> > > xfrm_nlmsg_multicast(net, skb, 0, ...
> >
> > Oh yeah, sorry, I think I misread the patch - will try to add
> > compat
> > skb in the multicast call.
> >
--
Thanks,
Dmitry
^ permalink raw reply
* [PATCH bpf] bpf: use GFP_ATOMIC instead of GFP_KERNEL in bpf_parse_prog()
From: Taehee Yoo @ 2018-07-28 15:28 UTC (permalink / raw)
To: daniel, ast; +Cc: netdev, ap420073
bpf_parse_prog() is protected by rcu_read_lock().
so that GFP_KERNEL is not allowed in the bpf_parse_prog().
[51015.579396] =============================
[51015.579418] WARNING: suspicious RCU usage
[51015.579444] 4.18.0-rc6+ #208 Not tainted
[51015.579464] -----------------------------
[51015.579488] ./include/linux/rcupdate.h:303 Illegal context switch in RCU read-side critical section!
[51015.579510] other info that might help us debug this:
[51015.579532] rcu_scheduler_active = 2, debug_locks = 1
[51015.579556] 2 locks held by ip/1861:
[51015.579577] #0: 00000000a8c12fd1 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x2e0/0x910
[51015.579711] #1: 00000000bf815f8e (rcu_read_lock){....}, at: lwtunnel_build_state+0x96/0x390
[51015.579842] stack backtrace:
[51015.579869] CPU: 0 PID: 1861 Comm: ip Not tainted 4.18.0-rc6+ #208
[51015.579891] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015
[51015.579911] Call Trace:
[51015.579950] dump_stack+0x74/0xbb
[51015.580000] ___might_sleep+0x16b/0x3a0
[51015.580047] __kmalloc_track_caller+0x220/0x380
[51015.580077] kmemdup+0x1c/0x40
[51015.580077] bpf_parse_prog+0x10e/0x230
[51015.580164] ? kasan_kmalloc+0xa0/0xd0
[51015.580164] ? bpf_destroy_state+0x30/0x30
[51015.580164] ? bpf_build_state+0xe2/0x3e0
[51015.580164] bpf_build_state+0x1bb/0x3e0
[51015.580164] ? bpf_parse_prog+0x230/0x230
[51015.580164] ? lock_is_held_type+0x123/0x1a0
[51015.580164] lwtunnel_build_state+0x1aa/0x390
[51015.580164] fib_create_info+0x1579/0x33d0
[51015.580164] ? sched_clock_local+0xe2/0x150
[51015.580164] ? fib_info_update_nh_saddr+0x1f0/0x1f0
[51015.580164] ? sched_clock_local+0xe2/0x150
[51015.580164] fib_table_insert+0x201/0x1990
[51015.580164] ? lock_downgrade+0x610/0x610
[51015.580164] ? fib_table_lookup+0x1920/0x1920
[51015.580164] ? lwtunnel_valid_encap_type.part.6+0xcb/0x3a0
[51015.580164] ? rtm_to_fib_config+0x637/0xbd0
[51015.580164] inet_rtm_newroute+0xed/0x1b0
[51015.580164] ? rtm_to_fib_config+0xbd0/0xbd0
[51015.580164] rtnetlink_rcv_msg+0x331/0x910
[ ... ]
Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
net/core/lwt_bpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c
index e7e626f..e450985 100644
--- a/net/core/lwt_bpf.c
+++ b/net/core/lwt_bpf.c
@@ -217,7 +217,7 @@ static int bpf_parse_prog(struct nlattr *attr, struct bpf_lwt_prog *prog,
if (!tb[LWT_BPF_PROG_FD] || !tb[LWT_BPF_PROG_NAME])
return -EINVAL;
- prog->name = nla_memdup(tb[LWT_BPF_PROG_NAME], GFP_KERNEL);
+ prog->name = nla_memdup(tb[LWT_BPF_PROG_NAME], GFP_ATOMIC);
if (!prog->name)
return -ENOMEM;
--
2.9.3
^ permalink raw reply related
* Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink
From: Bjorn Helgaas @ 2018-07-28 16:06 UTC (permalink / raw)
To: Alexander Duyck
Cc: Jiri Pirko, Jakub Kicinski, Eran Ben Elisha, Saeed Mahameed,
David S. Miller, netdev@vger.kernel.org, linux-pci
In-Reply-To: <CAKgT0UeGOhjR756fMPx_k_o8Qq5x4waKMcdmtR3pLAT=xRHMgA@mail.gmail.com>
On Thu, Jul 26, 2018 at 07:00:20AM -0700, Alexander Duyck wrote:
> On Thu, Jul 26, 2018 at 12:14 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> > Thu, Jul 26, 2018 at 02:43:59AM CEST, jakub.kicinski@netronome.com wrote:
> >>On Wed, 25 Jul 2018 08:23:26 -0700, Alexander Duyck wrote:
> >>> On Wed, Jul 25, 2018 at 5:31 AM, Eran Ben Elisha wrote:
> >>> > On 7/24/2018 10:51 PM, Jakub Kicinski wrote:
> >>> >>>> The devlink params haven't been upstream even for a full cycle and
> >>> >>>> already you guys are starting to use them to configure standard
> >>> >>>> features like queuing.
> >>> >>>
> >>> >>> We developed the devlink params in order to support non-standard
> >>> >>> configuration only. And for non-standard, there are generic and vendor
> >>> >>> specific options.
> >>> >>
> >>> >> I thought it was developed for performing non-standard and possibly
> >>> >> vendor specific configuration. Look at DEVLINK_PARAM_GENERIC_* for
> >>> >> examples of well justified generic options for which we have no
> >>> >> other API. The vendor mlx4 options look fairly vendor specific if you
> >>> >> ask me, too.
> >>> >>
> >>> >> Configuring queuing has an API. The question is it acceptable to enter
> >>> >> into the risky territory of controlling offloads via devlink parameters
> >>> >> or would we rather make vendors take the time and effort to model
> >>> >> things to (a subset) of existing APIs. The HW never fits the APIs
> >>> >> perfectly.
> >>> >
> >>> > I understand what you meant here, I would like to highlight that this
> >>> > mechanism was not meant to handle SRIOV, Representors, etc.
> >>> > The vendor specific configuration suggested here is to handle a congestion
> >>> > state in Multi Host environment (which includes PF and multiple VFs per
> >>> > host), where one host is not aware to the other hosts, and each is running
> >>> > on its own pci/driver. It is a device working mode configuration.
> >>> >
> >>> > This couldn't fit into any existing API, thus creating this vendor specific
> >>> > unique API is needed.
> >>>
> >>> If we are just going to start creating devlink interfaces in for every
> >>> one-off option a device wants to add why did we even bother with
> >>> trying to prevent drivers from using sysfs? This just feels like we
> >>> are back to the same arguments we had back in the day with it.
> >>>
> >>> I feel like the bigger question here is if devlink is how we are going
> >>> to deal with all PCIe related features going forward, or should we
> >>> start looking at creating a new interface/tool for PCI/PCIe related
> >>> features? My concern is that we have already had features such as DMA
> >>> Coalescing that didn't really fit into anything and now we are
> >>> starting to see other things related to DMA and PCIe bus credits. I'm
> >>> wondering if we shouldn't start looking at a tool/interface to
> >>> configure all the PCIe related features such as interrupts, error
> >>> reporting, DMA configuration, power management, etc. Maybe we could
> >>> even look at sharing it across subsystems and include things like
> >>> storage, graphics, and other subsystems in the conversation.
> >>
> >>Agreed, for actual PCIe configuration (i.e. not ECN marking) we do need
> >>to build up an API. Sharing it across subsystems would be very cool!
I read the thread (starting at [1], for anybody else coming in late)
and I see this has something to do with "configuring outbound PCIe
buffers", but I haven't seen the connection to PCIe protocol or
features, i.e., I can't connect this to anything in the PCIe spec.
Can somebody help me understand how the PCI core is relevant? If
there's some connection with a feature defined by PCIe, or if it
affects the PCIe transaction protocol somehow, I'm definitely
interested in this. But if this only affects the data transferred
over PCIe, i.e., the data payloads of PCIe TLP packets, then I'm not
sure why the PCI core should care.
> > I wonder howcome there isn't such API in place already. Or is it?
> > If it is not, do you have any idea how should it look like? Should it be
> > an extension of the existing PCI uapi or something completely new?
> > It would be probably good to loop some PCI people in...
>
> The closest thing I can think of in terms of answering your questions
> as to why we haven't seen anything like that would be setpci.
> Basically with that tool you can go through the PCI configuration
> space and update any piece you want. The problem is it can have
> effects on the driver and I don't recall there ever being any sort of
> notification mechanism added to make a driver aware of configuration
> updates.
setpci is a development and debugging tool, not something we should
use as the standard way of configuring things. Use of setpci should
probably taint the kernel because the PCI core configures features
like MPS, ASPM, AER, etc., based on the assumption that nobody else is
changing things in PCI config space.
> As far as the interface I don't know if we would want to use something
> like netlink or look at something completely new.
>
> I've gone ahead and added the linux-pci mailing list to the thread.
>
> - Alex
[1] https://lkml.kernel.org/r/20180719010107.22363-11-saeedm@mellanox.com
^ permalink raw reply
* Re: [PATCH net-next 1/2] tcp: call tcp_drop() in tcp collapse
From: Eric Dumazet @ 2018-07-28 16:28 UTC (permalink / raw)
To: Yafang Shao; +Cc: David Miller, netdev, LKML
In-Reply-To: <CALOAHbAjtNf1LOhWEJMKNEEHSxjfEKiVV22KPUK88CTzt-eW0w@mail.gmail.com>
On Sat, Jul 28, 2018 at 12:43 AM Yafang Shao <laoar.shao@gmail.com> wrote:
>
> On Sat, Jul 28, 2018 at 11:38 AM, Eric Dumazet <edumazet@google.com> wrote:
> > On Fri, Jul 27, 2018 at 8:35 PM Yafang Shao <laoar.shao@gmail.com> wrote:
> >
> >> So what about LINUX_MIB_TCPOFOMERGE ?
> >> Regarding LINUX_MIB_TCPOFOMERGE, a skb is already covered by another
> >> skb, is that dropping the packet or simply lowering the memory
> >> overhead ?
> >
> > What do you think ?
> >
> > If you receive two times the same payload, don't you have to drop one
> > of the duplicate ?
> >
> > There is a a big difference between the two cases.
>
> If the drop caused some data lost (which may then cause retransmition
> or something), then this is a really DROP.
> While if the drop won't cause any data lost, meaning it is a
> non-harmful behavior, I think it should not be defined as DROP.
> This is my suggestion anyway.
Sigh.
We count drops, not because they are ' bad or something went wrong'.
If TCP stack receives twice the same sequence (same payload), we
_drop_ one of the duplicate, so we account for this event.
When ' collapsing' we reorganize our own storage, not because we have
to drop a payload,
but for some memory pressure reason.
We have specific SNMP counters to account for these, we do not want to
pretend a packet was ' dropped' since it was not.
If we have to _drop_ some packets, it is called Pruning, and we do
properly account for these drops.
^ permalink raw reply
* Re: [patch net-next] net: sched: don't dump chains only held by actions
From: Cong Wang @ 2018-07-28 17:20 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jakub Kicinski, mlxsw
In-Reply-To: <20180727074505.855-1-jiri@resnulli.us>
On Fri, Jul 27, 2018 at 12:47 AM Jiri Pirko <jiri@resnulli.us> wrote:
>
> From: Jiri Pirko <jiri@mellanox.com>
>
> In case a chain is empty and not explicitly created by a user,
> such chain should not exist. The only exception is if there is
> an action "goto chain" pointing to it. In that case, don't show the
> chain in the dump. Track the chain references held by actions and
> use them to find out if a chain should or should not be shown
> in chain dump.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Looks reasonable to me.
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
^ permalink raw reply
* Re: [patch net-next] net: sched: don't dump chains only held by actions
From: Cong Wang @ 2018-07-28 17:39 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jakub Kicinski, mlxsw
In-Reply-To: <CAM_iQpVsENuQh9iCGbqWXkOjg7880PN0cDG+dw0dYR1F2Z+OLA@mail.gmail.com>
On Sat, Jul 28, 2018 at 10:20 AM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> On Fri, Jul 27, 2018 at 12:47 AM Jiri Pirko <jiri@resnulli.us> wrote:
> >
> > From: Jiri Pirko <jiri@mellanox.com>
> >
> > In case a chain is empty and not explicitly created by a user,
> > such chain should not exist. The only exception is if there is
> > an action "goto chain" pointing to it. In that case, don't show the
> > chain in the dump. Track the chain references held by actions and
> > use them to find out if a chain should or should not be shown
> > in chain dump.
> >
> > Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>
> Looks reasonable to me.
>
> Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Hold on...
If you increase the refcnt for a zombie chain on NEWCHAIN path,
then it would become a non-zombie, this makes sense. However,
if the action_refcnt gets increased again when another action uses it,
it become a zombie again because refcnt==action_refcnt??
^ permalink raw reply
* Re: [PATCH net-next] cls_bpf: Use kmemdup instead of duplicating it in cls_bpf_prog_from_ops
From: Daniel Borkmann @ 2018-07-28 19:17 UTC (permalink / raw)
To: YueHaibing, davem, ast, jhs, xiyou.wangcong, jiri; +Cc: linux-kernel, netdev
In-Reply-To: <20180728103515.8576-1-yuehaibing@huawei.com>
On 07/28/2018 12:35 PM, YueHaibing wrote:
> Replace calls to kmalloc followed by a memcpy with a direct call to
> kmemdup.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next] act_bpf: Use kmemdup instead of duplicating it in tcf_bpf_init_from_ops
From: Daniel Borkmann @ 2018-07-28 19:17 UTC (permalink / raw)
To: YueHaibing, davem, ast, jhs, xiyou.wangcong, jiri; +Cc: linux-kernel, netdev
In-Reply-To: <20180728103806.19592-1-yuehaibing@huawei.com>
On 07/28/2018 12:38 PM, YueHaibing wrote:
> Replace calls to kmalloc followed by a memcpy with a direct call to
> kmemdup.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH] perf build: Build error in libbpf missing initialization
From: Daniel Borkmann @ 2018-07-28 19:30 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Thomas Richter, ast, netdev, linux-kernel, heiko.carstens,
brueckner, schwidefsky
In-Reply-To: <20180727125632.33634af5@cakuba.netronome.com>
On 07/27/2018 09:56 PM, Jakub Kicinski wrote:
> On Fri, 27 Jul 2018 21:31:01 +0200, Daniel Borkmann wrote:
>> On 07/27/2018 07:59 PM, Jakub Kicinski wrote:
>>> On Fri, 27 Jul 2018 10:21:26 +0200, Thomas Richter wrote:
>>>> In linux-next tree compiling the perf tool with additional make flags
>>>> "EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2"
>>>> causes a compiler error. It is the warning
>>>> 'variable may be used uninitialized'
>>>> which is treated as error:
>>>>
>>>> I compile it using a FEDORA 28 installation, my gcc compiler version:
>>>> gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
>>>>
>>>> The file that causes the error is tools/lib/bpf/libbpf.c
>>>>
>>>> Here is the error message:
>>>>
>>>> [root@p23lp27] # make V=1 EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2"
>>>> [...]
>>>> Makefile.config:849: No openjdk development package found, please
>>>> install JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
>>>> Warning: Kernel ABI header at 'tools/include/uapi/linux/if_link.h'
>>>> differs from latest version at 'include/uapi/linux/if_link.h'
>>>> CC libbpf.o
>>>> libbpf.c: In function ‘bpf_perf_event_read_simple’:
>>>> libbpf.c:2342:6: error: ‘ret’ may be used uninitialized in this
>>>> function [-Werror=maybe-uninitialized]
>>>> int ret;
>>>> ^
>>>> cc1: all warnings being treated as errors
>>>> mv: cannot stat './.libbpf.o.tmp': No such file or directory
>>>> /home6/tmricht/linux-next/tools/build/Makefile.build:96: recipe for target 'libbpf.o' failed
>>>>
>>>> Fix this warning and add an addition check at the beginning
>>>> of the while loop.
>>>>
>>>> Cc: Alexei Starovoitov <ast@kernel.org>
>>>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>>>>
>>>> Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>>>> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
>>>
>>> Ah, you already sent this, LGTM, thanks Thomas!
>>>
>>>> tools/lib/bpf/libbpf.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>>>> index 73465caa33ba..66965ca96113 100644
>>>> --- a/tools/lib/bpf/libbpf.c
>>>> +++ b/tools/lib/bpf/libbpf.c
>>>> @@ -2349,6 +2349,8 @@ bpf_perf_event_read_simple(void *mem, unsigned long size,
>>>>
>>>> begin = base + data_tail % size;
>>>> end = base + data_head % size;
>>>> + if (begin == end)
>>>> + return LIBBPF_PERF_EVENT_ERROR;
>>>>
>>>> while (begin != end) {
>>>> struct perf_event_header *ehdr;
>>
>> One question though, any objections to go for something like the below instead?
>> I doubt we ever hit this in a 'normal' situation, and given we already test for
>> the begin and end anyway, we could just avoid the extra test altogether. I could
>> change it to the below if you're good as well (no need to resend anything):
>>
>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index d881d37..1aafdbe 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -2273,8 +2273,8 @@ bpf_perf_event_read_simple(void *mem, unsigned long size,
>> volatile struct perf_event_mmap_page *header = mem;
>> __u64 data_tail = header->data_tail;
>> __u64 data_head = header->data_head;
>> + int ret = LIBBPF_PERF_EVENT_ERROR;
>> void *base, *begin, *end;
>> - int ret;
>>
>> asm volatile("" ::: "memory"); /* in real code it should be smp_rmb() */
>> if (data_head == data_tail)
>
> No real objection, although as a matter of personal taste I'm not a big
> fan of initializing err/ret variables unless the code is explicitly
> structured to make use of it. Here it looks slightly more like
> silencing a compiler warning, hence my preference to address the actual
> cause of the warning rather than catch all. I guess one could argue
> the other way, i.e. if the loop never run (and therefore ret was not
> overwritten) there must be *some* error. I like verbose/explicit code I
> guess..
>
> Up to you :)
Ok, I pushed this variant out to the bpf tree since it also is affected there.
Thanks a lot everyone!
^ permalink raw reply
* [PATCH bpf] bpf: fix bpf_skb_load_bytes_relative pkt length check
From: Daniel Borkmann @ 2018-07-28 19:04 UTC (permalink / raw)
To: netdev; +Cc: kafai, Daniel Borkmann
The len > skb_headlen(skb) cannot be used as a maximum upper bound
for the packet length since it does not have any relation to the full
linear packet length when filtering is used from upper layers (e.g.
in case of reuseport BPF programs) as by then skb->data, skb->len
already got mangled through __skb_pull() and others.
Fixes: 4e1ec56cdc59 ("bpf: add skb_load_bytes_relative helper")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
---
net/core/filter.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 06da770..9dfd145 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1712,24 +1712,26 @@ static const struct bpf_func_proto bpf_skb_load_bytes_proto = {
BPF_CALL_5(bpf_skb_load_bytes_relative, const struct sk_buff *, skb,
u32, offset, void *, to, u32, len, u32, start_header)
{
+ u8 *end = skb_tail_pointer(skb);
+ u8 *net = skb_network_header(skb);
+ u8 *mac = skb_mac_header(skb);
u8 *ptr;
- if (unlikely(offset > 0xffff || len > skb_headlen(skb)))
+ if (unlikely(offset > 0xffff || len > (end - mac)))
goto err_clear;
switch (start_header) {
case BPF_HDR_START_MAC:
- ptr = skb_mac_header(skb) + offset;
+ ptr = mac + offset;
break;
case BPF_HDR_START_NET:
- ptr = skb_network_header(skb) + offset;
+ ptr = net + offset;
break;
default:
goto err_clear;
}
- if (likely(ptr >= skb_mac_header(skb) &&
- ptr + len <= skb_tail_pointer(skb))) {
+ if (likely(ptr >= mac && ptr + len <= end)) {
memcpy(to, ptr, len);
return 0;
}
--
2.9.5
^ permalink raw reply related
* Re: [PATCH][net-next] openvswitch: eliminate cpu_used_mask from sw_flow
From: Pravin Shelar @ 2018-07-28 19:05 UTC (permalink / raw)
To: Li RongQing; +Cc: Linux Kernel Network Developers
In-Reply-To: <1532678637-15079-1-git-send-email-lirongqing@baidu.com>
On Fri, Jul 27, 2018 at 1:03 AM, Li RongQing <lirongqing@baidu.com> wrote:
> The size of struct cpumask varies with CONFIG_NR_CPUS, some config
> CONFIG_NR_CPUS is very larger, like 5120, struct cpumask will take
> 640 bytes, if there is thousands of flows, it will take lots of
> memory
>
I am fine with removing cpumask bitmap from flow struct.
> cpu_used_mask has two purposes
> 1: Assume first cpu as cpu0 which maybe not true; now use
> cpumask_first(cpu_possible_mask)
I am not sure about this, most of system would have cpu zero, so why
this change is done in this patch ? This adds overhead of calculating
first cpu when updating stats in fast path.
> 2: when get/clear statistic, reduce the iteratation; but it
> is not hot path, so use for_each_possible_cpu
>
^ permalink raw reply
* Re: [PATCH bpf] tools/bpftool: fix a percpu_array map dump problem
From: Daniel Borkmann @ 2018-07-28 19:14 UTC (permalink / raw)
To: Yonghong Song, ast, netdev; +Cc: kernel-team
In-Reply-To: <20180727231138.3318561-1-yhs@fb.com>
On 07/28/2018 01:11 AM, Yonghong Song wrote:
> I hit the following problem when I tried to use bpftool
> to dump a percpu array.
>
> $ sudo ./bpftool map show
> 61: percpu_array name stub flags 0x0
> key 4B value 4B max_entries 1 memlock 4096B
> ...
> $ sudo ./bpftool map dump id 61
> bpftool: malloc.c:2406: sysmalloc: Assertion
> `(old_top == initial_top (av) && old_size == 0) || \
> ((unsigned long) (old_size) >= MINSIZE && \
> prev_inuse (old_top) && \
> ((unsigned long) old_end & (pagesize - 1)) == 0)'
> failed.
> Aborted
>
> Further debugging revealed that this is due to
> miscommunication between bpftool and kernel.
> For example, for the above percpu_array with value size of 4B.
> The map info returned to user space has value size of 4B.
>
> In bpftool, the values array for lookup is allocated like:
> info->value_size * get_possible_cpus() = 4 * get_possible_cpus()
> In kernel (kernel/bpf/syscall.c), the values array size is
> rounded up to multiple of 8.
> round_up(map->value_size, 8) * num_possible_cpus()
> = 8 * num_possible_cpus()
> So when kernel copies the values to user buffer, the kernel will
> overwrite beyond user buffer boundary.
>
> This patch fixed the issue by allocating and stepping through
> percpu map value array properly in bpftool.
>
> Fixes: 71bb428fe2c19 ("tools: bpf: add bpftool")
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
> tools/bpf/bpftool/map.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
> index 0ee3ba479d87..92bc55f98c4c 100644
> --- a/tools/bpf/bpftool/map.c
> +++ b/tools/bpf/bpftool/map.c
> @@ -35,6 +35,7 @@
> #include <errno.h>
> #include <fcntl.h>
> #include <linux/err.h>
> +#include <linux/kernel.h>
> #include <stdbool.h>
> #include <stdio.h>
> #include <stdlib.h>
> @@ -91,7 +92,8 @@ static bool map_is_map_of_progs(__u32 type)
> static void *alloc_value(struct bpf_map_info *info)
> {
> if (map_is_per_cpu(info->type))
> - return malloc(info->value_size * get_possible_cpus());
> + return malloc(round_up(info->value_size, 8) *
> + get_possible_cpus());
> else
> return malloc(info->value_size);
> }
> @@ -273,9 +275,10 @@ static void print_entry_json(struct bpf_map_info *info, unsigned char *key,
> do_dump_btf(&d, info, key, value);
> }
> } else {
> - unsigned int i, n;
> + unsigned int i, n, step;
>
> n = get_possible_cpus();
> + step = round_up(info->value_size, 8);
>
> jsonw_name(json_wtr, "key");
> print_hex_data_json(key, info->key_size);
> @@ -288,7 +291,7 @@ static void print_entry_json(struct bpf_map_info *info, unsigned char *key,
> jsonw_int_field(json_wtr, "cpu", i);
>
> jsonw_name(json_wtr, "value");
> - print_hex_data_json(value + i * info->value_size,
> + print_hex_data_json(value + i * step,
> info->value_size);
>
> jsonw_end_object(json_wtr);
Fix looks correct to me, but you would also need the same fix in print_entry_plain(), no?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH bpf] bpf: use GFP_ATOMIC instead of GFP_KERNEL in bpf_parse_prog()
From: Daniel Borkmann @ 2018-07-28 19:24 UTC (permalink / raw)
To: Taehee Yoo, ast; +Cc: netdev
In-Reply-To: <20180728152831.3541-1-ap420073@gmail.com>
On 07/28/2018 05:28 PM, Taehee Yoo wrote:
> bpf_parse_prog() is protected by rcu_read_lock().
> so that GFP_KERNEL is not allowed in the bpf_parse_prog().
>
> [51015.579396] =============================
> [51015.579418] WARNING: suspicious RCU usage
> [51015.579444] 4.18.0-rc6+ #208 Not tainted
> [51015.579464] -----------------------------
> [51015.579488] ./include/linux/rcupdate.h:303 Illegal context switch in RCU read-side critical section!
> [51015.579510] other info that might help us debug this:
> [51015.579532] rcu_scheduler_active = 2, debug_locks = 1
> [51015.579556] 2 locks held by ip/1861:
> [51015.579577] #0: 00000000a8c12fd1 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x2e0/0x910
> [51015.579711] #1: 00000000bf815f8e (rcu_read_lock){....}, at: lwtunnel_build_state+0x96/0x390
> [51015.579842] stack backtrace:
> [51015.579869] CPU: 0 PID: 1861 Comm: ip Not tainted 4.18.0-rc6+ #208
> [51015.579891] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015
> [51015.579911] Call Trace:
> [51015.579950] dump_stack+0x74/0xbb
> [51015.580000] ___might_sleep+0x16b/0x3a0
> [51015.580047] __kmalloc_track_caller+0x220/0x380
> [51015.580077] kmemdup+0x1c/0x40
> [51015.580077] bpf_parse_prog+0x10e/0x230
> [51015.580164] ? kasan_kmalloc+0xa0/0xd0
> [51015.580164] ? bpf_destroy_state+0x30/0x30
> [51015.580164] ? bpf_build_state+0xe2/0x3e0
> [51015.580164] bpf_build_state+0x1bb/0x3e0
> [51015.580164] ? bpf_parse_prog+0x230/0x230
> [51015.580164] ? lock_is_held_type+0x123/0x1a0
> [51015.580164] lwtunnel_build_state+0x1aa/0x390
> [51015.580164] fib_create_info+0x1579/0x33d0
> [51015.580164] ? sched_clock_local+0xe2/0x150
> [51015.580164] ? fib_info_update_nh_saddr+0x1f0/0x1f0
> [51015.580164] ? sched_clock_local+0xe2/0x150
> [51015.580164] fib_table_insert+0x201/0x1990
> [51015.580164] ? lock_downgrade+0x610/0x610
> [51015.580164] ? fib_table_lookup+0x1920/0x1920
> [51015.580164] ? lwtunnel_valid_encap_type.part.6+0xcb/0x3a0
> [51015.580164] ? rtm_to_fib_config+0x637/0xbd0
> [51015.580164] inet_rtm_newroute+0xed/0x1b0
> [51015.580164] ? rtm_to_fib_config+0xbd0/0xbd0
> [51015.580164] rtnetlink_rcv_msg+0x331/0x910
> [ ... ]
>
> Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure")
> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Applied to bpf, thanks Taehee!
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: net: Fix Broadcom iProc mdio mux driver base address
From: Andrew Lunn @ 2018-07-28 21:09 UTC (permalink / raw)
To: Arun Parameswaran
Cc: David S. Miller, Florian Fainelli, Rob Herring, Mark Rutland,
Ray Jui, Scott Branden, Catalin Marinas, Will Deacon, netdev,
devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1532726613-6483-2-git-send-email-arun.parameswaran@broadcom.com>
On Fri, Jul 27, 2018 at 02:23:27PM -0700, Arun Parameswaran wrote:
> Modify the base address of the Broadcom iProc MDIO mux driver to
> point to the start of the block's register address space.
>
> Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox