On Thu, Apr 15, 2021 at 10:07:32PM -0700, Guenter Roeck wrote:
> On 4/15/21 7:13 PM, rentao.b...@gmail.com wrote:
> > From: Tao Ren
> >
> > Fix the time comparison (timeout vs. max_hw_heartbeat_ms) in set_timeout
> > handler to avoid potential integer overflo
On Thu, Apr 15, 2021 at 05:50:32PM -0700, Guenter Roeck wrote:
> On 4/15/21 5:12 PM, rentao.b...@gmail.com wrote:
> > From: Tao Ren
> >
> > Fix the time comparison (timeout vs. max_hw_heartbeat_ms) in set_timeout
> > handler to avoid potential integer overflo
On Mon, Mar 29, 2021 at 08:17:35AM +0200, Christoph Hellwig wrote:
> On Sat, Mar 27, 2021 at 03:17:59PM -0700, Tao Ren wrote:
> > On Fri, Mar 26, 2021 at 01:05:26PM +0100, Christoph Hellwig wrote:
> > > On Fri, Mar 26, 2021 at 12:03:03PM +, Robin Murphy wrote:
> > >
On Fri, Mar 26, 2021 at 01:05:26PM +0100, Christoph Hellwig wrote:
> On Fri, Mar 26, 2021 at 12:03:03PM +, Robin Murphy wrote:
> > This might happen to work out, but is far from correct. Just wait until you
> > try it on a platform where the USB controller is behind an IOMMU...
> >
> > It
On Mon, Nov 23, 2020 at 05:18:32AM -0800, Guenter Roeck wrote:
> On Sun, Nov 22, 2020 at 11:45:31PM -0800, rentao.b...@gmail.com wrote:
> > From: Tao Ren
> >
> > Add hardware monitoring driver for the Maxim MAX127 chip.
> >
> > MAX127 min/max range handling code
On Mon, Nov 23, 2020 at 05:16:41AM -0800, Guenter Roeck wrote:
> On Sun, Nov 22, 2020 at 11:54:49PM -0800, Tao Ren wrote:
> > On Sun, Nov 22, 2020 at 10:33:42AM -0800, Guenter Roeck wrote:
> > > On Thu, Nov 19, 2020 at 09:53:23AM -0800, rentao.b...@gmail.com wrote:
>
On Sun, Nov 22, 2020 at 10:33:42AM -0800, Guenter Roeck wrote:
> On Thu, Nov 19, 2020 at 09:53:23AM -0800, rentao.b...@gmail.com wrote:
> > From: Tao Ren
> >
> > Add hardware monitoring driver for the Maxim MAX127 chip.
> >
> > MAX127 min/max range handling code
On Wed, Nov 18, 2020 at 05:26:53PM -0800, Guenter Roeck wrote:
> On Wed, Nov 18, 2020 at 05:01:19PM -0800, Guenter Roeck wrote:
> > On Wed, Nov 18, 2020 at 03:42:53PM -0800, Tao Ren wrote:
> > > On Thu, Nov 19, 2020 at 12:27:19AM +0100, Andrew Lunn wrote:
> > > > On W
On Thu, Nov 19, 2020 at 12:27:19AM +0100, Andrew Lunn wrote:
> On Wed, Nov 18, 2020 at 03:09:27PM -0800, rentao.b...@gmail.com wrote:
> > From: Tao Ren
> >
> > The patch series adds hardware monitoring driver for the Maxim MAX127
> > chip.
>
> Hi Tao
>
&g
Hi Guenter,
Thanks for pointing out these problems. I'm working on the comments and
will send out v2 soon.
Cheers,
Tao
On Mon, Nov 16, 2020 at 09:13:52PM -0800, Guenter Roeck wrote:
> On Mon, Nov 16, 2020 at 05:09:43PM -0800, rentao.b...@gmail.com wrote:
> > From: Tao Ren
>
On Mon, Nov 16, 2020 at 03:33:45AM +, Joel Stanley wrote:
> On Tue, 10 Nov 2020 at 07:24, wrote:
> >
> > From: Tao Ren
> >
> > Create all the i2c switches in device tree and use aliases to assign
> > child channels with consistent bus numbers.
> >
On Thu, Nov 12, 2020 at 05:49:30AM +, Joel Stanley wrote:
> On Thu, 12 Nov 2020 at 03:18, Patrick Williams wrote:
> >
> > On Wed, Nov 11, 2020 at 11:34:10PM +, Joel Stanley wrote:
> > > On Wed, 11 Nov 2020 at 23:23, wrote:
> > > >
> > > >
On Wed, Nov 11, 2020 at 09:18:28PM -0600, Patrick Williams wrote:
> On Wed, Nov 11, 2020 at 11:34:10PM +, Joel Stanley wrote:
> > On Wed, 11 Nov 2020 at 23:23, wrote:
> > >
> > > From: Tao Ren
> > >
> > > The patch series adds the initial versio
On Wed, Nov 11, 2020 at 11:34:10PM +, Joel Stanley wrote:
> On Wed, 11 Nov 2020 at 23:23, wrote:
> >
> > From: Tao Ren
> >
> > The patch series adds the initial version of device tree for Facebook
> > Galaxy100 (AST2400) BMC.
> >
> > Patch #1 a
On Wed, Sep 30, 2020 at 12:08:23PM +0800, Ryan Chen wrote:
> Add EHCI UHCI enable build in aspeed-ast2600-evb.dts
>
> Signed-off-by: Ryan Chen
Reviewed-by: Tao Ren
On Wed, Sep 30, 2020 at 12:08:22PM +0800, Ryan Chen wrote:
> Add support for AST2600 SOC UHCI driver.
>
> Signed-off-by: Ryan Chen
Reviewed-by: Tao Ren
On Wed, Sep 30, 2020 at 12:08:21PM +0800, Ryan Chen wrote:
> Enable UHCI driver in aspeed_g5_defconfig.
>
> Signed-off-by: Ryan Chen
Reviewed-by: Tao Ren
On Thu, Sep 17, 2020 at 08:42:27AM +0930, Andrew Jeffery wrote:
>
>
> On Thu, 17 Sep 2020, at 06:12, rentao.b...@gmail.com wrote:
> > From: Tao Ren
> >
> > GPIO_U is mapped to the least significant byte of input/output mask, and
> > the byte in "output&quo
by: Eddie James
Reviewed-by: Tao Ren
> ---
> drivers/i2c/busses/i2c-aspeed.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index 31268074c422..2a388911038a 100644
> --- a/drivers/i2c/busses/i2c-asp
On Mon, Aug 31, 2020 at 12:54:57PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Tao Ren writes:
> > On Mon, Aug 17, 2020 at 04:49:32PM +0300, Felipe Balbi wrote:
> >>
> >> Hi,
> >>
> >> rentao.b...@gmail.com writes:
> >> >
On Tue, Aug 25, 2020 at 09:18:08AM -0500, Patrick Williams wrote:
> On Mon, Aug 24, 2020 at 02:19:47PM -0700, rentao.b...@gmail.com wrote:
> > From: Tao Ren
> >
> > Set 64Mb FMC flash layout in Minipack device tree explicitly because the
> > flash layout was removed fr
On Tue, Aug 25, 2020 at 04:07:56AM +, Joel Stanley wrote:
> On Mon, 24 Aug 2020 at 21:20, wrote:
> >
> > From: Tao Ren
> >
> > Add initial version of device tree for Facebook Wedge400 (AST2500) BMC.
> >
> > Signed-off-by: Tao Ren
>
> Reviewe
On Tue, Aug 25, 2020 at 02:47:51PM -0500, Eddie James wrote:
>
> On 8/25/20 1:38 AM, Joel Stanley wrote:
> > On Thu, 20 Aug 2020 at 16:12, Eddie James wrote:
> > > Mask the IRQ status to only the bits that the driver checks. This
> > > prevents excessive driver warnings when operating in slave
On Mon, Aug 17, 2020 at 04:49:32PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> rentao.b...@gmail.com writes:
> > From: Tao Ren
> >
> > This is a follow-on patch for commit a23be4ed8f48 ("usb: gadget: aspeed:
> > improve vhub port irq handling"):
On Fri, Jul 24, 2020 at 05:32:30AM +, Joel Stanley wrote:
> On Thu, 23 Jul 2020 at 23:05, wrote:
> >
> > From: Tao Ren
> >
> > The patch series update several devices' settings in Facebook Wedge40
> > device tree.
> >
> > Patch #1 disables a f
member
> 'langid' not described in 'usb_validate_langid'
> ../drivers/usb/gadget/usbstring.c:77: warning: Excess function parameter
> 'lang' description in 'usb_validate_langid'
>
> Fixes: 17309a6a4356 ("usb: gadget: add "usb_validate_langid" function")
> Signed
-0700, rentao.b...@gmail.com wrote:
> From: Tao Ren
>
> This is a follow-on patch for commit a23be4ed8f48 ("usb: gadget: aspeed:
> improve vhub port irq handling"): for_each_set_bit() is replaced with
> simple for() loop because for() loop runs faster on ASPEED BMC.
&g
Introduce "facebook-netbmc-ast2500-common.dtsi" which is included by all
Facebook AST2500 Network BMC platforms. The major purpose is to minimize
duplicated device entries cross Facebook Network BMC dts files.
Signed-off-by: Tao Ren
---
.../dts/facebook-netbmc-ast2500-common.d
-by: Tao Ren
---
.../arm/boot/dts/aspeed-bmc-facebook-yamp.dts | 62 ++-
1 file changed, 5 insertions(+), 57 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-yamp.dts
b/arch/arm/boot/dts/aspeed-bmc-facebook-yamp.dts
index 4e09a9cf32b7..b184fa1abb60 100644
--- a/arch
-by: Tao Ren
---
arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts | 66 +--
1 file changed, 16 insertions(+), 50 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts
b/arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts
index d519d307aa2a..0a031132594a 100644
--- a/arch
to 64MB.
- enabling the emmc device in slot #1.
Signed-off-by: Tao Ren
---
.../boot/dts/aspeed-bmc-facebook-minipack.dts | 59 ++-
1 file changed, 19 insertions(+), 40 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-minipack.dts
b/arch/arm/boot/dts/aspeed-bmc
-netbmc-ast2500-common.dtsi" file, and the
remaining 3 patches update CMM, Minipack and Yamp device tree to consume
the new dtsi file.
Tao Ren (4):
ARM: dts: aspeed: add dtsi for Facebook AST2500 Network BMCs
ARM: dts: aspeed: cmm: include dtsi for common network BMC devices
ARM: dts: aspee
Hi David,
I'm not sure if the patch series v9 was delivered to your mailbox successfully,
but somehow I still cannot find the patches in patchwork.
Any suggestions? Maybe my git is mis-configured?
Thanks,
Tao
On 10/15/19 12:12 PM, Tao Ren wrote:
> This patch series aims at supporting a
On 10/15/19 10:22 AM, Florian Fainelli wrote:
> On 10/15/19 10:20 AM, David Miller wrote:
>> From: Tao Ren
>> Date: Tue, 15 Oct 2019 17:16:26 +
>>
>>> Can you please apply the patch series to net-next tree when you have
>>> bandwidth? All the 3 patches
On 10/15/19 10:20 AM, David Miller wrote:
> From: Tao Ren
> Date: Tue, 15 Oct 2019 17:16:26 +
>
>> Can you please apply the patch series to net-next tree when you have
>> bandwidth? All the 3 patches are reviewed.
>
> If it is not active in patchwork you need
Hi David,
Can you please apply the patch series to net-next tree when you have bandwidth?
All the 3 patches are reviewed.
Thanks,
Tao
On 9/14/19 7:17 AM, Andrew Lunn wrote:
> On Mon, Sep 09, 2019 at 01:49:06PM -0700, Tao Ren wrote:
>> From: Heiner Kallweit
>>
>> Th
On 9/14/19 7:17 AM, Andrew Lunn wrote:
> On Mon, Sep 09, 2019 at 01:49:06PM -0700, Tao Ren wrote:
>> From: Heiner Kallweit
>>
>> This patch adds support for clause 37 1000Base-X auto-negotiation.
>>
>> Signed-off-by: Heiner Kallweit
>> Signed-off-by
Hi Andrew / Florian,
On 9/9/19 1:49 PM, Tao Ren wrote:
> From: Heiner Kallweit
>
> This patch adds support for clause 37 1000Base-X auto-negotiation.
>
> Signed-off-by: Heiner Kallweit
> Signed-off-by: Tao Ren
> Tested-by: René van Dorst
Just want to check if I mi
From: Heiner Kallweit
This patch adds support for clause 37 1000Base-X auto-negotiation.
Signed-off-by: Heiner Kallweit
Signed-off-by: Tao Ren
Tested-by: René van Dorst
---
Changes in v8:
- Rebased the patch on top of net-next HEAD.
Changes in v7:
- Update "if (AUTONEG_ENABLE != p
Modify the assignment to OR when dealing with phydev->dev_flags in
phy_attach_direct function, and this is to make sure dev_flags set in
driver's probe callback won't be lost.
Suggested-by: Andrew Lunn
CC: Heiner Kallweit
CC: Vladimir Oltean
Signed-off-by: Tao Ren
Reviewed-by: Andrew L
e-FX mode, and
100Base-FX support is not available as of now.
Signed-off-by: Tao Ren
Acked-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
No changes in v8.
Changes in v7:
- Add comment "BCM54616S 100Base-FX is not supported".
Changes in v6:
- nothing changed.
Changes in v5:
- inc
On 8/19/19 4:15 PM, René van Dorst wrote:
> Hi Tao,
>
> Quoting Tao Ren :
>
>> On 8/11/19 4:40 PM, Tao Ren wrote:
>>> From: Heiner Kallweit
>>>
>>> This patch adds support for clause 37 1000Base-X auto-negotiation.
>>>
>>> Signed-of
On 8/11/19 4:40 PM, Tao Ren wrote:
> From: Heiner Kallweit
>
> This patch adds support for clause 37 1000Base-X auto-negotiation.
>
> Signed-off-by: Heiner Kallweit
> Signed-off-by: Tao Ren
A kind reminder: could someone help to review the patch when you have bandwid
On 8/15/19 4:36 PM, Florian Fainelli wrote:
> On 8/11/19 4:40 PM, Tao Ren wrote:
>> The BCM54616S PHY cannot work properly in RGMII->1000Base-X mode, mainly
>> because genphy functions are designed for copper links, and 1000Base-X
>> (clause 37) auto negotiation needs t
On 8/15/19 4:15 PM, Vladimir Oltean wrote:
> Hi Tao,
>
> On Fri, 16 Aug 2019 at 02:13, Tao Ren wrote:
>>
>> Hi Andrew / Florian / Heiner / Vladimir,
>>
>> Any further suggestions on the patch series?
>>
>>
>> Thanks,
>>
>> Tao
>&g
Hi Andrew / Florian / Heiner / Vladimir,
Any further suggestions on the patch series?
Thanks,
Tao
On 8/11/19 4:40 PM, Tao Ren wrote:
> The BCM54616S PHY cannot work properly in RGMII->1000Base-X mode, mainly
> because genphy functions are designed for copper links, and 1000Base-X
>
From: Heiner Kallweit
This patch adds support for clause 37 1000Base-X auto-negotiation.
Signed-off-by: Heiner Kallweit
Signed-off-by: Tao Ren
---
Changes in v7:
- Update "if (AUTONEG_ENABLE != phydev->autoneg)" to
"if (phydev->autoneg != AUTONEG_ENABLE)"
Modify the assignment to OR when dealing with phydev->dev_flags in
phy_attach_direct function, and this is to make sure dev_flags set in
driver's probe callback won't be lost.
Suggested-by: Andrew Lunn
CC: Heiner Kallweit
CC: Vladimir Oltean
Signed-off-by: Tao Ren
Reviewed-by: Andrew L
e-FX mode, and
100Base-FX support is not available as of now.
Signed-off-by: Tao Ren
---
Changes in v7:
- Add comment "BCM54616S 100Base-FX is not supported".
Changes in v6:
- nothing changed.
Changes in v5:
- include Heiner's patch "net: phy: add support for clause 37
auto-nego
On 8/9/19 2:59 PM, Heiner Kallweit wrote:
> On 09.08.2019 23:13, Tao Ren wrote:
>> On 8/9/19 1:54 PM, Tao Ren wrote:
>>> Hi Heiner,
>>>
>>> On 8/9/19 1:21 PM, Heiner Kallweit wrote:
>>>> On 09.08.2019 07:44, Tao Ren wrote:
>>>>> Th
On 8/9/19 1:54 PM, Tao Ren wrote:
> Hi Heiner,
>
> On 8/9/19 1:21 PM, Heiner Kallweit wrote:
>> On 09.08.2019 07:44, Tao Ren wrote:
>>> The BCM54616S PHY cannot work properly in RGMII->1000Base-KX mode (for
>>> example, on Facebook CMM BMC platfo
Hi Heiner,
On 8/9/19 1:21 PM, Heiner Kallweit wrote:
> On 09.08.2019 07:44, Tao Ren wrote:
>> The BCM54616S PHY cannot work properly in RGMII->1000Base-KX mode (for
>> example, on Facebook CMM BMC platform), mainly because genphy functions
>> are designed for copper links
Modify the assignment to OR when dealing with phydev->dev_flags in
phy_attach_direct function, and this is to make sure dev_flags set in
driver's probe callback won't be lost.
Suggested-by: Andrew Lunn
CC: Heiner Kallweit
CC: Vladimir Oltean
Signed-off-by: Tao Ren
Reviewed-by: Andrew L
From: Heiner Kallweit
This patch adds support for clause 37 1000Base-X auto-negotiation.
Signed-off-by: Heiner Kallweit
Signed-off-by: Tao Ren
---
Changes in v6:
- add "Signed-off-by: Tao Ren "
Changes in v1-v5:
- nothing changed. It's given v6 just to align with t
ode; otherwise, genphy_config_aneg will be called.
- read_status: calls genphy_c37_read_status when the PHY is running in
1000Base-X mode; otherwise, genphy_read_status will be called.
Signed-off-by: Tao Ren
---
Changes in v6:
- nothing changed.
Changes in v5:
- include Heiner's patch "
On 8/8/19 4:03 PM, Andrew Lunn wrote:
>> After giving it more thought, I'm thinking about adding ncsi dt node
>> with following structure (mac/ncsi similar to mac/mdio/phy):
>>
>> {
>> /* MAC properties... */
>>
>> use-ncsi;
>
> This property seems to be specific to Faraday FTGMAC100.
On 8/8/19 9:58 PM, Vladimir Oltean wrote:
> On Fri, 9 Aug 2019 at 02:48, Tao Ren wrote:
>>
>> From: Heiner Kallweit
>>
>> This patch adds support for clause 37 1000Base-X auto-negotiation.
>> It's compile-tested only as I don't have fiber equipment.
>
ode; otherwise, genphy_config_aneg will be called.
- read_status: calls genphy_c37_read_status when the PHY is running in
1000Base-X mode; otherwise, genphy_read_status will be called.
Signed-off-by: Tao Ren
---
Changes in v5:
- include Heiner's patch "net: phy: add support for clause 37
Modify the assignment to OR when dealing with phydev->dev_flags in
phy_attach_direct function, and this is to make sure dev_flags set in
driver's probe callback won't be lost.
Suggested-by: Andrew Lunn
CC: Heiner Kallweit
CC: Vladimir Oltean
Signed-off-by: Tao Ren
Reviewed-by: Andrew L
From: Heiner Kallweit
This patch adds support for clause 37 1000Base-X auto-negotiation.
It's compile-tested only as I don't have fiber equipment.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy_device.c | 139 +++
include/linux/phy.h | 5 ++
On 8/8/19 3:11 PM, Heiner Kallweit wrote:
> On 08.08.2019 23:47, Tao Ren wrote:
>> Hi Heiner,
>>
>> On 8/7/19 9:24 PM, Tao Ren wrote:
>>> Hi Heiner,
>>>
>>> On 8/7/19 12:18 PM, Heiner Kallweit wrote:
>>>> On 06.08.2019 23:42, Tao Ren wr
On 8/8/19 2:16 PM, Andrew Lunn wrote:
> On Thu, Aug 08, 2019 at 07:02:54PM +0000, Tao Ren wrote:
>> Hi Andrew,
>>
>> On 8/8/19 6:32 AM, Andrew Lunn wrote:
>>>> Let me prepare patch v2 using device tree. I'm not sure if standard
>>>> "ma
Hi Heiner,
On 8/7/19 9:24 PM, Tao Ren wrote:
> Hi Heiner,
>
> On 8/7/19 12:18 PM, Heiner Kallweit wrote:
>> On 06.08.2019 23:42, Tao Ren wrote:
>>> Hi Andrew / Heiner / Vladimir,
>>>
>>> On 8/6/19 2:09 PM, Tao Ren wrote:
>>>> The BCM5461
Hi Andrew,
On 8/8/19 6:32 AM, Andrew Lunn wrote:
>> Let me prepare patch v2 using device tree. I'm not sure if standard
>> "mac-address" fits this situation because all we need is an offset
>> (integer) and BMC MAC is calculated by adding the offset to NIC's
>> MAC address. Anyways, let me work
On 8/7/19 10:36 AM, Vijay Khemka wrote:
> Lgtm except one small comment below.
>
> On 8/6/19, 5:22 PM, "openbmc on behalf of Tao Ren"
> tao...@fb.com> wrote:
>
> Currently BMC's MAC address is calculated by adding 1 to NCSI NIC's base
> MAC addres
On 8/7/19 11:41 AM, Andrew Lunn wrote:
> On Wed, Aug 07, 2019 at 11:25:18AM -0700, Jakub Kicinski wrote:
>> On Tue, 6 Aug 2019 17:21:18 -0700, Tao Ren wrote:
>>> Currently BMC's MAC address is calculated by adding 1 to NCSI NIC's base
>>> MAC address when CONFIG_
Hi Heiner,
On 8/7/19 12:18 PM, Heiner Kallweit wrote:
> On 06.08.2019 23:42, Tao Ren wrote:
>> Hi Andrew / Heiner / Vladimir,
>>
>> On 8/6/19 2:09 PM, Tao Ren wrote:
>>> The BCM54616S PHY cannot work properly in RGMII->1000Base-KX mode (for
>>> exam
address ("BaseMAC + 1" is reserved for Host use).
This patch adds NET_NCSI_MC_MAC_OFFSET config option to customize offset
between NIC's Base MAC address and BMC's MAC address. Its default value is
set to 1 to avoid breaking existing users.
Signed-off-by: Tao Ren
---
net/ncsi/Kconf
On 8/6/19 3:00 PM, Heiner Kallweit wrote:
> On 06.08.2019 23:09, Tao Ren wrote:
>> The BCM54616S PHY cannot work properly in RGMII->1000Base-KX mode (for
>> example, on Facebook CMM BMC platform), mainly because genphy functions
>> are designed for copper links, and 100
Hi Andrew / Heiner / Vladimir,
On 8/6/19 2:09 PM, Tao Ren wrote:
> The BCM54616S PHY cannot work properly in RGMII->1000Base-KX mode (for
> example, on Facebook CMM BMC platform), mainly because genphy functions
> are designed for copper links, and 1000Base-X (clause 37) auto negotia
ion in 1000Base-X mode.
- read_status: BCM54616S and BCM5482 PHY share the same read_status
callback which manually set link speed and duplex mode in 1000Base-X
mode.
Signed-off-by: Tao Ren
---
Changes in v4:
- add bcm54616s_config_aneg_1000bx() to deal with auto negotiation in
1000Base-X m
Modify the assignment to OR when dealing with phydev->dev_flags in
phy_attach_direct function, and this is to make sure dev_flags set in
driver's probe callback won't be lost.
Suggested-by: Andrew Lunn
CC: Heiner Kallweit
CC: Vladimir Oltean
Signed-off-by: Tao Ren
---
Changes:
- noth
On 8/5/19 1:45 PM, Heiner Kallweit wrote:
> On 04.08.2019 21:22, Vladimir Oltean wrote:
>> On Sun, 4 Aug 2019 at 19:07, Heiner Kallweit wrote:
>>>
>>> On 04.08.2019 17:59, Vladimir Oltean wrote:
On Sun, 4 Aug 2019 at 17:52, Andrew Lunn wrote:
>
>>> The patchset looks better now. But
Modify the assignment to OR when dealing with phydev->dev_flags in
phy_attach_direct function, and this is to make sure dev_flags set in
driver's probe callback won't be lost.
Suggested-by: Andrew Lunn
CC: Heiner Kallweit
CC: Vladimir Oltean
Signed-off-by: Tao Ren
---
drivers/net/
Hi Andrew,
On 8/4/19 7:51 AM, Andrew Lunn wrote:
>>> The patchset looks better now. But is it ok, I wonder, to keep
>>> PHY_BCM_FLAGS_MODE_1000BX in phydev->dev_flags, considering that
>>> phy_attach_direct is overwriting it?
>>
>
>> I checked ftgmac100 driver (used on my machine) and it calls
Hi Vladimir,
On 8/3/19 6:49 AM, Vladimir Oltean wrote:
> Hi Tao,
>
> On Sat, 3 Aug 2019 at 00:56, Tao Ren wrote:
>>
>> genphy_read_status() cannot report correct link speed when BCM54616S PHY
>> is configured in RGMII->1000Base-KX mode (for example, o
d_status" callback if PHY-switch link is 1000Base-X.
Signed-off-by: Tao Ren
---
Changes in v3:
- rename bcm5482_read_status to bcm54xx_read_status so the callback can
be shared by BCM5482 and BCM54616S.
Changes in v2:
- Auto-detect PHY operation mode instead of passing DT node.
On 8/2/19 7:50 AM, Andrew Lunn wrote:
>> +static int bcm54616s_read_status(struct phy_device *phydev)
>> +{
>> +int err;
>> +
>> +err = genphy_read_status(phydev);
>> +
>> +/* 1000Base-X register set doesn't provide speed fields: the
>> + * link speed is always 1000 Mb/s as long as
On 8/1/19, 10:26 PM, "Joel Stanley" wrote:
> I've applied both of these to the aspeed tree for 5.4.
Thank you Joel.
Cheers,
Tao
On 8/1/19, 9:21 PM, "Joel Stanley" wrote:
> On Fri, 2 Aug 2019 at 04:10, Tao Ren wrote:
>>
>> Add initial version of device tree for Facebook Wedge100 AST2400 BMC
>> platform.
>>
>> Signed-off-by: Tao Ren
>> Reviewed-by: Andrew Jeffery
&g
Add initial version of device tree for Facebook Wedge100 AST2400 BMC
platform.
Signed-off-by: Tao Ren
Reviewed-by: Andrew Jeffery
---
Changes in v2:
- remove "debug" from bootargs.
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/aspeed-bmc-facebook-wedge100
Add initial version of device tree for Facebook Wedge40 AST2400 BMC
platform.
Signed-off-by: Tao Ren
Reviewed-by: Andrew Jeffery
---
Changes in v2:
- remove "debug" from bootargs.
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/aspeed-bmc-facebook-wedge40.
On 8/1/19, 7:56 PM, "Andrew Jeffery" wrote:
>On Fri, 2 Aug 2019, at 10:24, Tao Ren wrote:
>> Add initial version of device tree for Facebook Wedge40 AST2400 BMC
>> platform.
>>
>> Signed-off-by: Tao Ren
>
> Reviewed-by: Andrew Jeffery
Tha
On 8/1/19, 8:02 PM, "Joel Stanley" wrote:
> On Fri, 2 Aug 2019 at 01:02, Tao Ren wrote:
>> +
>> + chosen {
>> + stdout-path =
>> + bootargs = "debug console=ttyS2,9600n8 root=/dev/ram rw";
>
>
On 7/31/19 10:20 PM, Tao Ren wrote:
> On 7/30/19 11:00 PM, Tao Ren wrote:
>> On 7/30/19 10:53 PM, Heiner Kallweit wrote:
>>> On 31.07.2019 02:12, Tao Ren wrote:
>>>> On 7/29/19 11:00 PM, Heiner Kallweit wrote:
>>>>> On 30.07.2019 07:05, Tao Ren wrote:
Add initial version of device tree for Facebook Wedge100 AST2400 BMC
platform.
Signed-off-by: Tao Ren
---
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/aspeed-bmc-facebook-wedge100.dts | 149 ++
2 files changed, 150 insertions(+)
create mode 100644 arch
Add initial version of device tree for Facebook Wedge40 AST2400 BMC
platform.
Signed-off-by: Tao Ren
---
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/aspeed-bmc-facebook-wedge40.dts | 141 ++
2 files changed, 142 insertions(+)
create mode 100644 arch/arm
d_status" callback if PHY-switch link is 1000Base-X.
Signed-off-by: Tao Ren
---
Changes in v2:
- Auto-detect PHY operation mode instead of passing DT node.
- move PHY mode auto-detect logic from config_init to probe callback.
- only set speed (not including duplex) in read_status cal
On 7/30/19 11:00 PM, Tao Ren wrote:
> On 7/30/19 10:53 PM, Heiner Kallweit wrote:
>> On 31.07.2019 02:12, Tao Ren wrote:
>>> On 7/29/19 11:00 PM, Heiner Kallweit wrote:
>>>> On 30.07.2019 07:05, Tao Ren wrote:
>>>>> On 7/29/19 8:35 PM, Andrew Lunn wro
On 7/30/19 10:55 PM, Tao Ren wrote:
> On 7/30/19 7:34 PM, Andrew Lunn wrote:
>>> Hi Andrew,
>>>
>>> The BCM54616S PHY on my machine is connected to a BCM5396 switch chip over
>>> backplane (1000Base-KX).
>>
>> Ah, that is different. So the bo
On 7/30/19 10:53 PM, Heiner Kallweit wrote:
> On 31.07.2019 02:12, Tao Ren wrote:
>> On 7/29/19 11:00 PM, Heiner Kallweit wrote:
>>> On 30.07.2019 07:05, Tao Ren wrote:
>>>> On 7/29/19 8:35 PM, Andrew Lunn wrote:
>>>>> On Mon, Jul 29, 2019 at 05:2
On 7/30/19 7:34 PM, Andrew Lunn wrote:
>> Hi Andrew,
>>
>> The BCM54616S PHY on my machine is connected to a BCM5396 switch chip over
>> backplane (1000Base-KX).
>
> Ah, that is different. So the board is using it for RGMII to 1000Base-KX?
>
> phy-mode is about the MAC-PHY link. So in this case
On 7/30/19 6:36 PM, Andrew Lunn wrote:
>> The INTF_SEL pins report correct mode (RGMII-Fiber) on my machine,
>> but there are 2 "sub-modes" (1000Base-X and 100Base-FX) and I
>> couldn't find a proper/safe way to auto-detect which "sub-mode" is
>> active. The datasheet just describes instructions
On 7/30/19 6:17 AM, Andrew Lunn wrote:
>> Again, I don't think Linux has generic support for overwriting (or
>> even describing) the operating mode of a PHY, although maybe that's a
>> direction we would want to push the discussion towards. RGMII to
>> copper, RGMII to fiber, SGMII to copper,
On 7/29/19 11:00 PM, Heiner Kallweit wrote:
> On 30.07.2019 07:05, Tao Ren wrote:
>> On 7/29/19 8:35 PM, Andrew Lunn wrote:
>>> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote:
>>>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcde
On 7/30/19 3:15 AM, Vladimir Oltean wrote:
> On Tue, 30 Jul 2019 at 07:52, Tao Ren wrote:
>>
>> On 7/29/19 6:32 PM, Vladimir Oltean wrote:
>>> Hi Tao,
>>>
>>> On Tue, 30 Jul 2019 at 03:31, Tao Ren wrote:
>>>>
>>>> Conf
On 7/29/19 8:35 PM, Andrew Lunn wrote:
> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote:
>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc
>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic
>
On 7/29/19 6:32 PM, Vladimir Oltean wrote:
> Hi Tao,
>
> On Tue, 30 Jul 2019 at 03:31, Tao Ren wrote:
>>
>> Configure the BCM54616S for 1000Base-X mode when "brcm-phy-mode-1000bx"
>> is set in device tree. This is needed when the PHY is used f
On 6/20/19 1:13 AM, Tao Ren wrote:
> On 6/20/19 1:01 AM, Ryan Chen wrote:
>> Hello Tao,
>> Let me more clear. When you set (3, 15, 14) the device sometimes
>> response nack.
>> but when you set (4, 7, 7), the device always ack. Am I right?
>> Ryan
&
On 6/20/19 1:01 AM, Ryan Chen wrote:
> Hello Tao,
> Let me more clear. When you set (3, 15, 14) the device sometimes
> response nack.
> but when you set (4, 7, 7), the device always ack. Am I right?
> Ryan
Hello Ryan,
It's correct. We have seen the problem on 2 Facebook BMC
1 - 100 of 146 matches
Mail list logo
