* Re: [PATCH] mlx4_ib: Increase the timeout for CM cache
From: Håkon Bugge @ 2019-02-06 8:50 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: netdev, OFED mailing list, rds-devel, linux-kernel,
Jack Morgenstein
In-Reply-To: <20190205223608.GA23110@ziepe.ca>
> On 5 Feb 2019, at 23:36, Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Thu, Jan 31, 2019 at 06:09:51PM +0100, Håkon Bugge wrote:
>> Using CX-3 virtual functions, either from a bare-metal machine or
>> pass-through from a VM, MAD packets are proxied through the PF driver.
>>
>> Since the VMs have separate name spaces for MAD Transaction Ids
>> (TIDs), the PF driver has to re-map the TIDs and keep the book keeping
>> in a cache.
>>
>> Following the RDMA CM protocol, it is clear when an entry has to
>> evicted form the cache. But life is not perfect, remote peers may die
>> or be rebooted. Hence, it's a timeout to wipe out a cache entry, when
>> the PF driver assumes the remote peer has gone.
>>
>> We have experienced excessive amount of DREQ retries during fail-over
>> testing, when running with eight VMs per database server.
>>
>> The problem has been reproduced in a bare-metal system using one VM
>> per physical node. In this environment, running 256 processes in each
>> VM, each process uses RDMA CM to create an RC QP between himself and
>> all (256) remote processes. All in all 16K QPs.
>>
>> When tearing down these 16K QPs, excessive DREQ retries (and
>> duplicates) are observed. With some cat/paste/awk wizardry on the
>> infiniband_cm sysfs, we observe:
>>
>> dreq: 5007
>> cm_rx_msgs:
>> drep: 3838
>> dreq: 13018
>> rep: 8128
>> req: 8256
>> rtu: 8256
>> cm_tx_msgs:
>> drep: 8011
>> dreq: 68856
>> rep: 8256
>> req: 8128
>> rtu: 8128
>> cm_tx_retries:
>> dreq: 60483
>>
>> Note that the active/passive side is distributed.
>>
>> Enabling pr_debug in cm.c gives tons of:
>>
>> [171778.814239] <mlx4_ib> mlx4_ib_multiplex_cm_handler: id{slave:
>> 1,sl_cm_id: 0xd393089f} is NULL!
>>
>> By increasing the CM_CLEANUP_CACHE_TIMEOUT from 5 to 30 seconds, the
>> tear-down phase of the application is reduced from 113 to 67
>> seconds. Retries/duplicates are also significantly reduced:
>>
>> cm_rx_duplicates:
>> dreq: 7726
>> []
>> cm_tx_retries:
>> drep: 1
>> dreq: 7779
>>
>> Increasing the timeout further didn't help, as these duplicates and
>> retries stem from a too short CMA timeout, which was 20 (~4 seconds)
>> on the systems. By increasing the CMA timeout to 22 (~17 seconds), the
>> numbers fell down to about one hundred for both of them.
>>
>> Adjustment of the CMA timeout is _not_ part of this commit.
>>
>> Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
>> ---
>> drivers/infiniband/hw/mlx4/cm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Jack? What do you think?
I am tempted to send a v2 making this a sysctl tuneable. This because, full-rack testing using 8 servers, each with 8 VMs, only showed 33% reduction in the occurrences of "mlx4_ib_multiplex_cm_handler: id{slave:1,sl_cm_id: 0xd393089f} is NULL" with this commit.
But sure, Jack's opinion matters.
Thxs, Håkon
>
>> diff --git a/drivers/infiniband/hw/mlx4/cm.c b/drivers/infiniband/hw/mlx4/cm.c
>> index fedaf8260105..8c79a480f2b7 100644
>> --- a/drivers/infiniband/hw/mlx4/cm.c
>> +++ b/drivers/infiniband/hw/mlx4/cm.c
>> @@ -39,7 +39,7 @@
>>
>> #include "mlx4_ib.h"
>>
>> -#define CM_CLEANUP_CACHE_TIMEOUT (5 * HZ)
>> +#define CM_CLEANUP_CACHE_TIMEOUT (30 * HZ)
>>
>> struct id_map_entry {
>> struct rb_node node;
>> --
>> 2.20.1
^ permalink raw reply
* Re: [PATCH] rhashtable: use irq-safe spinlock in rhashtable_rehash_table()
From: Johannes Berg @ 2019-02-06 8:15 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: Jouni Malinen, Thomas Graf, Herbert Xu
In-Reply-To: <20190205143706.28371-1-johannes@sipsolutions.net>
On Tue, 2019-02-05 at 15:37 +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> When an rhashtabl walk is done from irq/bh context, we rightfully
> get a lockdep complaint saying that we could get a (soft-)IRQ in
> the middle of a rehash. This happened e.g. in mac80211 as it does
> a walk in soft-irq context.
>
> Fix this by using irq-safe locking here. We don't need _irqsave()
> as we know this will be called only in process context from the
> workqueue. We could get away with _bh() but that seems a bit less
> generic, though I'm not sure anyone would want to do a walk from
> a real IRQ handler.
Please drop this, it doesn't make sense.
I'll resend with all the spinlock usage changed to either _bh or
_irqsave(), since it makes no sense to enforce any kind of outside
BH/irq disabling for purposes of the inner lock.
johannes
^ permalink raw reply
* Re: [PATCH net-next v3 00/12] net: Introduce ndo_get_port_parent_id()
From: Ido Schimmel @ 2019-02-06 7:51 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, open list,
open list:MELLANOX MLX5 core VPI driver,
open list:NETRONOME ETHERNET DRIVERS, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE
In-Reply-To: <20190205235326.14600-1-f.fainelli@gmail.com>
On Tue, Feb 05, 2019 at 03:53:14PM -0800, Florian Fainelli wrote:
> Hi all,
>
> Based on discussion with Ido and feedback from Jakub there are clearly
> two classes of users that implement SWITCHDEV_ATTR_ID_PORT_PARENT_ID:
>
> - PF/VF drivers which typically only implement return the port's parent
> ID, yet have to implement switchdev_port_attr_get() just for that
>
> - Ethernet switch drivers: mlxsw, ocelot, DSA, etc. which implement more
> attributes which we want to be able to eventually veto in the context
> of the caller, thus making them candidates for using a blocking notifier
> chain
Florian, patches look good to me. I'm going to build a kernel with these
patches and run some tests. Will report later today.
Thanks
^ permalink raw reply
* Re: [PATCH net 0/3] net: stmmac: Misc fixes
From: Jose Abreu @ 2019-02-06 7:37 UTC (permalink / raw)
To: Niklas Cassel, Jose Abreu
Cc: netdev, Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, vinod.koul
In-Reply-To: <20190205220544.GA25400@centauri.lan>
Hi Niklas,
On 2/5/2019 10:05 PM, Niklas Cassel wrote:
> On Wed, Jan 30, 2019 at 03:54:18PM +0100, Jose Abreu wrote:
>>
>> Some misc fixes for stmmac targeting -net.
>>
>> Cc: Joao Pinto <jpinto@synopsys.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> Cc: Alexandre Torgue <alexandre.torgue@st.com>
>>
>> Jose Abreu (3):
>> net: stmmac: Fallback to Platform Data clock in Watchdog conversion
>> net: stmmac: Send TSO packets always from Queue 0
>> net: stmmac: Disable EEE mode earlier in XMIT callback
>
> Hello Jose,
>
> Thanks for your great work of improving the stmmac driver.
>
> Unfortunately, I'm seeing that a lot of important stmmac fixes
> aren't getting backported to stable kernels.
>
>
> I think that the problem is that a lot of stmmac commit messages do
> not clearly indicate what happens if these patches are not included.
>
> See netdev FAQ:
>
> Q: I have created a network patch and I think it should be backported to
> stable. Should I add a "Cc: stable@vger.kernel.org" like the references
> in the kernel's Documentation/ directory say?
>
> A: No. See above answer. In short, if you think it really belongs in
> stable, then ensure you write a decent commit log that describes who
> gets impacted by the bugfix and how it manifests itself, and when the
> bug was introduced. If you do that properly, then the commit will
> get handled appropriately and most likely get put in the patchworks
> stable queue if it really warrants it.
I will try to add a Fixes tag and explain more carefully the next
time. Sorry.
>
>
>
> Could you please tell me what happens if I don't include
> "net: stmmac: Disable EEE mode earlier in XMIT callback" ?
Probably a drop in performance. Not critical though.
>
>
> likewise if I don't include "net: stmmac: Send TSO packets always from
> Queue 0" ?
In my tests I get a drop in performance also.
>
> I assume that I will get a TX timeout if I try to send a TSO packet
> from a queue that does not support it?
No. Packets will still be sent but they will not be TSO packets.
>
> Also, we already define the TX queues in the snps,mtl-tx-config:
> Documentation/devicetree/bindings/net/stmmac.txt
>
> Wouldn't it be possible to add a snps,tso-capable property for each tx
> queue node that supports tso?
Yes but that would be more like a -next improvement.
Thanks,
Jose Miguel Abreu
>
>
> Kind regards,
> Niklas
>
>>
>> drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 14 ++++++++++----
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 17 +++++++++++++----
>> include/linux/stmmac.h | 1 +
>> 3 files changed, 24 insertions(+), 8 deletions(-)
>>
>> --
>> 2.7.4
>>
^ permalink raw reply
* Re: [PATCH v2 2/2] r8169: Avoid pointer aliasing
From: Michal Kubecek @ 2019-02-06 7:25 UTC (permalink / raw)
To: netdev
Cc: Joe Perches, David Miller, thierry.reding, hkallweit1, andrew,
nic_swsd, linux-kernel
In-Reply-To: <143a8f022c73c71f170eb04dc0b763f9ae83f6b5.camel@perches.com>
On Tue, Feb 05, 2019 at 11:19:04AM -0800, Joe Perches wrote:
> On Tue, 2019-02-05 at 11:14 -0800, David Miller wrote:
> > From: Joe Perches <joe@perches.com>
> > Date: Tue, 05 Feb 2019 10:42:54 -0800
> >
> > > On Mon, 2019-02-04 at 19:20 -0800, David Miller wrote:
> > >> From: Thierry Reding <thierry.reding@gmail.com>
> > >> Date: Mon, 4 Feb 2019 17:42:13 +0100
> > >>
> > >> > @@ -7316,7 +7325,7 @@ static int rtl_get_ether_clk(struct rtl8169_private *tp)
> > >> > static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> > >> > {
> > >> > const struct rtl_cfg_info *cfg = rtl_cfg_infos + ent->driver_data;
> > >> > - u8 mac_addr[ETH_ALEN] __aligned(4) = {};
> > >> > + u8 mac_addr[ETH_ALEN] = {};
> > >> > struct rtl8169_private *tp;
> > >>
> > >> I agree with Heiner, you have to provide at least 2 byte alignment for this
> > >> buffer due to the reasons he stated.
> > >
> > > It's declared after a pointer so it is already is 2 byte aligned.
> > >
> > > A lot of drivers wouldn't work otherwise.
> >
> > That's assuming a lot about what the compiler will do when nit allocates
> > local variables to the stack.
>
> It's also assuming what a compiler will do when
> it defines a struct.
This is not a structure member, it's a local variable. I'm not aware of
any C norm requirement for ordering of local variables on the stack.
After all, some of them might not be on the stack at all and use only
registers or be optimized out completely.
Michal Kubecek
^ permalink raw reply
* pull-request: wireless-drivers-next 2019-02-06
From: Kalle Valo @ 2019-02-06 7:17 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net-next for 5.1, more info below. Please let
me know if there are any problems.
Kalle
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2019-02-06
for you to fetch changes up to 030b43671ae88f827a415ad35700705ffc10d10d:
wireless: prefix header search paths with $(srctree)/ (2019-02-01 14:42:25 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 5.1
First set of patches for 5.1. Lots of new features in various drivers
but nothing really special standing out.
Major changes:
brcmfmac
* DMI nvram filename quirk for PoV TAB-P1006W-232 tablet
rsi
* support for hardware scan offload
iwlwifi
* support for Target Wakeup Time (TWT) -- a feature that allows the AP
to specify when individual stations can access the medium
* support for mac80211 AMSDU handling
* some new PCI IDs
* relicense the pcie submodule to dual GPL/BSD
* reworked the TOF/CSI (channel estimation matrix) implementation
* Some product name updates in the human-readable strings
mt76
* energy detect regulatory compliance fixes
* preparation for MT7603 support
* channel switch announcement support
mwifiex
* support for sd8977 chipset
qtnfmac
* support for 4addr mode
* convert to SPDX license identifiers
----------------------------------------------------------------
Andrei Otcheretianski (1):
iwlwifi: mvm: Disconnect on large beacon loss
Andrey Shevchenko (1):
qtnfmac: support EBUSY errcode for QLINK protocol
Bernd Edlinger (5):
rtl8723ae: Take the FW LPS mode handling out
rtl8723ae: Dont use old data for input gain control
rtl8723ae: Re-introduce the adaptive rate control
rtlwifi: Don't clear num_rx_inperiod too early
rt2x00: Work around a firmware bug with shared keys
Colin Ian King (8):
ray_cs: fix array out-of-bounds access
mt76: make const array 'data' static, shrinks object size
iwlwifi: pcie: make array 'prop' static, shrinks object size
iwlwifi: fix spelling mistake "registrating" -> "registering"
libertas: fix indentation issue
cw1200: fix indentation issues
rtlwifi: rtl818x: fix indentation issue
wlcore: clean up an indentation issue
David Spinadel (1):
iwlwifi: mvm: Change FW channel info API
Emmanuel Grumbach (4):
iwlwifi: mvm: advertise support for TWT in the Extended Capability IE
iwlwifi: mvm: rely on mac80211 to configure TWT support
iwlwifi: mvm: fix firmware statistics usage
iwlwifi: mvm: freeze management TXQ timer when station goes to sleep
Felix Fietkau (12):
mt76: add size check for additional rx fragments
mt76: throttle transmission of buffered multicast packets
mt76: request tx status for powersave released EOSP packet
mt76: fix tx status reporting for non-probing frames
mt76: set IEEE80211_HW_NEEDS_UNIQUE_STA_ADDR flag
mt76: move mt76x02_get_txpower to mt76 core
mt76: move mt76x02_phy_get_min_avg_rssi to mt76 core
mt76: fix rssi ewma tracking
mt76: fix signedness of rx status signal field
mt76: add channel switch announcement support
mt76: fix per-chain signal strength reporting
mt76: avoid scheduling tx queues for powersave stations
Greg Kroah-Hartman (15):
iwlegacy: no need to check return value of debugfs_create functions
wlcore: no need to check return value of debugfs_create functions
wl1251: no need to check return value of debugfs_create functions
wl12xx: no need to check return value of debugfs_create functions
wl18xx: no need to check return value of debugfs_create functions
rtlwifi: no need to check return value of debugfs_create functions
qtnfmac: no need to check return value of debugfs_create functions
cw1200: no need to check return value of debugfs_create functions
b43: no need to check return value of debugfs_create functions
b43legacy: no need to check return value of debugfs_create functions
brcmsmac: no need to check return value of debugfs_create functions
rsi: no need to check return value of debugfs_create functions
rt2x00: no need to check return value of debugfs_create functions
libertas: no need to check return value of debugfs_create functions
mwifiex: no need to check return value of debugfs_create functions
Gustavo A. R. Silva (1):
qtnfmac: use struct_size() in kzalloc()
Hans de Goede (2):
brcmfmac: Add DMI nvram filename quirk for PoV TAB-P1006W-232 tablet
brcmfmac: Use firmware_request_nowarn for the clm_blob
Hauke Mehrtens (1):
mt76: Add missing include of linux/module.h
Hemantkumar Suthar (1):
mwifiex: add support for sd8977 chipset
Ihab Zhaika (3):
iwlwifi: correct one of the PCI struct names
iwlwifi: add new cards for 22560, 9260 and killer series
iwlwifi: update product name for 9260 and 9560
Ilan Peer (3):
iwlwifi: mvm: Flush transmit queues on P2P Device ROC done
iwlwifi: mvm: Set Tx rate and flags when there is not station
iwlwifi: mvm: Do not set RTS/CTS protection for P2P Device MAC
Johannes Berg (16):
iwlwifi: mvm: make NVM access actually fail on failures
iwlwifi: fw api: remove unused/deprecated filter status
iwlwifi: fw api: document WoWLAN patterns command
iwlwifi: mvm: fix %16 to %016 print format
iwlwifi: mvm: read IWL_RX_MPDU_PHY_SHORT_PREAMBLE only for CCK
iwlwifi: pcie: align licensing to dual GPL/BSD
iwlwifi: mvm: clean up LDBG config command usage
iwlwifi: move iwl_enable_{rx,tx}_ampdu to iwl-modparams.h
iwlwifi: mvm: fix A-MPDU reference assignment
iwlwifi: remove TOF implementation
iwlwifi: dvm: remove useless condition
iwlwifi: pcie: use u32* argument to iwl_trans_get_fw_monitor_len()
iwlwifi: mvm: add location APIs
iwlwifi: mvm: implement CSI reporting
iwlwifi: mvm: document monitor mode reorder buffer bypass
iwlwifi: mvm: include configured sniffer AID in radiotap
Julia Lawall (1):
cw1200: drop useless LIST_HEAD
Kalle Valo (3):
Merge tag 'iwlwifi-next-for-kalle-2019-01-25' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge tag 'mt76-for-kvalo-2019-01-22' of https://github.com/nbd168/wireless
Merge tag 'iwlwifi-next-for-kalle-2019-01-29' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Kangjie Lu (2):
brcmfmac: add a check for the status of usb_register
libertas: add checks for the return value of sysfs_create_group
Liad Kaufman (5):
iwlwifi: update hcmds documentation
iwlwifi: mvm: make num_active_macs unsigned
iwlwifi: tighten boundary checks
iwlwifi: memcpy from dev_cmd and not dev_cmd->hdr
iwlwifi: mvm: remove sta key on wep ap
Lo-Hsiang Lo (1):
brcmfmac: fix system warning message during wowl suspend
Lorenzo Bianconi (18):
mt76: dma: remove napi from mt76_dma_rx_fill signature
mt76: usb: do not build the skb if reported len does not fit in buf_size
mt76: fix typo in mt76x02_check_mac_err routine
mt76: mac: run mt76x02_mac_work routine atomically
mt76: usb: avoid queue/status spinlocks while passing tx status to mac80211
mt76x0: pci: fix ACS support
mt76x2: add static qualifier to mt76x2_init_hardware
mt76: dfs: run mt76x02_dfs_set_domain atomically
mt76x2: init: set default value for MT_TX_LINK_CFG
mt76: add energy detect CCA support to mt76x{0,2}e drivers
mt76: mac: minor optimizations in mt76x02_mac_tx_rate_val
mt76: dma: do not build skb if reported len does not fit in buf_size
mt76: mmio: introduce mt76x02_check_tx_hang watchdog
mt76: dma: avoid indirect call in mt76_dma_tx_queue_skb
mt76: use proper name for __MT76x02_H macro
mt76: add led support to mt76x0e driver
mt76: do not report out-of-range rx nss
mt7601u: do not use WARN_ON in the datapath
Luca Coelho (12):
iwlwifi: add PCI IDs for the 22260 device series
iwlwifi: pcie: recognize NICs with hw_rev 0x364 correctly
iwlwifi: remove support for 9000 A-step devices
iwlwifi: pcie: remove unnecessary iwl_pcie_enable_rx_wake() function
iwlwifi: pcie: remove suspend/resume workaround for 9000A devices
iwlwifi: mvm: fix values in the table example
iwlwifi: mvm: save and export regdb blob from the NVM
iwlwifi: make iwl_fw_dbg_start_stop_hcmd() inline
iwlwifi: mvm: pre-initialize alive_data in wait_alive()
iwlwifi: calculate pointers from out_cmd instead of out_cmd->hdr
iwlwifi: make sure cur_fw_img is valid before accessing img
iwlwifi: mvm: fix merge damage in iwl_mvm_rx_mpdu_mq()
Masahiro Yamada (1):
wireless: prefix header search paths with $(srctree)/
Mordechay Goodstein (3):
iwlwifi: mvm: avoid possible access out of array.
iwlwifi: avoid access out of memory allocated
iwlwifi: mvm: disable completely low latency mode with debugfs
Prameela Rani Garnepudi (1):
rsi: add support for hardware scan offload
Rafał Miłecki (2):
bcma: keep a direct pointer to the struct device
bcma: use dev_* printing functions
Sara Sharon (7):
iwlwifi: mvm: support mac80211 TXQs model
iwlwifi: mvm: support mac80211 AMSDU
iwlwifi: mvm: bring back mvm GSO code
iwlwifi: pcie: fix the use of a wrong define
iwlwifi: pcie: add prints to track virtual ID
iwlwifi: mvm: add an option to dereference vif by id
iwlwifi: mvm: get rid of tx_path_lock
Sergey Matyukevich (8):
qtnfmac: fix INTx interrupt handling
qtnfmac: add support for 4addr mode
qtnfmac: switch to 32bit values for RTS/FRAG thresholds
qtnfmac: do not reject retry changes in driver
qtnfmac: convert to SPDX license identifiers
qtnfmac: add missing bss record to host scan cache
qtnfmac: remove unused declarations
qtnfmac: qtnf_cmd_send_with_reply cleanup
Shahar S Matityahu (9):
iwlwifi: wrt: add to dump number of lmacs, lmac1 and umac error id
iwlwifi: wrt: add 22000 device familiy prph dump support
iwlwifi: monitor dumping flow cleanup
iwlwifi: trigger dump on assert prior to setting the device up
iwlwifi: dbg_ini: allocate dram buffer with proper flags
iwlwifi: dbg_ini: properly handle ini user trigger
iwlwifi: dbg_ini: retrieve dump_delay value properly
iwlwifi: dbg_ini: set dump mask BIT(n) instead of n
iwiwifi: fix bad monitor buffer register addresses
Shaul Triebitz (4):
iwlwifi: mvm: fix wrong DCM TLC config
iwlwifi: iwlmvm: ignore HE PPDU type regarding EOF
iwlwifi: iwlmvm: in monitor NDP notif take the NSS from rx_vec
iwlwifi: mvm: update firmware when MU EDCA params change
Siva Rebbagondla (1):
rsi: Suppress sdhci warnings in mmc
Stanislaw Gruszka (5):
mt76x02: do not set protection on set_rts_threshold callback
mt76x02: fixup MT_PROT_RATE_* defines
mt76x02: set protection according to ht operation element
mt76x0: configure MT_VHT_HT_FBK_CFG1
mt7601u: bump supported EEPROM version
Tomislav Požega (1):
rt2x00: reduce tx power to nominal level on RT6352
Wei Yongjun (1):
cw1200: fix missing unlock on error in cw1200_hw_scan()
YueHaibing (3):
brcmsmac: remove set but not used variables 'phybw40, maxtargetpwr'
iwlwifi: use kmemdup in iwl_parse_nvm_mcc_info()
wireless: remove unneeded semicolon
Zumeng Chen (1):
wlcore: Fix memory leak in case wl12xx_fetch_firmware failure
drivers/bcma/bcma_private.h | 9 +-
drivers/bcma/driver_gpio.c | 2 +-
drivers/bcma/host_pci.c | 2 +
drivers/bcma/host_soc.c | 4 +-
drivers/bcma/main.c | 45 +-
drivers/net/wireless/ath/ath10k/wmi.h | 2 +-
drivers/net/wireless/ath/ath6kl/init.c | 2 +-
drivers/net/wireless/broadcom/b43/debugfs.c | 36 +-
drivers/net/wireless/broadcom/b43legacy/debugfs.c | 35 +-
.../wireless/broadcom/brcm80211/brcmfmac/Makefile | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/dmi.c | 15 +
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 5 +
.../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 6 +-
.../wireless/broadcom/brcm80211/brcmsmac/Makefile | 6 +-
.../wireless/broadcom/brcm80211/brcmsmac/debug.c | 26 +-
.../wireless/broadcom/brcm80211/brcmsmac/debug.h | 2 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_lcn.c | 13 +-
.../wireless/broadcom/brcm80211/brcmutil/Makefile | 4 +-
drivers/net/wireless/intel/iwlegacy/3945-mac.c | 5 +-
drivers/net/wireless/intel/iwlegacy/4965-mac.c | 5 +-
drivers/net/wireless/intel/iwlegacy/common.h | 6 +-
drivers/net/wireless/intel/iwlegacy/debug.c | 34 +-
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 74 +-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 139 ++--
drivers/net/wireless/intel/iwlwifi/dvm/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c | 23 +-
drivers/net/wireless/intel/iwlwifi/dvm/main.c | 2 +-
drivers/net/wireless/intel/iwlwifi/dvm/tt.c | 5 +-
.../net/wireless/intel/iwlwifi/fw/api/commands.h | 23 +-
drivers/net/wireless/intel/iwlwifi/fw/api/d3.h | 10 +
.../net/wireless/intel/iwlwifi/fw/api/datapath.h | 55 ++
drivers/net/wireless/intel/iwlwifi/fw/api/debug.h | 33 +-
.../net/wireless/intel/iwlwifi/fw/api/location.h | 711 ++++++++++++++++++
.../net/wireless/intel/iwlwifi/fw/api/phy-ctxt.h | 51 +-
drivers/net/wireless/intel/iwlwifi/fw/api/rx.h | 11 +-
drivers/net/wireless/intel/iwlwifi/fw/api/stats.h | 15 +-
drivers/net/wireless/intel/iwlwifi/fw/api/tdls.h | 19 +-
.../net/wireless/intel/iwlwifi/fw/api/time-event.h | 34 +-
drivers/net/wireless/intel/iwlwifi/fw/api/tof.h | 393 ----------
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 212 ++++--
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 22 +-
drivers/net/wireless/intel/iwlwifi/fw/error-dump.h | 11 +-
drivers/net/wireless/intel/iwlwifi/fw/file.h | 12 +-
drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 3 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 17 +-
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 27 +-
drivers/net/wireless/intel/iwlwifi/iwl-io.c | 41 +-
drivers/net/wireless/intel/iwlwifi/iwl-io.h | 38 +-
drivers/net/wireless/intel/iwlwifi/iwl-modparams.h | 18 +
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 7 +-
drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 8 +-
.../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 813 ++-------------------
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 91 +--
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 7 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 200 ++---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 249 +++++--
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 203 ++++-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 15 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 116 +--
drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c | 24 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 21 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 26 +-
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 10 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 104 ++-
drivers/net/wireless/intel/iwlwifi/mvm/sf.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 377 ++++------
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 4 -
drivers/net/wireless/intel/iwlwifi/mvm/tdls.c | 33 +-
.../net/wireless/intel/iwlwifi/mvm/time-event.c | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/tof.c | 305 --------
drivers/net/wireless/intel/iwlwifi/mvm/tof.h | 89 ---
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 161 ++--
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 37 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 266 ++++---
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 46 +-
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 78 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 45 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 14 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 47 +-
drivers/net/wireless/marvell/libertas/debugfs.c | 6 -
drivers/net/wireless/marvell/libertas/mesh.c | 5 +
drivers/net/wireless/marvell/libertas_tf/main.c | 2 +-
drivers/net/wireless/marvell/mwifiex/Kconfig | 2 +-
drivers/net/wireless/marvell/mwifiex/debugfs.c | 5 +-
drivers/net/wireless/marvell/mwifiex/sdio.c | 5 +
drivers/net/wireless/marvell/mwifiex/sdio.h | 70 ++
drivers/net/wireless/mediatek/mt76/dma.c | 31 +-
drivers/net/wireless/mediatek/mt76/mac80211.c | 68 +-
drivers/net/wireless/mediatek/mt76/mt76.h | 23 +-
.../net/wireless/mediatek/mt76/mt76x0/initvals.h | 1 +
drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 11 +-
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 6 +-
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 2 +-
.../net/wireless/mediatek/mt76/mt76x0/usb_mcu.c | 1 +
drivers/net/wireless/mediatek/mt76/mt76x02.h | 22 +-
.../net/wireless/mediatek/mt76/mt76x02_debugfs.c | 2 +
drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c | 6 +
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 222 +++++-
drivers/net/wireless/mediatek/mt76/mt76x02_mac.h | 12 +-
drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c | 142 +++-
drivers/net/wireless/mediatek/mt76/mt76x02_phy.c | 47 --
drivers/net/wireless/mediatek/mt76/mt76x02_phy.h | 1 -
drivers/net/wireless/mediatek/mt76/mt76x02_regs.h | 38 +-
drivers/net/wireless/mediatek/mt76/mt76x02_txrx.c | 2 +-
.../net/wireless/mediatek/mt76/mt76x02_usb_core.c | 3 +-
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 89 ++-
drivers/net/wireless/mediatek/mt76/mt76x2/init.c | 1 +
drivers/net/wireless/mediatek/mt76/mt76x2/mcu.h | 23 -
drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2.h | 1 -
.../net/wireless/mediatek/mt76/mt76x2/pci_init.c | 58 +-
.../net/wireless/mediatek/mt76/mt76x2/pci_main.c | 4 +-
.../net/wireless/mediatek/mt76/mt76x2/pci_phy.c | 2 +
drivers/net/wireless/mediatek/mt76/mt76x2/phy.c | 4 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_main.c | 2 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_mcu.c | 2 +-
drivers/net/wireless/mediatek/mt76/tx.c | 17 +-
drivers/net/wireless/mediatek/mt76/usb.c | 20 +-
drivers/net/wireless/mediatek/mt76/util.c | 42 ++
drivers/net/wireless/mediatek/mt7601u/dma.c | 6 +-
drivers/net/wireless/mediatek/mt7601u/eeprom.h | 2 +-
drivers/net/wireless/quantenna/Makefile | 1 +
drivers/net/wireless/quantenna/qtnfmac/bus.h | 19 +-
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 43 +-
drivers/net/wireless/quantenna/qtnfmac/cfg80211.h | 17 +-
drivers/net/wireless/quantenna/qtnfmac/commands.c | 63 +-
drivers/net/wireless/quantenna/qtnfmac/commands.h | 22 +-
drivers/net/wireless/quantenna/qtnfmac/core.c | 21 +-
drivers/net/wireless/quantenna/qtnfmac/core.h | 17 +-
drivers/net/wireless/quantenna/qtnfmac/debug.c | 31 +-
drivers/net/wireless/quantenna/qtnfmac/debug.h | 17 +-
drivers/net/wireless/quantenna/qtnfmac/event.c | 96 ++-
drivers/net/wireless/quantenna/qtnfmac/event.h | 17 +-
.../wireless/quantenna/qtnfmac/pcie/topaz_pcie.c | 6 +-
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 27 +-
.../net/wireless/quantenna/qtnfmac/qlink_util.c | 16 +-
.../net/wireless/quantenna/qtnfmac/qlink_util.h | 28 +-
.../net/wireless/quantenna/qtnfmac/qtn_hw_ids.h | 17 +-
drivers/net/wireless/quantenna/qtnfmac/shm_ipc.c | 17 +-
drivers/net/wireless/quantenna/qtnfmac/shm_ipc.h | 17 +-
.../net/wireless/quantenna/qtnfmac/shm_ipc_defs.h | 17 +-
drivers/net/wireless/quantenna/qtnfmac/trans.c | 17 +-
drivers/net/wireless/quantenna/qtnfmac/trans.h | 17 +-
drivers/net/wireless/quantenna/qtnfmac/util.c | 17 +-
drivers/net/wireless/quantenna/qtnfmac/util.h | 17 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 27 -
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 93 +--
drivers/net/wireless/ray_cs.c | 4 +-
.../net/wireless/realtek/rtl818x/rtl8180/Makefile | 2 +-
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c | 2 +-
.../net/wireless/realtek/rtl818x/rtl8187/Makefile | 2 +-
drivers/net/wireless/realtek/rtlwifi/base.c | 4 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +
drivers/net/wireless/realtek/rtlwifi/debug.c | 14 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 95 ++-
.../net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 6 +-
drivers/net/wireless/rsi/rsi_91x_debugfs.c | 5 -
drivers/net/wireless/rsi/rsi_91x_hal.c | 3 +
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 67 ++
drivers/net/wireless/rsi/rsi_91x_main.c | 1 +
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 133 ++++
drivers/net/wireless/rsi/rsi_91x_sdio.c | 15 +-
drivers/net/wireless/rsi/rsi_main.h | 22 +
drivers/net/wireless/rsi/rsi_mgmt.h | 35 +
drivers/net/wireless/st/cw1200/debug.c | 26 +-
drivers/net/wireless/st/cw1200/fwio.c | 4 +-
drivers/net/wireless/st/cw1200/queue.c | 1 -
drivers/net/wireless/st/cw1200/scan.c | 5 +-
drivers/net/wireless/ti/wl1251/debugfs.c | 59 +-
drivers/net/wireless/ti/wl12xx/debugfs.c | 20 +-
drivers/net/wireless/ti/wl18xx/debugfs.c | 20 +-
drivers/net/wireless/ti/wlcore/cmd.c | 2 +-
drivers/net/wireless/ti/wlcore/debugfs.c | 28 +-
drivers/net/wireless/ti/wlcore/debugfs.h | 10 +-
drivers/net/wireless/ti/wlcore/main.c | 7 +-
include/linux/bcma/bcma.h | 11 +-
183 files changed, 4083 insertions(+), 3927 deletions(-)
create mode 100644 drivers/net/wireless/intel/iwlwifi/fw/api/location.h
delete mode 100644 drivers/net/wireless/intel/iwlwifi/fw/api/tof.h
delete mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/tof.c
delete mode 100644 drivers/net/wireless/intel/iwlwifi/mvm/tof.h
^ permalink raw reply
* [PATCH 2/2 v2 net-next] net: phy: make use of new MMD accessors
From: Heiner Kallweit @ 2019-02-06 6:38 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller, Russell King
Cc: netdev@vger.kernel.org, Nikita Yushchenko
In-Reply-To: <e0e26b49-8e77-98f5-01df-6b7c7938ea41@gmail.com>
Make use of the new MMD accessors.
v2:
- fix SoB
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/dp83867.c | 47 +++++++++++++-----------------------
drivers/net/phy/dp83tc811.c | 15 +++---------
drivers/net/phy/marvell10g.c | 38 ++++++++---------------------
drivers/net/phy/phy-c45.c | 21 +++-------------
drivers/net/phy/phy.c | 11 +++------
5 files changed, 38 insertions(+), 94 deletions(-)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 8a8d9f606..fc09c5c1a 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -127,17 +127,13 @@ static int dp83867_config_port_mirroring(struct phy_device *phydev)
{
struct dp83867_private *dp83867 =
(struct dp83867_private *)phydev->priv;
- u16 val;
-
- val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4);
if (dp83867->port_mirroring == DP83867_PORT_MIRROING_EN)
- val |= DP83867_CFG4_PORT_MIRROR_EN;
+ phy_set_bits_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4,
+ DP83867_CFG4_PORT_MIRROR_EN);
else
- val &= ~DP83867_CFG4_PORT_MIRROR_EN;
-
- phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4, val);
-
+ phy_clear_bits_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4,
+ DP83867_CFG4_PORT_MIRROR_EN);
return 0;
}
@@ -222,11 +218,9 @@ static int dp83867_config_init(struct phy_device *phydev)
}
/* RX_DV/RX_CTRL strapped in mode 1 or mode 2 workaround */
- if (dp83867->rxctrl_strap_quirk) {
- val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4);
- val &= ~BIT(7);
- phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4, val);
- }
+ if (dp83867->rxctrl_strap_quirk)
+ phy_clear_bits_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4,
+ BIT(7));
if (phy_interface_is_rgmii(phydev)) {
val = phy_read(phydev, MII_DP83867_PHYCTRL);
@@ -275,17 +269,11 @@ static int dp83867_config_init(struct phy_device *phydev)
phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_RGMIIDCTL,
delay);
- if (dp83867->io_impedance >= 0) {
- val = phy_read_mmd(phydev, DP83867_DEVADDR,
- DP83867_IO_MUX_CFG);
-
- val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
- val |= dp83867->io_impedance &
- DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
-
- phy_write_mmd(phydev, DP83867_DEVADDR,
- DP83867_IO_MUX_CFG, val);
- }
+ if (dp83867->io_impedance >= 0)
+ phy_modify_mmd(phydev, DP83867_DEVADDR, DP83867_IO_MUX_CFG,
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL,
+ dp83867->io_impedance &
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL);
}
/* Enable Interrupt output INT_OE in CFG3 register */
@@ -299,12 +287,11 @@ static int dp83867_config_init(struct phy_device *phydev)
dp83867_config_port_mirroring(phydev);
/* Clock output selection if muxing property is set */
- if (dp83867->clk_output_sel != DP83867_CLK_O_SEL_REF_CLK) {
- val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_IO_MUX_CFG);
- val &= ~DP83867_IO_MUX_CFG_CLK_O_SEL_MASK;
- val |= (dp83867->clk_output_sel << DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT);
- phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_IO_MUX_CFG, val);
- }
+ if (dp83867->clk_output_sel != DP83867_CLK_O_SEL_REF_CLK)
+ phy_modify_mmd(phydev, DP83867_DEVADDR, DP83867_IO_MUX_CFG,
+ DP83867_IO_MUX_CFG_CLK_O_SEL_MASK,
+ dp83867->clk_output_sel <<
+ DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT);
return 0;
}
diff --git a/drivers/net/phy/dp83tc811.c b/drivers/net/phy/dp83tc811.c
index da1335699..e9704af1d 100644
--- a/drivers/net/phy/dp83tc811.c
+++ b/drivers/net/phy/dp83tc811.c
@@ -144,11 +144,8 @@ static int dp83811_set_wol(struct phy_device *phydev,
phy_write_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_CFG,
value);
} else {
- value = phy_read_mmd(phydev, DP83811_DEVADDR,
- MII_DP83811_WOL_CFG);
- value &= ~DP83811_WOL_EN;
- phy_write_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_CFG,
- value);
+ phy_clear_bits_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_CFG,
+ DP83811_WOL_EN);
}
return 0;
@@ -328,14 +325,10 @@ static int dp83811_suspend(struct phy_device *phydev)
static int dp83811_resume(struct phy_device *phydev)
{
- int value;
-
genphy_resume(phydev);
- value = phy_read_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_CFG);
-
- phy_write_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_CFG, value |
- DP83811_WOL_CLR_INDICATION);
+ phy_set_bits_mmd(phydev, DP83811_DEVADDR, MII_DP83811_WOL_CFG,
+ DP83811_WOL_CLR_INDICATION);
return 0;
}
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index be2cfdfd8..296a537cd 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -58,24 +58,6 @@ struct mv3310_priv {
char *hwmon_name;
};
-static int mv3310_modify(struct phy_device *phydev, int devad, u16 reg,
- u16 mask, u16 bits)
-{
- int old, val, ret;
-
- old = phy_read_mmd(phydev, devad, reg);
- if (old < 0)
- return old;
-
- val = (old & ~mask) | (bits & mask);
- if (val == old)
- return 0;
-
- ret = phy_write_mmd(phydev, devad, reg, val);
-
- return ret < 0 ? ret : 1;
-}
-
#ifdef CONFIG_HWMON
static umode_t mv3310_hwmon_is_visible(const void *data,
enum hwmon_sensor_types type,
@@ -159,8 +141,8 @@ static int mv3310_hwmon_config(struct phy_device *phydev, bool enable)
return ret;
val = enable ? MV_V2_TEMP_CTRL_SAMPLE : MV_V2_TEMP_CTRL_DISABLE;
- ret = mv3310_modify(phydev, MDIO_MMD_VEND2, MV_V2_TEMP_CTRL,
- MV_V2_TEMP_CTRL_MASK, val);
+ ret = phy_modify_mmd(phydev, MDIO_MMD_VEND2, MV_V2_TEMP_CTRL,
+ MV_V2_TEMP_CTRL_MASK, val);
return ret < 0 ? ret : 0;
}
@@ -363,18 +345,18 @@ static int mv3310_config_aneg(struct phy_device *phydev)
linkmode_and(phydev->advertising, phydev->advertising,
phydev->supported);
- ret = mv3310_modify(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE,
- ADVERTISE_ALL | ADVERTISE_100BASE4 |
- ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM,
- linkmode_adv_to_mii_adv_t(phydev->advertising));
+ ret = phy_modify_mmd(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE,
+ ADVERTISE_ALL | ADVERTISE_100BASE4 |
+ ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM,
+ linkmode_adv_to_mii_adv_t(phydev->advertising));
if (ret < 0)
return ret;
if (ret > 0)
changed = true;
reg = linkmode_adv_to_mii_ctrl1000_t(phydev->advertising);
- ret = mv3310_modify(phydev, MDIO_MMD_AN, MV_AN_CTRL1000,
- ADVERTISE_1000FULL | ADVERTISE_1000HALF, reg);
+ ret = phy_modify_mmd(phydev, MDIO_MMD_AN, MV_AN_CTRL1000,
+ ADVERTISE_1000FULL | ADVERTISE_1000HALF, reg);
if (ret < 0)
return ret;
if (ret > 0)
@@ -387,8 +369,8 @@ static int mv3310_config_aneg(struct phy_device *phydev)
else
reg = 0;
- ret = mv3310_modify(phydev, MDIO_MMD_AN, MDIO_AN_10GBT_CTRL,
- MDIO_AN_10GBT_CTRL_ADV10G, reg);
+ ret = phy_modify_mmd(phydev, MDIO_MMD_AN, MDIO_AN_10GBT_CTRL,
+ MDIO_AN_10GBT_CTRL_ADV10G, reg);
if (ret < 0)
return ret;
if (ret > 0)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index b874c4858..c92d0fb7e 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -75,15 +75,9 @@ EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
*/
int genphy_c45_an_disable_aneg(struct phy_device *phydev)
{
- int val;
-
- val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1);
- if (val < 0)
- return val;
-
- val &= ~(MDIO_AN_CTRL1_ENABLE | MDIO_AN_CTRL1_RESTART);
- return phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1, val);
+ return phy_clear_bits_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1,
+ MDIO_AN_CTRL1_ENABLE | MDIO_AN_CTRL1_RESTART);
}
EXPORT_SYMBOL_GPL(genphy_c45_an_disable_aneg);
@@ -97,15 +91,8 @@ EXPORT_SYMBOL_GPL(genphy_c45_an_disable_aneg);
*/
int genphy_c45_restart_aneg(struct phy_device *phydev)
{
- int val;
-
- val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1);
- if (val < 0)
- return val;
-
- val |= MDIO_AN_CTRL1_ENABLE | MDIO_AN_CTRL1_RESTART;
-
- return phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1, val);
+ return phy_set_bits_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1,
+ MDIO_AN_CTRL1_ENABLE | MDIO_AN_CTRL1_RESTART);
}
EXPORT_SYMBOL_GPL(genphy_c45_restart_aneg);
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index d12aa512b..89ead29ce 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1060,17 +1060,12 @@ int phy_init_eee(struct phy_device *phydev, bool clk_stop_enable)
if (!phy_check_valid(phydev->speed, phydev->duplex, common))
goto eee_exit_err;
- if (clk_stop_enable) {
+ if (clk_stop_enable)
/* Configure the PHY to stop receiving xMII
* clock while it is signaling LPI.
*/
- int val = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_CTRL1);
- if (val < 0)
- return val;
-
- val |= MDIO_PCS_CTRL1_CLKSTOP_EN;
- phy_write_mmd(phydev, MDIO_MMD_PCS, MDIO_CTRL1, val);
- }
+ phy_set_bits_mmd(phydev, MDIO_MMD_PCS, MDIO_CTRL1,
+ MDIO_PCS_CTRL1_CLKSTOP_EN);
return 0; /* EEE supported */
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 2/2 net-next] net: phy: make use of new MMD accessors
From: Heiner Kallweit @ 2019-02-06 6:37 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, David Miller, Russell King,
netdev@vger.kernel.org, Nikita Yushchenko
In-Reply-To: <20190206021029.GB20672@lunn.ch>
On 06.02.2019 03:10, Andrew Lunn wrote:
> On Tue, Feb 05, 2019 at 10:13:07PM +0100, Heiner Kallweit wrote:
>> Make use of the new MMD accessors.
>>
>> Andrew Lunn <andrew@lunn.ch>
>
> This is missing the Signed-off-by: prefix.
>
Uups, I send a v2.
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>
> Andrew
>
Heiner
^ permalink raw reply
* [PATCH 1/2 v2 net-next] net: phy: provide full set of accessor functions to MMD registers
From: Heiner Kallweit @ 2019-02-06 6:36 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller, Russell King
Cc: netdev@vger.kernel.org, Nikita Yushchenko
In-Reply-To: <e0e26b49-8e77-98f5-01df-6b7c7938ea41@gmail.com>
From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
This adds full set of locked and unlocked accessor functions to read and
write PHY MMD registers and/or bitfields.
Set of functions exactly matches what is already available for PHY
legacy registers.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-core.c | 116 ++++++++++++++++++++++++++++----
include/linux/phy.h | 134 ++++++++++++++++++++++++++++++-------
2 files changed, 214 insertions(+), 36 deletions(-)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index 909b3344b..7d6aad287 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -414,15 +414,15 @@ static void mmd_phy_indirect(struct mii_bus *bus, int phy_addr, int devad,
}
/**
- * phy_read_mmd - Convenience function for reading a register
+ * __phy_read_mmd - Convenience function for reading a register
* from an MMD on a given PHY.
* @phydev: The phy_device struct
* @devad: The MMD to read from (0..31)
* @regnum: The register on the MMD to read (0..65535)
*
- * Same rules as for phy_read();
+ * Same rules as for __phy_read();
*/
-int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
+int __phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
{
int val;
@@ -434,33 +434,52 @@ int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
} else if (phydev->is_c45) {
u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff);
- val = mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, addr);
+ val = __mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, addr);
} else {
struct mii_bus *bus = phydev->mdio.bus;
int phy_addr = phydev->mdio.addr;
- mutex_lock(&bus->mdio_lock);
mmd_phy_indirect(bus, phy_addr, devad, regnum);
/* Read the content of the MMD's selected register */
val = __mdiobus_read(bus, phy_addr, MII_MMD_DATA);
- mutex_unlock(&bus->mdio_lock);
}
return val;
}
+EXPORT_SYMBOL(__phy_read_mmd);
+
+/**
+ * phy_read_mmd - Convenience function for reading a register
+ * from an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ *
+ * Same rules as for phy_read();
+ */
+int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
+{
+ int ret;
+
+ mutex_lock(&phydev->mdio.bus->mdio_lock);
+ ret = __phy_read_mmd(phydev, devad, regnum);
+ mutex_unlock(&phydev->mdio.bus->mdio_lock);
+
+ return ret;
+}
EXPORT_SYMBOL(phy_read_mmd);
/**
- * phy_write_mmd - Convenience function for writing a register
+ * __phy_write_mmd - Convenience function for writing a register
* on an MMD on a given PHY.
* @phydev: The phy_device struct
* @devad: The MMD to read from
* @regnum: The register on the MMD to read
* @val: value to write to @regnum
*
- * Same rules as for phy_write();
+ * Same rules as for __phy_write();
*/
-int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
+int __phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
{
int ret;
@@ -472,23 +491,43 @@ int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
} else if (phydev->is_c45) {
u32 addr = MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff);
- ret = mdiobus_write(phydev->mdio.bus, phydev->mdio.addr,
- addr, val);
+ ret = __mdiobus_write(phydev->mdio.bus, phydev->mdio.addr,
+ addr, val);
} else {
struct mii_bus *bus = phydev->mdio.bus;
int phy_addr = phydev->mdio.addr;
- mutex_lock(&bus->mdio_lock);
mmd_phy_indirect(bus, phy_addr, devad, regnum);
/* Write the data into MMD's selected register */
__mdiobus_write(bus, phy_addr, MII_MMD_DATA, val);
- mutex_unlock(&bus->mdio_lock);
ret = 0;
}
return ret;
}
+EXPORT_SYMBOL(__phy_write_mmd);
+
+/**
+ * phy_write_mmd - Convenience function for writing a register
+ * on an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ * @val: value to write to @regnum
+ *
+ * Same rules as for phy_write();
+ */
+int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val)
+{
+ int ret;
+
+ mutex_lock(&phydev->mdio.bus->mdio_lock);
+ ret = __phy_write_mmd(phydev, devad, regnum, val);
+ mutex_unlock(&phydev->mdio.bus->mdio_lock);
+
+ return ret;
+}
EXPORT_SYMBOL(phy_write_mmd);
/**
@@ -538,6 +577,57 @@ int phy_modify(struct phy_device *phydev, u32 regnum, u16 mask, u16 set)
}
EXPORT_SYMBOL_GPL(phy_modify);
+/**
+ * __phy_modify_mmd - Convenience function for modifying a register on MMD
+ * @phydev: the phy_device struct
+ * @devad: the MMD containing register to modify
+ * @regnum: register number to modify
+ * @mask: bit mask of bits to clear
+ * @set: new value of bits set in mask to write to @regnum
+ *
+ * Unlocked helper function which allows a MMD register to be modified as
+ * new register value = (old register value & ~mask) | set
+ */
+int __phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
+ u16 mask, u16 set)
+{
+ int ret;
+
+ ret = __phy_read_mmd(phydev, devad, regnum);
+ if (ret < 0)
+ return ret;
+
+ ret = __phy_write_mmd(phydev, devad, regnum, (ret & ~mask) | set);
+
+ return ret < 0 ? ret : 0;
+}
+EXPORT_SYMBOL_GPL(__phy_modify_mmd);
+
+/**
+ * phy_modify_mmd - Convenience function for modifying a register on MMD
+ * @phydev: the phy_device struct
+ * @devad: the MMD containing register to modify
+ * @regnum: register number to modify
+ * @mask: bit mask of bits to clear
+ * @set: new value of bits set in mask to write to @regnum
+ *
+ * NOTE: MUST NOT be called from interrupt context,
+ * because the bus read/write functions may wait for an interrupt
+ * to conclude the operation.
+ */
+int phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
+ u16 mask, u16 set)
+{
+ int ret;
+
+ mutex_lock(&phydev->mdio.bus->mdio_lock);
+ ret = __phy_modify_mmd(phydev, devad, regnum, mask, set);
+ mutex_unlock(&phydev->mdio.bus->mdio_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_modify_mmd);
+
static int __phy_read_page(struct phy_device *phydev)
{
return phydev->drv->read_page(phydev);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 70f83d0d7..237dd0358 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -692,17 +692,6 @@ static inline bool phy_is_started(struct phy_device *phydev)
void phy_resolve_aneg_linkmode(struct phy_device *phydev);
-/**
- * phy_read_mmd - Convenience function for reading a register
- * from an MMD on a given PHY.
- * @phydev: The phy_device struct
- * @devad: The MMD to read from
- * @regnum: The register on the MMD to read
- *
- * Same rules as for phy_read();
- */
-int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum);
-
/**
* phy_read - Convenience function for reading a given PHY register
* @phydev: the phy_device struct
@@ -758,9 +747,60 @@ static inline int __phy_write(struct phy_device *phydev, u32 regnum, u16 val)
val);
}
+/**
+ * phy_read_mmd - Convenience function for reading a register
+ * from an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ *
+ * Same rules as for phy_read();
+ */
+int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum);
+
+/**
+ * __phy_read_mmd - Convenience function for reading a register
+ * from an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ *
+ * Same rules as for __phy_read();
+ */
+int __phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum);
+
+/**
+ * phy_write_mmd - Convenience function for writing a register
+ * on an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to write to
+ * @regnum: The register on the MMD to read
+ * @val: value to write to @regnum
+ *
+ * Same rules as for phy_write();
+ */
+int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val);
+
+/**
+ * __phy_write_mmd - Convenience function for writing a register
+ * on an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to write to
+ * @regnum: The register on the MMD to read
+ * @val: value to write to @regnum
+ *
+ * Same rules as for __phy_write();
+ */
+int __phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val);
+
int __phy_modify(struct phy_device *phydev, u32 regnum, u16 mask, u16 set);
int phy_modify(struct phy_device *phydev, u32 regnum, u16 mask, u16 set);
+int __phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
+ u16 mask, u16 set);
+int phy_modify_mmd(struct phy_device *phydev, int devad, u32 regnum,
+ u16 mask, u16 set);
+
/**
* __phy_set_bits - Convenience function for setting bits in a PHY register
* @phydev: the phy_device struct
@@ -810,6 +850,66 @@ static inline int phy_clear_bits(struct phy_device *phydev, u32 regnum, u16 val)
return phy_modify(phydev, regnum, val, 0);
}
+/**
+ * __phy_set_bits_mmd - Convenience function for setting bits in a register
+ * on MMD
+ * @phydev: the phy_device struct
+ * @devad: the MMD containing register to modify
+ * @regnum: register number to modify
+ * @val: bits to set
+ *
+ * The caller must have taken the MDIO bus lock.
+ */
+static inline int __phy_set_bits_mmd(struct phy_device *phydev, int devad,
+ u32 regnum, u16 val)
+{
+ return __phy_modify_mmd(phydev, devad, regnum, 0, val);
+}
+
+/**
+ * __phy_clear_bits_mmd - Convenience function for clearing bits in a register
+ * on MMD
+ * @phydev: the phy_device struct
+ * @devad: the MMD containing register to modify
+ * @regnum: register number to modify
+ * @val: bits to clear
+ *
+ * The caller must have taken the MDIO bus lock.
+ */
+static inline int __phy_clear_bits_mmd(struct phy_device *phydev, int devad,
+ u32 regnum, u16 val)
+{
+ return __phy_modify_mmd(phydev, devad, regnum, val, 0);
+}
+
+/**
+ * phy_set_bits_mmd - Convenience function for setting bits in a register
+ * on MMD
+ * @phydev: the phy_device struct
+ * @devad: the MMD containing register to modify
+ * @regnum: register number to modify
+ * @val: bits to set
+ */
+static inline int phy_set_bits_mmd(struct phy_device *phydev, int devad,
+ u32 regnum, u16 val)
+{
+ return phy_modify_mmd(phydev, devad, regnum, 0, val);
+}
+
+/**
+ * phy_clear_bits_mmd - Convenience function for clearing bits in a register
+ * on MMD
+ * @phydev: the phy_device struct
+ * @devad: the MMD containing register to modify
+ * @regnum: register number to modify
+ * @val: bits to clear
+ */
+static inline int phy_clear_bits_mmd(struct phy_device *phydev, int devad,
+ u32 regnum, u16 val)
+{
+ return phy_modify_mmd(phydev, devad, regnum, val, 0);
+}
+
/**
* phy_interrupt_is_valid - Convenience function for testing a given PHY irq
* @phydev: the phy_device struct
@@ -886,18 +986,6 @@ static inline bool phy_is_pseudo_fixed_link(struct phy_device *phydev)
return phydev->is_pseudo_fixed_link;
}
-/**
- * phy_write_mmd - Convenience function for writing a register
- * on an MMD on a given PHY.
- * @phydev: The phy_device struct
- * @devad: The MMD to read from
- * @regnum: The register on the MMD to read
- * @val: value to write to @regnum
- *
- * Same rules as for phy_write();
- */
-int phy_write_mmd(struct phy_device *phydev, int devad, u32 regnum, u16 val);
-
int phy_save_page(struct phy_device *phydev);
int phy_select_page(struct phy_device *phydev, int page);
int phy_restore_page(struct phy_device *phydev, int oldpage, int ret);
--
2.20.1
^ permalink raw reply related
* [PATCH 0/2 v2 net-next] net: phy: add and use further MMD accessors
From: Heiner Kallweit @ 2019-02-06 6:35 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller, Russell King
Cc: netdev@vger.kernel.org, Nikita Yushchenko
Add MMD accessors for modifying MMD registers and clearing / setting
bits in MMD registers. Use these accessors in PHY drivers and phylib.
v2:
- fix SoB in patch 2
Nikita Yushchenko (1):
net: phy: provide full set of accessor functions to MMD registers
Heiner Kallweit (1):
net: phy: make use of new MMD accessors
drivers/net/phy/dp83867.c | 47 +++++-------
drivers/net/phy/dp83tc811.c | 15 ++--
drivers/net/phy/marvell10g.c | 38 +++-------
drivers/net/phy/phy-c45.c | 21 ++----
drivers/net/phy/phy-core.c | 116 ++++++++++++++++++++++++++----
drivers/net/phy/phy.c | 11 +--
include/linux/phy.h | 134 +++++++++++++++++++++++++++++------
7 files changed, 252 insertions(+), 130 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH bpf-next] tools: bpftool: doc, fix incorrect text
From: Y Song @ 2019-02-06 6:27 UTC (permalink / raw)
To: Prashant Bhole; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev
In-Reply-To: <20190206014723.1424-1-bhole_prashant_q7@lab.ntt.co.jp>
On Tue, Feb 5, 2019 at 6:26 PM Prashant Bhole
<bhole_prashant_q7@lab.ntt.co.jp> wrote:
>
> Documentation about cgroup, feature, prog uses wrong header
> 'MAP COMMANDS' while listing commands. This patch corrects the header
> in respective doc files.
>
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Acked-by: Yonghong Song <yhs@fb.com>
> ---
> tools/bpf/bpftool/Documentation/bpftool-cgroup.rst | 4 ++--
> tools/bpf/bpftool/Documentation/bpftool-feature.rst | 4 ++--
> tools/bpf/bpftool/Documentation/bpftool-prog.rst | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
> index d43fce568ef7..9bb9ace54ba8 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
> @@ -17,8 +17,8 @@ SYNOPSIS
> *COMMANDS* :=
> { **show** | **list** | **tree** | **attach** | **detach** | **help** }
>
> -MAP COMMANDS
> -=============
> +CGROUP COMMANDS
> +===============
>
> | **bpftool** **cgroup { show | list }** *CGROUP*
> | **bpftool** **cgroup tree** [*CGROUP_ROOT*]
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-feature.rst b/tools/bpf/bpftool/Documentation/bpftool-feature.rst
> index 8d489a26e3c9..82de03dd8f52 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-feature.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-feature.rst
> @@ -16,8 +16,8 @@ SYNOPSIS
>
> *COMMANDS* := { **probe** | **help** }
>
> -MAP COMMANDS
> -=============
> +FEATURE COMMANDS
> +================
>
> | **bpftool** **feature probe** [*COMPONENT*] [**macros** [**prefix** *PREFIX*]]
> | **bpftool** **feature help**
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-prog.rst b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> index 13b56102f528..7e59495cb028 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> @@ -18,7 +18,7 @@ SYNOPSIS
> { **show** | **list** | **dump xlated** | **dump jited** | **pin** | **load**
> | **loadall** | **help** }
>
> -MAP COMMANDS
> +PROG COMMANDS
> =============
>
> | **bpftool** **prog { show | list }** [*PROG*]
> --
> 2.20.1
>
>
^ permalink raw reply
* Re: [PATCH bpf-next] tools: bpftool: doc, add text about feature-subcommand
From: Y Song @ 2019-02-06 6:26 UTC (permalink / raw)
To: Prashant Bhole; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev
In-Reply-To: <20190206014556.3548-1-bhole_prashant_q7@lab.ntt.co.jp>
On Tue, Feb 5, 2019 at 6:25 PM Prashant Bhole
<bhole_prashant_q7@lab.ntt.co.jp> wrote:
>
> This patch adds missing information about feature-subcommand in
> bpftool.rst
>
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Acked-by: Yonghong Song <yhs@fb.com>
> ---
> tools/bpf/bpftool/Documentation/bpftool.rst | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/bpf/bpftool/Documentation/bpftool.rst b/tools/bpf/bpftool/Documentation/bpftool.rst
> index 27153bb816ac..0685d5ada3ce 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool.rst
> @@ -16,7 +16,7 @@ SYNOPSIS
>
> **bpftool** **version**
>
> - *OBJECT* := { **map** | **program** | **cgroup** | **perf** | **net** }
> + *OBJECT* := { **map** | **program** | **cgroup** | **perf** | **net** | **feature** }
>
> *OPTIONS* := { { **-V** | **--version** } | { **-h** | **--help** }
> | { **-j** | **--json** } [{ **-p** | **--pretty** }] }
> @@ -34,6 +34,8 @@ SYNOPSIS
>
> *NET-COMMANDS* := { **show** | **list** | **help** }
>
> + *FEATURE-COMMANDS* := { **probe** | **help** }
> +
> DESCRIPTION
> ===========
> *bpftool* allows for inspection and simple modification of BPF objects
> --
> 2.20.1
>
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next 2/2] btf: expose API to work with raw btf data
From: Alexei Starovoitov @ 2019-02-06 6:24 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Song Liu, Yonghong Song, Alexei Starovoitov,
Martin Lau, netdev, Daniel Borkmann
In-Reply-To: <CAEf4BzZ+adR4_sM23p7b6NLPjfQX2Vavb6vg7gZd_1PsBbR-yQ@mail.gmail.com>
On Tue, Feb 05, 2019 at 09:46:14PM -0800, Andrii Nakryiko wrote:
> On Tue, Feb 5, 2019 at 7:07 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Tue, Feb 05, 2019 at 04:29:49PM -0800, Andrii Nakryiko wrote:
> > > This patch exposes two new APIs btf__get_raw_data_size() and
> > > btf__get_raw_data() that allows to get a copy of raw BTF data out of
> > > struct btf. This is useful for external programs that need to manipulate
> > > raw data, e.g., pahole using btf__dedup() to deduplicate BTF type info
> > > and then writing it back to file.
> > >
> > > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > > Acked-by: Song Liu <songliubraving@fb.com>
> > > ---
> > > tools/lib/bpf/btf.c | 10 ++++++++++
> > > tools/lib/bpf/btf.h | 2 ++
> > > tools/lib/bpf/libbpf.map | 2 ++
> > > 3 files changed, 14 insertions(+)
> > >
> > > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> > > index 1c2ba7182400..34bfb3641aac 100644
> > > --- a/tools/lib/bpf/btf.c
> > > +++ b/tools/lib/bpf/btf.c
> > > @@ -437,6 +437,16 @@ int btf__fd(const struct btf *btf)
> > > return btf->fd;
> > > }
> > >
> > > +__u32 btf__get_raw_data_size(const struct btf *btf)
> > > +{
> > > + return btf->data_size;
> > > +}
> > > +
> > > +void btf__get_raw_data(const struct btf *btf, char *data)
> > > +{
> > > + memcpy(data, btf->data, btf->data_size);
> > > +}
> >
> > I cannot think of any other way to use this api,
> > but to call btf__get_raw_data_size() first,
> > then malloc that much memory and then call btf__get_raw_data()
> > to store btf into it.
> >
> > If so, may be api should be single call that allocates, copies,
> > and returns pointer to new mem and its size?
> > Probably less error prone?
> >
>
> I don't have strong preference, but providing pointer to allocated memory
> seems more flexible and allows more clever/optimal use of memory from caller
> side. E.g., instead of doing two mallocs, you can imagine doing something
> like:
>
> int max_size = max(btf__get_raw_data_size(btf),
> btf_ext__get_raw_data_size(btf_ext));
> char *m = malloc(max_size);
> btf__get_raw_data(btf, m);
> dump_btf_section_to_file(m, some_file);
> btf_ext__get_raw_data(btf_ext, m);
> dump_btf_ext_section_to_file(m, some_file);
> free(m);
>
> Also, pointer to memory could be mmap()'ed file, for instance. In general,
> for a library it might be a good thing to not be prescriptive as to how one
> gets that piece of memory.
Plausible, but I'd like to see pahole patches to be convinced ;)
^ permalink raw reply
* [PATCH v4 2/2] netdev/phy: add MDIO bus multiplexer driven by a regmap
From: Pankaj Bansal @ 2019-02-06 6:20 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev@vger.kernel.org, Pankaj Bansal
In-Reply-To: <20190206114523.8954-1-pankaj.bansal@nxp.com>
Add support for an MDIO bus multiplexer controlled by a regmap
device, like an FPGA.
Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA
attached to the i2c bus.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---
Notes:
V4:
- Use IS_ENABLED macro in mdio-mux.h
V3:
- make the return type of uninit function to void
- reorder the Make file change to be alphabetically sorted
- fix the compilation error when mdio-mux-regmap is built as module
by adding CONFIG_MDIO_BUS_MUX_REGMAP_MODULE macro in mdio-mux.h
V2:
- Added Kconfig entry for regmap based mdio mux
- restrict the comment lines to 80 chars
- use kerneldoc formatting for this function documentation.
drivers/net/phy/Kconfig | 14 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-mux-regmap.c | 169 ++++++++++++++++++++++++++++
include/linux/mdio-mux.h | 33 ++++++
4 files changed, 217 insertions(+)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 3d187cd50eb0..93ef2505caba 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -87,6 +87,20 @@ config MDIO_BUS_MUX_MMIOREG
Currently, only 8/16/32 bits registers are supported.
+config MDIO_BUS_MUX_REGMAP
+ tristate "regmap device controlled MDIO bus multiplexers"
+ depends on OF_MDIO && REGMAP
+ select MDIO_BUS_MUX
+ help
+ This module provides a driver for MDIO bus multiplexers that
+ are controlled via a regmap device, like an FPGA connected to i2c bus
+ or spi bus or memory mapped FPGA.
+ The multiplexer connects one of several child MDIO busses to a
+ parent bus. Child bus selection is under the control of one of
+ the FPGA's registers.
+
+ Currently, only 32 bits registers are supported.
+
config MDIO_CAVIUM
tristate
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 5805c0b7d60e..99737128de8a 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_MDIO_BUS_MUX) += mdio-mux.o
obj-$(CONFIG_MDIO_BUS_MUX_BCM_IPROC) += mdio-mux-bcm-iproc.o
obj-$(CONFIG_MDIO_BUS_MUX_GPIO) += mdio-mux-gpio.o
obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
+obj-$(CONFIG_MDIO_BUS_MUX_REGMAP) += mdio-mux-regmap.o
obj-$(CONFIG_MDIO_CAVIUM) += mdio-cavium.o
obj-$(CONFIG_MDIO_GPIO) += mdio-gpio.o
obj-$(CONFIG_MDIO_HISI_FEMAC) += mdio-hisi-femac.o
diff --git a/drivers/net/phy/mdio-mux-regmap.c b/drivers/net/phy/mdio-mux-regmap.c
new file mode 100644
index 000000000000..bbec43b30f3c
--- /dev/null
+++ b/drivers/net/phy/mdio-mux-regmap.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/* Simple regmap based MDIO MUX driver
+ *
+ * Copyright 2018-2019 NXP
+ *
+ * Based on mdio-mux-mmioreg.c by Timur Tabi
+ *
+ * Author:
+ * Pankaj Bansal <pankaj.bansal@nxp.com>
+ */
+
+#include <linux/platform_device.h>
+#include <linux/device.h>
+#include <linux/of_mdio.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+#include <linux/mdio-mux.h>
+#include <linux/regmap.h>
+
+struct mdio_mux_regmap_state {
+ void *mux_handle;
+ struct device *dev;
+ struct regmap *regmap;
+ u32 mux_reg;
+ u32 mask;
+};
+
+/**
+ * mdio_mux_regmap_switch_fn - This function is called by the mdio-mux layer
+ * when it thinks the mdio bus multiplexer needs
+ * to switch.
+ * @current_child: current value of the mux register (masked via s->mask).
+ * @desired_child: value of the 'reg' property of the target child MDIO node.
+ * @data: Private data used by this switch_fn passed to mdio_mux_init function
+ * via mdio_mux_init(.., .., .., .., data, ..).
+ *
+ * The first time this function is called, current_child == -1.
+ * If current_child == desired_child, then the mux is already set to the
+ * correct bus.
+ */
+static int mdio_mux_regmap_switch_fn(int current_child, int desired_child,
+ void *data)
+{
+ struct mdio_mux_regmap_state *s = data;
+ bool change;
+ int ret;
+
+ ret = regmap_update_bits_check(s->regmap,
+ s->mux_reg,
+ s->mask,
+ desired_child,
+ &change);
+
+ if (ret)
+ return ret;
+ if (change)
+ dev_dbg(s->dev, "%s %d -> %d\n", __func__, current_child,
+ desired_child);
+ return ret;
+}
+
+/**
+ * mdio_mux_regmap_init - control MDIO bus muxing using regmap constructs.
+ * @dev: device with which regmap construct is associated.
+ * @mux_node: mdio bus mux node that contains parent mdio bus phandle.
+ * This node also contains sub nodes, where each subnode denotes
+ * a child mdio bus. All the child mdio buses are muxed, i.e. at a
+ * time only one of the child mdio buses can be used.
+ * @data: to store the address of data allocated by this function
+ */
+int mdio_mux_regmap_init(struct device *dev,
+ struct device_node *mux_node,
+ void **data)
+{
+ struct device_node *child;
+ struct mdio_mux_regmap_state *s;
+ int ret;
+ u32 val;
+
+ dev_dbg(dev, "probing node %pOF\n", mux_node);
+
+ s = devm_kzalloc(dev, sizeof(*s), GFP_KERNEL);
+ if (!s)
+ return -ENOMEM;
+
+ s->regmap = dev_get_regmap(dev, NULL);
+ if (IS_ERR(s->regmap)) {
+ dev_err(dev, "Failed to get parent regmap\n");
+ return PTR_ERR(s->regmap);
+ }
+
+ ret = of_property_read_u32(mux_node, "reg", &s->mux_reg);
+ if (ret) {
+ dev_err(dev, "missing or invalid reg property\n");
+ return -ENODEV;
+ }
+
+ /* Test Register read write */
+ ret = regmap_read(s->regmap, s->mux_reg, &val);
+ if (ret) {
+ dev_err(dev, "error while reading reg\n");
+ return ret;
+ }
+
+ ret = regmap_write(s->regmap, s->mux_reg, val);
+ if (ret) {
+ dev_err(dev, "error while writing reg\n");
+ return ret;
+ }
+
+ ret = of_property_read_u32(mux_node, "mux-mask", &s->mask);
+ if (ret) {
+ dev_err(dev, "missing or invalid mux-mask property\n");
+ return -ENODEV;
+ }
+
+ /* Verify that the 'reg' property of each child MDIO bus does not
+ * set any bits outside of the 'mask'.
+ */
+ for_each_available_child_of_node(mux_node, child) {
+ ret = of_property_read_u32(child, "reg", &val);
+ if (ret) {
+ dev_err(dev, "%pOF is missing a 'reg' property\n",
+ child);
+ of_node_put(child);
+ return -ENODEV;
+ }
+ if (val & ~s->mask) {
+ dev_err(dev,
+ "%pOF has a 'reg' value with unmasked bits\n",
+ child);
+ of_node_put(child);
+ return -ENODEV;
+ }
+ }
+
+ ret = mdio_mux_init(dev, mux_node, mdio_mux_regmap_switch_fn,
+ &s->mux_handle, s, NULL);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "failed to register mdio-mux bus %pOF\n",
+ mux_node);
+ return ret;
+ }
+
+ *data = s;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mdio_mux_regmap_init);
+
+/**
+ * mdio_mux_regmap_uninit - relinquish the control of MDIO bus muxing using
+ * regmap constructs.
+ * @data: address of data allocated by mdio_mux_regmap_init
+ */
+void mdio_mux_regmap_uninit(void *data)
+{
+ struct mdio_mux_regmap_state *s = data;
+
+ mdio_mux_uninit(s->mux_handle);
+}
+EXPORT_SYMBOL_GPL(mdio_mux_regmap_uninit);
+
+MODULE_AUTHOR("Pankaj Bansal <pankaj.bansal@nxp.com>");
+MODULE_DESCRIPTION("regmap based MDIO MUX driver");
+MODULE_LICENSE("GPL");
+
diff --git a/include/linux/mdio-mux.h b/include/linux/mdio-mux.h
index a5d58f221939..bc358435b4b3 100644
--- a/include/linux/mdio-mux.h
+++ b/include/linux/mdio-mux.h
@@ -29,4 +29,37 @@ int mdio_mux_init(struct device *dev,
void mdio_mux_uninit(void *mux_handle);
+#if IS_ENABLED(CONFIG_MDIO_BUS_MUX_REGMAP)
+/**
+ * mdio_mux_regmap_init - control MDIO bus muxing using regmap constructs.
+ * @dev: device with which regmap construct is associated.
+ * @mux_node: mdio bus mux node that contains parent mdio bus phandle.
+ * This node also contains sub nodes, where each subnode denotes
+ * a child mdio bus. All the child mdio buses are muxed, i.e. at a
+ * time only one of the child mdio buses can be used.
+ * @data: to store the address of data allocated by this function
+ */
+int mdio_mux_regmap_init(struct device *dev,
+ struct device_node *mux_node,
+ void **data);
+
+/**
+ * mdio_mux_regmap_uninit - relinquish the control of MDIO bus muxing using
+ * regmap constructs.
+ * @data: address of data allocated by mdio_mux_regmap_init
+ */
+void mdio_mux_regmap_uninit(void *data);
+#else /* IS_ENABLED(CONFIG_MDIO_BUS_MUX_REGMAP) */
+static inline int mdio_mux_regmap_init(struct device *dev,
+ struct device_node *mux_node,
+ void **data)
+{
+ return -ENODEV;
+}
+
+static inline void mdio_mux_regmap_uninit(void *data)
+{
+}
+#endif /* IS_ENABLED(CONFIG_MDIO_BUS_MUX_REGMAP) */
+
#endif /* __LINUX_MDIO_MUX_H */
--
2.17.1
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: net: add MDIO bus multiplexer driven by a regmap device
From: Pankaj Bansal @ 2019-02-06 6:20 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev@vger.kernel.org, Pankaj Bansal
In-Reply-To: <20190206114523.8954-1-pankaj.bansal@nxp.com>
Add support for an MDIO bus multiplexer controlled by a regmap
device, like an FPGA.
Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA
attached to the i2c bus.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---
Notes:
V4:
- No change
V3:
- No change
V2:
- New file describing the device tree bindings for regmap controlled devices'
mdio mux
.../bindings/net/mdio-mux-regmap.txt | 167 +++++++++++++++++
1 file changed, 167 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt b/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
new file mode 100644
index 000000000000..8968f317965f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
@@ -0,0 +1,167 @@
+Properties for an MDIO bus multiplexer controlled by a regmap
+
+This is a special case of a MDIO bus multiplexer. A regmap device,
+like an FPGA, is used to control which child bus is connected. The mdio-mux
+node must be a child of the device that is controlled by a regmap.
+The driver currently only supports devices with upto 32-bit registers.
+
+Required properties in addition to the generic multiplexer properties:
+
+- reg : integer, contains the offset of the register that controls the bus
+ multiplexer. it can be 32 bit number.
+
+- mux-mask : integer, contains an 32 bit mask that specifies which
+ bits in the register control the actual bus multiplexer. The
+ 'reg' property of each child mdio-mux node must be constrained by
+ this mask.
+
+Example 1:
+
+The FPGA node defines a i2c connected FPGA with a register space of 0x30 bytes.
+For the "EMI2" MDIO bus, register 0x54 (BRDCFG4) controls the mux on that bus.
+A bitmask of 0x07 means that bits 0, 1 and 2 (bit 0 is lsb) are the bits on
+BRDCFG4 that control the actual mux.
+
+i2c@2000000 {
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2000000 0x0 0x10000>;
+ interrupts = <0 34 0x4>; // Level high type
+ clock-names = "i2c";
+ clocks = <&clockgen 4 7>;
+ fsl-scl-gpio = <&gpio2 15 0>;
+ status = "okay";
+
+ /* The FPGA node */
+ fpga@66 {
+ compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
+ reg = <0x66>; // fpga device address on i2c bus
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-mux-2@54 {
+ mdio-parent-bus = <&emdio2>; /* MDIO bus */
+ reg = <0x54>; /* BRDCFG4 */
+ mux-mask = <0x07>; /* EMI2_MDIO */
+ #address-cells=<1>;
+ #size-cells = <0>;
+
+ mdio@0 { // Slot 1
+ reg = <0x00>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@@1 {
+ reg = <1>;
+ compatible = "ethernet-phy-id0210.7441";
+ };
+
+ ethernet-phy@@0 {
+ reg = <0>;
+ compatible = "ethernet-phy-id0210.7441";
+ };
+ };
+
+ mdio@1 { // Slot 2
+ reg = <0x01>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ };
+
+ mdio@2 { // Slot 3
+ reg = <0x02>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ };
+ };
+ };
+};
+
+/* The parent MDIO bus. */
+emdio2: mdio@0x8B97000 {
+ compatible = "fsl,fman-memac-mdio";
+ reg = <0x0 0x8B97000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ little-endian;
+};
+
+Example 2:
+
+The FPGA node defines a memory mapped FPGA with a register space of 0x100 bytes.
+For the "EMI1" MDIO bus, register 0x54 (BRDCFG4) controls the mux on that bus.
+A bitmask of 0xe0 means that bits 5, 6 and 7 (bit 0 is lsb) are the bits on
+BRDCFG4 that control the actual mux.
+
+ifc: ifc@1530000 {
+ compatible = "fsl,ifc", "simple-bus";
+ reg = <0x0 0x1530000 0x0 0x10000>;
+ interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ /* NOR, NAND Flashes and FPGA on board */
+ ranges = <0x0 0x0 0x0 0x60000000 0x08000000
+ 0x2 0x0 0x0 0x7e800000 0x00010000
+ 0x3 0x0 0x0 0x7fb00000 0x00000100>;
+ status = "okay";
+
+ /* The FPGA node */
+ fpga: board-control@3,0 {
+ compatible = "fsl,ls1021aqds-fpga", "fsl,fpga-qixis";
+ reg = <0x3 0x0 0x0000100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-mux-1@54 {
+ mdio-parent-bus = <&emdio1>; /* MDIO bus */
+ reg = <0x54>; /* BRDCFG4 */
+ mux-mask = <0xe0>; /* EMI1_MDIO */
+ #address-cells=<1>;
+ #size-cells = <0>;
+
+ mdio@0 { // Onboard PHYs rgmii_phy1
+ reg = <0x00>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@@1 {
+ reg = <1>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ };
+ };
+
+ mdio@20 { // Onboard PHYs rgmii_phy2
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethernet-phy@2 {
+ reg = <0x2>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ };
+ };
+
+ mdio@40 { // Onboard PHYs rgmii_phy3
+ reg = <0x40>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethernet-phy@3 {
+ reg = <0x3>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ };
+ };
+ };
+ };
+};
+
+/* The parent MDIO bus. */
+emdio1: mdio@2d24000 {
+ compatible = "gianfar";
+ device_type = "mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2d24000 0x0 0x4000>,
+ <0x0 0x2d10030 0x0 0x4>;
+};
--
2.17.1
^ permalink raw reply related
* [PATCH v4 0/2] add MDIO bus multiplexer driven by a regmap device
From: Pankaj Bansal @ 2019-02-06 6:20 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli
Cc: netdev@vger.kernel.org, Pankaj Bansal, Varun Sethi
Add support for an MDIO bus multiplexer controlled by a regmap device, like an FPGA.
These apis is an extension of the existing driver drivers/net/phy/mdio-mux-mmioreg.c.
The problem with mmioreg driver is that it can operate only on memory mapped devices.
but if we have a device that controls mdio muxing and that device is controlled using i2c or spi, then it will not work.
Therefore, added apis that can be used by regmap device to control mdio mux.
Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA attached to the i2c bus.
This is my second attempt at this.
In my previous approach i wrote a separate driver for regmap apis.
But then i realized that it is not meant to control a specific device.
It is meant to control some registers of parent device.
Therefore, IMO this should not be a Platform driver and there should not be any "compatible" property to which this driver is associated.
The previous approach patches and discussion can be accessed here:
https://www.mail-archive.com/netdev@vger.kernel.org/msg252744.html
Cc: Varun Sethi <V.Sethi@nxp.com>
---
Notes:
V3:
- https://www.mail-archive.com/netdev@vger.kernel.org/msg282380.html
V2:
- https://www.mail-archive.com/netdev@vger.kernel.org/msg282176.html
V1:
- https://www.spinics.net/lists/netdev/msg548027.html
Pankaj Bansal (2):
dt-bindings: net: add MDIO bus multiplexer driven by a regmap device
netdev/phy: add MDIO bus multiplexer driven by a regmap
.../bindings/net/mdio-mux-regmap.txt | 167 +++++++++++++++++
drivers/net/phy/Kconfig | 14 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-mux-regmap.c | 169 ++++++++++++++++++
include/linux/mdio-mux.h | 33 ++++
5 files changed, 384 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
create mode 100644 drivers/net/phy/mdio-mux-regmap.c
--
2.17.1
^ permalink raw reply
* Re: [PATCH bpf-next] tools/bpf: silence a libbpf unnecessary warning
From: Alexei Starovoitov @ 2019-02-06 6:09 UTC (permalink / raw)
To: Yonghong Song
Cc: Andrii Nakryiko, netdev, Alexei Starovoitov, Daniel Borkmann,
kernel-team
In-Reply-To: <20190206053830.4071175-1-yhs@fb.com>
On Tue, Feb 05, 2019 at 09:38:30PM -0800, Yonghong Song wrote:
> Commit 96408c43447a ("tools/bpf: implement libbpf
> btf__get_map_kv_tids() API function") refactored
> function bpf_map_find_btf_info() and moved bulk of
> implementation into btf.c as btf__get_map_kv_tids().
> This change introduced a bug such that test_btf will
> print out the following warning although the test passed:
> BTF libbpf test[2] (test_btf_nokv.o): libbpf: map:btf_map
> container_name:____btf_map_btf_map cannot be found
> in BTF. Missing BPF_ANNOTATE_KV_PAIR?
>
> Previously, the error message is guarded with pr_debug().
> Commit 96408c43447a changed it to pr_warning() and
> hence caused the warning.
>
> Restoring to pr_debug() for the message fixed the issue.
>
> Fixes: 96408c43447a ("tools/bpf: implement libbpf btf__get_map_kv_tids() API function")
> Signed-off-by: Yonghong Song <yhs@fb.com>
Applied. It fixed the issue I was seeing. Thanks!
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] tools/bpf: add log_level to bpf_load_program_attr
From: Yonghong Song @ 2019-02-06 5:51 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: netdev@vger.kernel.org, Alexei Starovoitov, Daniel Borkmann,
Kernel Team
In-Reply-To: <20190206022640.lnhpp6ebxmjvizo6@ast-mbp>
On 2/5/19 6:26 PM, Alexei Starovoitov wrote:
> On Tue, Feb 05, 2019 at 11:48:23AM -0800, Yonghong Song wrote:
>> The kernel verifier has three levels of logs:
>> 0: no logs
>> 1: logs mostly useful
>> > 1: verbose
>>
>> Current libbpf API functions bpf_load_program_xattr() and
>> bpf_load_program() cannot specify log_level.
>> The bcc, however, provides an interface for user to
>> specify log_level 2 for verbose output.
>>
>> This patch added log_level into structure
>> bpf_load_program_attr, so users, including bcc, can use
>> bpf_load_program_xattr() to change log_level.
>>
>> The bpf selftest test_sock.c is modified to enable log_level = 2.
>> If the "verbose" in test_sock.c is changed to true,
>> the test will output logs like below:
>> $ ./test_sock
>> func#0 @0
>> 0: R1=ctx(id=0,off=0,imm=0) R10=fp0,call_-1
>> 0: (bf) r6 = r1
>> 1: R1=ctx(id=0,off=0,imm=0) R6_w=ctx(id=0,off=0,imm=0) R10=fp0,call_-1
>> 1: (61) r7 = *(u32 *)(r6 +28)
>> invalid bpf_context access off=28 size=4
>>
>> Test case: bind4 load with invalid access: src_ip6 .. [PASS]
>> ...
>> Test case: bind6 allow all .. [PASS]
>> Summary: 16 PASSED, 0 FAILED
>>
>> Some test_sock tests are negative tests and verbose verifier
>> log will be printed out as shown in the above.
>>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>> ---
>> tools/lib/bpf/bpf.c | 4 +++-
>> tools/lib/bpf/bpf.h | 1 +
>> tools/testing/selftests/bpf/test_sock.c | 9 ++++++++-
>> 3 files changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>> index 3defad77dc7a..78aa8c2b1a5c 100644
>> --- a/tools/lib/bpf/bpf.c
>> +++ b/tools/lib/bpf/bpf.c
>> @@ -214,6 +214,7 @@ int bpf_load_program_xattr(const struct bpf_load_program_attr *load_attr,
>> {
>> void *finfo = NULL, *linfo = NULL;
>> union bpf_attr attr;
>> + __u32 log_level;
>> __u32 name_len;
>> int fd;
>>
>> @@ -292,7 +293,8 @@ int bpf_load_program_xattr(const struct bpf_load_program_attr *load_attr,
>> /* Try again with log */
>> attr.log_buf = ptr_to_u64(log_buf);
>> attr.log_size = log_buf_sz;
>> - attr.log_level = 1;
>> + log_level = load_attr->log_level;
>> + attr.log_level = (log_level >= 2) ? log_level : 1;
>> log_buf[0] = 0;
>> fd = sys_bpf_prog_load(&attr, sizeof(attr));
>> done:
>> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
>> index ed09eed2dc3b..15a8e22e8eae 100644
>> --- a/tools/lib/bpf/bpf.h
>> +++ b/tools/lib/bpf/bpf.h
>> @@ -76,6 +76,7 @@ struct bpf_load_program_attr {
>> const struct bpf_insn *insns;
>> size_t insns_cnt;
>> const char *license;
>> + __u32 log_level;
>> __u32 kern_version;
>> __u32 prog_ifindex;
>> __u32 prog_btf_fd;
>
> this will break binary compatibility in libbpf api.
> Please add new fields always to the end of *_attr structs.
I felt that we were still at 0.0.x stage and still could tweak
the api a little bit so I used the above sequence to
mimic the kernel prog_load attr sequence. I do agree that
in general we should add to the end of data structure.
I can change to the end of structure we still decided
if exposing log_level=2 is needed.
>
> Also why not to silence bcc instead?
> Let it treat log_level > 1 as log_level=1
> I don't think anyone but the most extreme verifier hacker used level=2.
In general, that is true. I just used the feature a couple of
weeks ago to toubleshoot a verifier error... But most cases
log_level=1 should be sufficient.
> Personally I don't remember when was the last time I used it.
> It seem like a niche feature that we can safely remove in bcc.
Will discuss a little more in bcc community and then make
a decision.
^ permalink raw reply
* Re: [RFC bpf-next 0/7] net: flow_dissector: trigger BPF hook when called from eth_get_headlen
From: Stanislav Fomichev @ 2019-02-06 5:49 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Willem de Bruijn, Stanislav Fomichev, Network Development,
David Miller, Alexei Starovoitov, Daniel Borkmann, simon.horman,
Willem de Bruijn
In-Reply-To: <20190206041112.h3ccahimp2uerdfk@ast-mbp>
On 02/05, Alexei Starovoitov wrote:
> On Tue, Feb 05, 2019 at 07:56:19PM -0800, Stanislav Fomichev wrote:
> > On 02/05, Alexei Starovoitov wrote:
> > > On Tue, Feb 05, 2019 at 04:59:31PM -0800, Stanislav Fomichev wrote:
> > > > On 02/05, Alexei Starovoitov wrote:
> > > > > On Tue, Feb 05, 2019 at 12:40:03PM -0800, Stanislav Fomichev wrote:
> > > > > > On 02/05, Willem de Bruijn wrote:
> > > > > > > On Tue, Feb 5, 2019 at 12:57 PM Stanislav Fomichev <sdf@google.com> wrote:
> > > > > > > >
> > > > > > > > Currently, when eth_get_headlen calls flow dissector, it doesn't pass any
> > > > > > > > skb. Because we use passed skb to lookup associated networking namespace
> > > > > > > > to find whether we have a BPF program attached or not, we always use
> > > > > > > > C-based flow dissector in this case.
> > > > > > > >
> > > > > > > > The goal of this patch series is to add new networking namespace argument
> > > > > > > > to the eth_get_headlen and make BPF flow dissector programs be able to
> > > > > > > > work in the skb-less case.
> > > > > > > >
> > > > > > > > The series goes like this:
> > > > > > > > 1. introduce __init_skb and __init_skb_shinfo; those will be used to
> > > > > > > > initialize temporary skb
> > > > > > > > 2. introduce skb_net which can be used to get networking namespace
> > > > > > > > associated with an skb
> > > > > > > > 3. add new optional network namespace argument to __skb_flow_dissect and
> > > > > > > > plumb through the callers
> > > > > > > > 4. add new __flow_bpf_dissect which constructs temporary on-stack skb
> > > > > > > > (using __init_skb) and calls BPF flow dissector program
> > > > > > >
> > > > > > > The main concern I see with this series is this cost of skb zeroing
> > > > > > > for every packet in the device driver receive routine, *independent*
> > > > > > > from the real skb allocation and zeroing which will likely happen
> > > > > > > later.
> > > > > > Yes, plus ~200 bytes on the stack for the callers.
> > > > > >
> > > > > > Not sure how visible this zeroing though, I can probably try to get some
> > > > > > numbers from BPF_PROG_TEST_RUN (running current version vs running with
> > > > > > on-stack skb).
> > > > >
> > > > > imo extra 256 byte memset for every packet is non starter.
> > > > We can put pre-allocated/initialized skbs without data into percpu or even
> > > > use pcpu_freelist_pop/pcpu_freelist_push to make sure we don't have to think
> > > > about having multiple percpu for irq/softirq/process contexts.
> > > > Any concerns with that approach?
> > > > Any other possible concerns with the overall series?
> > >
> > > I'm missing why the whole thing is needed.
> > > You're saying:
> > > " make BPF flow dissector programs be able to work in the skb-less case".
> > > What does it mean specifically?
> > > The only non-skb case is XDP.
> > > Are you saying you want flow_dissector prog to be run in XDP?
> > eth_get_headlen that drivers call on RX path on a chunk of data to
> > guesstimate the length of the headers calls flow dissector without an skb
> > (__skb_flow_dissect was a weird interface where it accepts skb or
> > data+len). Right now, there is no way to trigger BPF flow dissector
> > for this case (we don't have an skb to get associated namespace/etc/etc).
> > The patch series tries to fix that to make sure that we always trigger
> > BPF program if it's attached to a device's namespace.
>
> then why not to create flow_dissector prog type that works without skb?
> Why do you need to fake an skb?
> XDP progs work just fine without it.
What's the advantage of having another prog type? In this case we would have
to write the same flow dissector program twice: first time against __skb_buff
interface, second time against xdp_md.
By using fake skb, we make the same flow dissector __sk_buff BPF program
work in both contexts without a rewrite to an xdp interface (I don't
think users should care whether flow dissector was called form "xdp" vs skb
context; and we're sort of stuck with __sk_buff interface already).
^ permalink raw reply
* Re: [PATCH v2 bpf-next 2/2] btf: expose API to work with raw btf data
From: Andrii Nakryiko @ 2019-02-06 5:46 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Andrii Nakryiko, Song Liu, Yonghong Song, Alexei Starovoitov,
Martin Lau, netdev, Daniel Borkmann
In-Reply-To: <20190206030709.hrxaorkkmgaxn5au@ast-mbp>
On Tue, Feb 5, 2019 at 7:07 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Feb 05, 2019 at 04:29:49PM -0800, Andrii Nakryiko wrote:
> > This patch exposes two new APIs btf__get_raw_data_size() and
> > btf__get_raw_data() that allows to get a copy of raw BTF data out of
> > struct btf. This is useful for external programs that need to manipulate
> > raw data, e.g., pahole using btf__dedup() to deduplicate BTF type info
> > and then writing it back to file.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > Acked-by: Song Liu <songliubraving@fb.com>
> > ---
> > tools/lib/bpf/btf.c | 10 ++++++++++
> > tools/lib/bpf/btf.h | 2 ++
> > tools/lib/bpf/libbpf.map | 2 ++
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> > index 1c2ba7182400..34bfb3641aac 100644
> > --- a/tools/lib/bpf/btf.c
> > +++ b/tools/lib/bpf/btf.c
> > @@ -437,6 +437,16 @@ int btf__fd(const struct btf *btf)
> > return btf->fd;
> > }
> >
> > +__u32 btf__get_raw_data_size(const struct btf *btf)
> > +{
> > + return btf->data_size;
> > +}
> > +
> > +void btf__get_raw_data(const struct btf *btf, char *data)
> > +{
> > + memcpy(data, btf->data, btf->data_size);
> > +}
>
> I cannot think of any other way to use this api,
> but to call btf__get_raw_data_size() first,
> then malloc that much memory and then call btf__get_raw_data()
> to store btf into it.
>
> If so, may be api should be single call that allocates, copies,
> and returns pointer to new mem and its size?
> Probably less error prone?
>
I don't have strong preference, but providing pointer to allocated memory
seems more flexible and allows more clever/optimal use of memory from caller
side. E.g., instead of doing two mallocs, you can imagine doing something
like:
int max_size = max(btf__get_raw_data_size(btf),
btf_ext__get_raw_data_size(btf_ext));
char *m = malloc(max_size);
btf__get_raw_data(btf, m);
dump_btf_section_to_file(m, some_file);
btf_ext__get_raw_data(btf_ext, m);
dump_btf_ext_section_to_file(m, some_file);
free(m);
Also, pointer to memory could be mmap()'ed file, for instance. In general,
for a library it might be a good thing to not be prescriptive as to how one
gets that piece of memory.
If those examples are not convincing enough, I'm happy to go with single
btf__get_raw_data() call doing allocation and returning pointer.
^ permalink raw reply
* [PATCH bpf-next] tools/bpf: silence a libbpf unnecessary warning
From: Yonghong Song @ 2019-02-06 5:38 UTC (permalink / raw)
To: Andrii Nakryiko, netdev
Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team, Yonghong Song
Commit 96408c43447a ("tools/bpf: implement libbpf
btf__get_map_kv_tids() API function") refactored
function bpf_map_find_btf_info() and moved bulk of
implementation into btf.c as btf__get_map_kv_tids().
This change introduced a bug such that test_btf will
print out the following warning although the test passed:
BTF libbpf test[2] (test_btf_nokv.o): libbpf: map:btf_map
container_name:____btf_map_btf_map cannot be found
in BTF. Missing BPF_ANNOTATE_KV_PAIR?
Previously, the error message is guarded with pr_debug().
Commit 96408c43447a changed it to pr_warning() and
hence caused the warning.
Restoring to pr_debug() for the message fixed the issue.
Fixes: 96408c43447a ("tools/bpf: implement libbpf btf__get_map_kv_tids() API function")
Signed-off-by: Yonghong Song <yhs@fb.com>
---
tools/lib/bpf/btf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
index 3b3a2959d03a..ab6528c935a1 100644
--- a/tools/lib/bpf/btf.c
+++ b/tools/lib/bpf/btf.c
@@ -531,8 +531,8 @@ int btf__get_map_kv_tids(const struct btf *btf, const char *map_name,
container_id = btf__find_by_name(btf, container_name);
if (container_id < 0) {
- pr_warning("map:%s container_name:%s cannot be found in BTF. Missing BPF_ANNOTATE_KV_PAIR?\n",
- map_name, container_name);
+ pr_debug("map:%s container_name:%s cannot be found in BTF. Missing BPF_ANNOTATE_KV_PAIR?\n",
+ map_name, container_name);
return container_id;
}
--
2.17.1
^ permalink raw reply related
* Re: [Patch net v2] xfrm: destroy xfrm_state synchronously on net exit path
From: Steffen Klassert @ 2019-02-06 5:14 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, syzbot+e9aebef558e3ed673934
In-Reply-To: <20190131210549.3114-1-xiyou.wangcong@gmail.com>
On Thu, Jan 31, 2019 at 01:05:49PM -0800, Cong Wang wrote:
> xfrm_state_put() moves struct xfrm_state to the GC list
> and schedules the GC work to clean it up. On net exit call
> path, xfrm_state_flush() is called to clean up and
> xfrm_flush_gc() is called to wait for the GC work to complete
> before exit.
>
> However, this doesn't work because one of the ->destructor(),
> ipcomp_destroy(), schedules the same GC work again inside
> the GC work. It is hard to wait for such a nested async
> callback. This is also why syzbot still reports the following
> warning:
>
> WARNING: CPU: 1 PID: 33 at net/ipv6/xfrm6_tunnel.c:351 xfrm6_tunnel_net_exit+0x2cb/0x500 net/ipv6/xfrm6_tunnel.c:351
> ...
> ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153
> cleanup_net+0x51d/0xb10 net/core/net_namespace.c:551
> process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
> worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
> kthread+0x357/0x430 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
>
> In fact, it is perfectly fine to bypass GC and destroy xfrm_state
> synchronously on net exit call path, because it is in process context
> and doesn't need a work struct to do any blocking work.
>
> This patch introduces xfrm_state_put_sync() which simply bypasses
> GC, and lets its callers to decide whether to use this synchronous
> version. On net exit path, xfrm_state_fini() and
> xfrm6_tunnel_net_exit() use it. And, as ipcomp_destroy() itself is
> blocking, it can use xfrm_state_put_sync() directly too.
>
> Also rename xfrm_state_gc_destroy() to ___xfrm_state_destroy() to
> reflect this change.
>
> Fixes: b48c05ab5d32 ("xfrm: Fix warning in xfrm6_tunnel_net_exit.")
> Reported-and-tested-by: syzbot+e9aebef558e3ed673934@syzkaller.appspotmail.com
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thanks a lot!
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/2] btf: separate btf creation and loading
From: Andrii Nakryiko @ 2019-02-06 5:03 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Andrii Nakryiko, Song Liu, Yonghong Song, Alexei Starovoitov,
Martin Lau, netdev, daniel
In-Reply-To: <20190206030333.lurnxegmblbxrqjw@ast-mbp>
On Tue, Feb 5, 2019 at 7:03 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Feb 05, 2019 at 04:29:48PM -0800, Andrii Nakryiko wrote:
> > This change splits out previous btf__new functionality of constructing
> > struct btf and loading it into kernel into two:
> > - btf__new() just creates and initializes struct btf
> > - btf__load() attempts to load existing struct btf into kernel
> >
> > btf__free will still close BTF fd, if it was ever loaded successfully
> > into kernel.
> >
> > This change allows users of libbpf to manipulate BTF using its API,
> > without the need to unnecessarily load it into kernel.
> >
> > One of the intended use cases is pahole using libbpf to do DWARF to BTF
> > conversion and deduplication using libbpf, while handling ELF sections
> > overwrites and other concerns on its own.
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > Acked-by: Song Liu <songliubraving@fb.com>
>
> should it be
> Fixes: 2d3feca8c44f ("bpf: btf: print map dump and lookup with btf info")
> ?
> Even back then btf__new() was doing the loading.
> So that btf support in bpftool was silently double loading btf.
>
ok, will add that to commit message
^ permalink raw reply
* KASAN: slab-out-of-bounds Read in ip_send_unicast_reply
From: syzbot @ 2019-02-06 5:02 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11a6994b400000
kernel config: https://syzkaller.appspot.com/x/.config?x=b03c5892bb940c76
dashboard link: https://syzkaller.appspot.com/bug?extid=f1741fbf71635c029556
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f1741fbf71635c029556@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in sock_net include/net/sock.h:2403 [inline]
BUG: KASAN: slab-out-of-bounds in ip_send_unicast_reply+0x14a6/0x1800
net/ipv4/ip_output.c:1569
Read of size 8 at addr ffff888097d4c5ac by task syz-executor4/19801
CPU: 0 PID: 19801 Comm: syz-executor4 Not tainted 4.20.0+ #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report mm/kasan/report.c:412 [inline]
kasan_report.cold+0x8c/0x2ba mm/kasan/report.c:396
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
sock_net include/net/sock.h:2403 [inline]
ip_send_unicast_reply+0x14a6/0x1800 net/ipv4/ip_output.c:1569
tcp_v4_send_reset+0x1496/0x2ad0 net/ipv4/tcp_ipv4.c:775
tcp_v4_rcv+0x1e17/0x3c40 net/ipv4/tcp_ipv4.c:1936
ip_protocol_deliver_rcu+0xb6/0xa20 net/ipv4/ip_input.c:208
ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ip_local_deliver+0x1f0/0x740 net/ipv4/ip_input.c:255
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish+0x1f4/0x2f0 net/ipv4/ip_input.c:414
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ip_rcv+0xed/0x620 net/ipv4/ip_input.c:523
__netif_receive_skb_one_core+0x160/0x210 net/core/dev.c:4973
__netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083
process_backlog+0x206/0x750 net/core/dev.c:5923
napi_poll net/core/dev.c:6346 [inline]
net_rx_action+0x76d/0x1930 net/core/dev.c:6412
__do_softirq+0x30b/0xb11 kernel/softirq.c:292
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1027
</IRQ>
do_softirq.part.0+0x11a/0x170 kernel/softirq.c:337
do_softirq kernel/softirq.c:329 [inline]
__local_bh_enable_ip+0x211/0x270 kernel/softirq.c:189
local_bh_enable include/linux/bottom_half.h:32 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:696 [inline]
ip_finish_output2+0xa88/0x1a00 net/ipv4/ip_output.c:231
ip_finish_output+0x7e4/0xf60 net/ipv4/ip_output.c:317
NF_HOOK_COND include/linux/netfilter.h:278 [inline]
ip_output+0x226/0x880 net/ipv4/ip_output.c:405
dst_output include/net/dst.h:444 [inline]
ip_local_out+0xc4/0x1b0 net/ipv4/ip_output.c:124
__ip_queue_xmit+0x99a/0x1ee0 net/ipv4/ip_output.c:505
ip_queue_xmit+0x5a/0x70 include/net/ip.h:198
__tcp_transmit_skb+0x1add/0x3af0 net/ipv4/tcp_output.c:1160
tcp_transmit_skb net/ipv4/tcp_output.c:1176 [inline]
tcp_connect+0x33ca/0x4770 net/ipv4/tcp_output.c:3535
kobject: 'rx-0' (0000000070ecd47e): kobject_uevent_env
tcp_v4_connect+0x1598/0x1da0 net/ipv4/tcp_ipv4.c:315
__inet_stream_connect+0x9a3/0x11b0 net/ipv4/af_inet.c:655
kobject: 'rx-0' (0000000070ecd47e): fill_kobj_path: path
= '/devices/virtual/net/gretap0/queues/rx-0'
kobject: 'tx-0' (00000000301d47dc): kobject_add_internal: parent: 'queues',
set: 'queues'
inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:719
__sys_connect+0x357/0x490 net/socket.c:1664
kobject: 'tx-0' (00000000301d47dc): kobject_uevent_env
__do_sys_connect net/socket.c:1675 [inline]
__se_sys_connect net/socket.c:1672 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:1672
kobject: 'tx-0' (00000000301d47dc): fill_kobj_path: path
= '/devices/virtual/net/gretap0/queues/tx-0'
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
kobject: 'batman_adv' (00000000ab8b79c4): kobject_add_internal:
parent: 'gretap0', set: '<NULL>'
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457ec9
Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f116f5d1c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
kobject: 'erspan0' (000000001f020f96): kobject_add_internal: parent: 'net',
set: 'devices'
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457ec9
RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000007
RBP: 000000000073bfa0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f116f5d26d4
R13: 00000000004be30a R14: 00000000004ce6d8 R15: 00000000ffffffff
Allocated by task 3862:
save_stack+0x45/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc mm/kasan/kasan.c:553 [inline]
kasan_kmalloc+0xce/0xf0 mm/kasan/kasan.c:531
kasan_slab_alloc+0xf/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x700 mm/slab.c:3554
getname_flags fs/namei.c:140 [inline]
getname_flags+0xd6/0x5b0 fs/namei.c:129
getname+0x1a/0x20 fs/namei.c:211
kobject: 'erspan0' (000000001f020f96): kobject_uevent_env
do_sys_open+0x3a5/0x740 fs/open.c:1057
__do_sys_open fs/open.c:1081 [inline]
__se_sys_open fs/open.c:1076 [inline]
__x64_sys_open+0x7e/0xc0 fs/open.c:1076
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 3862:
save_stack+0x45/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
kobject: 'erspan0' (000000001f020f96): fill_kobj_path: path
= '/devices/virtual/net/erspan0'
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x86/0x260 mm/slab.c:3760
putname+0xef/0x130 fs/namei.c:261
do_sys_open+0x3f4/0x740 fs/open.c:1072
__do_sys_open fs/open.c:1081 [inline]
__se_sys_open fs/open.c:1076 [inline]
__x64_sys_open+0x7e/0xc0 fs/open.c:1076
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff888097d4cb00
which belongs to the cache names_cache of size 4096
The buggy address is located 1364 bytes to the left of
4096-byte region [ffff888097d4cb00, ffff888097d4db00)
The buggy address belongs to the page:
kobject: 'queues' (000000003e95a060): kobject_add_internal:
parent: 'erspan0', set: '<NULL>'
page:ffffea00025f5300 count:1 mapcount:0 mapping:ffff88812c2bec40 index:0x0
compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea0002498108 ffffea0000cfdc88 ffff88812c2bec40
raw: 0000000000000000 ffff888097d4cb00 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888097d4c480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888097d4c500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
kobject: 'queues' (000000003e95a060): kobject_uevent_env
> ffff888097d4c580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff888097d4c600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888097d4c680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* KASAN: use-after-free Read in tcp_sk_exit
From: syzbot @ 2019-02-06 5:01 UTC (permalink / raw)
To: davem, edumazet, kuznet, linux-kernel, netdev, syzkaller-bugs,
yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 33a0efa4baec devlink: Use DIV_ROUND_UP_ULL in DEVLINK_HEAL..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14e2e55f400000
kernel config: https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68
dashboard link: https://syzkaller.appspot.com/bug?extid=f797267da5e5012d0920
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f797267da5e5012d0920@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in inet_ctl_sock_destroy
include/net/inet_common.h:56 [inline]
BUG: KASAN: use-after-free in tcp_sk_exit+0x203/0x230
net/ipv4/tcp_ipv4.c:2588
Read of size 8 at addr ffff888064de4378 by task kworker/u4:3/131
CPU: 0 PID: 131 Comm: kworker/u4:3 Not tainted 5.0.0-rc3+ #17
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
inet_ctl_sock_destroy include/net/inet_common.h:56 [inline]
tcp_sk_exit+0x203/0x230 net/ipv4/tcp_ipv4.c:2588
ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153
cleanup_net+0x51d/0xb10 net/core/net_namespace.c:551
process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Allocated by task 5864:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_kmalloc mm/kasan/common.c:496 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
kasan_kmalloc mm/kasan/common.c:504 [inline]
kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:411
kmem_cache_alloc+0x12d/0x710 mm/slab.c:3543
getname_flags fs/namei.c:140 [inline]
getname_flags+0xd6/0x5b0 fs/namei.c:129
getname+0x1a/0x20 fs/namei.c:211
do_sys_open+0x3a5/0x7c0 fs/open.c:1057
__do_sys_open fs/open.c:1081 [inline]
__se_sys_open fs/open.c:1076 [inline]
__x64_sys_open+0x7e/0xc0 fs/open.c:1076
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 5864:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
__cache_free mm/slab.c:3487 [inline]
kmem_cache_free+0x86/0x260 mm/slab.c:3749
putname+0xef/0x130 fs/namei.c:261
do_sys_open+0x3f4/0x7c0 fs/open.c:1072
__do_sys_open fs/open.c:1081 [inline]
__se_sys_open fs/open.c:1076 [inline]
__x64_sys_open+0x7e/0xc0 fs/open.c:1076
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff888064de4180
which belongs to the cache names_cache of size 4096
The buggy address is located 504 bytes inside of
4096-byte region [ffff888064de4180, ffff888064de5180)
The buggy address belongs to the page:
page:ffffea0001937900 count:1 mapcount:0 mapping:ffff88821bc45380 index:0x0
compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea0001931108 ffffea0001796b88 ffff88821bc45380
raw: 0000000000000000 ffff888064de4180 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888064de4200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888064de4280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff888064de4300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888064de4380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888064de4400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ 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