* Re: [PATCH net-next 1/2] ravb: Add tx and rx clock internal delays mode of APSR
From: Sergei Shtylyov @ 2017-01-27 13:00 UTC (permalink / raw)
To: Simon Horman, David Miller
Cc: Magnus Damm, netdev, linux-renesas-soc, Kazuya Mizuguchi
In-Reply-To: <1485515090-7570-2-git-send-email-horms+renesas@verge.net.au>
On 01/27/2017 02:04 PM, Simon Horman wrote:
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> This patch enables tx and rx clock internal delay modes (TDM and RDM).
>
> This is to address a failure in the case of 1Gbps communication using the
> by salvator-x board with the KSZ9031RNX phy. This has been reported to
> occur with both the r8a7795 (H3) and r8a7796 (M3-W) SoCs.
>
> With this change APSR internal delay modes are enabled for
> "rgmii-id", "rgmii-rxid" and "rgmii-txid" phy modes as follows:
>
> phy mode | ASPR delay mode
> -----------+----------------
> rgmii-id | TDM and RDM
> rgmii-rxid | RDM
> rgmii-txid | TDM
>
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> ---
> v1 [Simon Horman]
> - Combined patches
> - Reworded changelog
>
> v0 [Kazuya Mizuguchi]
[...]
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index 89ac1e3f6175..9fb4c04c5885 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1904,6 +1904,29 @@ static void ravb_set_config_mode(struct net_device *ndev)
> }
> }
>
> +static void ravb_set_delay_mode(struct net_device *ndev)
> +{
> + struct ravb_private *priv = netdev_priv(ndev);
> +
> + if (priv->chip_id != RCAR_GEN2) {
> + switch (priv->phy_interface) {
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + ravb_modify(ndev, APSR, APSR_DM, APSR_DM_RDM |
> + APSR_DM_TDM);
> + break;
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + ravb_modify(ndev, APSR, APSR_DM, APSR_DM_RDM);
> + break;
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + ravb_modify(ndev, APSR, APSR_DM, APSR_DM_TDM);
> + break;
> + default:
> + ravb_modify(ndev, APSR, APSR_DM, 0);
> + break;
> + }
> + }
> +}
> +
> static int ravb_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> @@ -2016,6 +2039,9 @@ static int ravb_probe(struct platform_device *pdev)
> /* Request GTI loading */
> ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
>
> + /* Set APSR */
> + ravb_set_delay_mode(ndev);
> +
> /* Allocate descriptor base address table */
> priv->desc_bat_size = sizeof(struct ravb_desc) * DBAT_ENTRY_NUM;
> priv->desc_bat = dma_alloc_coherent(ndev->dev.parent, priv->desc_bat_size,
> @@ -2152,6 +2178,9 @@ static int __maybe_unused ravb_resume(struct device *dev)
> /* Request GTI loading */
> ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
>
> + /* Set APSR */
> + ravb_set_delay_mode(ndev);
> +
So far the pattern was to first check if gen != 2, then calling a gen3
specific function. I'd like to keep it, rather than checking in the function
itself.
[...]
MBR, Sergei
^ permalink raw reply
* [next-20170124] Kernel oops(rt6_fill_node) during reboot of LPAR
From: Sachin Sant @ 2017-01-27 12:54 UTC (permalink / raw)
To: linux-next@vger.kernel.org, netdev, dsa
Cc: Michael Ellerman, Stephen Rothwell, linuxppc-dev, davem
While rebooting PowerVM LPAR running 4.10.0-rc5-next-20170124
on a POWER8 box, following kernel oops is displayed.
This problem was introduced with next-20170123. next-20170120 works.
Initial analysis points to following patch included with next-20170123
commit a1a22c12060e4b9c52f45d4b3460f614e00162a2
net: ipv6: Keep nexthop of multipath route on admin down
[ OK ] Stopped Logout off all iSCSI sessions on shutdown.
[ OK ] Stopped CUPS Printing Service.
[ OK ] Stopped Dynamic System Tuning Daemon.
[ OK ] Stopped target Network.
Stopping LSB: Bring up/down networking...
[ 86.292027] Unable to handle kernel paging request for data at address 0x000001d4
[ 86.292050] Faulting instruction address: 0xc0000000008734b0
[ 86.292054] Oops: Kernel access of bad area, sig: 11 [#1]
[ 86.292056] SMP NR_CPUS=2048
[ 86.292057] NUMA
[ 86.292059] pSeries
[ 86.292062] Modules linked in: xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun kvm_pr kvm ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm iw_cxgb3 ib_core ghash_generic xts gf128mul tpm_ibmvtpm tpm vmx_crypto sg pseries_rng nfsd auth_rpcgss nfs_acl lockd
[ 86.292099] grace sunrpc ip_tables xfs libcrc32c sr_mod sd_mod cdrom cxgb3 ibmvscsi ibmveth scsi_transport_srp mdio dm_mirror dm_region_hash dm_log dm_mod
[ 86.292109] CPU: 0 PID: 1500 Comm: NetworkManager Not tainted 4.10.0-rc5-next-20170124 #1
[ 86.292113] task: c00000000319b800 task.stack: c0000000fb9e0000
[ 86.292115] NIP: c0000000008734b0 LR: c000000000873444 CTR: c000000000879490
[ 86.292118] REGS: c0000000fb9e33d0 TRAP: 0300 Not tainted (4.10.0-rc5-next-20170124)
[ 86.292121] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>
[ 86.292124] CR: 28004428 XER: 00000000
[ 86.292128] CFAR: c000000000008850 DAR: 00000000000001d4 DSISR: 40000000 SOFTE: 1
[ 86.292128] GPR00: c000000000873444 c0000000fb9e3650 c000000000ff9f00 0000000000000000
[ 86.292128] GPR04: c0000000fb9e36b4 0000000000000004 c00000026ff50024 0000000000007e80
[ 86.292128] GPR08: 0000000000000000 0000000000000000 0000000000000002 0000000000000014
[ 86.292128] GPR12: c000000000879490 c00000000e800000 0000000000000000 0000000000000000
[ 86.292128] GPR16: 0000000000000000 0000000000000000 0000000000000000 c000000000fa6d00
[ 86.292128] GPR20: 0000000000000000 c000000000fa6d00 0000000000000000 c00000026a5bba00
[ 86.292128] GPR24: c000000000fa6d00 0000000000000000 0000000000000000 00000000384005dc
[ 86.292128] GPR28: 0000000000000000 c00000026a5bba00 c000000279f71c00 c00000026ff50000
[ 86.292163] NIP [c0000000008734b0] rt6_fill_node.isra.42+0x150/0x640
[ 86.292166] LR [c000000000873444] rt6_fill_node.isra.42+0xe4/0x640
[ 86.292169] Call Trace:
[ 86.292171] [c0000000fb9e3650] [c000000000873444] rt6_fill_node.isra.42+0xe4/0x640 (unreliable)
[ 86.292175] [c0000000fb9e3710] [c000000000878718] rt6_dump_route+0x68/0xa0
[ 86.292178] [c0000000fb9e3780] [c0000000008794d8] fib6_dump_node+0x48/0xb0
[ 86.292182] [c0000000fb9e37b0] [c000000000878de8] fib6_walk_continue+0x1d8/0x200
[ 86.292185] [c0000000fb9e3800] [c000000000879134] fib6_walk+0x44/0xa0
[ 86.292189] [c0000000fb9e3840] [c00000000087a0f4] inet6_dump_fib+0x1f4/0x2d0
[ 86.292193] [c0000000fb9e38f0] [c0000000007ae9cc] netlink_dump+0x14c/0x370
[ 86.292196] [c0000000fb9e3940] [c0000000007af428] __netlink_dump_start+0x198/0x210
[ 86.292201] [c0000000fb9e3990] [c0000000007833f4] rtnetlink_rcv_msg+0x194/0x300
[ 86.292204] [c0000000fb9e3a10] [c0000000007b1e48] netlink_rcv_skb+0x128/0x140
[ 86.292208] [c0000000fb9e3a50] [c00000000077f46c] rtnetlink_rcv+0x3c/0x60
[ 86.292211] [c0000000fb9e3a80] [c0000000007b13dc] netlink_unicast+0x1ec/0x370
[ 86.292215] [c0000000fb9e3ae0] [c0000000007b1adc] netlink_sendmsg+0x40c/0x480
[ 86.292219] [c0000000fb9e3b70] [c00000000073caec] sock_sendmsg+0x5c/0x90
[ 86.292223] [c0000000fb9e3ba0] [c00000000073d79c] ___sys_sendmsg+0x31c/0x330
[ 86.292226] [c0000000fb9e3d30] [c00000000073ece4] __sys_sendmsg+0x54/0xc0
[ 86.292229] [c0000000fb9e3dd0] [c00000000073f88c] SyS_socketcall+0x35c/0x3e0
[ 86.292234] [c0000000fb9e3e30] [c00000000000b184] system_call+0x38/0xe0
[ 86.292236] Instruction dump:
[ 86.292238] 39200000 913f0018 e93e0018 e9490048 794807e1 41820010 e9290048 792af7e3
[ 86.292243] 41820024 39200010 913f0018 e93e0158 <812901d4> 2f890000 419e000c 39200011
[ 86.292249] ---[ end trace 6bc185aea0ad63a6 ]---
[ 86.292251]
[ 88.292296] Kernel panic - not syncing: Fatal exception in interrupt
[ 88.292399] Rebooting in 10 seconds..
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Arend Van Spriel @ 2017-01-27 12:53 UTC (permalink / raw)
To: Kalle Valo, Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <8737g47kpd.fsf@kamboji.qca.qualcomm.com>
On 27-1-2017 13:26, Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
>> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
>>> Pali Rohár <pali.rohar@gmail.com> writes:
>>>
>>>>> So
>>>>> for those other platforms there will be a delay waiting for user-mode
>>>>> helper to fail, before trying to get nvs file from /lib/firmware.
>>>>
>>>> Yes, there will be. But there is no easy way to fix this problem that
>>>> kernel is trying to use default/example NVS data...
>>>
>>> Kernel is doing correctly and requesting NVS data as expected, the
>>> problem here is that linux-firmware claims that the example NVS data is
>>> real calibration data (which it is not). Distros should not use that,
>>> only developers for testing purposes. We should not courage users using
>>> example calibration data.
>>>
>>> The simple fix is to rename the NVS file in linux-firmware to something
>>> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
>>> you send a patch to linux-firmware I'm happy to ack that.
>>
>> I agree with rename and fact that default/example data should not be
>> used.
>>
>> But...
>>
>> 1) Kernel should not read device/model specific data from VFS where
>> are stored not-device-specific files preinstalled by linux
>> distributions.
>>
>> And linux distributions are already putting files into VFS and kernel
>> cannot enforce userspace to not do that (as they are already doing it).
>
> I'm having problems to understand what you are saying here.
This is a personal opinion. I read it as: /lib/firmware can only contain
files for from linux-firmware.
At least the device-specific vs. non-device-specific does not seem to
hold. The firmware files that we have in the linux-firmware repository
are very device-specific. Unless you mean the 'platform' when talking
about 'device'.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH net-next 2/2] ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W
From: Sergei Shtylyov @ 2017-01-27 12:52 UTC (permalink / raw)
To: Simon Horman, David Miller
Cc: Magnus Damm, netdev, linux-renesas-soc, Geert Uytterhoeven
In-Reply-To: <1485515090-7570-3-git-send-email-horms+renesas@verge.net.au>
On 01/27/2017 02:04 PM, Simon Horman wrote:
> From: Geert Uytterhoeven <geert+renesas@glider.be>
>
> The limitation to 10/100Mbit speeds on R-Car Gen3 is valid for R-Car H3
> ES1.0 only. Check for the exact SoC model to allow 1Gbps on newer
> revisions of R-Car H3, and on R-Car M3-W.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] net: phy: broadcom: add support for BCM54210E
From: kbuild test robot @ 2017-01-27 12:50 UTC (permalink / raw)
To: Rafał Miłecki
Cc: kbuild-all, David S . Miller, Florian Fainelli, Xo Wang,
Joel Stanley, Jon Mason, Jaedon Shin, netdev,
Rafał Miłecki
In-Reply-To: <20170127104705.25162-1-zajec5@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]
Hi Rafał,
[auto build test WARNING on net-next/master]
[also build test WARNING on v4.10-rc5 next-20170125]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/net-phy-broadcom-add-support-for-BCM54210E/20170127-190002
config: x86_64-randconfig-s5-01271950 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/linux/phy.h:19:0,
from drivers/net/phy/bcm-phy-lib.h:17,
from drivers/net/phy/broadcom.c:17:
drivers/net/phy/broadcom.c: In function 'bcm54xx_config_init':
drivers/net/phy/broadcom.c:249:32: error: 'PHY_ID_BCM54210E' undeclared (first use in this function)
if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/net/phy/broadcom.c:249:2: note: in expansion of macro 'if'
if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E) {
^~
drivers/net/phy/broadcom.c:249:32: note: each undeclared identifier is reported only once for each function it appears in
if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/net/phy/broadcom.c:249:2: note: in expansion of macro 'if'
if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E) {
^~
drivers/net/phy/broadcom.c: At top level:
drivers/net/phy/broadcom.c:565:13: error: 'PHY_ID_BCM54210E' undeclared here (not in a function)
.phy_id = PHY_ID_BCM54210E,
^~~~~~~~~~~~~~~~
drivers/net/phy/broadcom.c:714:4: error: initializer element is not constant
{ PHY_ID_BCM54210E, 0xfffffff0 },
^~~~~~~~~~~~~~~~
drivers/net/phy/broadcom.c:714:4: note: (near initialization for 'broadcom_tbl[2].phy_id')
vim +/if +249 drivers/net/phy/broadcom.c
233 MII_BCM54XX_INT_SPEED |
234 MII_BCM54XX_INT_LINK);
235 err = phy_write(phydev, MII_BCM54XX_IMR, reg);
236 if (err < 0)
237 return err;
238
239 if ((BRCM_PHY_MODEL(phydev) == PHY_ID_BCM50610 ||
240 BRCM_PHY_MODEL(phydev) == PHY_ID_BCM50610M) &&
241 (phydev->dev_flags & PHY_BRCM_CLEAR_RGMII_MODE))
242 bcm_phy_write_shadow(phydev, BCM54XX_SHD_RGMII_MODE, 0);
243
244 if ((phydev->dev_flags & PHY_BRCM_RX_REFCLK_UNUSED) ||
245 (phydev->dev_flags & PHY_BRCM_DIS_TXCRXC_NOENRGY) ||
246 (phydev->dev_flags & PHY_BRCM_AUTO_PWRDWN_ENABLE))
247 bcm54xx_adjust_rxrefclk(phydev);
248
> 249 if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E) {
250 err = bcm54210e_config_init(phydev);
251 if (err)
252 return err;
253 } else if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
254 err = bcm54810_config(phydev);
255 if (err)
256 return err;
257 }
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32428 bytes --]
^ permalink raw reply
* Re: [PATCH net] be2net: fix initial MAC setting
From: Ivan Vecera @ 2017-01-27 12:43 UTC (permalink / raw)
To: Sriharsha Basavapatna; +Cc: netdev, Sathya Perla, Ajit Khaparde, Somnath Kotur
In-Reply-To: <CAHHeUGXitTaXqQk8zDymcCX09vFq3CtM20FHJPL6AeVhc2iBPQ@mail.gmail.com>
2017-01-27 13:38 GMT+01:00 Sriharsha Basavapatna
<sriharsha.basavapatna@broadcom.com>:
> Hi Ivan,
>
> This patch is a bit involved. We need some time to review and test
> this to make sure it works with other (non-BE3/VF - Skyhawk, Lancer)
> devices. Also, IIRC we shouldn't see this issue with the latest FW.
>
I have done tests on BE3 PF & both privileged and non-privileged as well
as on Skyhawk PF and VF. No problems found.
Regarding firmware, I'm using version 11.1.215.0 on my devices and this version
is affected on BE3. Older versions are affected as well.
Ivan
>
> On Thu, Jan 26, 2017 at 3:58 PM, Ivan Vecera <cera@cera.cz> wrote:
>> Recent commit 34393529163a ("be2net: fix MAC addr setting on privileged
>> BE3 VFs") allows privileged BE3 VFs to set its MAC address during
>> initialization. Although the initial MAC for such VFs is already
>> programmed by parent PF the subsequent setting performed by VF is OK,
>> but in certain cases (after fresh boot) this command in VF can fail.
>>
>> The MAC should be initialized only when:
>> 1) no MAC is programmed (always except BE3 VFs during first init)
>> 2) programmed MAC is different from requested (e.g. MAC is set when
>> interface is down). In this case the initial MAC programmed by PF
>> needs to be deleted.
>>
>> The adapter->dev_mac contains MAC address currently programmed in HW so
>> it should be zeroed when the MAC is deleted from HW and should not be
>> filled when MAC is set when interface is down in be_mac_addr_set() as
>> no programming is performed in this case.
>>
>> Example of failure without the fix (immediately after fresh boot):
>>
>> # ip link set eth0 up <- eth0 is BE3 PF
>> be2net 0000:01:00.0 eth0: Link is Up
>>
>> # echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create 1 VF
>> ...
>> be2net 0000:01:04.0: Emulex OneConnect(be3): VF port 0
>>
>> # ip link set eth8 up <- eth8 is created privileged VF
>> be2net 0000:01:04.0: opcode 59-1 failed:status 1-76
>> RTNETLINK answers: Input/output error
>>
>> # echo 0 > /sys/class/net/eth0/device/sriov_numvfs <- Delete VF
>> iommu: Removing device 0000:01:04.0 from group 33
>> ...
>>
>> # echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create it again
>> iommu: Removing device 0000:01:04.0 from group 33
>> ...
>>
>> # ip link set eth8 up
>> be2net 0000:01:04.0 eth8: Link is Up
>>
>> Initialization is now OK.
>>
>> Fixes: 34393529163a ("be2net: fix MAC addr setting on privileged BE3 VFs")
>> Cc: Sathya Perla <sathya.perla@broadcom.com>
>> Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
>> Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
>> Cc: Somnath Kotur <somnath.kotur@broadcom.com>
>> Signed-off-by: Ivan Vecera <cera@cera.cz>
>> ---
>> drivers/net/ethernet/emulex/benet/be_main.c | 31 ++++++++++++++++++++++++-----
>> 1 file changed, 26 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
>> index 1a7f8ad7b9c6..cf13b99b8551 100644
>> --- a/drivers/net/ethernet/emulex/benet/be_main.c
>> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
>> @@ -362,8 +362,10 @@ static int be_mac_addr_set(struct net_device *netdev, void *p)
>> status = -EPERM;
>> goto err;
>> }
>> -done:
>> +
>> + /* Remember currently programmed MAC */
>> ether_addr_copy(adapter->dev_mac, addr->sa_data);
>> +done:
>> ether_addr_copy(netdev->dev_addr, addr->sa_data);
>> dev_info(dev, "MAC address changed to %pM\n", addr->sa_data);
>> return 0;
>> @@ -3618,8 +3620,10 @@ static void be_disable_if_filters(struct be_adapter *adapter)
>> {
>> /* Don't delete MAC on BE3 VFs without FILTMGMT privilege */
>> if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
>> - check_privilege(adapter, BE_PRIV_FILTMGMT))
>> + check_privilege(adapter, BE_PRIV_FILTMGMT)) {
>> be_dev_mac_del(adapter, adapter->pmac_id[0]);
>> + eth_zero_addr(adapter->dev_mac);
>> + }
>>
>> be_clear_uc_list(adapter);
>> be_clear_mc_list(adapter);
>> @@ -3773,12 +3777,25 @@ static int be_enable_if_filters(struct be_adapter *adapter)
>> if (status)
>> return status;
>>
>> - /* Don't add MAC on BE3 VFs without FILTMGMT privilege */
>> - if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
>> - check_privilege(adapter, BE_PRIV_FILTMGMT)) {
>> + /* Normally this condition usually true as the ->dev_mac is zeroed.
>> + * But on BE3 VFs the initial MAC is pre-programmed by PF and
>> + * subsequent be_dev_mac_add() can fail (after fresh boot)
>> + */
>> + if (!ether_addr_equal(adapter->dev_mac, adapter->netdev->dev_addr)) {
>> + int old_pmac_id = -1;
>> +
>> + /* Remember old programmed MAC if any - can happen on BE3 VF */
>> + if (!is_zero_ether_addr(adapter->dev_mac))
>> + old_pmac_id = adapter->pmac_id[0];
>> +
>> status = be_dev_mac_add(adapter, adapter->netdev->dev_addr);
>> if (status)
>> return status;
>> +
>> + /* Delete old programmed MAC if necessary */
>> + if (old_pmac_id > 0 && old_pmac_id != adapter->pmac_id[0])
>> + be_dev_mac_del(adapter, old_pmac_id);
>> +
>> ether_addr_copy(adapter->dev_mac, adapter->netdev->dev_addr);
>> }
>>
>> @@ -4552,6 +4569,10 @@ static int be_mac_setup(struct be_adapter *adapter)
>>
>> memcpy(adapter->netdev->dev_addr, mac, ETH_ALEN);
>> memcpy(adapter->netdev->perm_addr, mac, ETH_ALEN);
>> +
>> + /* Initial MAC for BE3 VFs is already programmed by PF */
>> + if (BEx_chip(adapter) && be_virtfn(adapter))
>> + memcpy(adapter->dev_mac, mac, ETH_ALEN);
>> }
>>
>> return 0;
>> --
>> 2.10.2
>>
^ permalink raw reply
* Re: [PATCH] Net: ethernet: mediatek - Fix possible NULL derefrence.
From: Corentin Labbe @ 2017-01-27 12:44 UTC (permalink / raw)
To: Shailendra Verma
Cc: Felix Fietkau, ashish.kalra-Sze3O3UU22JBDgjK7y7TUQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
p.shailesh-Sze3O3UU22JBDgjK7y7TUQ,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
Shailendra Verma,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, John Crispin
In-Reply-To: <1485515980-3814-1-git-send-email-shailendra.v-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Fri, Jan 27, 2017 at 04:49:40PM +0530, Shailendra Verma wrote:
> of_match_device could return NULL, and so can cause a NULL
> pointer dereference later.
>
> Signed-off-by: Shailendra Verma <shailendra.v-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 4a62ffd..4495b7b 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2369,6 +2369,10 @@ static int mtk_probe(struct platform_device *pdev)
> int i;
>
> match = of_match_device(of_mtk_match, &pdev->dev);
> + if (!match) {
> + dev_err(&pdev->dev, "Error: No device match found\n");
> + return -ENODEV;
> + }
> soc = (struct mtk_soc_data *)match->data;
>
> eth = devm_kzalloc(&pdev->dev, sizeof(*eth), GFP_KERNEL);
> --
Hello
You could use of_device_get_match_data() and simplifiy code
Regards
Corentin Labbe
^ permalink raw reply
* Re: [PATCH net-next 1/2] ravb: Add tx and rx clock internal delays mode of APSR
From: Sergei Shtylyov @ 2017-01-27 12:42 UTC (permalink / raw)
To: Simon Horman, David Miller
Cc: Magnus Damm, netdev, linux-renesas-soc, Kazuya Mizuguchi
In-Reply-To: <1485515090-7570-2-git-send-email-horms+renesas@verge.net.au>
Hello!
On 01/27/2017 02:04 PM, Simon Horman wrote:
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> This patch enables tx and rx clock internal delay modes (TDM and RDM).
>
> This is to address a failure in the case of 1Gbps communication using the
> by salvator-x board with the KSZ9031RNX phy. This has been reported to
> occur with both the r8a7795 (H3) and r8a7796 (M3-W) SoCs.
>
> With this change APSR internal delay modes are enabled for
> "rgmii-id", "rgmii-rxid" and "rgmii-txid" phy modes as follows:
>
> phy mode | ASPR delay mode
> -----------+----------------
> rgmii-id | TDM and RDM
> rgmii-rxid | RDM
> rgmii-txid | TDM
>
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> ---
> v1 [Simon Horman]
> - Combined patches
> - Reworded changelog
>
> v0 [Kazuya Mizuguchi]
> ---
> drivers/net/ethernet/renesas/ravb.h | 10 ++++++++++
> drivers/net/ethernet/renesas/ravb_main.c | 29 +++++++++++++++++++++++++++++
> 2 files changed, 39 insertions(+)
>
> diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
> index f1109661a533..d7c91d48cc48 100644
> --- a/drivers/net/ethernet/renesas/ravb.h
> +++ b/drivers/net/ethernet/renesas/ravb.h
[...]
> @@ -248,6 +249,15 @@ enum ESR_BIT {
> ESR_EIL = 0x00001000,
> };
>
> +/* APSR */
> +enum APSR_BIT {
> + APSR_MEMS = 0x00000002,
Not documented in the revision 0.5 of the gen3 manual...
> + APSR_CMSW = 0x00000010,
> + APSR_DM = 0x00006000,
... and neither this field. Are these documented in the latter revs?
> + APSR_DM_RDM = 0x00002000,
> + APSR_DM_TDM = 0x00004000,
> +};
> +
> /* RCR */
> enum RCR_BIT {
> RCR_EFFS = 0x00000001,
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index 89ac1e3f6175..9fb4c04c5885 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1904,6 +1904,29 @@ static void ravb_set_config_mode(struct net_device *ndev)
> }
> }
>
> +static void ravb_set_delay_mode(struct net_device *ndev)
> +{
> + struct ravb_private *priv = netdev_priv(ndev);
> +
> + if (priv->chip_id != RCAR_GEN2) {
> + switch (priv->phy_interface) {
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + ravb_modify(ndev, APSR, APSR_DM, APSR_DM_RDM |
> + APSR_DM_TDM);
> + break;
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + ravb_modify(ndev, APSR, APSR_DM, APSR_DM_RDM);
> + break;
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + ravb_modify(ndev, APSR, APSR_DM, APSR_DM_TDM);
> + break;
> + default:
> + ravb_modify(ndev, APSR, APSR_DM, 0);
> + break;
> + }
How about doing ravb_modify() only once?
[...]
MNR, Sergei
^ permalink raw reply
* Re: [PATCH net] be2net: fix initial MAC setting
From: Sriharsha Basavapatna @ 2017-01-27 12:38 UTC (permalink / raw)
To: Ivan Vecera
Cc: netdev, Sathya Perla, Ajit Khaparde, Somnath Kotur,
Sriharsha Basavapatna
In-Reply-To: <20170126102801.18914-1-cera@cera.cz>
Hi Ivan,
This patch is a bit involved. We need some time to review and test
this to make sure it works with other (non-BE3/VF - Skyhawk, Lancer)
devices. Also, IIRC we shouldn't see this issue with the latest FW.
Thanks,
-Harsha
On Thu, Jan 26, 2017 at 3:58 PM, Ivan Vecera <cera@cera.cz> wrote:
> Recent commit 34393529163a ("be2net: fix MAC addr setting on privileged
> BE3 VFs") allows privileged BE3 VFs to set its MAC address during
> initialization. Although the initial MAC for such VFs is already
> programmed by parent PF the subsequent setting performed by VF is OK,
> but in certain cases (after fresh boot) this command in VF can fail.
>
> The MAC should be initialized only when:
> 1) no MAC is programmed (always except BE3 VFs during first init)
> 2) programmed MAC is different from requested (e.g. MAC is set when
> interface is down). In this case the initial MAC programmed by PF
> needs to be deleted.
>
> The adapter->dev_mac contains MAC address currently programmed in HW so
> it should be zeroed when the MAC is deleted from HW and should not be
> filled when MAC is set when interface is down in be_mac_addr_set() as
> no programming is performed in this case.
>
> Example of failure without the fix (immediately after fresh boot):
>
> # ip link set eth0 up <- eth0 is BE3 PF
> be2net 0000:01:00.0 eth0: Link is Up
>
> # echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create 1 VF
> ...
> be2net 0000:01:04.0: Emulex OneConnect(be3): VF port 0
>
> # ip link set eth8 up <- eth8 is created privileged VF
> be2net 0000:01:04.0: opcode 59-1 failed:status 1-76
> RTNETLINK answers: Input/output error
>
> # echo 0 > /sys/class/net/eth0/device/sriov_numvfs <- Delete VF
> iommu: Removing device 0000:01:04.0 from group 33
> ...
>
> # echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create it again
> iommu: Removing device 0000:01:04.0 from group 33
> ...
>
> # ip link set eth8 up
> be2net 0000:01:04.0 eth8: Link is Up
>
> Initialization is now OK.
>
> Fixes: 34393529163a ("be2net: fix MAC addr setting on privileged BE3 VFs")
> Cc: Sathya Perla <sathya.perla@broadcom.com>
> Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
> Cc: Somnath Kotur <somnath.kotur@broadcom.com>
> Signed-off-by: Ivan Vecera <cera@cera.cz>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 31 ++++++++++++++++++++++++-----
> 1 file changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 1a7f8ad7b9c6..cf13b99b8551 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -362,8 +362,10 @@ static int be_mac_addr_set(struct net_device *netdev, void *p)
> status = -EPERM;
> goto err;
> }
> -done:
> +
> + /* Remember currently programmed MAC */
> ether_addr_copy(adapter->dev_mac, addr->sa_data);
> +done:
> ether_addr_copy(netdev->dev_addr, addr->sa_data);
> dev_info(dev, "MAC address changed to %pM\n", addr->sa_data);
> return 0;
> @@ -3618,8 +3620,10 @@ static void be_disable_if_filters(struct be_adapter *adapter)
> {
> /* Don't delete MAC on BE3 VFs without FILTMGMT privilege */
> if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
> - check_privilege(adapter, BE_PRIV_FILTMGMT))
> + check_privilege(adapter, BE_PRIV_FILTMGMT)) {
> be_dev_mac_del(adapter, adapter->pmac_id[0]);
> + eth_zero_addr(adapter->dev_mac);
> + }
>
> be_clear_uc_list(adapter);
> be_clear_mc_list(adapter);
> @@ -3773,12 +3777,25 @@ static int be_enable_if_filters(struct be_adapter *adapter)
> if (status)
> return status;
>
> - /* Don't add MAC on BE3 VFs without FILTMGMT privilege */
> - if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
> - check_privilege(adapter, BE_PRIV_FILTMGMT)) {
> + /* Normally this condition usually true as the ->dev_mac is zeroed.
> + * But on BE3 VFs the initial MAC is pre-programmed by PF and
> + * subsequent be_dev_mac_add() can fail (after fresh boot)
> + */
> + if (!ether_addr_equal(adapter->dev_mac, adapter->netdev->dev_addr)) {
> + int old_pmac_id = -1;
> +
> + /* Remember old programmed MAC if any - can happen on BE3 VF */
> + if (!is_zero_ether_addr(adapter->dev_mac))
> + old_pmac_id = adapter->pmac_id[0];
> +
> status = be_dev_mac_add(adapter, adapter->netdev->dev_addr);
> if (status)
> return status;
> +
> + /* Delete old programmed MAC if necessary */
> + if (old_pmac_id > 0 && old_pmac_id != adapter->pmac_id[0])
> + be_dev_mac_del(adapter, old_pmac_id);
> +
> ether_addr_copy(adapter->dev_mac, adapter->netdev->dev_addr);
> }
>
> @@ -4552,6 +4569,10 @@ static int be_mac_setup(struct be_adapter *adapter)
>
> memcpy(adapter->netdev->dev_addr, mac, ETH_ALEN);
> memcpy(adapter->netdev->perm_addr, mac, ETH_ALEN);
> +
> + /* Initial MAC for BE3 VFs is already programmed by PF */
> + if (BEx_chip(adapter) && be_virtfn(adapter))
> + memcpy(adapter->dev_mac, mac, ETH_ALEN);
> }
>
> return 0;
> --
> 2.10.2
>
^ permalink raw reply
* Re: [iproute PATCH] man: tc-csum.8: Fix example
From: Jiri Pirko @ 2017-01-27 12:26 UTC (permalink / raw)
To: Phil Sutter; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20170127111501.21439-1-phil@nwl.cc>
Fri, Jan 27, 2017 at 12:15:01PM CET, phil@nwl.cc wrote:
>This fixes two issues with the provided example:
>
>- Add missing 'dev' keyword to second command.
>- Use a real IPv4 address instead of a bogus hex value since that will
> be rejected by get_addr_ipv4().
>
>Fixes: dbfb17a67f9c7 ("man: tc-csum.8: Add an example")
>Reported-by: Davide Caratti <dcaratti@redhat.com>
>Signed-off-by: Phil Sutter <phil@nwl.cc>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* [PATCH] [net] ISDN: eicon: silence misleading array-bounds warning
From: Arnd Bergmann @ 2017-01-27 12:32 UTC (permalink / raw)
To: Armin Schindler, Karsten Keil
Cc: Nicholas Mc Guire, kernel-build-reports, Arnd Bergmann, stable,
David S. Miller, netdev, linux-kernel
With some gcc versions, we get a warning about the eicon driver,
and that currently shows up as the only remaining warning in one
of the build bots:
In file included from ../drivers/isdn/hardware/eicon/message.c:30:0:
eicon/message.c: In function 'mixer_notify_update':
eicon/platform.h:333:18: warning: array subscript is above array bounds [-Warray-bounds]
The code is easily changed to open-code the unusual PUT_WORD() line
causing this to avoid the warning.
Cc: stable@vger.kernel.org
Link: http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.45/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/isdn/hardware/eicon/message.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/eicon/message.c b/drivers/isdn/hardware/eicon/message.c
index 1a1d99704fe6..296f1411fe84 100644
--- a/drivers/isdn/hardware/eicon/message.c
+++ b/drivers/isdn/hardware/eicon/message.c
@@ -11297,7 +11297,8 @@ static void mixer_notify_update(PLCI *plci, byte others)
((CAPI_MSG *) msg)->header.ncci = 0;
((CAPI_MSG *) msg)->info.facility_req.Selector = SELECTOR_LINE_INTERCONNECT;
((CAPI_MSG *) msg)->info.facility_req.structs[0] = 3;
- PUT_WORD(&(((CAPI_MSG *) msg)->info.facility_req.structs[1]), LI_REQ_SILENT_UPDATE);
+ ((CAPI_MSG *) msg)->info.facility_req.structs[1] = LI_REQ_SILENT_UPDATE & 0xff;
+ ((CAPI_MSG *) msg)->info.facility_req.structs[2] = LI_REQ_SILENT_UPDATE >> 8;
((CAPI_MSG *) msg)->info.facility_req.structs[3] = 0;
w = api_put(notify_plci->appl, (CAPI_MSG *) msg);
if (w != _QUEUE_FULL)
--
2.9.0
^ permalink raw reply related
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-27 12:26 UTC (permalink / raw)
To: Pali Rohár
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170127115706.GH24223@pali>
Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
>> Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>> >> So
>> >> for those other platforms there will be a delay waiting for user-mode
>> >> helper to fail, before trying to get nvs file from /lib/firmware.
>> >
>> > Yes, there will be. But there is no easy way to fix this problem that
>> > kernel is trying to use default/example NVS data...
>>
>> Kernel is doing correctly and requesting NVS data as expected, the
>> problem here is that linux-firmware claims that the example NVS data is
>> real calibration data (which it is not). Distros should not use that,
>> only developers for testing purposes. We should not courage users using
>> example calibration data.
>>
>> The simple fix is to rename the NVS file in linux-firmware to something
>> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
>> you send a patch to linux-firmware I'm happy to ack that.
>
> I agree with rename and fact that default/example data should not be
> used.
>
> But...
>
> 1) Kernel should not read device/model specific data from VFS where
> are stored not-device-specific files preinstalled by linux
> distributions.
>
> And linux distributions are already putting files into VFS and kernel
> cannot enforce userspace to not do that (as they are already doing it).
I'm having problems to understand what you are saying here.
> 2) It was already tested that example NVS data can be used for N900 e.g.
> for SSH connection. If real correct data are not available it is better
> to use at least those example (and probably log warning message) so user
> can connect via SSH and start investigating where is problem.
I disagree. Allowing default calibration data to be used can be
unnoticed by user and left her wondering why wifi works so badly.
> 3) If we do rename *now* we will totally break wifi support on Nokia
> N900.
Then the distro should fix that when updating the linux-firmware
packages. Can you provide details about the setup, what distro etc?
--
Kalle Valo
^ permalink raw reply
* [PATCH] stmmac: Discard masked flags in interrupt status register
From: Alexey Brodkin @ 2017-01-27 12:24 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, Alexey Brodkin, Giuseppe Cavallaro, Fabrice Gasnier,
Joachim Eastwood, Phil Reid, David Miller, Alexandre Torgue,
Vineet Gupta
DW GMAC databook says the following about bits in "Register 15 (Interrupt
Mask Register)":
--------------------------->8-------------------------
When set, this bit __disables_the_assertion_of_the_interrupt_signal__
because of the setting of XXX bit in Register 14 (Interrupt
Status Register).
--------------------------->8-------------------------
In fact even if we mask one bit in the mask register it doesn't prevent
corresponding bit to appear in the status register, it only disables
interrupt generation for corresponding event.
But currently we expect a bit different behavior: status bits to be in
sync with their masks, i.e. if mask for bit A is set in the mask
register then bit A won't appear in the interrupt status register.
This was proven to be incorrect assumption, see discussion here [1].
That misunderstanding causes unexpected behaviour of the GMAC, for
example we were happy enough to just see bogus messages about link
state changes.
So from now on we'll be only checking bits that really may trigger an
interrupt.
[1] https://lkml.org/lkml/2016/11/3/413
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Joachim Eastwood <manabian@gmail.com>
Cc: Phil Reid <preid@electromag.com.au>
Cc: David Miller <davem@davemloft.net>
Cc: Alexandre Torgue <alexandre.torgue@gmail.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index be3c91c7f211..5484fd726d5a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -305,8 +305,12 @@ static int dwmac1000_irq_status(struct mac_device_info *hw,
{
void __iomem *ioaddr = hw->pcsr;
u32 intr_status = readl(ioaddr + GMAC_INT_STATUS);
+ u32 intr_mask = readl(ioaddr + GMAC_INT_MASK);
int ret = 0;
+ /* Discard masked bits */
+ intr_status &= ~intr_mask;
+
/* Not used events (e.g. MMC interrupts) are not handled. */
if ((intr_status & GMAC_INT_STATUS_MMCTIS))
x->mmc_tx_irq_n++;
--
2.7.4
^ permalink raw reply related
* Re: [BUG/RFC] vhost: net: big endian viring access despite virtio 1
From: Halil Pasic @ 2017-01-27 12:24 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, netdev, Greg Kurz, virtualization@lists.linux-foundation.org
In-Reply-To: <20170126211511-mutt-send-email-mst@kernel.org>
On 01/26/2017 08:20 PM, Michael S. Tsirkin wrote:
> On Thu, Jan 26, 2017 at 06:39:14PM +0100, Halil Pasic wrote:
>>
>> Hi!
>>
>> Recently I have been investigating some strange migration problems on
>> s390x.
>>
>> It turned out under certain circumstances vhost_net corrupts avail.idx by
>> using wrong endianness.
[..]
>> -------------------------8<--------------
>> >From b26e2bbdc03832a0204ee2b42967a1b49a277dc8 Mon Sep 17 00:00:00 2001
>> From: Halil Pasic <pasic@linux.vnet.ibm.com>
>> Date: Thu, 26 Jan 2017 00:06:15 +0100
>> Subject: [PATCH] vhost: remove useless/dangerous reset of is_le
>>
>> The reset of is_le does no good, but it contributes its fair share to a
>> bug in vhost_net, which occurs if we have some oldubufs when stopping and
>> setting a fd = -1 as a backend. Instead of doing something convoluted in
>> vhost_net, let's just get rid of the reset.
>>
>> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
>> Fixes: commit 2751c9882b94
>> ---
>> drivers/vhost/vhost.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>> index d643260..08072a2 100644
>> --- a/drivers/vhost/vhost.c
>> +++ b/drivers/vhost/vhost.c
>> @@ -1714,10 +1714,8 @@ int vhost_vq_init_access(struct vhost_virtqueue *vq)
>> int r;
>> bool is_le = vq->is_le;
>>
>> - if (!vq->private_data) {
>> - vhost_reset_is_le(vq);
>> + if (!vq->private_data)
>> return 0;
>> - }
>>
>> vhost_init_is_le(vq);
>
>
> I think you do need to reset it, just maybe within vhost_init_is_le.
>
> if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
> vq->is_le = true;
> else
> vhost_reset_is_le(vq);
>
>
That is a very good point! I have overlooked that while the
CONFIG_VHOST_CROSS_ENDIAN_LEGACY variant
static void vhost_init_is_le(struct vhost_virtqueue *vq)
{
/* Note for legacy virtio: user_be is initialized at reset time
* according to the host endianness. If userspace does not set an
* explicit endianness, the default behavior is native endian, as
* expected by legacy virtio.
*/
vq->is_le = vhost_has_feature(vq, VIRTIO_F_VERSION_1) || !vq->user_be;
}
is fine the other variant
static void vhost_init_is_le(struct vhost_virtqueue *vq)
{
if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
vq->is_le = true;
}
is a very strange initializer (makes assumptions about the state
to be initialized).
I agree, setting native endianness there sounds very reasonable.
I have a question regarding readability. IMHO the relationship
of reset_is_le and int_is_le is a bit confusing, and I'm afraid
it could become even more confusing with using reset in one of
the init_is_le's.
How about we do the following?
static void vhost_init_is_le(struct vhost_virtqueue *vq)
{
if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
vq->is_le = true;
+ else
+ vq->is_le = virtio_legacy_is_little_endian();
}
static void vhost_reset_is_le(struct vhost_virtqueue *vq)
{
- vq->is_le = virtio_legacy_is_little_endian();
+ vhost_init_is_le(vq);
}
That way we would have correct endianness both after reset
and after init, I think :).
Thank you very much!
Halil
^ permalink raw reply
* Re: [PATCH v2 net] net: free ip_vs_dest structs when refcnt=0
From: Pablo Neira Ayuso @ 2017-01-27 12:21 UTC (permalink / raw)
To: Simon Horman
Cc: Julian Anastasov, David Windsor, netdev, kernel-hardening,
netfilter-devel, lvs-devel, wensong, keescook, elena.reshetova,
ishkamiel
In-Reply-To: <20170127080738.GD21195@verge.net.au>
On Fri, Jan 27, 2017 at 09:07:38AM +0100, Simon Horman wrote:
> On Thu, Jan 26, 2017 at 10:49:10PM +0200, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Mon, 23 Jan 2017, David Windsor wrote:
> >
> > > Currently, the ip_vs_dest cache frees ip_vs_dest objects when their
> > > reference count becomes < 0. Aside from not being semantically sound,
> > > this is problematic for the new type refcount_t, which will be introduced
> > > shortly in a separate patch. refcount_t is the new kernel type for
> > > holding reference counts, and provides overflow protection and a
> > > constrained interface relative to atomic_t (the type currently being
> > > used for kernel reference counts).
> > >
> > > Per Julian Anastasov: "The problem is that dest_trash currently holds
> > > deleted dests (unlinked from RCU lists) with refcnt=0." Changing
> > > dest_trash to hold dest with refcnt=1 will allow us to free ip_vs_dest
> > > structs when their refcnt=0, in ip_vs_dest_put_and_free().
> > >
> > > Signed-off-by: David Windsor <dwindsor@gmail.com>
> >
> > Thanks! I tested the first version and this one
> > just adds the needed changes in comments, so
> >
> > Signed-off-by: Julian Anastasov <ja@ssi.bg>
> >
> > Simon and Pablo, this is more appropriate for
> > ipvs-next/nf-next. Please apply!
>
> Pablo, would you mind taking this one directly into nf-next?
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
Sure, no problem. I'll take it. Thanks!
^ permalink raw reply
* Re: [PATCH net-next 0/2] ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W
From: Geert Uytterhoeven @ 2017-01-27 12:16 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, Sergei Shtylyov, Magnus Damm,
netdev@vger.kernel.org, Linux-Renesas
In-Reply-To: <1485515090-7570-1-git-send-email-horms+renesas@verge.net.au>
Hi Simon,
On Fri, Jan 27, 2017 at 12:04 PM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> The path from Mizuguchi-san is to address timing problems observed with
> gigabit transfers. I would like it considered although my own testing on
> M3-W did not show any timing problems.
Is there any relation with the *-skew-ps properties in the DTS in the BSP?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pavel Machek @ 2017-01-27 12:03 UTC (permalink / raw)
To: Pali Rohár
Cc: Arend Van Spriel, Kalle Valo, Ming Lei, Luis R. Rodriguez,
Greg Kroah-Hartman, David Gnedt, Michal Kazior, Daniel Wagner,
Tony Lindgren, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127101043.GD24223@pali>
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
Hi!
> > You are probably saying that on your platform you can not remove
> > anything from /lib/firmware, right? I don't see how you come from "it is
> > part of firmware package" to "removing is not possible". Trying to
> > understand this and it makes no sense.
>
> It is already in linux distribution packages. If I remove that file from
> file system it will be placed there again by package management or it it
> will throw error message about system integrity (missing file, etc...).
>
> Also that file is already in linux-firmware git and so is propagated to
> /lib/firmware by anybody who is using linux-firmware.
>
> > >> Like we discussed earlier, the default nvs file should not be used by
> > >> normal users.
> > >
> > > But already is and we need to deal with this fact.
> >
> > Why?
>
> Because everybody has already installed it.
>
> > Are there other platforms that use the default nvs file and have a
> > working wifi.
>
> I do not know.
>
> > So your "removing is not possible" would be about
> > regression for those?
>
> Yes, that is possible.
>
> Also you can use wifi on Nokia N900 with this default file. Yes it is
> not recommended and probably has performance problems... but more people
> use it for SSH and it is working. Pavel could confirm this.
Yes, wifi somehow works on N900. .. depending on userspace and kernel
versions.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 11:57 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <87bmus7mfk.fsf@kamboji.qca.qualcomm.com>
On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> >> So
> >> for those other platforms there will be a delay waiting for user-mode
> >> helper to fail, before trying to get nvs file from /lib/firmware.
> >
> > Yes, there will be. But there is no easy way to fix this problem that
> > kernel is trying to use default/example NVS data...
>
> Kernel is doing correctly and requesting NVS data as expected, the
> problem here is that linux-firmware claims that the example NVS data is
> real calibration data (which it is not). Distros should not use that,
> only developers for testing purposes. We should not courage users using
> example calibration data.
>
> The simple fix is to rename the NVS file in linux-firmware to something
> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
> you send a patch to linux-firmware I'm happy to ack that.
I agree with rename and fact that default/example data should not be
used.
But...
1) Kernel should not read device/model specific data from VFS where
are stored not-device-specific files preinstalled by linux
distributions.
And linux distributions are already putting files into VFS and kernel
cannot enforce userspace to not do that (as they are already doing it).
2) It was already tested that example NVS data can be used for N900 e.g.
for SSH connection. If real correct data are not available it is better
to use at least those example (and probably log warning message) so user
can connect via SSH and start investigating where is problem.
3) If we do rename *now* we will totally break wifi support on Nokia
N900.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-27 11:49 UTC (permalink / raw)
To: Pali Rohár
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127103408.GG24223@pali>
Pali Rohár <pali.rohar@gmail.com> writes:
>> So
>> for those other platforms there will be a delay waiting for user-mode
>> helper to fail, before trying to get nvs file from /lib/firmware.
>
> Yes, there will be. But there is no easy way to fix this problem that
> kernel is trying to use default/example NVS data...
Kernel is doing correctly and requesting NVS data as expected, the
problem here is that linux-firmware claims that the example NVS data is
real calibration data (which it is not). Distros should not use that,
only developers for testing purposes. We should not courage users using
example calibration data.
The simple fix is to rename the NVS file in linux-firmware to something
like wl1251-nvs.bin.example, no need to workaround this in kernel. If
you send a patch to linux-firmware I'm happy to ack that.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH iproute2 1/1] tc: distinguish Add/Replace action operations.
From: Phil Sutter @ 2017-01-27 11:37 UTC (permalink / raw)
To: Roman Mashak; +Cc: stephen, netdev, Jamal Hadi Salim
In-Reply-To: <1485093333-18317-1-git-send-email-mrv@mojatatu.com>
On Sun, Jan 22, 2017 at 08:55:33AM -0500, Roman Mashak wrote:
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Phil Sutter <phil@nwl.cc>
^ permalink raw reply
* Re: [PATCH net-next 2/3] sfc: refactor debug-or-warnings printks
From: Edward Cree @ 2017-01-27 11:34 UTC (permalink / raw)
To: David Miller; +Cc: linux-net-drivers, netdev
In-Reply-To: <20170126.143629.337763461510725581.davem@davemloft.net>
On 26/01/17 19:36, David Miller wrote:
> From: Edward Cree <ecree@solarflare.com>
> Date: Thu, 26 Jan 2017 17:53:48 +0000
>
>> diff --git a/drivers/net/ethernet/sfc/net_driver.h b/drivers/net/ethernet/sfc/net_driver.h
>> index 5927c20..c640955 100644
>> --- a/drivers/net/ethernet/sfc/net_driver.h
>> +++ b/drivers/net/ethernet/sfc/net_driver.h
>> @@ -51,6 +51,15 @@
>> #define EFX_WARN_ON_PARANOID(x) do {} while (0)
>> #endif
>>
>> +/* if @cond then downgrade to debug, else print at @level */
>> +#define netif_cond_dbg(priv, type, netdev, cond, level, fmt, args...) \
>> + do { \
>> + if (cond) \
>> + netif_dbg(priv, type, netdev, fmt, ##args); \
>> + else \
>> + netif_ ## level(priv, type, netdev, fmt, ##args); \
>> + } while (0)
>> +
>> /**************************************************************************
>> *
>> * Efx data structures
>>
> Please do not define locally in a driver an interface that looks like a generic
> one and might be useful to code outside of your driver.
>
> Thanks.
Sure. I'll put this in netdevice.h and respin.
-Ed
^ permalink raw reply
* [PATCH] Net: ethernet: mediatek - Fix possible NULL derefrence.
From: Shailendra Verma @ 2017-01-27 11:19 UTC (permalink / raw)
To: Felix Fietkau, John Crispin, Matthias Brugger, netdev,
linux-arm-kernel, linux-mediatek, linux-kernel, p.shailesh,
ashish.kalra, Shailendra Verma, Shailendra Verma
In-Reply-To: <CGME20170127111947epcas2p14f5ea86f0069142be02339754fda4a55@epcas2p1.samsung.com>
of_match_device could return NULL, and so can cause a NULL
pointer dereference later.
Signed-off-by: Shailendra Verma <shailendra.v@samsung.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 4a62ffd..4495b7b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2369,6 +2369,10 @@ static int mtk_probe(struct platform_device *pdev)
int i;
match = of_match_device(of_mtk_match, &pdev->dev);
+ if (!match) {
+ dev_err(&pdev->dev, "Error: No device match found\n");
+ return -ENODEV;
+ }
soc = (struct mtk_soc_data *)match->data;
eth = devm_kzalloc(&pdev->dev, sizeof(*eth), GFP_KERNEL);
--
1.7.9.5
^ permalink raw reply related
* [iproute PATCH] man: tc-csum.8: Fix example
From: Phil Sutter @ 2017-01-27 11:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
This fixes two issues with the provided example:
- Add missing 'dev' keyword to second command.
- Use a real IPv4 address instead of a bogus hex value since that will
be rejected by get_addr_ipv4().
Fixes: dbfb17a67f9c7 ("man: tc-csum.8: Add an example")
Reported-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
man/man8/tc-csum.8 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/man/man8/tc-csum.8 b/man/man8/tc-csum.8
index 3a64c82f09ba8..43561d9f90a8e 100644
--- a/man/man8/tc-csum.8
+++ b/man/man8/tc-csum.8
@@ -57,9 +57,9 @@ packets, both IP and UDP checksums have to be recalculated:
.RS
.EX
# tc qdisc add dev eth0 ingress handle ffff:
-# tc filter add eth0 prio 1 protocol ip parent ffff: \\
+# tc filter add dev eth0 prio 1 protocol ip parent ffff: \\
u32 match ip src 192.168.1.100/32 flowid :1 \\
- action pedit munge ip dst set 0x12345678 pipe \\
+ action pedit munge ip dst set 1.2.3.4 pipe \\
csum ip and udp
.EE
.RE
--
2.11.0
^ permalink raw reply related
* RE: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
From: Rafal Ozieblo @ 2017-01-27 11:06 UTC (permalink / raw)
To: Nicolas Ferre, Harini Katakam
Cc: tbultel@pixelsurmer.com, boris.brezillon@free-electrons.com,
netdev@vger.kernel.org, alexandre.belloni@free-electrons.com,
linux-kernel@vger.kernel.org, richardcochran@gmail.com,
Andrei Pistirica, michals@xilinx.com, anirudh@xilinx.com,
punnaia@xilinx.com, harini.katakam@xilinx.com,
davem@davemloft.net, linux-arm-kernel@lists.infradead.org
In-Reply-To: <779c1540-f4da-90ee-1fa1-c94339a892aa@atmel.com>
>-----Original Message-----
>From: Nicolas Ferre [mailto:nicolas.ferre@atmel.com]
>Sent: 27 stycznia 2017 11:28
>Subject: Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
>
>Le 27/01/2017 à 11:26, Rafal Ozieblo a écrit :
>>> -----Original Message-----
>>> From: Harini Katakam [mailto:harinikatakamlinux@gmail.com]
>>> Sent: 27 stycznia 2017 06:43
>>> Subject: Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
>>>
>>> Hi Rafal,
>>>
>>> On Thu, Jan 26, 2017 at 8:45 PM, Rafal Ozieblo <rafalo@cadence.com> wrote:
>>>>> -----Original Message-----
>>>>> From: Andrei Pistirica [mailto:andrei.pistirica@microchip.com]
>>>>> Sent: 19 stycznia 2017 16:56
>>>>> Subject: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
>>>>>
>>>>>
>>>>> +static inline bool gem_has_ptp(struct macb *bp)
>>>>> +{
>>>>> + return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP);
>>>>> +}
>>>> Why don't you use hardware capabilities here? Would it be better to read it from hardware instead adding it to many configuration?
>>>
>>> If you are referring to TSU bit in DCFG5, then we will be relying on
>>> Cadence IP's information irrespective of the SoC capability
>>> and whether the PTP support was adequate.
>>> I think the capability approach gives better control and
>>> it is not really much to add.
>>>
>>> Regards,
>>> Harini
>>>
>> Yes, I'm referring to TSU bit.
>> What if SoC contains multiple Cadence GEMs, some with PTP support and others without?
>
>Simply define different DT compatibility strings and we're good.
What with GEM on PCI ? There is no DT.
>> Relevant will be checking both, hardware capabilities and SoC capabilities from "caps" field.
>>
>
>
>--
>Nicolas Ferre
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next 1/2] ravb: Add tx and rx clock internal delays mode of APSR
From: Simon Horman @ 2017-01-27 11:04 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Kazuya Mizuguchi,
Simon Horman
In-Reply-To: <1485515090-7570-1-git-send-email-horms+renesas@verge.net.au>
From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
This patch enables tx and rx clock internal delay modes (TDM and RDM).
This is to address a failure in the case of 1Gbps communication using the
by salvator-x board with the KSZ9031RNX phy. This has been reported to
occur with both the r8a7795 (H3) and r8a7796 (M3-W) SoCs.
With this change APSR internal delay modes are enabled for
"rgmii-id", "rgmii-rxid" and "rgmii-txid" phy modes as follows:
phy mode | ASPR delay mode
-----------+----------------
rgmii-id | TDM and RDM
rgmii-rxid | RDM
rgmii-txid | TDM
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v1 [Simon Horman]
- Combined patches
- Reworded changelog
v0 [Kazuya Mizuguchi]
---
drivers/net/ethernet/renesas/ravb.h | 10 ++++++++++
drivers/net/ethernet/renesas/ravb_main.c | 29 +++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index f1109661a533..d7c91d48cc48 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -76,6 +76,7 @@ enum ravb_reg {
CDAR20 = 0x0060,
CDAR21 = 0x0064,
ESR = 0x0088,
+ APSR = 0x008C, /* R-Car Gen3 only */
RCR = 0x0090,
RQC0 = 0x0094,
RQC1 = 0x0098,
@@ -248,6 +249,15 @@ enum ESR_BIT {
ESR_EIL = 0x00001000,
};
+/* APSR */
+enum APSR_BIT {
+ APSR_MEMS = 0x00000002,
+ APSR_CMSW = 0x00000010,
+ APSR_DM = 0x00006000,
+ APSR_DM_RDM = 0x00002000,
+ APSR_DM_TDM = 0x00004000,
+};
+
/* RCR */
enum RCR_BIT {
RCR_EFFS = 0x00000001,
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 89ac1e3f6175..9fb4c04c5885 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1904,6 +1904,29 @@ static void ravb_set_config_mode(struct net_device *ndev)
}
}
+static void ravb_set_delay_mode(struct net_device *ndev)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+
+ if (priv->chip_id != RCAR_GEN2) {
+ switch (priv->phy_interface) {
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ ravb_modify(ndev, APSR, APSR_DM, APSR_DM_RDM |
+ APSR_DM_TDM);
+ break;
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ ravb_modify(ndev, APSR, APSR_DM, APSR_DM_RDM);
+ break;
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ ravb_modify(ndev, APSR, APSR_DM, APSR_DM_TDM);
+ break;
+ default:
+ ravb_modify(ndev, APSR, APSR_DM, 0);
+ break;
+ }
+ }
+}
+
static int ravb_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -2016,6 +2039,9 @@ static int ravb_probe(struct platform_device *pdev)
/* Request GTI loading */
ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
+ /* Set APSR */
+ ravb_set_delay_mode(ndev);
+
/* Allocate descriptor base address table */
priv->desc_bat_size = sizeof(struct ravb_desc) * DBAT_ENTRY_NUM;
priv->desc_bat = dma_alloc_coherent(ndev->dev.parent, priv->desc_bat_size,
@@ -2152,6 +2178,9 @@ static int __maybe_unused ravb_resume(struct device *dev)
/* Request GTI loading */
ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
+ /* Set APSR */
+ ravb_set_delay_mode(ndev);
+
/* Restore descriptor base address table */
ravb_write(ndev, priv->desc_bat_dma, DBAT);
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
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