diff mbox series

[1/3] net: ks8851-ml: Remove 8-bit bus accessors

Message ID 20200210184139.342716-1-marex@denx.de
State Changes Requested
Delegated to: David Miller
Headers show
Series [1/3] net: ks8851-ml: Remove 8-bit bus accessors | expand

Commit Message

Marek Vasut Feb. 10, 2020, 6:41 p.m. UTC 
This driver is mixing 8-bit and 16-bit bus accessors for reasons unknown,
however the speculation is that this was some sort of attempt to support
the 8-bit bus mode.

As per the KS8851-16MLL documentation, all two registers accessed via the
8-bit accessors are internally 16-bit registers, so reading them using
16-bit accessors is fine. The KS_CCR read can be converted to 16-bit read
outright, as it is already a concatenation of two 8-bit reads of that
register. The KS_RXQCR accesses are 8-bit only, however writing the top
8 bits of the register is OK as well, since the driver caches the entire
16-bit register value anyway.

Finally, the driver is not used by any hardware in the kernel right now.
The only hardware available to me is one with 16-bit bus, so I have no
way to test the 8-bit bus mode, however it is unlikely this ever really
worked anyway. If the 8-bit bus mode is ever required, it can be easily
added by adjusting the 16-bit accessors to do 2 consecutive accesses,
which is how this should have been done from the beginning.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Petr Stetiar <ynezz@true.cz>
Cc: YueHaibing <yuehaibing@huawei.com>
---
 drivers/net/ethernet/micrel/ks8851_mll.c | 45 +++---------------------
 1 file changed, 5 insertions(+), 40 deletions(-)

Comments

Lukas Wunner Feb. 10, 2020, 7:31 p.m. UTC | #1 
On Mon, Feb 10, 2020 at 07:41:37PM +0100, Marek Vasut wrote:
> This driver is mixing 8-bit and 16-bit bus accessors for reasons unknown,
> however the speculation is that this was some sort of attempt to support
> the 8-bit bus mode.

ks8851.c was introduced in July 2009 with commit 3ba81f3ece3c.
ks8851_mll.c was introduced two months later with a55c0a0ed415.

Perhaps the 8-bit accesses are remnants of the SPI-version ks8851.c?

Both chips are very similar.  Unfortunately ks8851_mll.c duplicated
much of ks8851.c, instead of separating it into a common portion and
an SPI-specific portion.  I've deduplicated at least the register
macros with commit aae079aa76d0.  It would be great if you could
continue this effort and increase the amount of shared code between
the two drivers.  Right now ks8851_mll.c supports features that
ks8851.c does not, e.g. multicast filtering.  On the other hand
I've fixed bugs in ks8851.c which I believe still exist in ks8851_mll.c,
see 536d3680fd2d for an example.  I didn't apply the fixes to
ks8851_mll.c simply because I don't have hardware with that chip.
I do have access to hardware using ks8851.c.

HTH,

Lukas
Marek Vasut Feb. 10, 2020, 7:44 p.m. UTC | #2 
On 2/10/20 8:31 PM, Lukas Wunner wrote:
> On Mon, Feb 10, 2020 at 07:41:37PM +0100, Marek Vasut wrote:
>> This driver is mixing 8-bit and 16-bit bus accessors for reasons unknown,
>> however the speculation is that this was some sort of attempt to support
>> the 8-bit bus mode.
> 
> ks8851.c was introduced in July 2009 with commit 3ba81f3ece3c.
> ks8851_mll.c was introduced two months later with a55c0a0ed415.
> 
> Perhaps the 8-bit accesses are remnants of the SPI-version ks8851.c?
> 
> Both chips are very similar.  Unfortunately ks8851_mll.c duplicated
> much of ks8851.c, instead of separating it into a common portion and
> an SPI-specific portion.  I've deduplicated at least the register
> macros with commit aae079aa76d0.  It would be great if you could
> continue this effort and increase the amount of shared code between
> the two drivers.  Right now ks8851_mll.c supports features that
> ks8851.c does not, e.g. multicast filtering.  On the other hand
> I've fixed bugs in ks8851.c which I believe still exist in ks8851_mll.c,
> see 536d3680fd2d for an example.  I didn't apply the fixes to
> ks8851_mll.c simply because I don't have hardware with that chip.
> I do have access to hardware using ks8851.c.

Right now I cannot promise that I'll be able to work on this driver
beyond these basic fixes. I'll see what I can do.
diff mbox series

Patch

diff --git a/drivers/net/ethernet/micrel/ks8851_mll.c b/drivers/net/ethernet/micrel/ks8851_mll.c
index a41a90c589db..e2fb20154511 100644
--- a/drivers/net/ethernet/micrel/ks8851_mll.c
+++ b/drivers/net/ethernet/micrel/ks8851_mll.c
@@ -156,24 +156,6 @@  static int msg_enable;
  * chip is busy transferring packet data (RX/TX FIFO accesses).
  */
 
-/**
- * ks_rdreg8 - read 8 bit register from device
- * @ks	  : The chip information
- * @offset: The register address
- *
- * Read a 8bit register from the chip, returning the result
- */
-static u8 ks_rdreg8(struct ks_net *ks, int offset)
-{
-	u16 data;
-	u8 shift_bit = offset & 0x03;
-	u8 shift_data = (offset & 1) << 3;
-	ks->cmd_reg_cache = (u16) offset | (u16)(BE0 << shift_bit);
-	iowrite16(ks->cmd_reg_cache, ks->hw_addr_cmd);
-	data  = ioread16(ks->hw_addr);
-	return (u8)(data >> shift_data);
-}
-
 /**
  * ks_rdreg16 - read 16 bit register from device
  * @ks	  : The chip information
@@ -189,22 +171,6 @@  static u16 ks_rdreg16(struct ks_net *ks, int offset)
 	return ioread16(ks->hw_addr);
 }
 
-/**
- * ks_wrreg8 - write 8bit register value to chip
- * @ks: The chip information
- * @offset: The register address
- * @value: The value to write
- *
- */
-static void ks_wrreg8(struct ks_net *ks, int offset, u8 value)
-{
-	u8  shift_bit = (offset & 0x03);
-	u16 value_write = (u16)(value << ((offset & 1) << 3));
-	ks->cmd_reg_cache = (u16)offset | (BE0 << shift_bit);
-	iowrite16(ks->cmd_reg_cache, ks->hw_addr_cmd);
-	iowrite16(value_write, ks->hw_addr);
-}
-
 /**
  * ks_wrreg16 - write 16bit register value to chip
  * @ks: The chip information
@@ -324,8 +290,7 @@  static void ks_read_config(struct ks_net *ks)
 	u16 reg_data = 0;
 
 	/* Regardless of bus width, 8 bit read should always work.*/
-	reg_data = ks_rdreg8(ks, KS_CCR) & 0x00FF;
-	reg_data |= ks_rdreg8(ks, KS_CCR+1) << 8;
+	reg_data = ks_rdreg16(ks, KS_CCR);
 
 	/* addr/data bus are multiplexed */
 	ks->sharedbus = (reg_data & CCR_SHARED) == CCR_SHARED;
@@ -429,7 +394,7 @@  static inline void ks_read_qmu(struct ks_net *ks, u16 *buf, u32 len)
 
 	/* 1. set sudo DMA mode */
 	ks_wrreg16(ks, KS_RXFDPR, RXFDPR_RXFPAI);
-	ks_wrreg8(ks, KS_RXQCR, (ks->rc_rxqcr | RXQCR_SDA) & 0xff);
+	ks_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr | RXQCR_SDA);
 
 	/* 2. read prepend data */
 	/**
@@ -446,7 +411,7 @@  static inline void ks_read_qmu(struct ks_net *ks, u16 *buf, u32 len)
 	ks_inblk(ks, buf, ALIGN(len, 4));
 
 	/* 4. reset sudo DMA Mode */
-	ks_wrreg8(ks, KS_RXQCR, ks->rc_rxqcr);
+	ks_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr);
 }
 
 /**
@@ -679,13 +644,13 @@  static void ks_write_qmu(struct ks_net *ks, u8 *pdata, u16 len)
 	ks->txh.txw[1] = cpu_to_le16(len);
 
 	/* 1. set sudo-DMA mode */
-	ks_wrreg8(ks, KS_RXQCR, (ks->rc_rxqcr | RXQCR_SDA) & 0xff);
+	ks_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr | RXQCR_SDA);
 	/* 2. write status/lenth info */
 	ks_outblk(ks, ks->txh.txw, 4);
 	/* 3. write pkt data */
 	ks_outblk(ks, (u16 *)pdata, ALIGN(len, 4));
 	/* 4. reset sudo-DMA mode */
-	ks_wrreg8(ks, KS_RXQCR, ks->rc_rxqcr);
+	ks_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr);
 	/* 5. Enqueue Tx(move the pkt from TX buffer into TXQ) */
 	ks_wrreg16(ks, KS_TXQCR, TXQCR_METFE);
 	/* 6. wait until TXQCR_METFE is auto-cleared */