Thread (33 messages) 33 messages, 4 authors, 2019-05-28

Re: [PATCH 09/16] mmc: sdhci-xenon: use new match_string() helper/macro

From: Dan Carpenter <hidden>
Date: 2019-05-10 11:04:01
Also in: alsa-devel, cgroups, dri-devel, intel-gfx, linux-arm-kernel, linux-gpio, linux-ide, linux-mm, linux-mmc, linux-omap, linux-pm, linux-rockchip, linux-tegra

On Fri, May 10, 2019 at 09:13:26AM +0000, Ardelean, Alexandru wrote:
On Wed, 2019-05-08 at 16:26 +0300, Alexandru Ardelean wrote:
quoted
On Wed, 2019-05-08 at 15:20 +0300, Dan Carpenter wrote:
quoted

On Wed, May 08, 2019 at 02:28:35PM +0300, Alexandru Ardelean wrote:
quoted
-static const char * const phy_types[] = {
-     "emmc 5.0 phy",
-     "emmc 5.1 phy"
-};
-
 enum xenon_phy_type_enum {
      EMMC_5_0_PHY,
      EMMC_5_1_PHY,
      NR_PHY_TYPES
There is no need for NR_PHY_TYPES now so you could remove that as well.
I thought the same.
The only reason to keep NR_PHY_TYPES, is for potential future patches,
where it would be just 1 addition

 enum xenon_phy_type_enum {
      EMMC_5_0_PHY,
      EMMC_5_1_PHY,
+      EMMC_5_2_PHY,
      NR_PHY_TYPES
  }

Depending on style/preference of how to do enums (allow comma on last
enum
or not allow comma on last enum value), adding new enum values woudl be 2
additions + 1 deletion lines.

 enum xenon_phy_type_enum {
      EMMC_5_0_PHY,
-      EMMC_5_1_PHY
+      EMM
C_5_1_PHY,
+      EMMC_5_2_PHY
 }

Either way (leave NR_PHY_TYPES or remove NR_PHY_TYPES) is fine from my
side.
Preference on this ?
If no objection [nobody insists] I would keep.

I don't feel strongly about it [dropping NR_PHY_TYPES or not].
If you end up resending the series could you remove it, but if not then
it's not worth it.

regards,
dan carpenter
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help