Re: [PATCH net v2] drivers/net/wan/hdlc_fr: Add needed_headroom for PVC devices
Xie He writes: > The HDLC device is not actually prepending any header when it is used > with this driver. When the PVC device has prepended its header and > handed over the skb to the HDLC device, the HDLC device just hands it > over to the hardware driver for transmission without prepending any > header. That's correct. IIRC: - Cisco and PPP modes add 4 bytes - Frame Relay adds 4 (specific protocols - mostly IPv4) or 10 (general case) bytes. There is that pvcX->hdlcX transition which adds nothing (the header is already in place when the packet leaves pvcX device). - Raw mode adds nothing (IPv4 only, though it could be modified for both IPv4/v6 easily) - Ethernet (hdlc_raw_eth.c) adds normal Ethernet header. (I had been "unplugged" for some time). -- Krzysztof Halasa Sieć Badawcza Łukasiewicz Przemysłowy Instytut Automatyki i Pomiarów PIAP Al. Jerozolimskie 202, 02-486 Warszawa
Re: [PATCH net] drivers/net/wan/hdlc_cisco: Add hard_header_len
Hello Xie,
Xie He writes:
> This driver didn't set hard_header_len. This patch sets hard_header_len
> for it according to its header_ops->create function.
BTW it's 4 bytes long:
struct hdlc_header {
u8 address;
u8 control;
__be16 protocol;
}__packed;
OTOH hdlc_setup_dev() initializes hard_header_len to 16,
but in this case I guess 4 bytes are better.
Acked-by: Krzysztof Halasa
> Cc: Martin Schiller
> Signed-off-by: Xie He
> ---
> --- a/drivers/net/wan/hdlc_cisco.c
> +++ b/drivers/net/wan/hdlc_cisco.c
> @@ -370,6 +370,7 @@ static int cisco_ioctl(struct net_device *dev, struct
> ifreq *ifr)
> memcpy(&state(hdlc)->settings, &new_settings, size);
> spin_lock_init(&state(hdlc)->lock);
> dev->header_ops = &cisco_header_ops;
> + dev->hard_header_len = sizeof(struct hdlc_header);
> dev->type = ARPHRD_CISCO;
> call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE, dev);
> netif_dormant_on(dev);
--
Krzysztof Halasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
Re: [PATCH] net: Use dma_pool_zalloc()
Souptick Joarder writes: > Any comment for this patch. I thought something like this was already aplied. Acked-by: Krzysztof Halasa > On Fri, Feb 16, 2018 at 9:58 PM, Souptick Joarder > wrote: >> Use dma_pool_zalloc() instead of dma_pool_alloc + memset >> >> Signed-off-by: Souptick Joarder >> --- >> drivers/net/ethernet/xscale/ixp4xx_eth.c | 3 +-- >> drivers/net/wan/ixp4xx_hss.c | 3 +-- >> 2 files changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c >> b/drivers/net/ethernet/xscale/ixp4xx_eth.c >> index aee55c0..5710ae8 100644 >> --- a/drivers/net/ethernet/xscale/ixp4xx_eth.c >> +++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c >> @@ -1108,10 +1108,9 @@ static int init_queues(struct port *port) >> return -ENOMEM; >> } >> >> - if (!(port->desc_tab = dma_pool_alloc(dma_pool, GFP_KERNEL, >> + if (!(port->desc_tab = dma_pool_zalloc(dma_pool, GFP_KERNEL, >> &port->desc_tab_phys))) >> return -ENOMEM; >> - memset(port->desc_tab, 0, POOL_ALLOC_SIZE); >> memset(port->rx_buff_tab, 0, sizeof(port->rx_buff_tab)); /* tables */ >> memset(port->tx_buff_tab, 0, sizeof(port->tx_buff_tab)); >> >> diff --git a/drivers/net/wan/ixp4xx_hss.c b/drivers/net/wan/ixp4xx_hss.c >> index 6a505c2..0caffbf 100644 >> --- a/drivers/net/wan/ixp4xx_hss.c >> +++ b/drivers/net/wan/ixp4xx_hss.c >> @@ -976,10 +976,9 @@ static int init_hdlc_queues(struct port *port) >> return -ENOMEM; >> } >> >> - if (!(port->desc_tab = dma_pool_alloc(dma_pool, GFP_KERNEL, >> + if (!(port->desc_tab = dma_pool_zalloc(dma_pool, GFP_KERNEL, >> &port->desc_tab_phys))) >> return -ENOMEM; >> - memset(port->desc_tab, 0, POOL_ALLOC_SIZE); >> memset(port->rx_buff_tab, 0, sizeof(port->rx_buff_tab)); /* tables */ >> memset(port->tx_buff_tab, 0, sizeof(port->tx_buff_tab)); >> -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Re: [PATCH 4.9.0-rc5] AR9300 calibration problems with antenna selected
miaoq...@codeaurora.org writes: >> rmmod ath9k >> modprobe ath9k >> iw dev wlan0 set type ibss >> iw phy phyX set antenna 2 > > 2 is a bad mask. We use bitmap, the valid masks are 1, 3, 7. Thanks for your response. I have two antenna connections (and a single antenna). Is it possible to select the secondary antenna connector only? How? -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
[PATCH 4.9.0-rc5] AR9300 calibration problems with antenna selected
Hi, I recently tried to select a single antenna on AR9300 and it works for 30 seconds only. The subsequent calibration makes the RX signal level to drop from the usual -30/-40 dBm to -70/-80 dBm, and the transmission practically stops. With the attached patch it works, though selecting the antenna doesn't seem to have any visible effect, at least with "iw wlanX station dump" (perhaps it works for TX). I'm using ad-hoc mode: rmmod ath9k modprobe ath9k iw dev wlan0 set type ibss iw phy phyX set antenna 2 ip link set up dev wlan0 iw dev wlan0 set bitrates legacy-2.4 18 iw dev wlan0 ibss join nameXXX freqYYY ip addr add ZZZ broadcast + dev wlan0 The card in question is Mikrotik (Routerboard) R11e-2HPnD mPCIe adapter: AR9580 Wireless Network Adapter (rev 01), ID 168c:0033, subsystem 19b6:d016. ieee80211 phy0: Atheros AR9300 Rev:4 mem=0xc0f4, irq=334 https://routerboard.com/R11e-2HPnD Linux 4.9.0-rc5. Is there a better way? Signed-off-by: Krzysztof Halasa diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c index e9f32b5..7f17e5d 100644 --- a/drivers/net/wireless/ath/ath9k/main.c +++ b/drivers/net/wireless/ath/ath9k/main.c @@ -2245,7 +2245,7 @@ static int ath9k_set_antenna(struct ieee80211_hw *hw, u32 tx_ant, u32 rx_ant) return 0; /* AR9100 runs into calibration issues if not all rx chains are enabled */ - if (AR_SREV_9100(ah)) + if (AR_SREV_9100(ah) || AR_SREV_9300(ah)) ah->rxchainmask = 0x7; else ah->rxchainmask = fill_chainmask(ah->caps.rx_chainmask, rx_ant); -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Re: [PATCH net-next 3/6] net: use core MTU range checking in WAN drivers
Jarod Wilson writes: > - set min/max_mtu in all hdlc drivers, remove hdlc_change_mtu > - sent max_mtu in lec driver, remove lec_change_mtu > drivers/net/wan/c101.c| 1 - > drivers/net/wan/hdlc.c| 11 ++- > drivers/net/wan/hdlc_fr.c | 3 ++- > drivers/net/wan/ixp4xx_hss.c | 1 - > drivers/net/wan/n2.c | 1 - > drivers/net/wan/pc300too.c| 1 - > drivers/net/wan/pci200syn.c | 1 - > drivers/net/wan/wanxl.c | 1 - > include/linux/hdlc.h | 2 -- Acked-by: Krzysztof Halasa -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Re: Aw: BUG: Wrong dma queue handling in ixp4 driver
Hi Lino, "Lino Sanfilippo" writes: >> maybe I miss something, but the ixp4 ethernet driver seems to handle dma >> pools >> in a wrong way: In init_queues() it creates a dma pool for descriptors and >> then >> only allocates a single descriptor from this pool. The author seems to >> assume the whole >> table has been allocated already, since after that the complete pool size is >> zeroed: >> > > Sorry, I indeed missed something. The allocation is correct. A pool is not > required, though, > since only one chunk is allocated. Not really: there is one pool for all ports, but each port uses a separate desc_tab (allocated from that pool). -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Re: [PATCH] I.MX6: Fix Ethernet PHY mode on Ventana boards
David Miller writes: > Since this only touched DT files in the ARM platform code, maybe > the ARM tree is the best path for this patch rather than mine? I think so. Tim, would you like to handle this patch yourself, or should I send it to the ARM contacts? -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] I.MX6: Fix Ethernet PHY mode on Ventana boards
Tim Harvey writes:
> It sounds like your saying this controls whether the phy is in charge
> of delay vs the MAC. I have never needed to set this and haven't found
> where its actually used (in at least 4.3). Is this caused by something
> new in the kernel I haven't seen yet or is it possible you have board
> that has an Ethernet issue?
I think you aren't using the Marvell PHY driver :-)
The existing DTS files work fine with the "default" PHY driver.
It's only the Marvell driver (drivers/net/phy/marvell.c, aka
CONFIG_MARVELL_PHY) which have the issue.
The problem is caused by the following code in m88e1121_config_aneg():
if (phy_interface_is_rgmii(phydev)) {
mscr = phy_read(phydev, MII_88E1121_PHY_MSCR_REG) &
MII_88E1121_PHY_MSCR_DELAY_MASK;
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
mscr |= (MII_88E1121_PHY_MSCR_RX_DELAY |
MII_88E1121_PHY_MSCR_TX_DELAY);
else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
mscr |= MII_88E1121_PHY_MSCR_RX_DELAY;
else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
mscr |= MII_88E1121_PHY_MSCR_TX_DELAY;
err = phy_write(phydev, MII_88E1121_PHY_MSCR_REG, mscr);
if (err < 0)
return err;
}
mscr initially holds the correct value (one with RX_DELAY and TX_DELAY
bits set). Since the _*ID are not specified, these bits are reset and
(now incorrect) value is written back to the register.
OTOH the generic PHY driver knows nothing about the MSCR and thus
doesn't "corrupt" it.
The whole -ID thing is about signal trace lengths (on PCB), where the
non-ID setup requires special, longer traces for certain signals to
compensate for propagation times etc. The -ID version does it internally
(when enabled) and the PCB layout can be a bit simpler.
To be honest I only checked it on a single GW5400 rev. C, but I'd expect
it to be exactly the same across all GW5[234]*. Can test on GW5[23] if
there is any doubt (in few days I guess).
This issue doesn't show itself on Yocto and OpenWrt, because they
apparently don't enable marvell PHY driver. Fedora 23 does and it
doesn't work (this probably means it could be worth it to push it to
stable).
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] I.MX6: Fix Ethernet PHY mode on Ventana boards
Gateworks Ventana boards seem to need "RGMII-ID" (internal delay)
PHY mode, instead of simple "RGMII", for their Marvell 88E1510
transceiver. Otherwise, the Ethernet MAC doesn't work with Marvell PHY
driver (TX doesn't seem to work correctly).
Tested on GW5400 rev. C.
This bug affects ARM Fedora 23.
Signed-off-by: Krzysztof Hałasa
diff --git a/arch/arm/boot/dts/imx6q-gw5400-a.dts
b/arch/arm/boot/dts/imx6q-gw5400-a.dts
index 822ffb2..6c168dc 100644
--- a/arch/arm/boot/dts/imx6q-gw5400-a.dts
+++ b/arch/arm/boot/dts/imx6q-gw5400-a.dts
@@ -154,7 +154,7 @@
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-reset-gpios = <&gpio1 30 GPIO_ACTIVE_HIGH>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
index f2867c4..90496aa 100644
--- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
@@ -94,7 +94,7 @@
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index 4493f6e..0a6730b 100644
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@ -154,7 +154,7 @@
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index cfad214..2c549ad 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -174,7 +174,7 @@
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index 535b536..b4ea087 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -164,7 +164,7 @@
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ixp4xx_hss: Delete an unnecessary check before the function call "dma_pool_destroy"
SF Markus Elfring writes:
> The dma_pool_destroy() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
> --- a/drivers/net/wan/ixp4xx_hss.c
> +++ b/drivers/net/wan/ixp4xx_hss.c
> @@ -1037,7 +1037,7 @@ static void destroy_hdlc_queues(struct port *port)
> port->desc_tab = NULL;
> }
>
> - if (!ports_open && dma_pool) {
> + if (!ports_open) {
> dma_pool_destroy(dma_pool);
> dma_pool = NULL;
> }
Acked-by: Krzysztof Halasa
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ixp4xx_eth: Delete an unnecessary check before the function call "dma_pool_destroy"
SF Markus Elfring writes:
> The dma_pool_destroy() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
> --- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
> +++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
> @@ -1192,7 +1192,7 @@ static void destroy_queues(struct port *port)
> port->desc_tab = NULL;
> }
>
> - if (!ports_open && dma_pool) {
> + if (!ports_open) {
> dma_pool_destroy(dma_pool);
> dma_pool = NULL;
> }
Acked-by: Krzysztof Halasa
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
