* Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek
From: Herbert Xu @ 2018-03-29 15:41 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: cluster-devel, netdev, LKML, NeilBrown, Thomas Graf, Tom Herbert
In-Reply-To: <CAHc6FU4i5LDoqXXTgAKtTA8EtGyawxXtY4iavo7NjHCsbX1G8w@mail.gmail.com>
On Thu, Mar 29, 2018 at 03:15:54PM +0200, Andreas Gruenbacher wrote:
>
> For all I know, Neil's latest plan is to get rhashtable_walk_peek
> replaced and removed because it is unfixable. This patch removes the
> one and only user.
His latest patch makes rhashtable_walk_peek stable in the face of
removals.
https://patchwork.ozlabs.org/patch/892534/
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] cw1200: fix spelling mistake: "Mailformed" -> "Malformed"
From: Colin King @ 2018-03-29 15:38 UTC (permalink / raw)
To: Solomon Peachy, Kalle Valo, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in wiphy_warn warning message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/st/cw1200/txrx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/st/cw1200/txrx.c b/drivers/net/wireless/st/cw1200/txrx.c
index e9050b41157a..f7b1b0062db3 100644
--- a/drivers/net/wireless/st/cw1200/txrx.c
+++ b/drivers/net/wireless/st/cw1200/txrx.c
@@ -1069,7 +1069,7 @@ void cw1200_rx_cb(struct cw1200_common *priv,
}
if (skb->len < sizeof(struct ieee80211_pspoll)) {
- wiphy_warn(priv->hw->wiphy, "Mailformed SDU rx'ed. Size is lesser than IEEE header.\n");
+ wiphy_warn(priv->hw->wiphy, "Malformed SDU rx'ed. Size is lesser than IEEE header.\n");
goto drop;
}
--
2.15.1
^ permalink raw reply related
* Re: [PATCH net] lan78xx: Crash in lan78xx_writ_reg (Workqueue: events lan78xx_deferred_multicast_write)
From: David Miller @ 2018-03-29 15:36 UTC (permalink / raw)
To: raghuramchary.jallipalli; +Cc: netdev, unglinuxdriver, woojung.huh
In-Reply-To: <20180327092116.8867-1-raghuramchary.jallipalli@microchip.com>
From: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
Date: Tue, 27 Mar 2018 14:51:16 +0530
> Description:
> Crash was reported with syzkaller pointing to lan78xx_write_reg routine.
>
> Root-cause:
> Proper cleanup of workqueues and init/setup routines was not happening
> in failure conditions.
>
> Fix:
> Handled the error conditions by cleaning up the queues and init/setup
> routines.
>
> Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [RFC PATCH v2 00/14] Introducing AF_XDP support
From: Jesper Dangaard Brouer @ 2018-03-29 15:36 UTC (permalink / raw)
To: Björn Töpel
Cc: Eric Leblond, Karlsson, Magnus, Duyck, Alexander H,
Alexander Duyck, John Fastabend, Alexei Starovoitov,
Willem de Bruijn, Daniel Borkmann, Netdev, Björn Töpel,
michael.lundkvist, Brandeburg, Jesse, Singhai, Anjali,
Zhang, Qi Z, ravineet.singh, brouer
In-Reply-To: <CAJ+HfNi+WX-0Q_zQLnvRhJGvWSDaFXzi2EBPVA6c6Znh=cRC=g@mail.gmail.com>
On Thu, 29 Mar 2018 08:16:23 +0200 Björn Töpel <bjorn.topel@gmail.com> wrote:
> 2018-03-28 23:18 GMT+02:00 Eric Leblond <eric@regit.org>:
> > Hello,
> >
> > On Tue, 2018-03-27 at 18:59 +0200, Björn Töpel wrote:
> >> From: Björn Töpel <bjorn.topel@intel.com>
> >>
> >>
> > optimized for high performance packet processing and, in upcoming
> >> patch sets, zero-copy semantics. In this v2 version, we have removed
> >> all zero-copy related code in order to make it smaller, simpler and
> >> hopefully more review friendly. This RFC only supports copy-mode for
> >> the generic XDP path (XDP_SKB) for both RX and TX and copy-mode for
> >> RX
> >>
> >
> > ...
> >>
> >> How is then packets distributed between these two XSK? We have
> >> introduced a new BPF map called XSKMAP (or BPF_MAP_TYPE_XSKMAP in
> >> full). The user-space application can place an XSK at an arbitrary
> >> place in this map. The XDP program can then redirect a packet to a
> >> specific index in this map and at this point XDP validates that the
> >> XSK in that map was indeed bound to that device and queue number. If
> >> not, the packet is dropped. If the map is empty at that index, the
> >> packet is also dropped. This also means that it is currently
> >> mandatory
> >> to have an XDP program loaded (and one XSK in the XSKMAP) to be able
> >> to get any traffic to user space through the XSK.
> >
> > If I get it correctly, this feature will have to be used to bound
> > multiple sockets to a single queue and the eBPF filter will be
> > responsible of the load balancing. Am I correct ?
> >
>
> Exactly! The XDP program executing for a certain Rx queue will
> distribute the packets to the socket(s) in the xskmap.
It is important to understand that we (want/need to) maintain a Single
Producer Single Consumer (SPSC) scenario here, for performance reasons.
This _is_ maintained in this patchset AFAIK. But as the API user, you
have to understand that the responsibility of aligning this is yours!
If you don't the frames are dropped (silently).
The BPF programmer MUST select the correct XSKMAP index, such that
the ctx->rx_queue_index match the queue_id registered in the xdp_sock
(and bounded ifindex also match).
Bjørn, Magnus and I have discussed other API options. E.g. where the
XSKMAP index _is_ the rx_queue_index, and BPF programmer is not allowed
select another index. We settled on the API in the patchset, where BPF
programmer get more freedom, and can select an invalid index, that
cause packets to be dropped.
An advantage of this API is that we allow one RX-queue, to multiplex
into many xdk_sock's (all bound to this same RX-queue and ifindex).
This still maintain a Single Producer, as the RX-queue just have a
Single Producer relationship's with each xdp_sock.
I imagine, that Suricata/Eric, want to capture all the RX-queues on
the net_device. For this to happen, he need to create a xdp_sock per
RX-queue, and have a side-bpf-map that assist in the XSKMAP lookup, or
simply populate the XSKMAP to correspond to the rx_queue_index.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: pull request (net-next): ipsec-next 2018-03-29
From: David Miller @ 2018-03-29 15:23 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20180329072549.2880-1-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 29 Mar 2018 09:25:45 +0200
> 1) Remove a redundant pointer initialization esp_input_set_header().
> From Colin Ian King.
>
> 2) Mark the xfrm kmem_caches as __ro_after_init.
> From Alexey Dobriyan.
>
> 3) Do the checksum for an ipsec offlad packet in software
> if the device does not advertise NETIF_F_HW_ESP_TX_CSUM.
> From Shannon Nelson.
>
> 4) Use booleans for true and false instead of integers
> in xfrm_policy_cache_flush().
> From Gustavo A. R. Silva
>
> Please pull or let me know if there are problems.
Also pulled, thank you.
^ permalink raw reply
* Fw: [Bug 199243] New: Ethernet doesn't work after sleep
From: Stephen Hemminger @ 2018-03-29 15:12 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Thu, 29 Mar 2018 15:02:07 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 199243] New: Ethernet doesn't work after sleep
https://bugzilla.kernel.org/show_bug.cgi?id=199243
Bug ID: 199243
Summary: Ethernet doesn't work after sleep
Product: Networking
Version: 2.5
Kernel Version: 4.15.12
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: zamazan4ik@tut.by
Regression: No
Description of problem:
Laptop with Fedora 27 cannot connect via Ethernet to a network after sleep (not
hibernation).
Version-Release number of selected component (if applicable):
Fedora 27
How reproducible:
Always
Steps to Reproduce:
1. With connected or disconnected Ethernet cable (in my case doesn't matter)
turn on sleep mode on a laptop.
2. Turn off sleep mode.
3. Ooops: Ethernet doesn't work (and even isn't detected).
Actual results:
There is chance to get workable Ethernet connection after sleep.
Expected results:
Fedora should be able to establish Ethernet connection after sleep.
Additional info:
Laptop model: Asus K55VJ-SX012D
Fedora 27
KDE Plasma 5.11.5
KDE Frameworks 5.43.0
Qt: 5.9.4
lspci | grep Ethernet: 04:00.2 Ethernet controller: Realtek Semiconductor Co.,
Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a)
uname -r: 4.15.12-301.fc27.x86_64
On Windows 10 all works fine. Ethernet cable is fine (tested on Windows and on
another machine).
Similar link to Redhat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1550701
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [net-next,v2,01/10] soc: ti: K2G: enhancement to support QMSS in NSS
From: Murali Karicheri @ 2018-03-29 14:59 UTC (permalink / raw)
To: Grygorii Strashko, robh+dt, ssantosh, malat, w-kwok2, devicetree,
linux-kernel, linux-arm-kernel, davem, netdev
Cc: mark.rutland
In-Reply-To: <1ccf03e7-17b4-cf00-176d-0e41038c88f8@ti.com>
On 03/28/2018 03:01 PM, Grygorii Strashko wrote:
> Hi Murali,
>
>>
>> +enum qmss_version {
>> + QMSS,
>> + QMSS_LITE,
>
> QMSS_66AK2G
>
OK.
>> +};
>> +
>> struct knav_device {
>> struct device *dev;
>> unsigned base_id;
>> @@ -305,6 +310,7 @@ struct knav_device {
>> struct list_head pools;
>> struct list_head pdsps;
>> struct list_head qmgrs;
>> + enum qmss_version version;
>> };
>>
>
> [...]
>
>> }
>>
>> +/* Match table for of_platform binding */
>> +static const struct of_device_id keystone_qmss_of_match[] = {
>> + {
>> + .compatible = "ti,keystone-navigator-qmss",
>
> .data = (void *)QMSS,
This seems to be unnecessary as QMSS is actually defined as zero. Also
this static. So that value is zero already in memory.
>
>> + },
>> + {
>> + .compatible = "ti,keystone-navigator-qmss-l",
>> + .data = (void *)QMSS_LITE,
>> + },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, keystone_qmss_of_match);
>> +
>> static int knav_queue_probe(struct platform_device *pdev)
>> {
>> struct device_node *node = pdev->dev.of_node;
>> struct device_node *qmgrs, *queue_pools, *regions, *pdsps;
>> + const struct of_device_id *match;
>> struct device *dev = &pdev->dev;
>> u32 temp[2];
>> int ret;
>> @@ -1700,6 +1749,10 @@ static int knav_queue_probe(struct platform_device *pdev)
>> return -ENOMEM;
>> }
>>
>> + match = of_match_device(of_match_ptr(keystone_qmss_of_match), dev);
>> + if (match && match->data)
>> + kdev->version = QMSS_LITE;
>
> if (match)
> kdev->version = match->data;
> else
> error?
Similar to above. This private memory is allocated using kzalloc which initializes
everything to zero. So the else part is unnecessary.
Murali
> [...]
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver
From: Andrew Lunn @ 2018-03-29 14:57 UTC (permalink / raw)
To: Alexandre Belloni
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Florian Fainelli, netdev, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20180329145352.GD12066@piout.net>
> > It sounds like the correct fix is for get_phy_id() to look at the
> > error code for mdiobus_read(bus, addr, MII_PHYSID1). If it is EIO and
> > maybe ENODEV, set *phy_id to 0xffffffff and return. The scan code
> > should then do the correct thing.
> >
>
> That could work indeed. Do you want me to test and send a patch?
Yes please.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH 000/109] remove in-kernel calls to syscalls
From: Dominik Brodowski @ 2018-03-29 14:55 UTC (permalink / raw)
To: David Laight
Cc: Matthew Wilcox, linux-kernel@vger.kernel.org,
viro@ZenIV.linux.org.uk, torvalds@linux-foundation.org,
arnd@arndb.de, linux-arch@vger.kernel.org, hmclauchlan@fb.com,
tautschn@amazon.co.uk, Amir Goldstein, Andi Kleen, Andrew Morton,
Christoph Hellwig, Darren Hart, David S . Miller,
Eric W . Biederman, H . Peter Anvin, Ingo Molnar,
Jaswinder Singh <jaswi
In-Reply-To: <07438b1e94ff42a184adb7134a680069@AcuMS.aculab.com>
On Thu, Mar 29, 2018 at 02:46:44PM +0000, David Laight wrote:
> From: Dominik Brodowski
> > Sent: 29 March 2018 15:42
> > On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote:
> > > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> > > > At least on 64-bit x86, it will likely be a hard requirement from v4.17
> > > > onwards to not call system call functions in the kernel: It is better to
> > > > use use a different calling convention for system calls there, where
> > > > struct pt_regs is decoded on-the-fly in a syscall wrapper which then hands
> > > > processing over to the actual syscall function. This means that only those
> > > > parameters which are actually needed for a specific syscall are passed on
> > > > during syscall entry, instead of filling in six CPU registers with random
> > > > user space content all the time (which may cause serious trouble down the
> > > > call chain).[*]
> > >
> > > How do we stop new ones from springing up? Some kind of linker trick
> > > like was used to, er, "dissuade" people from using gets()?
> >
> > Once the patches which modify the syscall calling convention are merged,
> > it won't compile on 64-bit x86, but bark loudly. That should frighten anyone.
> > Meow.
>
> Should be pretty easy to ensure the prototypes aren't in any normal header.
That's exactly why the compile will fail.
> Renaming the global symbols (to not match the function name) will make it
> much harder to call them as well.
That still depends on the exact design of the patchset, which is still under
review.
Thanks,
Dominik
^ permalink raw reply
* Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver
From: Alexandre Belloni @ 2018-03-29 14:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Florian Fainelli, netdev, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20180329144041.GA25752@lunn.ch>
On 29/03/2018 at 16:40:41 +0200, Andrew Lunn wrote:
> > > > + for (i = 0; i < PHY_MAX_ADDR; i++) {
> > > > + if (mscc_miim_read(bus, i, MII_PHYSID1) < 0)
> > > > + bus->phy_mask |= BIT(i);
> > > > + }
> > >
> > > Why do this? Especially so for the external bus, where the PHYs might
> > > have a GPIO reset line, and won't respond until the gpio is
> > > released. The core code does that just before it scans the bus, or
> > > just before it scans the particular address on the bus, depending on
> > > the scope of the GPIO.
> > >
> >
> > IIRC, this was needed when probing the bus without DT, in that case, the
> > mdiobus_scan loop of __mdiobus_register() will fail when doing the
> > get_phy_id for phys 0 to 31 because get_phy_id() transforms any error in
> > -EIO and so it is impossible to register the bus. Other drivers have a
> > similar code to handle that case.
>
> Hi Alexandre
>
> Do you mean mscc_miim_read() will return -EIO if there is no device on
> the bus at the address trying to be read? Most devices just return
> 0xffff because there is a pull up on the data line, nothing is driving
> it, so all 1's are read.
>
It will return -EIO but I tried to be clever and return -ENODEV but this
gets changed to -EIO by get_phy_id.
> It sounds like the correct fix is for get_phy_id() to look at the
> error code for mdiobus_read(bus, addr, MII_PHYSID1). If it is EIO and
> maybe ENODEV, set *phy_id to 0xffffffff and return. The scan code
> should then do the correct thing.
>
That could work indeed. Do you want me to test and send a patch?
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next] dt-bindings: net: renesas-ravb: Add support for r8a77470 SoC
From: Sergei Shtylyov @ 2018-03-29 14:51 UTC (permalink / raw)
To: Biju Das, David S . Miller, Rob Herring, Mark Rutland,
Russell King
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Chris Paterson,
Fabrizio Castro, devicetree, linux-renesas-soc, linux-arm-kernel,
netdev
In-Reply-To: <1522317775-35671-1-git-send-email-biju.das@bp.renesas.com>
Hello!
On 03/29/2018 01:02 PM, Biju Das wrote:
> Add a new compatible string for the RZ/G1C (R8A77470) SoC.
Needed solely to please checkpatch.pl. :-)
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [net-next, v2, 01/10] soc: ti: K2G: enhancement to support QMSS in NSS
From: Murali Karicheri @ 2018-03-29 14:50 UTC (permalink / raw)
To: Grygorii Strashko, robh+dt, ssantosh, malat, w-kwok2, devicetree,
linux-kernel, linux-arm-kernel, davem, netdev
Cc: mark.rutland
In-Reply-To: <1ccf03e7-17b4-cf00-176d-0e41038c88f8@ti.com>
Hi Grygorii,
Thanks for reviewing this!
On 03/28/2018 03:01 PM, Grygorii Strashko wrote:
> Hi Murali,
>
> On 03/27/2018 11:31 AM, Murali Karicheri wrote:
>> Navigator Subsystem (NSS) available on K2G SoC has a cut down
>> version of QMSS with less number of queues, internal linking ram
>> with lesser number of buffers etc. It doesn't have status and
>> explicit push register space as in QMSS available on other K2 SoCs.
>> So define reg indices specific to QMSS on K2G. This patch introduces
>> "keystone-navigator-qmss-l" compatibility to identify QMSS on
>> K2G NSS (QMSS Lite) and to customize the dts handling code. Per
>> Device manual, descriptors with index less than or equal to
>> regions0_size is in region 0 in the case of QMSS where as for
>> QMSS Lite, descriptors with index less than regions0_size is in
>> region 0. So update the size accordingly in the regions0_size bits
>> of the linking ram size 0 register.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
>> ---
>> .../bindings/soc/ti/keystone-navigator-qmss.txt | 7 ++
>> drivers/soc/ti/knav_qmss.h | 6 ++
>> drivers/soc/ti/knav_qmss_queue.c | 90 ++++++++++++++++------
>> 3 files changed, 81 insertions(+), 22 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
>> index 77cd42c..1b0878a 100644
>> --- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
>> +++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
>> @@ -18,6 +18,7 @@ pool management.
>>
>> Required properties:
>> - compatible : Must be "ti,keystone-navigator-qmss";
>> + : Must be "ti,keystone-navigator-qmss-l" for NSS Lite
>
>
> I think, It will be more accurate to add K2G specific compat string
> like "ti,66ak2g-navss-qm":
>
> compatible = "ti,66ak2g-navss-qm", "ti,keystone-navigator-qmss";
>
> because 66ak2g TRM doesn't mention "Navss light" and this Navss version is used
> only in 66ak2g Soc. As result, 66ak2g Navss QM is subset of of keystone 2 Navss QM
> which should be defined in DT by adding more specific compat string in addition
> to generic one.
>
As I have mentioned in the commit description, it is not a subset of the K2
registers. There are some differences that makes it not compatible with K2 QMSS.
See my description,
>>It doesn't have status and explicit push register space as in QMSS available on
>>other K2 SoCs.
And also
>> Per Device manual, descriptors with index less than or equal to
>> regions0_size is in region 0 in the case of QMSS where as for
>> QMSS Lite, descriptors with index less than regions0_size is in
>> region 0. So update the size accordingly in the regions0_size bits
>> of the linking ram size 0 register
So will have to use a specific compatible = "ti,66ak2g-navss-qm" for this QM IMO.
Murali
>
>> - clocks : phandle to the reference clock for this device.
>> - queue-range : <start number> total range of queue numbers for the device.
>> - linkram0 : <address size> for internal link ram, where size is the total
>> @@ -39,6 +40,12 @@ Required properties:
>> - Descriptor memory setup region.
>> - Queue Management/Queue Proxy region for queue Push.
>> - Queue Management/Queue Proxy region for queue Pop.
>> +
>> +For NSS lite, following QMSS reg indexes are used in that order
>
> For 66AK2G NAVSS QM..
>
>> + - Queue Peek region.
>> + - Queue configuration region.
>> + - Queue Management/Queue Proxy region for queue Push/Pop.
>> +
>> - queue-pools : child node classifying the queue ranges into pools.
>> Queue ranges are grouped into 3 type of pools:
>> - qpend : pool of qpend(interruptible) queues
>> diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
>> index 905b974..5fa1ce6 100644
>> --- a/drivers/soc/ti/knav_qmss.h
>> +++ b/drivers/soc/ti/knav_qmss.h
>> @@ -292,6 +292,11 @@ struct knav_queue {
>> struct list_head list;
>> };
>>
>> +enum qmss_version {
>> + QMSS,
>> + QMSS_LITE,
>
> QMSS_66AK2G
>
>> +};
>> +
>> struct knav_device {
>> struct device *dev;
>> unsigned base_id;
>> @@ -305,6 +310,7 @@ struct knav_device {
>> struct list_head pools;
>> struct list_head pdsps;
>> struct list_head qmgrs;
>> + enum qmss_version version;
>> };
>>
>
> [...]
>
>> }
>>
>> +/* Match table for of_platform binding */
>> +static const struct of_device_id keystone_qmss_of_match[] = {
>> + {
>> + .compatible = "ti,keystone-navigator-qmss",
>
> .data = (void *)QMSS,
>
>> + },
>> + {
>> + .compatible = "ti,keystone-navigator-qmss-l",
>> + .data = (void *)QMSS_LITE,
>> + },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, keystone_qmss_of_match);
>> +
>> static int knav_queue_probe(struct platform_device *pdev)
>> {
>> struct device_node *node = pdev->dev.of_node;
>> struct device_node *qmgrs, *queue_pools, *regions, *pdsps;
>> + const struct of_device_id *match;
>> struct device *dev = &pdev->dev;
>> u32 temp[2];
>> int ret;
>> @@ -1700,6 +1749,10 @@ static int knav_queue_probe(struct platform_device *pdev)
>> return -ENOMEM;
>> }
>>
>> + match = of_match_device(of_match_ptr(keystone_qmss_of_match), dev);
>> + if (match && match->data)
>> + kdev->version = QMSS_LITE;
>
> if (match)
> kdev->version = match->data;
> else
> error?
> [...]
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* RE: [PATCH 000/109] remove in-kernel calls to syscalls
From: David Laight @ 2018-03-29 14:46 UTC (permalink / raw)
To: 'Dominik Brodowski', Matthew Wilcox
Cc: linux-kernel@vger.kernel.org, viro@ZenIV.linux.org.uk,
torvalds@linux-foundation.org, arnd@arndb.de,
linux-arch@vger.kernel.org, hmclauchlan@fb.com,
tautschn@amazon.co.uk, Amir Goldstein, Andi Kleen, Andrew Morton,
Christoph Hellwig, Darren Hart, David S . Miller,
Eric W . Biederman, H . Peter Anvin, Ingo Molnar, Jaswinder Singh,
Jeff Dike <jdik
In-Reply-To: <20180329144209.GA25559@isilmar-4.linta.de>
From: Dominik Brodowski
> Sent: 29 March 2018 15:42
> On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote:
> > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> > > At least on 64-bit x86, it will likely be a hard requirement from v4.17
> > > onwards to not call system call functions in the kernel: It is better to
> > > use use a different calling convention for system calls there, where
> > > struct pt_regs is decoded on-the-fly in a syscall wrapper which then hands
> > > processing over to the actual syscall function. This means that only those
> > > parameters which are actually needed for a specific syscall are passed on
> > > during syscall entry, instead of filling in six CPU registers with random
> > > user space content all the time (which may cause serious trouble down the
> > > call chain).[*]
> >
> > How do we stop new ones from springing up? Some kind of linker trick
> > like was used to, er, "dissuade" people from using gets()?
>
> Once the patches which modify the syscall calling convention are merged,
> it won't compile on 64-bit x86, but bark loudly. That should frighten anyone.
> Meow.
Should be pretty easy to ensure the prototypes aren't in any normal header.
Renaming the global symbols (to not match the function name) will make it
much harder to call them as well.
David
^ permalink raw reply
* Re: [PATCH net] vhost: validate log when IOTLB is enabled
From: Michael S. Tsirkin @ 2018-03-29 14:44 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <1522310404-8486-1-git-send-email-jasowang@redhat.com>
On Thu, Mar 29, 2018 at 04:00:04PM +0800, Jason Wang wrote:
> Vq log_base is the userspace address of bitmap which has nothing to do
> with IOTLB. So it needs to be validated unconditionally otherwise we
> may try use 0 as log_base which may lead to pin pages that will lead
> unexpected result (e.g trigger BUG_ON() in set_bit_to_user()).
>
> Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
> Reported-by: syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com
> Signed-off-by: Jason Wang <jasowang@redhat.com>
One follow-up question:
We still observe that get user pages returns 0 sometimes. While I agree
we should not pass in unvalidated addresses, isn't this worth
documenting?
> ---
> drivers/vhost/vhost.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 5d5a9d9..5320039 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1244,14 +1244,12 @@ static int vq_log_access_ok(struct vhost_virtqueue *vq,
> /* Caller should have vq mutex and device mutex */
> int vhost_vq_access_ok(struct vhost_virtqueue *vq)
> {
> - if (vq->iotlb) {
> - /* When device IOTLB was used, the access validation
> - * will be validated during prefetching.
> - */
> - return 1;
> - }
> - return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used) &&
> - vq_log_access_ok(vq, vq->log_base);
> + int ret = vq_log_access_ok(vq, vq->log_base);
> +
> + if (ret || vq->iotlb)
> + return ret;
> +
> + return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used);
> }
> EXPORT_SYMBOL_GPL(vhost_vq_access_ok);
>
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH 000/109] remove in-kernel calls to syscalls
From: Dominik Brodowski @ 2018-03-29 14:42 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-kernel, viro, torvalds, arnd, linux-arch, hmclauchlan,
tautschn, Amir Goldstein, Andi Kleen, Andrew Morton,
Christoph Hellwig, Darren Hart, David S . Miller,
Eric W . Biederman, H . Peter Anvin, Ingo Molnar, Jaswinder Singh,
Jeff Dike, Jiri Slaby, kexec, linux-fsdevel, linux-mm, linux-s390,
Luis R . Rodriguez, netdev
In-Reply-To: <20180329142027.GA24860@bombadil.infradead.org>
On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote:
> On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> > At least on 64-bit x86, it will likely be a hard requirement from v4.17
> > onwards to not call system call functions in the kernel: It is better to
> > use use a different calling convention for system calls there, where
> > struct pt_regs is decoded on-the-fly in a syscall wrapper which then hands
> > processing over to the actual syscall function. This means that only those
> > parameters which are actually needed for a specific syscall are passed on
> > during syscall entry, instead of filling in six CPU registers with random
> > user space content all the time (which may cause serious trouble down the
> > call chain).[*]
>
> How do we stop new ones from springing up? Some kind of linker trick
> like was used to, er, "dissuade" people from using gets()?
Once the patches which modify the syscall calling convention are merged,
it won't compile on 64-bit x86, but bark loudly. That should frighten anyone.
Meow.
Thanks,
Dominik
^ permalink raw reply
* Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver
From: Andrew Lunn @ 2018-03-29 14:40 UTC (permalink / raw)
To: Alexandre Belloni
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Florian Fainelli, netdev, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20180329140544.GB12066@piout.net>
On Thu, Mar 29, 2018 at 04:05:44PM +0200, Alexandre Belloni wrote:
> On 23/03/2018 at 21:49:39 +0100, Andrew Lunn wrote:
> > On Fri, Mar 23, 2018 at 09:11:12PM +0100, Alexandre Belloni wrote:
> > > Add a driver for the Microsemi MII Management controller (MIIM) found on
> > > Microsemi SoCs.
> > > On Ocelot, there are two controllers, one is connected to the internal
> > > PHYs, the other one can communicate with external PHYs.
> >
> > Hi Alexandre
> >
> > This looks to be standalone. Such drivers we try to put in
> > drivers/net/phy.
> >
> > > +static int mscc_miim_read(struct mii_bus *bus, int mii_id, int regnum)
> > > +{
> > > + struct mscc_miim_dev *miim = bus->priv;
> > > + u32 val;
> > > + int ret;
> > > +
> > > + mutex_lock(&miim->lock);
> >
> > What are you locking against here?
> >
> > And you don't appear to initialize the mutex anywhere.
> >
> > > +static int mscc_miim_reset(struct mii_bus *bus)
> > > +{
> > > + struct mscc_miim_dev *miim = bus->priv;
> > > + int i;
> > > +
> > > + if (miim->phy_regs) {
> > > + writel(0, miim->phy_regs + MSCC_PHY_REG_PHY_CFG);
> > > + writel(0x1ff, miim->phy_regs + MSCC_PHY_REG_PHY_CFG);
> > > + mdelay(500);
> > > + }
> > > +
> > > + for (i = 0; i < PHY_MAX_ADDR; i++) {
> > > + if (mscc_miim_read(bus, i, MII_PHYSID1) < 0)
> > > + bus->phy_mask |= BIT(i);
> > > + }
> >
> > Why do this? Especially so for the external bus, where the PHYs might
> > have a GPIO reset line, and won't respond until the gpio is
> > released. The core code does that just before it scans the bus, or
> > just before it scans the particular address on the bus, depending on
> > the scope of the GPIO.
> >
>
> IIRC, this was needed when probing the bus without DT, in that case, the
> mdiobus_scan loop of __mdiobus_register() will fail when doing the
> get_phy_id for phys 0 to 31 because get_phy_id() transforms any error in
> -EIO and so it is impossible to register the bus. Other drivers have a
> similar code to handle that case.
Hi Alexandre
Do you mean mscc_miim_read() will return -EIO if there is no device on
the bus at the address trying to be read? Most devices just return
0xffff because there is a pull up on the data line, nothing is driving
it, so all 1's are read.
It sounds like the correct fix is for get_phy_id() to look at the
error code for mdiobus_read(bus, addr, MII_PHYSID1). If it is EIO and
maybe ENODEV, set *phy_id to 0xffffffff and return. The scan code
should then do the correct thing.
Andrew
^ permalink raw reply
* pull-request: bpf 2018-03-29
From: Daniel Borkmann @ 2018-03-29 14:38 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix nfp to properly check max insn count while emitting
instructions in the JIT which was wrongly comparing bytes
against number of instructions before, from Jakub.
2) Fix for bpftool to avoid usage of hex numbers in JSON
output since JSON doesn't accept hex numbers with 0x
prefix, also from Jakub.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 1bfa26ff8c4b7512f4e4efa6df211239223033d4:
ipv6: fix possible deadlock in rt6_age_examine_exception() (2018-03-23 13:40:34 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to e8a4796ee2954db9f7e9b52e5fbc66ef876752f6:
nfp: bpf: fix check of program max insn count (2018-03-24 10:41:24 -0700)
----------------------------------------------------------------
Jakub Kicinski (2):
tools: bpftool: don't use hex numbers in JSON output
nfp: bpf: fix check of program max insn count
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 6 +++++-
tools/bpf/bpftool/map.c | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
^ permalink raw reply
* [patch iproute2-next] man: fix devlink object list
From: Jiri Pirko @ 2018-03-29 14:26 UTC (permalink / raw)
To: netdev; +Cc: stephen, dsahern, mlxsw, valex
From: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
man/man8/devlink.8 | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/man/man8/devlink.8 b/man/man8/devlink.8
index b83909da9a53..7986310f0617 100644
--- a/man/man8/devlink.8
+++ b/man/man8/devlink.8
@@ -19,7 +19,7 @@ devlink \- Devlink tool
.ti -8
.IR OBJECT " := { "
-.BR dev " | " port " | " monitor " }"
+.BR dev " | " port " | " monitor " | " sb " | " resource " }"
.sp
.ti -8
@@ -74,6 +74,14 @@ When combined with -j generate a pretty JSON output.
.B monitor
- watch for netlink messages.
+.TP
+.B sb
+- devlink shared buffer configuration.
+
+.TP
+.B resource
+- devlink device resource configuration.
+
.SS
.I COMMAND
--
2.14.3
^ permalink raw reply related
* Re: [PATCH 07/30] aio: add delayed cancel support
From: Al Viro @ 2018-03-29 14:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180329085305.GA22215@lst.de>
On Thu, Mar 29, 2018 at 10:53:05AM +0200, Christoph Hellwig wrote:
> On Wed, Mar 28, 2018 at 05:35:26PM +0100, Al Viro wrote:
> > > ret = vfs_fsync(req->file, req->datasync);
> > > - fput(req->file);
> > > - aio_complete(container_of(req, struct aio_kiocb, fsync), ret, 0);
> > > + if (aio_complete(iocb, ret, 0, 0))
> > > + fput(file);
> >
> > IDGI.
> > 1) can aio_complete() ever return false here?
>
> It won't. But sometimes checking the return value and sometimes not
> seems like a bad pattern.
>
> > 2) do we ever have aio_kiocb that would not have an associated
> > struct file * that needs to be dropped on successful aio_complete()? AFAICS,
> > rw, fsync and poll variants all have one, and I'm not sure what kind of
> > async IO *could* be done without an opened file.
>
> All have a file assoiated at least right now. As mentioned last time
> finding a struct to pass that file would be rather annoying, so we'd either
> have to pass it explicitly, or do something nasty like duplicating the
> pointer in the aio_kiocb in addition to struct kiocb. Which might not
> be that bad after all, as it would only bloat the aio_kiocb and not
> struct kiocb used on stack all over.
OK. Let's leave that alone for now. Re deferred cancels - AFAICS, we *must*
remove the sucker from ctx->active_reqs before dropping ->ctx_lock.
As it is, you are creating a io_cancel()/io_cancel() race leading to double
fput(). It's not that hard to fix; I can do that myself while applying your
series (as described in previous posting - kiocb_cancel_locked() returning
NULL or ERR_PTR() in non-deferred case and pointer to aio_kiocb removed from
->active_reqs in deferred one) or you could fix it in some other way and
update your branch.
As it is, the race is user-exploitable and not that hard to trigger - AIO_POLL,
then have two threads try and cancel it at the same time.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH 000/109] remove in-kernel calls to syscalls
From: Matthew Wilcox @ 2018-03-29 14:20 UTC (permalink / raw)
To: Dominik Brodowski
Cc: linux-kernel, viro, torvalds, arnd, linux-arch, hmclauchlan,
tautschn, Amir Goldstein, Andi Kleen, Andrew Morton,
Christoph Hellwig, Darren Hart, David S . Miller,
Eric W . Biederman, H . Peter Anvin, Ingo Molnar, Jaswinder Singh,
Jeff Dike, Jiri Slaby, kexec, linux-fsdevel, linux-mm, linux-s390,
Luis R . Rodriguez, netdev
In-Reply-To: <20180329112426.23043-1-linux@dominikbrodowski.net>
On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> At least on 64-bit x86, it will likely be a hard requirement from v4.17
> onwards to not call system call functions in the kernel: It is better to
> use use a different calling convention for system calls there, where
> struct pt_regs is decoded on-the-fly in a syscall wrapper which then hands
> processing over to the actual syscall function. This means that only those
> parameters which are actually needed for a specific syscall are passed on
> during syscall entry, instead of filling in six CPU registers with random
> user space content all the time (which may cause serious trouble down the
> call chain).[*]
How do we stop new ones from springing up? Some kind of linker trick
like was used to, er, "dissuade" people from using gets()?
^ permalink raw reply
* Re: pull request (net): ipsec 2018-03-29
From: David Miller @ 2018-03-29 14:18 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20180329071120.27353-1-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 29 Mar 2018 09:11:12 +0200
> 1) Fix a rcu_read_lock/rcu_read_unlock imbalance
> in the error path of xfrm_local_error().
> From Taehee Yoo.
>
> 2) Some VTI MTU fixes. From Stefano Brivio.
>
> 3) Fix a too early overwritten skb control buffer
> on xfrm transport mode.
>
> Please not that this pull request has a merge conflict
> in net/ipv4/ip_tunnel.c.
...
Pulled, and thanks for the conflict info.
^ permalink raw reply
* Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver
From: Alexandre Belloni @ 2018-03-29 14:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Andrew Lunn, netdev, devicetree, linux-kernel,
linux-mips
In-Reply-To: <9547b11d-147d-5029-0abe-8bf0f705c959@gmail.com>
On 23/03/2018 at 14:51:19 -0700, Florian Fainelli wrote:
> > + writel(MSCC_MIIM_CMD_VLD | (mii_id << MSCC_MIIM_CMD_PHYAD_SHIFT) |
> > + (regnum << MSCC_MIIM_CMD_REGAD_SHIFT) | MSCC_MIIM_CMD_OPR_READ,
> > + miim->regs + MSCC_MIIM_REG_CMD);
> > +
> > + ret = mscc_miim_wait_ready(bus);
> > + if (ret)
> > + goto out;
>
> Your example had an interrupt specified, can't you use that instead of
> polling?
>
the interrupt doesn't handle that. It is used to detect when a PHY
register has changed once the MIIM controller is configured to poll the
phys. At some point, this could be used to replace the PHY interrupts
but it doesn't correspond to the linux model so I didn't investigate too
much.
> > + for (i = 0; i < PHY_MAX_ADDR; i++) {
> > + if (mscc_miim_read(bus, i, MII_PHYSID1) < 0)
> > + bus->phy_mask |= BIT(i);
> > + }
>
> What is this used for? You have an OF MDIO bus which would create a
> phy_device for each node specified, is this a similar workaround to what
> drivers/net/phy/mdio-bcm-unimac.c has to do? If so, please document it
> as such.
>
I replied to Andrew who had the same question.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] connector: add parent pid and tgid to coredump and exit events
From: Stefan Strogin @ 2018-03-29 14:12 UTC (permalink / raw)
To: Evgeniy Polyakov, netdev
Cc: Stefan Strogin, linux-kernel, xe-linux-external, Jesper Derehag,
Matt Helsley, Mathias Krause
The intention is to get notified of process failures as soon
as possible, before a possible core dumping (which could be very long)
(e.g. in some process-manager). Coredump and exit process events
are perfect for such use cases (see 2b5faa4c553f "connector: Added
coredumping event to the process connector").
The problem is that for now the process-manager cannot know the parent
of a dying process using connectors. This could be useful if the
process-manager should monitor for failures only children of certain
parents, so we could filter the coredump and exit events by parent
process and/or thread ID.
Add parent pid and tgid to coredump and exit process connectors event
data.
Signed-off-by: Stefan Strogin <sstrogin@cisco.com>
---
drivers/connector/cn_proc.c | 4 ++++
include/uapi/linux/cn_proc.h | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index a782ce87715c..ed5e42461094 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -262,6 +262,8 @@ void proc_coredump_connector(struct task_struct *task)
ev->what = PROC_EVENT_COREDUMP;
ev->event_data.coredump.process_pid = task->pid;
ev->event_data.coredump.process_tgid = task->tgid;
+ ev->event_data.coredump.parent_pid = task->real_parent->pid;
+ ev->event_data.coredump.parent_tgid = task->real_parent->tgid;
memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
msg->ack = 0; /* not used */
@@ -288,6 +290,8 @@ void proc_exit_connector(struct task_struct *task)
ev->event_data.exit.process_tgid = task->tgid;
ev->event_data.exit.exit_code = task->exit_code;
ev->event_data.exit.exit_signal = task->exit_signal;
+ ev->event_data.exit.parent_pid = task->real_parent->pid;
+ ev->event_data.exit.parent_tgid = task->real_parent->tgid;
memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
msg->ack = 0; /* not used */
diff --git a/include/uapi/linux/cn_proc.h b/include/uapi/linux/cn_proc.h
index 68ff25414700..db210625cee8 100644
--- a/include/uapi/linux/cn_proc.h
+++ b/include/uapi/linux/cn_proc.h
@@ -116,12 +116,16 @@ struct proc_event {
struct coredump_proc_event {
__kernel_pid_t process_pid;
__kernel_pid_t process_tgid;
+ __kernel_pid_t parent_pid;
+ __kernel_pid_t parent_tgid;
} coredump;
struct exit_proc_event {
__kernel_pid_t process_pid;
__kernel_pid_t process_tgid;
__u32 exit_code, exit_signal;
+ __kernel_pid_t parent_pid;
+ __kernel_pid_t parent_tgid;
} exit;
} event_data;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver
From: Alexandre Belloni @ 2018-03-29 14:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Florian Fainelli, netdev, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20180323204939.GS24361@lunn.ch>
On 23/03/2018 at 21:49:39 +0100, Andrew Lunn wrote:
> On Fri, Mar 23, 2018 at 09:11:12PM +0100, Alexandre Belloni wrote:
> > Add a driver for the Microsemi MII Management controller (MIIM) found on
> > Microsemi SoCs.
> > On Ocelot, there are two controllers, one is connected to the internal
> > PHYs, the other one can communicate with external PHYs.
>
> Hi Alexandre
>
> This looks to be standalone. Such drivers we try to put in
> drivers/net/phy.
>
> > +static int mscc_miim_read(struct mii_bus *bus, int mii_id, int regnum)
> > +{
> > + struct mscc_miim_dev *miim = bus->priv;
> > + u32 val;
> > + int ret;
> > +
> > + mutex_lock(&miim->lock);
>
> What are you locking against here?
>
> And you don't appear to initialize the mutex anywhere.
>
> > +static int mscc_miim_reset(struct mii_bus *bus)
> > +{
> > + struct mscc_miim_dev *miim = bus->priv;
> > + int i;
> > +
> > + if (miim->phy_regs) {
> > + writel(0, miim->phy_regs + MSCC_PHY_REG_PHY_CFG);
> > + writel(0x1ff, miim->phy_regs + MSCC_PHY_REG_PHY_CFG);
> > + mdelay(500);
> > + }
> > +
> > + for (i = 0; i < PHY_MAX_ADDR; i++) {
> > + if (mscc_miim_read(bus, i, MII_PHYSID1) < 0)
> > + bus->phy_mask |= BIT(i);
> > + }
>
> Why do this? Especially so for the external bus, where the PHYs might
> have a GPIO reset line, and won't respond until the gpio is
> released. The core code does that just before it scans the bus, or
> just before it scans the particular address on the bus, depending on
> the scope of the GPIO.
>
IIRC, this was needed when probing the bus without DT, in that case, the
mdiobus_scan loop of __mdiobus_register() will fail when doing the
get_phy_id for phys 0 to 31 because get_phy_id() transforms any error in
-EIO and so it is impossible to register the bus. Other drivers have a
similar code to handle that case.
Anyway, I'll remove that loop for now because I'm only supporting DT.
I'll get back to that later.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: David Miller @ 2018-03-29 14:04 UTC (permalink / raw)
To: okaya
Cc: benh, torvalds, alexander.duyck, will.deacon, arnd, jgg,
David.Laight, oohall, linuxppc-dev, linux-rdma, alexander.h.duyck,
paulmck, netdev, linus971
In-Reply-To: <29fe17e0-9978-dc43-d02c-de8fabdc66c2@codeaurora.org>
From: Sinan Kaya <okaya@codeaurora.org>
Date: Thu, 29 Mar 2018 09:56:01 -0400
> sparc question sent
Sparc never lets physical memory accesses pass MMIO, and vice versa.
They are always strongly ordered amongst eachother.
Therefore no explicit barrier instructions are necessary.
^ 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