Hi Rob,
Thanks for your comment and sorry for late response.
>> -minItems: 1
>> -maxItems: 2
>> +minItems: 2
>> +maxItems: 3
>
>1 entry was valid and now it is not? That's not a compatible change and
>needs an explanation at a minimum.
Yes, as the driver returns error in the
Hi Rob,
Thanks for your comments.
>> Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
>> This binding is not used in any upstreamed DTS yet, so changing
>> index of property 'j721e-intg' should not affect anything.
>
>TI folks might disagree, but weren't Cc'ed.
Kishon and
>> >>> Is this a property of the hardware, that is, are there multiple versions
>> >>> of this IP core covered by the same compatible string that support HDCP
>> >>> 1.4 only, DHCP 2.2 only or both ? Or is it a way to select what a given
>> >>> system will offer ?[]
>> >>
>> >> MHDP hardware
>; prane...@ti.com; Parshuram Raju Thombare
>
>Subject: [PATCH v10 0/7] I3C mastership handover support
>
>Main changes between v9 and v10 are:
>- Fix build failure reported by kernel test robot
>
>Main changes between v8 and v9 are:
>- Fix NULL dereference issue in current_master_
...@ti.com; Parshuram Raju Thombare
>
>Subject: [RESEND PATCH v9 0/7] I3C mastership handover support
>
>Main changes between v8 and v9 are:
>- Fix NULL dereference issue in current_master_show when
> cat'ing sysfs key current_master for secondary master
> before primar
Hi Laurent,
>> > Is this a property of the hardware, that is, are there multiple versions
>> > of this IP core covered by the same compatible string that support HDCP
>> > 1.4 only, DHCP 2.2 only or both ? Or is it a way to select what a given
>> > system will offer ?[]
>>
>> MHDP hardware
Hi Laurent,
>Is this a property of the hardware, that is, are there multiple versions
>of this IP core covered by the same compatible string that support HDCP
>1.4 only, DHCP 2.2 only or both ? Or is it a way to select what a given
>system will offer ?[]
MHDP hardware supports both HDCP 2.2 and
Hi Robert,
Thanks for your review comments.
I will fix this in next version of patch set.
Regards,
Parshuram Thombare
>-Original Message-
>From: Robert Foss
>Sent: Friday, February 26, 2021 10:06 PM
>To: Parshuram Raju Thombare
>Cc: Rob Herring ; Laurent Pinchart
>I'm not sure about the logic here. Why would the secondary master
>initialize the bus? If you make a distinction between primary and
>secondary, then the primary should be the owner of the bus and it should
>have enumerated it already. You should populate the bus structure with
>info provided by
>This looks a bit confusing. Here you're rolling back detailss in
>i3c_primary_master_register() that were factored out in
>i3c_master_init(). If i3c_master_init() is successful, then you
>shouldn't be undoing its things openly in i3c_primary_master_register().
>Instead, there should be another
Hi Russell,
It seems apart from changes in driver, we also need check for NULL pcs_config
below or make pcs_config as mandatory method for registering pcs_ops.
456 if (pl->pcs_ops) {
457 err = pl->pcs_ops->pcs_config(pl->pcs,
pl->cur_link_an_mode,
458
hylink, >phylink_pcs);
Regards,
Parshuram Thombare
>-Original Message-
>From: nicolas.fe...@microchip.com
>Sent: Wednesday, November 4, 2020 6:59 PM
>To: Parshuram Raju Thombare ; k...@kernel.org;
>linux-arm-ker...@lists.infradead.org; net...@vger.kernel.org
>Cc: claudiu.
>Whenever the interface changes, we go through the full reconfiguration
>procedure that I've already outlined. This involves calling the
>mac_prepare() method which calls into mvpp2_mac_prepare() and its
>child mvpp2__mac_prepare().
Ok, I misunderstood it as interface mode change between
Hi,
I was trying to find out any ethernet driver where this issue of selecting
appropriate
pcs_ops due to phylink changing interface mode dynamically is handled.
But, apparently, so far only mvpp2 has adapted pcs_ops. And even in mvpp2, it is
not obvious how this case is handled.
Also, apart
>If you're going to support pcs_ops for the 10GBASE-R mode, can you
>also convert macb to use pcs_ops for the lower speed modes as well?
Ok, I will add pcs_ops for low speed as well. In fact, having single
pcs_ops and using check for interface type within each method of
pcs_ops to decide
kernel.org; Milind Parab ;
>prane...@ti.com; Parshuram Raju Thombare
>Subject: [PATCH v5] i3c: master: fix for SETDASA and DAA process
>
>This patch fixes the following issue.
>Controller slots blocked for the devices with only static_addr
>or init_dyn_addr may limit the number o
>Hm, not sure that qualifies as a fix. The current implementation was
>correct, it was just reserving a slot in the device table for devices
>that didn't have an init address or on which SETDASA failed.
If I3C controllers like ours use hardware slots to store slave devices info,
due to limited
Hi Boris,
Thanks for your comments.
>> + * We anyway don't attach devices which are not addressable
>
>You can drop the anyway.
Sure, I will make above mentioned change in the comment.
>> + * (no static_addr and dyn_addr) and devices with static_addr
>> + * but no init_dyn_addr will
>> This patch fix following issues.
>> 1. Controller slots blocked for devices with static_addr
>>but no init_dyn_addr may limit the number of I3C devices
>>on the bus which gets dynamic address in DAA. So
>>instead of attaching all the devices with static_addr,
>>now we only
>Can you really select the bus mode without knowing the I3C devices you
>have on the bus? Or maybe that's a preliminary initialization which is
>then updated when you receive DEFSLVS events.
I think we can select bus mode based on knowledge of I2C devices on the
bus. I was expecting to support
>Those waits should be done in the master driver. Pass a timeout to
>->request_master() or make it a property of the i3c_master_controller
>if you like, but don't poll the status from the core.
Ok, I will move these pollings, check master has DA and MR done to
master driver method
>> Document describing secondary master initialization,
>> mastership handover and DEFSLVS handling processes.
>
>Thanks for doing that, but you probably didn't try to compile the doc
>(the formatting is all messed up).
>
># make htmldocs
Yes, it looks messed in email but I built html format of
>> +/**
>> + * i3c_master_register() - register an I3C master
>
>The function should be renamed and the doc updated to reflect the fact
>that it only works for primary masters:
>
>i3c_primary_master_register() - register a primary I3C master
Sure, I will do that.
>> + * @master: master used to
Hi Andrew,
>One thing which was never clear is how you are testing the features you are
>adding. Please could you describe your test setup and how each new feature
>is tested using that hardware. I'm particularly interested in what C45 device
>are you using? But i expect Russell would like to
Hi David,
Ok, I will resubmit it.
Regards,
Parshuram Thombare
>The closed nature of the USXGMII spec makes it very hard for us to know
>whether your implementation is correct or not.
>
>I have some documentation which suggests that USVGMII is a USXGMII link
>running at "5GR" rate as opposed to USXGMII running at "10GR" rate.
>
>So, I think 5G mode should be
>If you are interested in supporting SFPs as well, then using phylink
>makes sense, but you need to implement your phylink conversion properly,
>and that means supporting dynamic switching of the PHY interface mode,
>and allowing phylink to determine whether a PHY interface mode is
>supported or
>> >In which case, gem_phylink_validate() must clear the support mask when
>> >SGMII mode is requested to indicate that the interface mode is not
>> >supported.
>> >The same goes for _all_ other PHY link modes that the hardware does not
>> >actually support, such as PHY_INTERFACE_MODE_10GKR...
>> >> switch (state->interface) {
>> >> case PHY_INTERFACE_MODE_NA:
>> >> + case PHY_INTERFACE_MODE_USXGMII:
>> >> + case PHY_INTERFACE_MODE_10GKR:
>> >> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
>> >> + phylink_set(mask, 1baseCR_Full);
>> >> +
>> +if (change_interface) {
>> +bp->phy_interface = state->interface;
>> +gem_writel(bp, NCR, ~GEM_BIT(TWO_PT_FIVE_GIG) &
>> + gem_readl(bp, NCR));
>This could do with a comment, such as the one I gave in my example.
Sure. I will add a comment
>> +static inline void gem_mac_configure(struct macb *bp, int speed)
>> +switch (speed) {
>> +case SPEED_1000:
>> +gem_writel(bp, NCFGR, GEM_BIT(GBE) |
>> + gem_readl(bp, NCFGR));
>> +break;
>> +case SPEED_100:
>> +
>> switch (state->interface) {
>> case PHY_INTERFACE_MODE_NA:
>> +case PHY_INTERFACE_MODE_USXGMII:
>> +case PHY_INTERFACE_MODE_10GKR:
>> +if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
>> +phylink_set(mask, 1baseCR_Full);
>> +
Hi Andrew,
>What i'm saying is that the USXGMII rate is fixed. So why do you need a device
>tree property for the SERDES rate?
This is based on Cisco USXGMII specification, it specify USXGMII 5G and USXGMII
10G.
Sorry I can't share that document here.
Regards,
Parshuram Thombare
>> >Sorry, this reply doesn't answer my question. I'm not asking about
>> >bp->speed and bp->duplex. I'm asking:
>> >1) why you are initialising bp->phy_interface here
>> >2) you to consider the impact that has on the mac_config() implementation
>> > you are proposing
>> > because I think it's
>However, it seems from that comment that you're not talking about real
>hardware. Is there no real hardware out there supporting 10G mode with
>these proposed driver changes yet?
I think there are some 10GBaseT PHY out there, but I don't have any test
setup with those. This patch is tested on
>> >I still don't think this makes much sense, splitting the interface
>> > configuration between here and below.
>> Do you mean splitting mac_config in two *_configure functions ?
>> This was done as per Andrew's suggestion to make code mode readable
>> and easy to manage by splitting MAC
Hi Andrew,
>> +enum {
>> +MACB_SERDES_RATE_5_PT_15625Gbps = 5,
>> +MACB_SERDES_RATE_10_PT_3125Gbps = 10,
>> +};
>What do the units mean here? Why would you clock the SERDES at 15Tbps,
>or 3Tbps? 3.125Mbps would give you 2.5Gbps when using 8b/10b encoding.
>
MACB_SERDES_RATE_5_PT_15625Gbps
>Which Clause 45 PHY are you using?
I am using emulated PHY in our CSP environment.
This is using 10G generic PHY driver, with PHY having compatible =
"ethernet-phy-ieee802.3-c45"
Hi Andrew,
Can I add your "Reviewed-by" tag for this patch. You added it to this patch in
last series.
Regards,
>> +if (change_interface) {
>> +if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
>> +gem_writel(bp, NCFGR, ~GEM_BIT(SGMIIEN) &
>> + ~GEM_BIT(PCSSEL) &
>> + gem_readl(bp, NCFGR));
>> +
>From: Russell King - ARM Linux admin
>On Sun, Jun 23, 2019 at 10:17:37AM +0100, Parshuram Thombare wrote:
>> +switch (state->interface) {
>> +case PHY_INTERFACE_MODE_GMII:
>> +case PHY_INTERFACE_MODE_RGMII:
>> +if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
>> +
Hi Andrew,
>On Fri, Jun 21, 2019 at 09:33:57AM +0100, Parshuram Thombare wrote:
>> Hello !
>>
>> 2. 0002-net-macb-add-support-for-sgmii-MAC-PHY-interface.patch
>>This patch add support for SGMII mode.
>
>Hi Parshuram
>
>What PHYs are using to test this? You mention TI PHY DP83867, but that
>From: Russell King - ARM Linux admin
>
>On Wed, Jun 19, 2019 at 11:23:01AM +, Parshuram Raju Thombare wrote:
>
>> >From: Russell King - ARM Linux admin
>
>> >
>
>> >On Wed, Jun 19, 2019 at 09:40:46AM +0100, Parshuram Thombare wrote:
>
>>
>From: Russell King - ARM Linux admin
>
>On Wed, Jun 19, 2019 at 09:40:46AM +0100, Parshuram Thombare wrote:
>
>> This patch add support for SGMII interface) and
>
>> 2.5Gbps MAC in Cadence ethernet controller driver.
>> switch (state->interface) {
>
>> +case PHY_INTERFACE_MODE_SGMII:
>
Hi Russel,
Thanks for review comments.
>On Wed, Jun 19, 2019 at 09:40:36AM +0100, Parshuram Thombare wrote:
>
>> +bitmap_and(supported, supported, mask,
>__ETHTOOL_LINK_MODE_MASK_NBITS);
>
>> +bitmap_and(state->advertising, state->advertising, mask,
>
>> +
Hi Andrew,
Sure, I will Cc Russel King in next version of patch series.
Regards,
Parshuram Thombare
>-Original Message-
>From: Andrew Lunn
>Sent: Wednesday, June 19, 2019 3:03 AM
>To: Parshuram Raju Thombare
>Cc: nicolas.fe...@microchip.com; da...@davemloft.net;
>f.
Hi Florian,
>Please don't resubmit individual patches as replies to your previous
>ones, re-submitting the entire patch series, see this netdev-FAQ section
>for details:
I will resubmit entire patch series separately.
>
>> +- serdes-rate External serdes rate.Mandatory for USXGMII mode.
>
>> +
>> @@ -4217,8 +4257,8 @@ static int macb_probe(struct platform_device *pdev)
>>
>> tasklet_init(>hresp_err_tasklet, macb_hresp_error_task,
>> (unsigned long)bp);
>> -
>> -phy_attached_info(phydev);
>> +if (dev->phydev)
>> +phy_attached_info(dev->phydev);
>On Sun, Jun 16, 2019 at 12:49:39AM +0100, Parshuram Thombare wrote:
>> New parameters added to Cadence ethernet controller DT binding for
>> USXGMII interface.
>>
>> Signed-off-by: Parshuram Thombare
>> ---
>> Documentation/devicetree/bindings/net/macb.txt | 4
>> 1 file changed, 4
>
>> switch (state->interface) {
>> +case PHY_INTERFACE_MODE_NA:
>
>I would not list PHY_INTERFACE_MODE_NA here.
>
This was to experiment in band mode with sfp.
phylink_sfp_module_insert call phylink_validate with interface set to
PHY_INTERFACE_MODE_NA
, if it is not listed in validate
Andrew Lunn
>Sent: Monday, June 17, 2019 8:38 PM
>To: Parshuram Raju Thombare
>Cc: nicolas.fe...@microchip.com; da...@davemloft.net; f.faine...@gmail.com;
>net...@vger.kernel.org; hkallwe...@gmail.com; linux-kernel@vger.kernel.org;
>Rafal Ciepiela ; Anil Joy Varughese
>; P
t: Monday, June 17, 2019 8:35 PM
>To: Parshuram Raju Thombare
>Cc: nicolas.fe...@microchip.com; da...@davemloft.net; f.faine...@gmail.com;
>net...@vger.kernel.org; hkallwe...@gmail.com; linux-kernel@vger.kernel.org;
>Rafal Ciepiela ; Anil Joy Varughese
>; Piotr Sroka
>Subject: Re:
>> @@ -159,6 +160,9 @@
>> #define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */
>> #define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */
>> #define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */
>> +#define GEM_PCS_CTRL0x0200 /* PCS
; nicolas.fe...@microchip.com; da...@davemloft.net;
>f.faine...@gmail.com
>Cc: net...@vger.kernel.org; hkallwe...@gmail.com; linux-
>ker...@vger.kernel.org; Rafal Ciepiela ; Anil Joy
>Varughese ; Piotr Sroka ;
>Parshuram Raju Thombare
>Subject: [PATCH 0/6] net: macb patch set cover letter
>Le 2/22/19 à 12:12 PM, Parshuram Thombare a écrit :
>> This patch add support for PCS (for SGMII interface) and 2.5Gbps MAC
>> in Cadence ethernet controller driver.
>
>At a high level you don't seem to be making use of PHYLINK so which 2.5Gbps
>interfaces do you actually support?
>
New ethernet
>Hi,
>
>Le 2/22/19 à 12:11 PM, Parshuram Thombare a écrit :
>> Hello !
>>
>> This patch series contain changes to support high speed MAC and PCS in
>> Cadence ethernet controller driver.
>
>From patch submission perspective, your cover letter and individual patches do
>not appear as a reply to
>On Fri, Feb 22, 2019 at 08:12:42PM +, Parshuram Thombare wrote:
>> This patch modify MDIO read/write functions to support communication
>> with C45 PHY in Cadence ethernet controller driver.
>>
>> Signed-off-by: Parshuram Thombare
>> ---
>> drivers/net/ethernet/cadence/macb.h | 15
>> >On Fri, Feb 22, 2019 at 08:12:42PM +, Parshuram Thombare wrote:
>> >> This patch modify MDIO read/write functions to support
>> >> communication with C45 PHY in Cadence ethernet controller driver.
>> >
>> >Hi Parshuram
>> >
>> >Are all versions of the MDIO controller capable of doing C45?
Regards,
Parshuram Thombare
>-Original Message-
>From: Andrew Lunn
>Sent: Saturday, February 23, 2019 3:12 AM
>To: Parshuram Raju Thombare
>Cc: nicolas.fe...@microchip.com; da...@davemloft.net;
>net...@vger.kernel.org; f.faine...@gmail.com; hkallwe...@gmai
>> if (macb_is_gem(bp)) {
>> -linkmode_copy(phydev->supported, PHY_GBIT_FEATURES);
>> -if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED)
>> -
> linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
>> - phydev->supported);
>> +
>> /* mask with MAC supported features */
>> -if (macb_is_gem(bp) && bp->caps &
>MACB_CAPS_GIGABIT_MODE_AVAILABLE)
>> -phy_set_max_speed(phydev, SPEED_1000);
>> -else
>> -phy_set_max_speed(phydev, SPEED_100);
>> +if (macb_is_gem(bp)) {
>> +
ards,
Parshuram Thombare
>-Original Message-
>From: Ladvine D Almeida
>Sent: Friday, December 14, 2018 1:10 AM
>To: Parshuram Raju Thombare ; Eric Biggers
>
>Cc: ax...@kernel.dk; vinholika...@gmail.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com; mchehab+sams..
Hello Eric,
Thank you for a comment.
>-Original Message-
>From: Eric Biggers
>Sent: Tuesday, December 11, 2018 11:47 PM
>To: Parshuram Raju Thombare
>Cc: ax...@kernel.dk; vinholika...@gmail.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com; mchehab+sams..
Hello Jens,
Thank you for a comment.
>-Original Message-
>From: Jens Axboe
>Sent: Tuesday, December 11, 2018 7:07 PM
>To: Parshuram Raju Thombare ; t...@kernel.org;
>jba...@fb.com; michaelcalla...@fb.com; snit...@redhat.com;
>osan...@fb.com; keith.bu...@intel.com; ming
Hello Greg,
Thank you for comments.
>-Original Message-
>From: Greg KH
>Sent: Tuesday, December 11, 2018 5:34 PM
>To: Parshuram Raju Thombare
>Cc: ax...@kernel.dk; vinholika...@gmail.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com; mchehab+sams.
Hi Christoph,
Thank you for comments.
My comments are inline below.
Regards,
Parshuram Thombare
>-Original Message-
>From: Christoph Hellwig
>Sent: Tuesday, December 11, 2018 7:37 PM
>To: Parshuram Raju Thombare
>Cc: ax...@kernel.dk; vinholika...@gmail.com; j...@lin
65 matches
Mail list logo
