From: Florian Fainelli <ffainelli@freebox.fr>
To: jeffrey.t.kirsher@intel.com
Cc: davem@davemloft.net, Dirk Brandewie <dirk.j.brandewie@intel.com>,
netdev@vger.kernel.org, gosp@redhat.com, bphilips@novell.com
Subject: Re: [net-next 07/12] e1000: Add support for the CE4100 reference platform
Date: Mon, 10 Jan 2011 13:44:39 +0100 [thread overview]
Message-ID: <201101101344.40001.ffainelli@freebox.fr> (raw)
In-Reply-To: <1294360199-9860-8-git-send-email-jeffrey.t.kirsher@intel.com>
Hello,
On Friday 07 January 2011 01:29:54 jeffrey.t.kirsher@intel.com wrote:
> From: Dirk Brandewie <dirk.j.brandewie@intel.com>
>
> This patch adds support for the gigabit phys present on the CE4100
> reference platforms.
>
> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/e1000/e1000_hw.c | 328
> +++++++++++++++++++++++++++++++-------- drivers/net/e1000/e1000_hw.h |
> 59 +++++++-
> drivers/net/e1000/e1000_main.c | 35 ++++
> drivers/net/e1000/e1000_osdep.h | 19 ++-
> 4 files changed, 365 insertions(+), 76 deletions(-)
>
[snip]
> @@ -2840,7 +2985,7 @@ static s32 e1000_write_phy_reg_ex(struct e1000_hw
> *hw, u32 reg_addr, {
> u32 i;
> u32 mdic = 0;
> - const u32 phy_addr = 1;
> + const u32 phy_addr = (hw->mac_type == e1000_ce4100) ? hw->phy_addr : 1;
Why not simply use hw->phy_addr and set it to 1 when mac_type is not e1000_ce4100?
hw->phy_addr for CE4100 is auto detected later in this patch, so this should be safe.
>
> e_dbg("e1000_write_phy_reg_ex");
>
[snip]
> @@ -1135,6 +1153,20 @@ static int __devinit e1000_probe(struct pci_dev
> *pdev, adapter->wol = adapter->eeprom_wol;
> device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);
>
> + /* Auto detect PHY address */
> + if (hw->mac_type == e1000_ce4100) {
> + for (i = 0; i < 32; i++) {
^PHY_MAX_ADDR (in linux/phy.h)
> + hw->phy_addr = i;
> + e1000_read_phy_reg(hw, PHY_ID2, &tmp);
> + if (tmp == 0 || tmp == 0xFF) {
> + if (i == 31)
> + goto err_eeprom;
> + continue;
> + } else
> + break;
> + }
> + }
Do not you want to also autodetect the PHY address for all e1000
variants?
> +
> /* reset the hardware with the new settings */
> e1000_reset(adapter);
>
> @@ -1171,6 +1203,8 @@ err_eeprom:
> kfree(adapter->rx_ring);
> err_dma:
> err_sw_init:
> +err_mdio_ioremap:
> + iounmap(ce4100_gbe_mdio_base_virt);
> iounmap(hw->hw_addr);
> err_ioremap:
> free_netdev(netdev);
> @@ -1409,6 +1443,7 @@ static bool e1000_check_64k_bound(struct
> e1000_adapter *adapter, void *start, /* First rev 82545 and 82546 need to
> not allow any memory
> * write location to cross 64k boundary due to errata 23 */
> if (hw->mac_type == e1000_82545 ||
> + hw->mac_type == e1000_ce4100 ||
> hw->mac_type == e1000_82546) {
> return ((begin ^ (end - 1)) >> 16) != 0 ? false : true;
> }
> diff --git a/drivers/net/e1000/e1000_osdep.h
> b/drivers/net/e1000/e1000_osdep.h index edd1c75..55c1711 100644
> --- a/drivers/net/e1000/e1000_osdep.h
> +++ b/drivers/net/e1000/e1000_osdep.h
> @@ -34,12 +34,21 @@
> #ifndef _E1000_OSDEP_H_
> #define _E1000_OSDEP_H_
>
> -#include <linux/types.h>
> -#include <linux/pci.h>
> -#include <linux/delay.h>
> #include <asm/io.h>
> -#include <linux/interrupt.h>
> -#include <linux/sched.h>
> +
> +#define CONFIG_RAM_BASE 0x60000
> +#define GBE_CONFIG_OFFSET 0x0
> +
> +#define GBE_CONFIG_RAM_BASE \
> + ((unsigned int)(CONFIG_RAM_BASE + GBE_CONFIG_OFFSET))
> +
> +#define GBE_CONFIG_BASE_VIRT phys_to_virt(GBE_CONFIG_RAM_BASE)
> +
> +#define GBE_CONFIG_FLASH_WRITE(base, offset, count, data) \
> + (iowrite16_rep(base + offset, data, count))
> +
> +#define GBE_CONFIG_FLASH_READ(base, offset, count, data) \
> + (ioread16_rep(base + (offset << 1), data, count))
In my opinion, this is unsafe, especially because not everyone places a valid
e1000 "fake" EEPROM at 0x60000. Also, this is done by the bootloader, so there
is no guarantee chainloading, kexec/kdump or anything overwrites the zone.
Rather I'd go with doing a request_firmware() of the eeprom or, a platform-
specific callback to access it.
Retrieving such board specific informations is really integrator specific.
--
Florian
next prev parent reply other threads:[~2011-01-10 12:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-07 0:29 [net-next 00/12][pull-request] Intel Wired LAN Driver Updates jeffrey.t.kirsher
2011-01-07 0:29 ` [net-next 01/12] e1000e: cleanup variables set but not used jeffrey.t.kirsher
2011-01-07 0:29 ` [net-next 02/12] e1000e: convert calls of ops.[read|write]_reg to e1e_[r|w]phy jeffrey.t.kirsher
2011-01-07 0:29 ` [net-next 03/12] e1000e: properly bounds-check string functions jeffrey.t.kirsher
2011-01-07 0:48 ` Ben Hutchings
2011-01-07 0:29 ` [net-next 04/12] e1000e: use either_crc_le() rather than re-write it jeffrey.t.kirsher
2011-01-07 0:29 ` [net-next 05/12] e1000e: power off PHY after reset when interface is down jeffrey.t.kirsher
2011-01-07 0:29 ` [net-next 06/12] e1000e: add custom set_d[0|3]_lplu_state function pointer for 82574 jeffrey.t.kirsher
2011-01-07 0:29 ` [net-next 07/12] e1000: Add support for the CE4100 reference platform jeffrey.t.kirsher
2011-01-10 12:44 ` Florian Fainelli [this message]
2011-01-07 0:29 ` [net-next 08/12] ixgb: convert to new VLAN model jeffrey.t.kirsher
2011-01-07 15:41 ` Jesse Gross
2011-01-07 19:30 ` Tantilov, Emil S
2011-01-24 0:25 ` Tantilov, Emil S
2011-01-25 17:22 ` Jesse Gross
2011-01-25 18:20 ` Tantilov, Emil S
2011-01-27 3:53 ` Jesse Gross
2011-01-27 4:18 ` Ben Hutchings
2011-03-08 1:31 ` Jesse Gross
2011-03-08 2:30 ` Jeff Kirsher
2011-01-07 0:29 ` [net-next 09/12] ixgbe: make sure per Rx queue is disabled before unmapping the receive buffer jeffrey.t.kirsher
2011-01-07 0:29 ` [net-next 10/12] ixgbe: cleanup flow director hash computation to improve performance jeffrey.t.kirsher
2011-01-07 0:29 ` [net-next 11/12] ixgbe: further flow director performance optimizations jeffrey.t.kirsher
2011-01-07 0:29 ` [net-next 12/12] ixgbe: update ntuple filter configuration jeffrey.t.kirsher
2011-01-07 1:02 ` Ben Hutchings
2011-01-07 4:12 ` Alexander Duyck
2011-01-07 0:37 ` [net-next 00/12][pull-request] Intel Wired LAN Driver Updates Jeff Kirsher
2011-01-10 7:45 ` David Miller
2011-01-07 21:15 ` [rfc] Creating drivers/net/ethernet Joe Perches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201101101344.40001.ffainelli@freebox.fr \
--to=ffainelli@freebox.fr \
--cc=bphilips@novell.com \
--cc=davem@davemloft.net \
--cc=dirk.j.brandewie@intel.com \
--cc=gosp@redhat.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).