Re: [PATCH net-next] net: phy: fix autoneg mismatch case in genphy_read_status
On 08.04.2019 09:47, Simon Horman wrote:
> On Sun, Apr 07, 2019 at 05:09:28PM +0200, Heiner Kallweit wrote:
>> On 05.04.2019 18:16, Simon Horman wrote:
>>> On Tue, Apr 02, 2019 at 08:43:30PM +0200, Heiner Kallweit wrote:
>>>> The original patch didn't consider the case that autoneg process
>>>> finishes successfully but both link partners have no mode in common.
>>>> In this case there's no link, nevertheless we may be interested in
>>>> what the link partner advertised.
>>>>
>>>> Like phydev->link we set phydev->autoneg_complete in
>>>> genphy_update_link() and use the stored value in genphy_read_status().
>>>> This way we don't have to read register BMSR again.
>>>>
>>>> Fixes: b6163f194c69 ("net: phy: improve genphy_read_status")
>>>> Signed-off-by: Heiner Kallweit
>>>
>>> Hi,
>>>
>>> I have observed a regression with this patch as present as
>>> 4950c2ba49cc ("net: phy: fix autoneg mismatch case in genphy_read_status")
>>> in net-next.
>>>
>>> The platform is the Renesas R-Car E3 (r8a77990) based Ebisu-4D board.
>>>
>>>
>>> Without this patch (commit before 4950c2ba49cc) the link is negotiated
>>> as follows:
>>>
>>> [3.257699] libphy: ravb_mii: probed
>>> [3.266498] ravb e680.ethernet eth0: Base address at 0xe680,
>>> 2e:09:0a:03:85:38, IRQ 104.
>>> [3.537082] Micrel KSZ9031 Gigabit PHY e680.ethernet-:00:
>>> attached PHY driver [Micrel KSZ9031 Gigabit PHY]
>>> (mii_bus:phy_addr=e680.ethernet-:00, irq=165)
>>> [9.667161] ravb e680.ethernet eth0: Link is Up - 1Gbps/Full - flow
>>> control off
>>>
>>> # ethtool --version
>>> ethtool version 3.16
>>> # ethtool eth0
>>> Settings for eth0:
>>> Supported ports: [ TP MII ]
>>> Supported link modes: 100baseT/Full
>>> 1000baseT/Full
>>> Supported pause frame use: No
>>> Supports auto-negotiation: Yes
>>> Advertised link modes: 100baseT/Full
>>> 1000baseT/Full
>>> Advertised pause frame use: No
>>> Advertised auto-negotiation: Yes
>>> Link partner advertised link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Full
>>> Link partner advertised pause frame use: No
>>> Link partner advertised auto-negotiation: Yes
>>> Speed: 1000Mb/s
>>> Duplex: Full
>>> Port: MII
>>> PHYAD: 0
>>> Transceiver: external
>>> Auto-negotiation: on
>>> Supports Wake-on: g
>>> Wake-on: d
>>> Current message level: 0x00cc (204)
>>>link timer rx_err tx_err
>>> Link detected: yes
>>>
>>>
>>> With this patch the link is negotiated as follows, note the "Unknown":
>>>
>>> [3.268609] libphy: ravb_mii: probed
>>> [3.277402] ravb e680.ethernet eth0: Base address at 0xe680,
>>> 2e:09:0a:03:85:38, IRQ 104.
>>> [3.565057] Micrel KSZ9031 Gigabit PHY e680.ethernet-:00:
>>> attached PHY driver [Micrel KSZ9031 Gigabit PHY]
>>> (mii_bus:phy_addr=e680.ethernet-:00, irq=165)
>>> [9.804423] ravb e680.ethernet eth0: Link is Up - Unknown/Unknown -
>>> flow control off
>>>
>>> And ethtool reports:
>>>
>>> # ethtool eth0
>>> Settings for eth0:
>>> Supported ports: [ TP MII ]
>>> Supported link modes: 100baseT/Full
>>> 1000baseT/Full
>>> Supported pause frame use: No
>>> Supports auto-negotiation: Yes
>>> Advertised link modes: 100baseT/Full
>>> 1000baseT/Full
>>> Advertised pause frame use: No
>>> Advertised auto-negotiation: Yes
>>> Speed: Unknown!
>>> Duplex: Unknown! (255)
>>> Port: MII
>>> PHYAD: 0
>>> Transceiver: external
>>> Auto-negotiation: on
>>> Supports Wake-on: g
>>>
Re: [PATCH net-next] net: phy: fix autoneg mismatch case in genphy_read_status
On 05.04.2019 18:16, Simon Horman wrote:
> On Tue, Apr 02, 2019 at 08:43:30PM +0200, Heiner Kallweit wrote:
>> The original patch didn't consider the case that autoneg process
>> finishes successfully but both link partners have no mode in common.
>> In this case there's no link, nevertheless we may be interested in
>> what the link partner advertised.
>>
>> Like phydev->link we set phydev->autoneg_complete in
>> genphy_update_link() and use the stored value in genphy_read_status().
>> This way we don't have to read register BMSR again.
>>
>> Fixes: b6163f194c69 ("net: phy: improve genphy_read_status")
>> Signed-off-by: Heiner Kallweit
>
> Hi,
>
> I have observed a regression with this patch as present as
> 4950c2ba49cc ("net: phy: fix autoneg mismatch case in genphy_read_status")
> in net-next.
>
> The platform is the Renesas R-Car E3 (r8a77990) based Ebisu-4D board.
>
>
> Without this patch (commit before 4950c2ba49cc) the link is negotiated
> as follows:
>
> [3.257699] libphy: ravb_mii: probed
> [3.266498] ravb e680.ethernet eth0: Base address at 0xe680,
> 2e:09:0a:03:85:38, IRQ 104.
> [3.537082] Micrel KSZ9031 Gigabit PHY e680.ethernet-:00:
> attached PHY driver [Micrel KSZ9031 Gigabit PHY]
> (mii_bus:phy_addr=e680.ethernet-:00, irq=165)
> [9.667161] ravb e680.ethernet eth0: Link is Up - 1Gbps/Full - flow
> control off
>
> # ethtool --version
> ethtool version 3.16
> # ethtool eth0
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 100baseT/Full
> 1000baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes: 100baseT/Full
> 1000baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Link partner advertised pause frame use: No
> Link partner advertised auto-negotiation: Yes
> Speed: 1000Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 0
> Transceiver: external
> Auto-negotiation: on
> Supports Wake-on: g
> Wake-on: d
> Current message level: 0x00cc (204)
>link timer rx_err tx_err
> Link detected: yes
>
>
> With this patch the link is negotiated as follows, note the "Unknown":
>
> [3.268609] libphy: ravb_mii: probed
> [3.277402] ravb e680.ethernet eth0: Base address at 0xe680,
> 2e:09:0a:03:85:38, IRQ 104.
> [3.565057] Micrel KSZ9031 Gigabit PHY e680.ethernet-:00:
> attached PHY driver [Micrel KSZ9031 Gigabit PHY]
> (mii_bus:phy_addr=e680.ethernet-:00, irq=165)
> [9.804423] ravb e680.ethernet eth0: Link is Up - Unknown/Unknown -
> flow control off
>
> And ethtool reports:
>
> # ethtool eth0
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 100baseT/Full
> 1000baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes: 100baseT/Full
> 1000baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Speed: Unknown!
> Duplex: Unknown! (255)
> Port: MII
> PHYAD: 0
> Transceiver: external
> Auto-negotiation: on
> Supports Wake-on: g
> Wake-on: d
> Current message level: 0x00cc (204)
>link timer rx_err tx_err
> Link detected: yes
>
>
>
> I noticed this when preparing a patch limit the maximum speed the device to
> 100Mbit/s as follows:
>
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> @@ -272,6 +272,7 @@
> interrupt-parent = <&gpio2>;
> interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
> reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
> + max-speed = <100>;
> };
> };
>
> While the 100Mbit/s limit applied on top of the commit before 4950c2ba49cc
> things work as expected:
>
> [3.258347] libphy: ravb_mii: probed
> [3.26
Re: [PATCH net-next] net: phy: fix autoneg mismatch case in genphy_read_status
On 05.04.2019 19:40, Heiner Kallweit wrote:
> On 05.04.2019 18:16, Simon Horman wrote:
>> On Tue, Apr 02, 2019 at 08:43:30PM +0200, Heiner Kallweit wrote:
>>> The original patch didn't consider the case that autoneg process
>>> finishes successfully but both link partners have no mode in common.
>>> In this case there's no link, nevertheless we may be interested in
>>> what the link partner advertised.
>>>
>>> Like phydev->link we set phydev->autoneg_complete in
>>> genphy_update_link() and use the stored value in genphy_read_status().
>>> This way we don't have to read register BMSR again.
>>>
>>> Fixes: b6163f194c69 ("net: phy: improve genphy_read_status")
>>> Signed-off-by: Heiner Kallweit
>>
>> Hi,
>>
>> I have observed a regression with this patch as present as
>> 4950c2ba49cc ("net: phy: fix autoneg mismatch case in genphy_read_status")
>> in net-next.
>>
>> The platform is the Renesas R-Car E3 (r8a77990) based Ebisu-4D board.
>>
>>
>> Without this patch (commit before 4950c2ba49cc) the link is negotiated
>> as follows:
>>
>> [3.257699] libphy: ravb_mii: probed
>> [3.266498] ravb e680.ethernet eth0: Base address at 0xe680,
>> 2e:09:0a:03:85:38, IRQ 104.
>> [3.537082] Micrel KSZ9031 Gigabit PHY e680.ethernet-:00:
>> attached PHY driver [Micrel KSZ9031 Gigabit PHY]
>> (mii_bus:phy_addr=e680.ethernet-:00, irq=165)
>> [9.667161] ravb e680.ethernet eth0: Link is Up - 1Gbps/Full - flow
>> control off
>>
>> # ethtool --version
>> ethtool version 3.16
>> # ethtool eth0
>> Settings for eth0:
>> Supported ports: [ TP MII ]
>> Supported link modes: 100baseT/Full
>> 1000baseT/Full
>> Supported pause frame use: No
>> Supports auto-negotiation: Yes
>> Advertised link modes: 100baseT/Full
>> 1000baseT/Full
>> Advertised pause frame use: No
>> Advertised auto-negotiation: Yes
>> Link partner advertised link modes: 10baseT/Half 10baseT/Full
>> 100baseT/Half 100baseT/Full
>> 1000baseT/Full
>> Link partner advertised pause frame use: No
>> Link partner advertised auto-negotiation: Yes
>> Speed: 1000Mb/s
>> Duplex: Full
>> Port: MII
>> PHYAD: 0
>> Transceiver: external
>> Auto-negotiation: on
>> Supports Wake-on: g
>> Wake-on: d
>> Current message level: 0x00cc (204)
>>link timer rx_err tx_err
>> Link detected: yes
>>
>>
>> With this patch the link is negotiated as follows, note the "Unknown":
>>
>> [3.268609] libphy: ravb_mii: probed
>> [3.277402] ravb e680.ethernet eth0: Base address at 0xe680,
>> 2e:09:0a:03:85:38, IRQ 104.
>> [3.565057] Micrel KSZ9031 Gigabit PHY e680.ethernet-:00:
>> attached PHY driver [Micrel KSZ9031 Gigabit PHY]
>> (mii_bus:phy_addr=e680.ethernet-:00, irq=165)
>> [9.804423] ravb e680.ethernet eth0: Link is Up - Unknown/Unknown -
>> flow control off
>>
> Looks like the PHY doesn't set the "aneg complete" bit. But then, how
> can the link be up? Could you please add a debug output in
> genphy_update_link() printing the value of register BMSR?
There's also an easier way, you can switch on tracing by
echo 1 > /sys/kernel/debug/tracing/events/mdio/mdio_access/enable
and then find the trace in
/sys/kernel/debug/tracing/trace
> I wonder whether your case may be caused by a chip erratum. Item 5 in
> the errata documentation
> (http://ww1.microchip.com/downloads/en/DeviceDoc/8692D.pdf)
> may be a candidate. Could you please check (as explained in the
> errata document) and report the exact PHY version?
>
This erratum is taken care of in the phy driver already, so that
doesn't seem to be the reason.
> Could you please also test with another link partner?
>
>> And ethtool reports:
>>
>> # ethtool eth0
>> Settings for eth0:
>> Supported ports: [ TP MII ]
>> Supported link modes: 100baseT/Full
>> 1000baseT/Full
>> Supported pause frame use: No
>> Supports auto-negotiation: Yes
>> Advertised link modes:
Re: [PATCH net-next] net: phy: fix autoneg mismatch case in genphy_read_status
On 05.04.2019 18:16, Simon Horman wrote:
> On Tue, Apr 02, 2019 at 08:43:30PM +0200, Heiner Kallweit wrote:
>> The original patch didn't consider the case that autoneg process
>> finishes successfully but both link partners have no mode in common.
>> In this case there's no link, nevertheless we may be interested in
>> what the link partner advertised.
>>
>> Like phydev->link we set phydev->autoneg_complete in
>> genphy_update_link() and use the stored value in genphy_read_status().
>> This way we don't have to read register BMSR again.
>>
>> Fixes: b6163f194c69 ("net: phy: improve genphy_read_status")
>> Signed-off-by: Heiner Kallweit
>
> Hi,
>
> I have observed a regression with this patch as present as
> 4950c2ba49cc ("net: phy: fix autoneg mismatch case in genphy_read_status")
> in net-next.
>
> The platform is the Renesas R-Car E3 (r8a77990) based Ebisu-4D board.
>
>
> Without this patch (commit before 4950c2ba49cc) the link is negotiated
> as follows:
>
> [3.257699] libphy: ravb_mii: probed
> [3.266498] ravb e680.ethernet eth0: Base address at 0xe680,
> 2e:09:0a:03:85:38, IRQ 104.
> [3.537082] Micrel KSZ9031 Gigabit PHY e680.ethernet-:00:
> attached PHY driver [Micrel KSZ9031 Gigabit PHY]
> (mii_bus:phy_addr=e680.ethernet-:00, irq=165)
> [9.667161] ravb e680.ethernet eth0: Link is Up - 1Gbps/Full - flow
> control off
>
> # ethtool --version
> ethtool version 3.16
> # ethtool eth0
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 100baseT/Full
> 1000baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes: 100baseT/Full
> 1000baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Link partner advertised pause frame use: No
> Link partner advertised auto-negotiation: Yes
> Speed: 1000Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 0
> Transceiver: external
> Auto-negotiation: on
> Supports Wake-on: g
> Wake-on: d
> Current message level: 0x00cc (204)
>link timer rx_err tx_err
> Link detected: yes
>
>
> With this patch the link is negotiated as follows, note the "Unknown":
>
> [3.268609] libphy: ravb_mii: probed
> [3.277402] ravb e680.ethernet eth0: Base address at 0xe680,
> 2e:09:0a:03:85:38, IRQ 104.
> [3.565057] Micrel KSZ9031 Gigabit PHY e680.ethernet-:00:
> attached PHY driver [Micrel KSZ9031 Gigabit PHY]
> (mii_bus:phy_addr=e680.ethernet-:00, irq=165)
> [9.804423] ravb e680.ethernet eth0: Link is Up - Unknown/Unknown -
> flow control off
>
Looks like the PHY doesn't set the "aneg complete" bit. But then, how
can the link be up? Could you please add a debug output in
genphy_update_link() printing the value of register BMSR?
I wonder whether your case may be caused by a chip erratum. Item 5 in
the errata documentation
(http://ww1.microchip.com/downloads/en/DeviceDoc/8692D.pdf)
may be a candidate. Could you please check (as explained in the
errata document) and report the exact PHY version?
Could you please also test with another link partner?
> And ethtool reports:
>
> # ethtool eth0
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 100baseT/Full
> 1000baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes: 100baseT/Full
> 1000baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Speed: Unknown!
> Duplex: Unknown! (255)
> Port: MII
> PHYAD: 0
> Transceiver: external
> Auto-negotiation: on
> Supports Wake-on: g
> Wake-on: d
> Current message level: 0x00cc (204)
>link timer rx_err tx_err
> Link detected: yes
>
>
>
> I noticed this when preparing a patch limit the maximum speed the device to
> 100Mbit/s as follows:
>
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
>
Re: [PATCH 0/7] sh_eth: implement simple RX checksum offload
On 27.01.2019 18:33, Sergei Shtylyov wrote: > Hello! > > Here's a set of 7 patches against DaveM's 'net-next.git' repo. I'm implemeting > the simple RX checksum offload (like was done for the 'ravb' driver by Simon > Horman); it was only tested on the R8A77980 SoC, the other SoCs should just > work (according to their manuals)... > > [1/7] sh_eth: rename sh_eth_cpu_data::hw_checksum > [2/7] sh_eth: RX checksum offload support > [3/7] sh_eth: offload RX checksum on R7S72100 > [4/7] sh_eth: offload RX checksum on R8A7740 > [5/7] sh_eth: offload RX checksum on R8A77980 > [6/7] sh_eth: offload RX checksum on SH7734 > [7/7] sh_eth: offload RX checksum on SH7763 > > MBR, Sergei > Hi Sergei, the formatting of the patch series isn't in line with the netdev standards. See here: https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html - cover letter isn't generated by git - That's not ok --- *net-next.orig/*drivers/net/ethernet/renesas/sh_eth.h +++ *net-next/*drivers/net/ethernet/renesas/sh_eth.h - patches miss net / net-next annotation Heiner
Re: [PATCH/RFC] net: phy: device: Don't deassert the reset when register and probe
On 27.11.2018 17:44, Andrew Lunn wrote: > On Tue, Nov 27, 2018 at 12:18:20PM +, Yoshihiro Shimoda wrote: >> Some PHY device needs edge signal of the reset, but the previous code >> is impossible to achieve it like following: >> >> 1) Kernel boots by using initramfs. >> --> No open the nic, so the provious code deasserts the reset by >> phy_device_register() and phy_probe(). >> 2) Kernel enters the suspend. >> --> So, keep the reset signal as deassert. >> --> On R-Car Salvator-XS board, unfortunately, the board power is >> turned off. >> 3) Kernel returns from suspend. >> 4) ifconfig eth0 up >> --> Then, since edge signal of the reset doesn't happen, >> it cannot link up. > > Hi Yoshihiro > > It sounds like you should be adding code to the suspend/resume > handling of phylib, so that it toggle the reset on resume. You cannot > just delete code like you proposed, it is going to break devices. But > adding code should be O.K. > The commit message mentions that the patch is supposed to fix some issue on the Salvator-XS board. I found the following from a year ago https://www.spinics.net/lists/netdev/msg457308.html which is also about PHY reset and this board. Is there still something open? But as Andrew mentioned already: Just deleting code w/o checking what it's good for and whether this could have side effects, isn't a solution. Especially because the patch would silently remove the call to phy_scan_fixups(). Heiner >Andrew > . >
Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")
Am 12.04.2018 um 15:30 schrieb Vincent Guittot:
> Heiner, Niklas,
>
> Le Thursday 12 Apr 2018 à 13:15:19 (+0200), Niklas Söderlund a écrit :
>> Hi Vincent,
>>
>> Thanks for your feedback.
>>
>> On 2018-04-12 12:33:27 +0200, Vincent Guittot wrote:
>>> Hi Niklas,
>>>
>>> On 12 April 2018 at 11:18, Niklas Söderlund
>>> wrote:
Hi Vincent,
I have observed issues running on linus/master from a few days back [1].
I'm running on a Renesas Koelsch board (arm32) and I can trigger a issue
by X forwarding the v4l2 test application qv4l2 over ssh and moving the
courser around in the GUI (best test case description award...). I'm
sorry about the really bad way I trigger this but I can't do it in any
other way, I'm happy to try other methods if you got some ideas. The
symptom of the issue is a complete hang of the system for more then 30
seconds and then this information is printed in the console:
>>>
>>> Heiner (edded cc) also reported similar problem with his platform: a
>>> dual core celeron
>>>
>>> Do you confirm that your platform is a dual cortex-A15 ? At least that
>>> what I have seen on web
>>> This would confirm that dual system is a key point.
>>
>> I can confirm that my platform is a dual core.
>>
>>>
>>> The ssh connection is also common with Heiner's setup
>>
>> Interesting, I found Heiner's mail and I can confirm that I too
>> experience ssh sessions lockups. I ssh into the system and by repeatedly
>> hitting the return key I can lockup the board, while locked up starting
>> another ssh session unblocks the first. If I don't start another ssh
>> session but keep hitting return key sporadically in the first one I can
>> get the trace I reported in my first mail to be printed on the serial
>> console.
>>
>> When locked up the symptoms are that both the single ssh session is dead
>> and the serial console. But attempting another ssh connection
>> immediately unblocks both ssh and serial console. And if I allow enough
>> time before starting the second ssh connection I can trigger a trace to
>> be printed on the serial console, it's similar but different from the
>> first I reported.
>>
>> [ 207.548610] 1-...!: (0 ticks this GP) idle=79a/1/1073741824
>> softirq=2146/2146 fqs=0
>> [ 207.556442] (detected by 0, t=12645 jiffies, g=333, c=332, q=20)
>> [ 207.562546] rcu_sched kthread starved for 12645 jiffies! g333 c332 f0x2
>> RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
>> [ 207.572548] RCU grace-period kthread stack dump:
>>
>> [ 207.577166] rcu_sched R running task0 9 2
>> 0x
>> [ 207.584389] Backtrace:
>> [ 207.586849] [] (__schedule) from []
>> (schedule+0x94/0xb8)
>> [ 207.593901] r10:e77813c0 r9:e77813c0 r8: r7:e709bed4 r6:aa80
>> r5:
>> [ 207.601732] r4:e000
>> [ 207.604269] [] (schedule) from []
>> (schedule_timeout+0x380/0x3dc)
>> [ 207.612013] r5: r4:
>> [ 207.615596] [] (schedule_timeout) from []
>> (rcu_gp_kthread+0x668/0xe2c)
>> [ 207.623863] r10:c0b79018 r9:014d r8:014c r7:0001 r6:
>> r5:c0b10ad0
>> [ 207.631693] r4:c0b10980
>> [ 207.634230] [] (rcu_gp_kthread) from []
>> (kthread+0x148/0x160)
>> [ 207.641712] r7:c0b10980
>> [ 207.644249] [] (kthread) from []
>> (ret_from_fork+0x14/0x2c)
>> [ 207.651472] Exception stack(0xe709bfb0 to 0xe709bff8)
>> [ 207.656527] bfa0:
>>
>> [ 207.664709] bfc0:
>>
>> [ 207.672890] bfe0: 0013
>> [ 207.679508] r10: r9: r8: r7: r6:
>> r5:c013dc90
>> [ 207.687340] r4:e7026f4
>>
>> Continuing the anecdotal testing, I can't seem to be able to trigger the
>> lockup if i have ever had two ssh sessions open to the systems. And
>> about half the time I can't trigger it at all but after a reset of the
>> system it triggers with just hitting the return key 2-5 times of opening
>> a ssh session and just hitting the return key. But please take this part
>> with a grain of salt as it's done by the monkey testing method :-)
>>
>> All tests above have been run base on c18bb396d3d261eb ("Merge
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net").
>>
>>>
>
> [snip]
>
I'm a bit lost on how to progress with this issue and would appreciate
any help you can provide to help me figure this out.
>>>
>>> Can you send me your config ?
>>>
>>> I'm going to prepare a debug patch to spy what's happening when entering
>>> idle
>
> I'd like to narrow the problem a bit more with the 2 patchies aboves. Can you
> try
> them separatly on top of c18bb396d3d261eb ("Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net"))
> and check if one of them fixes the problem ?i
>
> (They should apply on linux-next as well)
>
> Firs
Re: i2c_new_{secondary_device,dummy,device}() return type.
Am 09.02.2018 um 11:01 schrieb Kieran Bingham: > Hi Wolfram, > > As part of my work looking at using i2c_new_secondary_device() to move address > mappings into the device tree, it has become evident that the return code of > the > i2c_new_secondary_device() is obfuscated, and is simply a valid client - or > NULL. > > This means that we must 'guess' as to whether the device failed due to a > memory > allocation, or if the device address was already in use (perhaps a more common > failure). > > Because of this - I would like to see the return codes of > i2c_new_secondary_device(), ic2_new_dummy(), and therefore i2c_new_device() > support returning ERR_PTR()s rather than a client or NULL. > > These functions are used fairly extensively - thus it will be a fair bit of > work > (or a good coccinelle script) - So I'd like to ask your opinion on the > validity > of this task before I commence anything down that rabbit hole! > > Any comments? Pre-ack/nack? (from anyone?) > This has been addressed as part of adding a devm_i2c_new_dummy(). Related patches are in status "under review" since end of December. See also here: https://marc.info/?l=linux-i2c&m=151375074832371&w=2 https://patchwork.ozlabs.org/patch/851268/ Maybe these patches cover already what you need. Rgds, Heiner > -- > Regards > > Kieran Bingham > . >
