On 13.04.2021 22:59, Xose Vazquez Perez wrote:
> A non-recurring bug, on 5.11.12-300.fc34.x86_64 (Fedora kernel).
>
> Thanks.
>
>
> 0c:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
>
> [
On 09.04.2021 20:41, Radu Pirea (NXP OSS) wrote:
> Add driver for tja1103 driver and for future NXP C45 PHYs.
>
> Signed-off-by: Radu Pirea (NXP OSS)
> ---
> MAINTAINERS | 6 +
> drivers/net/phy/Kconfig | 6 +
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/nxp-c45.c
On 08.04.2021 20:35, Sven Van Asbroeck wrote:
> Hi George,
>
> On Thu, Apr 8, 2021 at 2:26 PM Sven Van Asbroeck wrote:
>>
>> George, I will send a patch for you to try shortly. Except if you're
>> already ahead :)
>
> Would this work for you? It does for me.
>
> diff --git
On 08.04.2021 20:00, George McCollister wrote:
> On Thu, Apr 8, 2021 at 12:46 PM Sven Van Asbroeck wrote:
>>
>> Hi George,
>>
>> On Thu, Apr 8, 2021 at 1:36 PM George McCollister
>> wrote:
>>>
>>> Can you explain the difference in behavior with what I was observing
>>> on the LAN7431?
>>
>> I'm
On 08.04.2021 19:23, Sven Van Asbroeck wrote:
> From: Sven Van Asbroeck
>
> This reverts commit 3e21a10fdea3c2e4e4d1b72cb9d720256461af40.
>
> The reverted patch completely breaks all network connectivity on the
> lan7430. tcpdump indicates missing bytes when receiving ping
> packets from an
On 07.04.2021 12:05, Joakim Zhang wrote:
>
> Hi Heiner,
>
>> -Original Message-
>> From: Joakim Zhang
>> Sent: 2021年4月7日 15:46
>> To: Heiner Kallweit ; christian.me...@t2data.com;
>> and...@lunn.ch; li...@armlinux.org.uk; da...@davem
On 07.04.2021 03:43, Joakim Zhang wrote:
>
> Hi Heiner,
>
>> -Original Message-
>> From: Heiner Kallweit
>> Sent: 2021年4月7日 2:22
>> To: Joakim Zhang ; christian.me...@t2data.com;
>> and...@lunn.ch; li...@armlinux.org.uk; da...@davemloft.net;
>&
On 06.04.2021 20:32, Florian Fainelli wrote:
>
>
> On 4/6/2021 4:42 AM, Heiner Kallweit wrote:
>>
>> Waiting for ANEG_COMPLETE to be set wouldn't be a good option. Aneg may never
>> complete for different reasons, e.g. no physical link. And even if we use a
>&
On 06.04.2021 13:42, Heiner Kallweit wrote:
> On 06.04.2021 12:07, Joakim Zhang wrote:
>>
>>> -Original Message-
>>> From: Heiner Kallweit
>>> Sent: 2021年4月6日 14:29
>>> To: Joakim Zhang ; christian.me...@t2data.com;
>>> and...@lunn
On 06.04.2021 12:07, Joakim Zhang wrote:
>
>> -Original Message-
>> From: Heiner Kallweit
>> Sent: 2021年4月6日 14:29
>> To: Joakim Zhang ; christian.me...@t2data.com;
>> and...@lunn.ch; li...@armlinux.org.uk; da...@davemloft.net;
>> k...@kernel.o
On 06.04.2021 04:07, Joakim Zhang wrote:
>
> Hi Heiner,
>
>> -Original Message-
>> From: Heiner Kallweit
>> Sent: 2021年4月5日 20:10
>> To: christian.me...@t2data.com; Joakim Zhang ;
>> and...@lunn.ch; li...@armlinux.org.uk; da...@davem
On 05.04.2021 15:53, Christian Melki wrote:
> On 4/5/21 2:09 PM, Heiner Kallweit wrote:
>> On 05.04.2021 10:43, Christian Melki wrote:
>>> On 4/5/21 12:48 AM, Heiner Kallweit wrote:
>>>> On 04.04.2021 16:09, Heiner Kallweit wrote:
>>>>> On 04.04.
On 05.04.2021 10:43, Christian Melki wrote:
> On 4/5/21 12:48 AM, Heiner Kallweit wrote:
>> On 04.04.2021 16:09, Heiner Kallweit wrote:
>>> On 04.04.2021 12:07, Joakim Zhang wrote:
>>>> commit 4c0d2e96ba055 ("net: phy: consider that suspend2ram may cut
>&
On 04.04.2021 16:09, Heiner Kallweit wrote:
> On 04.04.2021 12:07, Joakim Zhang wrote:
>> commit 4c0d2e96ba055 ("net: phy: consider that suspend2ram may cut
>> off PHY power") invokes phy_init_hw() when MDIO bus resume, it will
>> soft reset PHY if PHY driver
On 04.04.2021 12:07, Joakim Zhang wrote:
> commit 4c0d2e96ba055 ("net: phy: consider that suspend2ram may cut
> off PHY power") invokes phy_init_hw() when MDIO bus resume, it will
> soft reset PHY if PHY driver implements soft_reset callback.
> commit 764d31cacfe4 ("net: phy: micrel: set
On 29.03.2021 11:02, Lv Yunlong wrote:
> In rtl8169_start_xmit, it calls rtl8169_tso_csum_v2(tp, skb, opts) and
> rtl8169_tso_csum_v2() calls __skb_put_padto(skb, padto, false). If
> __skb_put_padto() failed, it will free the skb in the first time and
> return error. Then rtl8169_start_xmit will
On 26.03.2021 22:26, Bjorn Helgaas wrote:
> [+cc Randy, Andrew (though I'm sure you have zero interest in this
> ancient question :))]
>
> On Wed, Dec 09, 2020 at 09:31:21AM +0100, Heiner Kallweit wrote:
>> pci_set_mwi() and pci_try_set_mwi() do exactly the same, just that
On 23.03.2021 17:46, Wong Vee Khee wrote:
> Add generic code to enable C45 PHY loopback into the common phy-c45.c
> file. This will allow C45 PHY drivers aceess this by setting
> .set_loopback.
>
> Suggested-by: Heiner Kallweit
> Signed-off-by: Wong Vee Khee
> ---
> d
On 23.03.2021 09:48, Wong Vee Khee wrote:
> From: Tan Tee Min
>
> Add support for PHY loopback for the Marvell 88E2110 PHY.
>
> This allow user to perform selftest using ethtool.
>
> Signed-off-by: Tan Tee Min
> Signed-off-by: Wong Vee Khee
> ---
> drivers/net/phy/marvell10g.c | 12
On 18.03.2021 10:09, Wong Vee Khee wrote:
> When using Clause-22 to probe for PHY devices such as the Marvell
> 88E2110, PHY ID with value 0 is read from the MII PHYID registers
> which caused the PHY framework failed to attach the Marvell PHY
> driver.
>
> Fixed this by adding a check of PHY ID
0074a-2572-5914-6f3e-77202cbf9...@gmail.com/
>
> Suggested-by: Vladimir Oltean
> Signed-off-by: Michael Walle
> ---
Reviewed-by: Heiner Kallweit
On 18.03.2021 18:04, Vladimir Oltean wrote:
> On Thu, Mar 18, 2021 at 05:38:13PM +0100, Michael Walle wrote:
>> Am 2021-03-18 17:21, schrieb Heiner Kallweit:
>>> On 18.03.2021 16:17, Vladimir Oltean wrote:
>>>> On Thu, Mar 18, 2021 at 03:54:00PM +0100, Heiner Kallweit
On 18.03.2021 17:02, Florian Fainelli wrote:
>
>
> On 3/18/2021 6:25 AM, Heiner Kallweit wrote:
>> On 18.03.2021 10:09, Wong Vee Khee wrote:
>>> When using Clause-22 to probe for PHY devices such as the Marvell
>>> 88E2110, PHY ID with value 0 is read from
On 18.03.2021 16:17, Vladimir Oltean wrote:
> On Thu, Mar 18, 2021 at 03:54:00PM +0100, Heiner Kallweit wrote:
>> On 18.03.2021 15:23, Michael Walle wrote:
>>> at803x_aneg_done() is pretty much dead code since the patch series
>>> "net: phy: improve and simplify p
On 18.03.2021 15:23, Michael Walle wrote:
> at803x_aneg_done() is pretty much dead code since the patch series
> "net: phy: improve and simplify phylib state machine" [1]. Remove it.
>
Well, it's not dead, it's resting .. There are few places where
phy_aneg_done() is used. So you would need to
On 18.03.2021 10:09, Wong Vee Khee wrote:
> When using Clause-22 to probe for PHY devices such as the Marvell
> 88E2110, PHY ID with value 0 is read from the MII PHYID registers
> which caused the PHY framework failed to attach the Marvell PHY
> driver.
>
> Fixed this by adding a check of PHY ID
On 16.03.2021 09:57, Wong Vee Khee wrote:
> When using Clause-22 to probe for PHY devices such as the Marvell
> 88E2110, PHY ID with value 0 is read from the MII PHYID registers
> which caused the PHY framework failed to attach the Marvell PHY
> driver.
>
The issue occurs with a MAC driver that
On 09.03.2021 09:33, Jia-Ju Bai wrote:
> When kcalloc() returns NULL to nl_table, no error return code of
> netlink_proto_init() is assigned.
> To fix this bug, err is assigned with -ENOMEM in this case.
>
Didn't we talk enough about your incorrect patches yesterday?
This one is incorrect again.
On 08.03.2021 13:18, Jia-Ju Bai wrote:
>
>
> On 2021/3/8 18:19, Heiner Kallweit wrote:
>> On 08.03.2021 10:31, Jia-Ju Bai wrote:
>>> When sock_alloc_send_skb() returns NULL to skb, no error return code of
>>> dgram_sendmsg() is assigned.
>>> To
On 08.03.2021 10:31, Jia-Ju Bai wrote:
> When sock_alloc_send_skb() returns NULL to skb, no error return code of
> dgram_sendmsg() is assigned.
> To fix this bug, err is assigned with -ENOMEM in this case.
>
Please stop sending such nonsense. Basically all such patches you
sent so far are false
On 07.03.2021 10:31, Jia-Ju Bai wrote:
> Hi Leon,
>
> I am quite sorry for my incorrect patches...
> My static analysis tool reports some possible bugs about error handling code,
> and thus I write some patches for the bugs that seem to be true in my opinion.
> Because I am not familiar with
On 06.03.2021 15:07, Jia-Ju Bai wrote:
> When fib_entry is NULL, no error return code of
> mlxsw_sp_router_nve_promote_decap() is assigned.
> To fix this bug, err is assigned with -EINVAL in this case.
>
Again, are you sure this is a bug? To me it looks like it is
intentional to not return an
*cmd |= 0x7f0 << 18;
> + *cmd |= 0xf70 << 18;
> }
>
> DECLARE_RTL_COND(rtl_eriar_cond)
>
Acked-by: Heiner Kallweit
On 04.03.2021 15:18, Jia-Ju Bai wrote:
> When mlx5_is_fpga_lookaside() returns a non-zero value, no error
> return code is assigned.
> To fix this bug, err is assigned with -EINVAL as error return code.
>
To me it looks like the current behavior is intentional.
Did you verify that it's actually
On 03.03.2021 08:39, Valdis Klētnieks wrote:
> On Wed, 03 Mar 2021 07:51:06 +0100, Heiner Kallweit said:
>>> # Firmware loader
>>> CONFIG_EXTRA_FIRMWARE="rtl_nic/rtl8106e-1.fw"
>>> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>>>
>>
On 03.03.2021 07:09, Valdis Klētnieks wrote:
> So my kernel build died..
>
> UPD drivers/base/firmware_loader/builtin/rtl_nic/rtl8106e-1.fw.gen.S
> make[4]: *** No rule to make target '/lib/firmware/rtl_nic/rtl8106e-1.fw',
> needed by
On 26.02.2021 13:18, Kai-Heng Feng wrote:
> On Fri, Feb 26, 2021 at 8:10 PM Heiner Kallweit wrote:
>>
>> On 26.02.2021 08:12, Kalle Valo wrote:
>>> Kai-Heng Feng writes:
>>>
>>>> Now we have a generic D3 shutdown quirk, so convert the original
>&
On 26.02.2021 08:12, Kalle Valo wrote:
> Kai-Heng Feng writes:
>
>> Now we have a generic D3 shutdown quirk, so convert the original
>> approach to a PCI quirk.
>>
>> Signed-off-by: Kai-Heng Feng
>> ---
>> drivers/net/wireless/realtek/rtw88/pci.c | 2 --
>> drivers/pci/quirks.c
gt; wrote:
>>>> On Tue, Feb 09, 2021 at 11:37:29AM +0100, Heiner Kallweit wrote:
>>>>> Right, adding something like a genphy_{read,write}_mmd() doesn't make
>>>>> too much sense for now. What I meant is just exporting mmd_phy_indirect().
>>>>
On 15.02.2021 17:58, Bjarni Jonasson wrote:
> The 'coma mode' (configurable through sw or hw) provides an
> optional feature that may be used to control when the PHYs become active.
> The typical usage is to synchronize the link-up time across
> all PHY instances. This patch releases coma mode if
On 15.02.2021 17:57, Bjarni Jonasson wrote:
> The current IB serdes calibration algorithm (performed by the onboard 8051)
> has proven to be unstable for the VSC8514 QSGMII phy.
> A new algorithm has been developed based on
> 'Frequency-offset Jittered-Injection' or 'FoJi' method which solves
>
On 15.02.2021 17:57, Bjarni Jonasson wrote:
> At Power-On Reset, transients may cause the LCPLL to lock onto a
> clock that is momentarily unstable. This is normally seen in QSGMII
> setups where the higher speed 6G SerDes is being used.
> This patch adds an initial LCPLL Reset to the PHY (first
On 11.02.2021 22:19, Alex Elder wrote:
> When initializing the IPA core clock and interconnects, it's
> possible we'll get an EPROBE_DEFER error. This isn't really an
> error, it's just means we need to be re-probed later.
>
> Check the return code when initializing these, and if it's
>
On 11.02.2021 13:17, Pavel Machek wrote:
> On Thu 2021-01-14 12:05:21, Heiner Kallweit wrote:
>> On 14.01.2021 11:41, claudiu.bez...@microchip.com wrote:
>>>
>>>
>>> On 14.01.2021 12:25, Russell King - ARM Linux admin wrote:
>>>>
>>>> A
On 11.02.2021 09:57, Saravana Kannan wrote:
> On Wed, Feb 10, 2021 at 11:31 PM Heiner Kallweit wrote:
>>
>> On 11.02.2021 00:29, Saravana Kannan wrote:
>>> On Wed, Feb 10, 2021 at 2:52 PM Andrew Lunn wrote:
>>>>
>>>> On Wed, Feb 10, 2021 at 0
On 11.02.2021 00:29, Saravana Kannan wrote:
> On Wed, Feb 10, 2021 at 2:52 PM Andrew Lunn wrote:
>>
>> On Wed, Feb 10, 2021 at 02:13:48PM -0800, Saravana Kannan wrote:
>>> Hi,
>>>
>>> This email was triggered by this other email[1].
>>>
>>> Why is phy_attach_direct() directly calling
On 10.02.2021 23:13, Saravana Kannan wrote:
> Hi,
>
> This email was triggered by this other email[1].
>
> Why is phy_attach_direct() directly calling device_bind_driver()
> instead of using bus_probe_device()? I'm asking because this is
> causing device links status to not get updated correctly
On 10.02.2021 17:47, Michael Walle wrote:
> Unfortunately, the IP101A and IP101G share the same PHY identifier.
> While most of the functions are somewhat backwards compatible, there is
> for example the APS_EN bit on the IP101A but on the IP101G this bit
> reserved. Also, the IP101G has many more
On 10.02.2021 13:55, Robert Marko wrote:
> This adds driver for the Qualcomm QCA8072 and QCA8075 PHY-s.
>
> They are 2 or 5 port IEEE 802.3 clause 22 compliant
> 10BASE-Te, 100BASE-TX and 1000BASE-T PHY-s.
>
> They feature 2 SerDes, one for PSGMII or QSGMII connection with MAC,
> while second
On 10.02.2021 13:17, Michael Walle wrote:
> Am 2021-02-10 12:48, schrieb Russell King - ARM Linux admin:
>> On Wed, Feb 10, 2021 at 12:14:35PM +0100, Michael Walle wrote:
>>> Am 2021-02-10 11:49, schrieb Russell King - ARM Linux admin:
>>> The PHY doesn't support fiber and register 0..15 are
On 10.02.2021 09:25, Michael Walle wrote:
> Hi,
>
> Am 2021-02-10 08:03, schrieb Heiner Kallweit:
>> On 09.02.2021 17:40, Michael Walle wrote:
>>> Registers >= 16 are paged. Be sure to set the page. It seems this was
>>> working for now, because the defau
On 09.02.2021 17:40, Michael Walle wrote:
> Registers >= 16 are paged. Be sure to set the page. It seems this was
> working for now, because the default is correct for the registers used
> in the driver at the moment. But this will also assume, nobody will
> change the page select register before
On 09.02.2021 17:40, Michael Walle wrote:
> Unfortunately, the IP101A and IP101G share the same PHY identifier.
> While most of the functions are somewhat backwards compatible, there is
> for example the APS_EN bit on the IP101A but on the IP101G this bit
> reserved. Also, the IP101G has many more
On 09.02.2021 11:15, Serge Semin wrote:
> On Mon, Feb 08, 2021 at 09:14:02PM +0100, Heiner Kallweit wrote:
>> On 08.02.2021 15:03, Serge Semin wrote:
>>> It has been noticed that RTL8211E PHY stops detecting and reporting events
>>> when EEE is successfully adverti
On 09.02.2021 02:30, Andrew Lunn wrote:
> On Tue, Feb 09, 2021 at 12:17:06AM +0100, Michael Walle wrote:
>> It is nowhere used in the kernel. It also seems to be lacking the
>> proper fiber advertise flags. Remove it.
>
> Maybe also remove the #define for PHY_BCM_FLAGS_MODE_1000BX? Maybe
> there
On 08.02.2021 15:03, Serge Semin wrote:
> It has been noticed that RTL8211E PHY stops detecting and reporting events
> when EEE is successfully advertised and RXC stopping in LPI is enabled.
> The freeze happens right after 3.0.10 bit (PC1R "Clock Stop Enable"
> register) is set. At the same time
ns(+), 6 deletions(-)
>
for net-next
Reviewed-by: Heiner Kallweit
On 01.02.2021 17:47, Kai-Heng Feng wrote:
> According to the vendor driver, the new chip with XID 0x54b is
> essentially the same as the one with XID 0x54a, but it doesn't need the
> firmware.
>
> So add support accordingly.
>
> Signed-off-by: Kai-Heng Feng
> ---
>
On 22.01.2021 15:35, Laurent Badel wrote:
> Some PHYs such as SMSC LAN87xx clear the interrupt mask register on
> software reset. Since mdio_bus_phy_restore() calls phy_init_hw() which
> does a software reset of the PHY, these PHYs will lose their interrupt
> mask configuration on resuming from
Since 60b7cab23e5e ("proc_sysctl: fix oops caused by incorrect command
parameters.")
I'm getting the following warning: Missing param value! Expected
'rw=...value...'
AFAIK param rw doesn't require a value. That's what my command line looks like:
Command line: initrd=\intel-ucode.img
On 14.01.2021 11:41, claudiu.bez...@microchip.com wrote:
>
>
> On 14.01.2021 12:25, Russell King - ARM Linux admin wrote:
>>
>> As I've said, if phylib/PHY driver is not restoring the state of the
>> PHY on resume from suspend-to-ram, then that's an issue with phylib
>> and/or the phy driver.
>
On 13.01.2021 23:01, Russell King - ARM Linux admin wrote:
> On Wed, Jan 13, 2021 at 10:34:53PM +0100, Heiner Kallweit wrote:
>> On 13.01.2021 13:36, claudiu.bez...@microchip.com wrote:
>>> On 13.01.2021 13:09, Heiner Kallweit wrote:
>>>> On 13.01.2021 10:29, clau
On 13.01.2021 13:36, claudiu.bez...@microchip.com wrote:
>
>
> On 13.01.2021 13:09, Heiner Kallweit wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> On 13.01.2021 10:29, claudiu.bez...@m
On 13.01.2021 10:29, claudiu.bez...@microchip.com wrote:
> Hi Heiner,
>
> On 08.01.2021 18:31, Heiner Kallweit wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> On 08.01.2021 16:45, Claudiu Beznea wro
On 11.01.2021 20:45, Paul Thomas wrote:
> Hello, recently I was doing a lot of tracing/profiling to understand
> an issue we were having. Anyway, during this I ran across
> __napi_schedule_irqoff() where the comment in dev.c says "Variant of
> __napi_schedule() assuming hard irqs are masked".
>
>
On 14.12.2020 14:01, Robin Murphy wrote:
> On 2020-12-13 16:32, Heiner Kallweit wrote:
>> Zillions of drivers use the unlikely() hint when checking the result of
>> dma_mapping_error(). This is an inline function anyway, so we can move
>> the hint into this function and r
On 08.01.2021 16:45, Claudiu Beznea wrote:
> KSZ9131 is used in setups with SAMA7G5. SAMA7G5 supports a special
> power saving mode (backup mode) that cuts the power for almost all
> parts of the SoC. The rail powering the ethernet PHY is also cut off.
> When resuming, in case the PHY has been
On 04.01.2021 18:28, Hongwei Zhang wrote:
>
>> From: Jakub Kicinski
>> Sent: Monday, December 28, 2020 5:01 PM
>>
>> On Tue, 22 Dec 2020 22:00:34 +0100 Andrew Lunn wrote:
>>> On Tue, Dec 22, 2020 at 09:46:52PM +0100, Heiner Kallweit wrote:
>>&
On 04.01.2021 18:39, Lukas Wunner wrote:
> On Thu, Dec 31, 2020 at 10:38:12AM +0100, Heiner Kallweit wrote:
>> On 31.12.2020 05:07, Lukas Wunner wrote:
>>> FWIW, if platform_pci_power_manageable() returns true, it can probably
>>> be assumed that allowing runtime
On 31.12.2020 10:38, Heiner Kallweit wrote:
> On 31.12.2020 05:07, Lukas Wunner wrote:
>> On Wed, Dec 30, 2020 at 11:56:04PM +0100, Heiner Kallweit wrote:
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -3024,7 +3024,9 @@ void pci_pm_init(str
On 31.12.2020 05:07, Lukas Wunner wrote:
> On Wed, Dec 30, 2020 at 11:56:04PM +0100, Heiner Kallweit wrote:
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3024,7 +3024,9 @@ void pci_pm_init(struct pci_dev *dev)
>> u16 status;
>> u16 pmc;
&g
On 17.11.2020 17:57, Rafael J. Wysocki wrote:
> On Tue, Nov 17, 2020 at 5:38 PM Bjorn Helgaas wrote:
>>
>> [+to Rafael, author of the commit you mentioned,
>> +cc Mika, Kai Heng, Lukas, linux-pm, linux-kernel]
>>
>> On Tue, Nov 17, 2020 at 04:56:09PM +0100, Heiner
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: 4b2d8ca9208be636b30e924b1cbcb267b0740c93
Gitweb:
https://git.kernel.org/tip/4b2d8ca9208be636b30e924b1cbcb267b0740c93
Author:Heiner Kallweit
AuthorDate:Tue, 01 Dec 2020 12:39:57 +01:00
On 30.12.2020 17:15, Florian Fainelli wrote:
>
>
> On 12/30/2020 1:12 AM, Heiner Kallweit wrote:
>> On 30.12.2020 10:07, DENG Qingfang wrote:
>>> Hi Heiner,
>>> Thanks for your reply.
>>>
>>> On Wed, Dec 30, 2020 at 3:39 PM Heiner Kallweit
&
On 30.12.2020 10:07, DENG Qingfang wrote:
> Hi Heiner,
> Thanks for your reply.
>
> On Wed, Dec 30, 2020 at 3:39 PM Heiner Kallweit wrote:
>> I don't think that's the best option.
>
> I'm well aware of that.
>
>> You may want to add a PHY driver for you
On 30.12.2020 05:22, DENG Qingfang wrote:
> Hi,
>
> I added MT7530 IRQ support and registered its internal PHYs to IRQ.
> It works but my patch used two hacks.
>
> 1. Removed phy_drv_supports_irq check, because config_intr and
> handle_interrupt are not set for Generic PHY.
>
I don't think
On 29.12.2020 12:56, Kai-Heng Feng wrote:
> On Sat, Dec 26, 2020 at 11:26 PM Heiner Kallweit wrote:
>>
>> On 17.11.2020 17:57, Rafael J. Wysocki wrote:
>>> On Tue, Nov 17, 2020 at 5:38 PM Bjorn Helgaas wrote:
>>>>
>>>> [+to Rafael, author of t
On 17.11.2020 17:57, Rafael J. Wysocki wrote:
> On Tue, Nov 17, 2020 at 5:38 PM Bjorn Helgaas wrote:
>>
>> [+to Rafael, author of the commit you mentioned,
>> +cc Mika, Kai Heng, Lukas, linux-pm, linux-kernel]
>>
>> On Tue, Nov 17, 2020 at 04:56:09PM +0100, Heiner
On 23.12.2020 15:11, Zheng Yongjun wrote:
> Signed-off-by: Zheng Yongjun
> ---
> drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
>
t; Hi Heiner,
>
>> From:Heiner Kallweit
>> Sent:Monday, December 21, 2020 4:37 PM
>>> Change the order of reading MAC address, try to read it from MAC chip
>>> first, if it's not availabe, then try to read it from device tree.
>>>
>&g
Am 21.12.2020 um 21:51 schrieb Hongwei Zhang:
> Change the order of reading MAC address, try to read it from MAC chip
> first, if it's not availabe, then try to read it from device tree.
>
This commit message leaves a number of questions. It seems the change
isn't related at all to the change
Am 13.12.2020 um 22:27 schrieb Song Bao Hua (Barry Song):
>
>
>> -Original Message-----
>> From: Heiner Kallweit [mailto:hkallwe...@gmail.com]
>> Sent: Monday, December 14, 2020 5:33 AM
>> To: Christoph Hellwig ; Marek Szyprowski
>> ; Robin Murphy ; Song
Zillions of drivers use the unlikely() hint when checking the result of
dma_mapping_error(). This is an inline function anyway, so we can move
the hint into this function and remove it from drivers.
Signed-off-by: Heiner Kallweit
---
v2:
Split the big patch into the change for dma-mapping.h
Am 11.12.2020 um 13:43 schrieb Sven Van Asbroeck:
> Hi Heiner,
>
> On Thu, Dec 10, 2020 at 2:32 AM Heiner Kallweit wrote:
>>
>>
>> In addition you could play with sysfs attributes
>> /sys/class/net//gro_flush_timeout
>> /sys/class/net//napi_defer_
Am 10.12.2020 um 20:04 schrieb Borislav Petkov:
> On Tue, Dec 01, 2020 at 12:39:57PM +0100, Heiner Kallweit wrote:
>> On this system the M.2 PCIe WiFi card isn't detected after reboot,
>> only after cold boot. reboot=pci fixes this behavior.
>> In [0] the same issue i
nly if something is really very unlikely.
I think that's the case here.
Patch was created with some help from coccinelle.
@@
expression dev, dma_addr;
@@
- unlikely(dma_mapping_error(dev, dma_addr))
+ dma_mapping_error(dev, dma_addr)
Signed-off-by: Heiner Kallweit
---
If ok, then tbd through wh
Am 10.12.2020 um 04:55 schrieb Sven Van Asbroeck:
> From: Sven Van Asbroeck
>
> Even if there is more rx data waiting on the chip, the rx napi poll fn
> will never run more than once - it will always read a few buffers, then
> bail out and re-arm interrupts. Which results in ping-pong between
pci_try_set_mwi() and remove the
__must_check attribute from pci_set_mwi().
I don't expect either function to be used in new code anyway.
Signed-off-by: Heiner Kallweit
---
patch applies on top of pci/misc for v5.11
---
Documentation/PCI/pci.rst | 5 +
drivers/ata
Am 08.12.2020 um 09:25 schrieb Kai-Heng Feng:
> If we are to use sysfs to change ASPM settings, we may want to override
> the default ASPM policy.
>
> So use ASPM capability, instead of default policy, to be able to use all
> possible ASPM states.
>
> Signed-off-by: Kai-Heng Feng
> ---
>
Am 08.12.2020 um 09:25 schrieb Kai-Heng Feng:
> If we use sysfs to disable L1 ASPM, then enable one L1 ASPM substate
> again, all other substates will also be enabled too:
>
> link# grep . *
> clkpm:1
> l0s_aspm:1
> l1_1_aspm:1
> l1_1_pcipm:1
> l1_2_aspm:1
> l1_2_pcipm:1
> l1_aspm:1
>
> link#
] involved the PCI maintainer, and proposal was
to go with the PCI reboot quirk on affected systems until a more
generic fix is available.
[0] https://bugzilla.kernel.org/show_bug.cgi?id=202399
Signed-off-by: Heiner Kallweit
---
arch/x86/kernel/reboot.c | 9 +
1 file changed, 9 insertions
Am 29.11.2020 um 22:17 schrieb Christophe JAILLET:
> he wrappers in include/linux/pci-dma-compat.h should go away.
>
> The patch has been generated with the coccinelle script below and has been
> hand modified to replace GFP_ with a correct flag.
> It has been compile tested.
>
> When memory is
Am 24.11.2020 um 23:33 schrieb Antonio Borneo:
> On Tue, 2020-11-24 at 23:22 +0100, Heiner Kallweit wrote:
>> Am 24.11.2020 um 22:59 schrieb Antonio Borneo:
>>> The rtl8211f supports downshift and before commit 5502b218e001
>>> ("net: phy: use phy_resolve_ane
sting
> function rtlgen_read_status().
>
> Signed-off-by: Antonio Borneo
> Link:
> https://lore.kernel.org/r/478f871a-583d-01f1-9cc5-2eea56d8c...@huawei.com
> ---
> To: Andrew Lunn
> To: Heiner Kallweit
> To: Russell King
> To: "David S. Miller"
> To:
Am 24.11.2020 um 16:17 schrieb Antonio Borneo:
> On Tue, 2020-11-24 at 14:56 +, Russell King - ARM Linux admin wrote:
>> On Tue, Nov 24, 2020 at 03:38:48PM +0100, Antonio Borneo wrote:
>>> If the auto-negotiation fails to establish a gigabit link, the phy
>>> can try to 'down-shift': it resets
ve_aneg_linkmode in
> genphy_read_status")
> Cc: sta...@vger.kernel.org # v5.1+
> Signed-off-by: Antonio Borneo
> Link:
> https://lore.kernel.org/r/478f871a-583d-01f1-9cc5-2eea56d8c...@huawei.com
> ---
> To: Andrew Lunn
> To: Heiner Kallweit
> To: Russell King
&g
-by: Heiner Kallweit
---
net/core/dev.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 4bfdcd6b2..3c3070d9d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3495,6 +3495,11 @@ static netdev_features_t gso_features_check(const struct
sk_buff *skb
Am 19.11.2020 um 22:41 schrieb Andrew Lunn:
Doesn't checkpatch complain about line length > 80 here?
>>>
>>> :)
>>>
>>> commit bdc48fa11e46f867ea4d75fa59ee87a7f48be144
>>> Author: Joe Perches
>>> Date: Fri May 29 16:12:21 2020 -0700
>>>
>>> checkpatch/coding-style: deprecate 80-column
Am 19.11.2020 um 22:17 schrieb Grygorii Strashko:
>
>
> On 19/11/2020 23:11, Heiner Kallweit wrote:
>> Am 19.11.2020 um 21:34 schrieb Grygorii Strashko:
>>> The mdio_bus may have dependencies from GPIO controller and so got
>>> deferred. Now it will print error
Am 19.11.2020 um 21:34 schrieb Grygorii Strashko:
> The mdio_bus may have dependencies from GPIO controller and so got
> deferred. Now it will print error message every time -EPROBE_DEFER is
> returned which from:
> __mdiobus_register()
> |-devm_gpiod_get_optional()
> without actually identifying
1 - 100 of 642 matches
Mail list logo
