Message ID | 20230724112934.2637802-1-danishanwar@ti.com |
---|---|
Headers | show |
Series | Introduce ICSSG based ethernet Driver | expand |
Hi Simon, On 25/07/23 12:55 pm, Simon Horman wrote: > On Mon, Jul 24, 2023 at 04:59:27PM +0530, MD Danish Anwar wrote: >> Add icssg_config.h / .c and icssg_classifier.c files. These are firmware >> configuration and classification related files. These will be used by >> ICSSG ethernet driver. >> >> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> >> Reviewed-by: Andrew Lunn <andrew@lunn.ch> > > Hi Danish, > > some feedback from my side. > Thanks for the feedback. > ... > >> diff --git a/drivers/net/ethernet/ti/icssg_classifier.c b/drivers/net/ethernet/ti/icssg_classifier.c > > ... > >> +void icssg_class_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac) > > This function appears to be unused. > Perhaps it would be better placed in a later patch? > > Or perhaps not, if it makes it hard to split up the patches nicely. > In which case, perhaps the __maybe_unused annotation could be added, > temporarily. > Due to splitting the patch into 8-9 patches, I had to introduce these helper APIs earlier. All these APIs are helper APIs, they will be used in patch 6 (Introduce ICSSG Prueth driver). I had this concern that some APIs which will be used later but introduced earlier can create some warnings, before splitting the patches. I had raised this concern in [1] and asked Jakub if it would be OK to introduce these APIs earlier. Jakub said it would be fine [2], so I went ahead with this approach. It will make very hard to break patches if these APIs are introduced and used in same patch. > Flagged by clang-16 W=1, and gcc=12 W=1 builds. > Likewise for other issues flagged below regarding > function declarations/definitions. > >> +{ >> + regmap_write(miig_rt, offs[slice].mac0, (u32)(mac[0] | mac[1] << 8 | >> + mac[2] << 16 | mac[3] << 24)); >> + regmap_write(miig_rt, offs[slice].mac1, (u32)(mac[4] | mac[5] << 8)); >> +} >> + >> +/* disable all RX traffic */ >> +void icssg_class_disable(struct regmap *miig_rt, int slice) > > This function is only used in this file. > Please consider making it static. > This is later used in icssg_prueth.c, that is why this is not static. > ... > >> +void icssg_class_default(struct regmap *miig_rt, int slice, bool allmulti) > > This function also appears to be unused. > This is later used in icssg_prueth.c > ... > >> +/* required for SAV check */ >> +void icssg_ft1_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac_addr) > > This function also appears to be unused. > This is later used in icssg_prueth.c > ... > >> diff --git a/drivers/net/ethernet/ti/icssg_config.c b/drivers/net/ethernet/ti/icssg_config.c > > ... > >> +void icssg_config_ipg(struct prueth_emac *emac) > > This function is also only used in this file. > This is later used in icssg_prueth.c > ... > >> +static void icssg_init_emac_mode(struct prueth *prueth) >> +{ >> + /* When the device is configured as a bridge and it is being brought >> + * back to the emac mode, the host mac address has to be set as 0. >> + */ >> + u8 mac[ETH_ALEN] = { 0 }; >> + >> + if (prueth->emacs_initialized) >> + return; >> + >> + regmap_update_bits(prueth->miig_rt, FDB_GEN_CFG1, >> + SMEM_VLAN_OFFSET_MASK, 0); >> + regmap_write(prueth->miig_rt, FDB_GEN_CFG2, 0); >> + /* Clear host MAC address */ >> + icssg_class_set_host_mac_addr(prueth->miig_rt, mac); > This is later used in icssg_prueth.c > icssg_class_set_host_mac_addr() is defined in icssg_classifier.c > but used here in icssg_config.c. > > Please consider providing a declaration of this function, > ideally in a .h file. > The declaration of this function is added later(in patch 6) in icssg_prueth.h > ... > >> +int emac_set_port_state(struct prueth_emac *emac, >> + enum icssg_port_state_cmd cmd) > > This function also appears to be unused. > > ... > >> +void icssg_config_set_speed(struct prueth_emac *emac) > > Ditto. > Both these APIs are later used in icssg_prueth.c > ... [1] https://lore.kernel.org/all/17cd1e70-73bc-78d5-7e9d-7b133d6f464b@ti.com/ [2] https://lore.kernel.org/all/20230720081741.0c32d5e6@kernel.org/
On Tue, Jul 25, 2023 at 01:10:30PM +0530, Md Danish Anwar wrote: > Hi Simon, > > On 25/07/23 12:55 pm, Simon Horman wrote: > > On Mon, Jul 24, 2023 at 04:59:27PM +0530, MD Danish Anwar wrote: > >> Add icssg_config.h / .c and icssg_classifier.c files. These are firmware > >> configuration and classification related files. These will be used by > >> ICSSG ethernet driver. > >> > >> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> > >> Reviewed-by: Andrew Lunn <andrew@lunn.ch> > > > > Hi Danish, > > > > some feedback from my side. > > > > Thanks for the feedback. > > > ... > > > >> diff --git a/drivers/net/ethernet/ti/icssg_classifier.c b/drivers/net/ethernet/ti/icssg_classifier.c > > > > ... > > > >> +void icssg_class_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac) > > > > This function appears to be unused. > > Perhaps it would be better placed in a later patch? > > > > Or perhaps not, if it makes it hard to split up the patches nicely. > > In which case, perhaps the __maybe_unused annotation could be added, > > temporarily. > > > > Due to splitting the patch into 8-9 patches, I had to introduce these helper > APIs earlier. All these APIs are helper APIs, they will be used in patch 6 > (Introduce ICSSG Prueth driver). > > I had this concern that some APIs which will be used later but introduced > earlier can create some warnings, before splitting the patches. > > I had raised this concern in [1] and asked Jakub if it would be OK to introduce > these APIs earlier. Jakub said it would be fine [2], so I went ahead with this > approach. > > It will make very hard to break patches if these APIs are introduced and used > in same patch. Thanks, I understand. In that case my suggestion is to, temporarily, add __maybe_unused, which will allow static analysis tools to work more cleanly over the series. It is just a suggestion, not a hard requirement. Probably something along those lines applies to all the review I provided in my previous email. Please use your discretion here.
On 7/26/2023 1:12 PM, Simon Horman wrote: > On Tue, Jul 25, 2023 at 01:28:21PM +0530, Md Danish Anwar wrote: >> On 25/07/23 1:14 pm, Simon Horman wrote: >>> On Tue, Jul 25, 2023 at 01:10:30PM +0530, Md Danish Anwar wrote: >>>> Hi Simon, >>>> >>>> On 25/07/23 12:55 pm, Simon Horman wrote: >>>>> On Mon, Jul 24, 2023 at 04:59:27PM +0530, MD Danish Anwar wrote: >>>>>> Add icssg_config.h / .c and icssg_classifier.c files. These are firmware >>>>>> configuration and classification related files. These will be used by >>>>>> ICSSG ethernet driver. >>>>>> >>>>>> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> >>>>>> Reviewed-by: Andrew Lunn <andrew@lunn.ch> >>>>> >>>>> Hi Danish, >>>>> >>>>> some feedback from my side. >>>>> >>>> >>>> Thanks for the feedback. >>>> >>>>> ... >>>>> >>>>>> diff --git a/drivers/net/ethernet/ti/icssg_classifier.c b/drivers/net/ethernet/ti/icssg_classifier.c >>>>> >>>>> ... >>>>> >>>>>> +void icssg_class_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac) >>>>> >>>>> This function appears to be unused. >>>>> Perhaps it would be better placed in a later patch? >>>>> >>>>> Or perhaps not, if it makes it hard to split up the patches nicely. >>>>> In which case, perhaps the __maybe_unused annotation could be added, >>>>> temporarily. >>>>> >>>> >>>> Due to splitting the patch into 8-9 patches, I had to introduce these helper >>>> APIs earlier. All these APIs are helper APIs, they will be used in patch 6 >>>> (Introduce ICSSG Prueth driver). >>>> >>>> I had this concern that some APIs which will be used later but introduced >>>> earlier can create some warnings, before splitting the patches. >>>> >>>> I had raised this concern in [1] and asked Jakub if it would be OK to introduce >>>> these APIs earlier. Jakub said it would be fine [2], so I went ahead with this >>>> approach. >>>> >>>> It will make very hard to break patches if these APIs are introduced and used >>>> in same patch. >>> >>> Thanks, I understand. >>> >>> In that case my suggestion is to, temporarily, add __maybe_unused, >>> which will allow static analysis tools to work more cleanly over the >>> series. It is just a suggestion, not a hard requirement. >>> >>> Probably something along those lines applies to all the >>> review I provided in my previous email. Please use your discretion here. >> >> For now I think I will leave it as it is. Let reviewers review all other >> patches. Let's see if there are any other comments on all the patches in this >> series. If there are any more comments on other patches, then while re-spinning >> next revision I will keep this in mind and try to add __maybe_unused tags in >> all APIs that are used later. > > Sure, that sounds reasonable. > I will be adding __maybe_unused tags to all the helper APIs introduced before the main driver patch. In the main driver patch I will be removing all those __maybe_unused tags and all the helper APIs will be back to their original name (without __maybe_unused tags) >> The idea behind splitting the patches was to get them reviewed individually as >> it is quite difficult to get one big patch reviewed as explained by Jakub. And >> these warnings were expected. If there are any other comments on this series, I >> will try to address all of them together in next revision. > > Yes, I understand. > Thanks for splitting things up into multiple patches. > I know that is a lot of work. But it is very helpful. > >> Meanwhile, Please let me know if you have any comments on other patches >> in this series. > > Will do, but I nothing to add at this time.