[PATCH 0/4] FDDI: defza: Fix a bunch of small issues

[Maciej W. Rozycki]

Hi,

 Here is a bunch of small fixes addressing issues that I missed in my 
final round of testing.  None of these affect run-time behaviour.  One was 
actually found by the kbuild bot, which turned out to be more pedantic 
than my compiler.  See individual change descriptions for details.

 Please apply.

  Maciej

[PATCH 2/4] FDDI: defza: Add missing comment closing

[Maciej W. Rozycki]

Fix:

drivers/net/fddi/defza.h:238:1: warning: "/*" within comment [-Wcomment]

by adding a missing comment closing.

Signed-off-by: Maciej W. Rozycki 
---
 drivers/net/fddi/defza.h |1 +
 1 file changed, 1 insertion(+)

linux-defza-cmd-size-comment-fix.diff
Index: linux-20181104-4maxp64/drivers/net/fddi/defza.h
===
--- linux-20181104-4maxp64.orig/drivers/net/fddi/defza.h
+++ linux-20181104-4maxp64/drivers/net/fddi/defza.h
@@ -235,6 +235,7 @@ struct fza_ring_cmd {
 #define FZA_RING_CMD   0x200400/* command ring address */
 #define FZA_RING_CMD_SIZE  0x40/* command descriptor ring
 * size
+*/
 /* Command constants. */
 #define FZA_RING_CMD_MASK  0x7fff
 #define FZA_RING_CMD_NOP   0x  /* nop */

[PATCH 4/4] FDDI: defza: Make the driver version string constant

[Maciej W. Rozycki]

The driver version string is obviously not meant to be changed at run 
time, so mark it `const'.

Signed-off-by: Maciej W. Rozycki 
---
 drivers/net/fddi/defza.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

linux-defza-version-static-fix.patch
Index: linux-20181104-4maxp64/drivers/net/fddi/defza.c
===
--- linux-20181104-4maxp64.orig/drivers/net/fddi/defza.c
+++ linux-20181104-4maxp64/drivers/net/fddi/defza.c
@@ -56,7 +56,7 @@
 #define DRV_VERSION "v.1.1.4"
 #define DRV_RELDATE "Oct  6 2018"
 
-static char version[] =
+static const char version[] =
DRV_NAME ": " DRV_VERSION "  " DRV_RELDATE "  Maciej W. Rozycki\n";
 
 MODULE_AUTHOR("Maciej W. Rozycki ");

[PATCH 1/4] FDDI: defza: Fix SPDX annotation

[Maciej W. Rozycki]

The SPDX annotation for this driver does not match the license text, 
which specifies GNU GPL 2 or later.  Make the two match by correcting 
the SPDX tag.

Signed-off-by: Maciej W. Rozycki 
---
 drivers/net/fddi/defza.c |2 +-
 drivers/net/fddi/defza.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

linux-defza-spdx-fix.diff
Index: linux-20181104-4maxp64/drivers/net/fddi/defza.c
===
--- linux-20181104-4maxp64.orig/drivers/net/fddi/defza.c
+++ linux-20181104-4maxp64/drivers/net/fddi/defza.c
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+// SPDX-License-Identifier: GPL-2.0+
 /* FDDI network adapter driver for DEC FDDIcontroller 700/700-C devices.
  *
  * Copyright (c) 2018  Maciej W. Rozycki
Index: linux-20181104-4maxp64/drivers/net/fddi/defza.h
===
--- linux-20181104-4maxp64.orig/drivers/net/fddi/defza.h
+++ linux-20181104-4maxp64/drivers/net/fddi/defza.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+/* SPDX-License-Identifier: GPL-2.0+ */
 /* FDDI network adapter driver for DEC FDDIcontroller 700/700-C devices.
  *
  * Copyright (c) 2018  Maciej W. Rozycki

[PATCH 3/4] FDDI: defza: Move SMT Tx data buffer declaration next to its skb

[Maciej W. Rozycki]

Move the temporary data buffer used when tapping into the SMT Tx queue 
from the outer function level into the conditional block it's actually 
used in and its containing skb is also declared, making the structure of 
code better.

Signed-off-by: Maciej W. Rozycki 
---
Hi,

 This was also present, though not further complained about in kbuild bot 
output:

drivers/net/fddi/defza.c:787:45: warning: unused variable 'skb_data_ptr' 
[-Wunused-variable]

because it ran on a tree revision as at commit 61414f5ec983 ("FDDI: defza: 
Add support for DEC FDDIcontroller 700 TURBOchannel adapter") and 
therefore without commit 9f9a742db40f ("FDDI: defza: Support capturing 
outgoing SMT traffic"), indicating that the buffer should have been 
declared in the containing block rather than at the function level, 
especially as the skb it comes from is also declared within that block.

  Maciej
---
 drivers/net/fddi/defza.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

linux-defza-skb-data-ptr-fix.diff
Index: linux-20181104-4maxp64/drivers/net/fddi/defza.c
===
--- linux-20181104-4maxp64.orig/drivers/net/fddi/defza.c
+++ linux-20181104-4maxp64/drivers/net/fddi/defza.c
@@ -784,7 +784,7 @@ static void fza_rx(struct net_device *de
 static void fza_tx_smt(struct net_device *dev)
 {
struct fza_private *fp = netdev_priv(dev);
-   struct fza_buffer_tx __iomem *smt_tx_ptr, *skb_data_ptr;
+   struct fza_buffer_tx __iomem *smt_tx_ptr;
int i, len;
u32 own;
 
@@ -799,6 +799,7 @@ static void fza_tx_smt(struct net_device
 
if (!netif_queue_stopped(dev)) {
if (dev_nit_active(dev)) {
+   struct fza_buffer_tx *skb_data_ptr;
struct sk_buff *skb;
 
/* Length must be a multiple of 4 as only word

Re: [PATCH net-next v2 0/2] FDDI: DEC FDDIcontroller 700 TURBOchannel adapter support

[Maciej W. Rozycki]

On Mon, 15 Oct 2018, David Miller wrote:

> Series applied, thank you.

 Great, thanks!

  Maciej

[PATCH net-next v2 2/2] FDDI: defza: Support capturing outgoing SMT traffic

[Maciej W. Rozycki]

DEC FDDIcontroller 700 (DEFZA) uses a Tx/Rx queue pair to communicate 
SMT frames with adapter's firmware.  Any SMT frame received from the RMC 
via the Rx queue is queued back by the driver to the SMT Rx queue for 
the firmware to process.  Similarly the firmware uses the SMT Tx queue 
to supply the driver with SMT frames which are queued back to the Tx 
queue for the RMC to send to the ring.

When a network tap is attached to an FDDI interface handled by `defza' 
any incoming SMT frames captured are queued to our usual processing of 
network data received, which in turn delivers them to any listening 
taps.

However the outgoing SMT frames produced by the firmware bypass our 
network protocol stack and are therefore not delivered to taps.  This in 
turn means that taps are missing a part of network traffic sent by the 
adapter, which may make it more difficult to track down network problems 
or do general traffic analysis.

Call `dev_queue_xmit_nit' then in the SMT Tx path, having checked that
a network tap is attached, with a newly-created `dev_nit_active' helper
wrapping the usual condition used in the transmit path.

Signed-off-by: Maciej W. Rozycki 
---
New in v2.
---
 drivers/net/fddi/defza.c  |   33 +++--
 include/linux/netdevice.h |1 +
 net/core/dev.c|   13 -
 3 files changed, 44 insertions(+), 3 deletions(-)

linux-defza-1.1.4-pcap.patch
Index: net-next-20181008-4maxp64/drivers/net/fddi/defza.c
===
--- net-next-20181008-4maxp64.orig/drivers/net/fddi/defza.c
+++ net-next-20181008-4maxp64/drivers/net/fddi/defza.c
@@ -797,11 +797,40 @@ static void fza_tx_smt(struct net_device
smt_tx_ptr = fp->mmio + readl_u(>ring_smt_tx[i].buffer);
len = readl_u(>ring_smt_tx[i].rmc) & FZA_RING_PBC_MASK;
 
-   /* Queue the frame to the RMC transmit ring. */
-   if (!netif_queue_stopped(dev))
+   if (!netif_queue_stopped(dev)) {
+   if (dev_nit_active(dev)) {
+   struct sk_buff *skb;
+
+   /* Length must be a multiple of 4 as only word
+* reads are permitted!
+*/
+   skb = fza_alloc_skb_irq(dev, (len + 3) & ~3);
+   if (!skb)
+   goto err_no_skb;/* Drop. */
+
+   skb_data_ptr = (struct fza_buffer_tx *)
+  skb->data;
+
+   fza_reads(smt_tx_ptr, skb_data_ptr,
+ (len + 3) & ~3);
+   skb->dev = dev;
+   skb_reserve(skb, 3);/* Skip over PRH. */
+   skb_put(skb, len - 3);
+   skb_reset_network_header(skb);
+
+   dev_queue_xmit_nit(skb, dev);
+
+   dev_kfree_skb_irq(skb);
+
+err_no_skb:
+   ;
+   }
+
+   /* Queue the frame to the RMC transmit ring. */
fza_do_xmit((union fza_buffer_txp)
{ .mmio_ptr = smt_tx_ptr },
len, dev, 1);
+   }
 
writel_o(FZA_RING_OWN_FZA, >ring_smt_tx[i].own);
fp->ring_smt_tx_index =
Index: net-next-20181008-4maxp64/include/linux/netdevice.h
===
--- net-next-20181008-4maxp64.orig/include/linux/netdevice.h
+++ net-next-20181008-4maxp64/include/linux/netdevice.h
@@ -3632,6 +3632,7 @@ static __always_inline int dev_forwa
return 0;
 }
 
+bool dev_nit_active(struct net_device *dev);
 void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev);
 
 extern int netdev_budget;
Index: net-next-20181008-4maxp64/net/core/dev.c
===
--- net-next-20181008-4maxp64.orig/net/core/dev.c
+++ net-next-20181008-4maxp64/net/core/dev.c
@@ -1954,6 +1954,17 @@ static inline bool skb_loop_sk(struct pa
return false;
 }
 
+/**
+ * dev_nit_active - return true if any network interface taps are in use
+ *
+ * @dev: network device to check for the presence of taps
+ */
+bool dev_nit_active(struct net_device *dev)
+{
+   return !list_empty(_all) || !list_empty(>ptype_all);
+}
+EXPORT_SYMBOL_GPL(dev_nit_active);
+
 /*
  * Support routine. Sends outgoing frames to any network
  * taps currently in use.
@@ -3211,7 +3222,7 @@ static int xmit_one(struct sk_buff *skb,
unsigned int len;
int rc;
 
-   if (!list_empty(_all) || !list_empty(>pty

[PATCH net-next v2 1/2] FDDI: defza: Add support for DEC FDDIcontroller 700 TURBOchannel adapter

[Maciej W. Rozycki]

Add support for the DEC FDDIcontroller 700 (DEFZA), Digital Equipment 
Corporation's first-generation FDDI network interface adapter, made for 
TURBOchannel and based on a discrete version of what eventually became 
Motorola's widely used CAMEL chipset.

The CAMEL chipset is present for example in the DEC FDDIcontroller 
TURBOchannel, EISA and PCI adapters (DEFTA/DEFEA/DEFPA) that we support 
with the `defxx' driver, however the host bus interface logic and the 
firmware API are different in the DEFZA and hence a separate driver is 
required.

There isn't much to say about the driver except that it works, but there 
is one peculiarity to mention.  The adapter implements two Tx/Rx queue 
pairs.

Of these one pair is the usual network Tx/Rx queue pair, in this case 
used by the adapter to exchange frames with the ring, via the RMC (Ring 
Memory Controller) chip.  The Tx queue is handled directly by the RMC 
chip and resides in onboard packet memory.  The Rx queue is maintained 
via DMA in host memory by adapter's firmware copying received data 
stored by the RMC in onboard packet memory.

The other pair is used to communicate SMT frames with adapter's 
firmware.  Any SMT frame received from the RMC via the Rx queue must be 
queued back by the driver to the SMT Rx queue for the firmware to 
process.  Similarly the firmware uses the SMT Tx queue to supply the 
driver with SMT frames that must be queued back to the Tx queue for the 
RMC to send to the ring.

This solution was chosen because the designers ran out of PCB space and 
could not squeeze in more logic onto the board that would be required to 
handle this SMT frame traffic without the need to involve the driver, as 
with the later DEFTA/DEFEA/DEFPA adapters.

Finally the driver does some Frame Control byte decoding, so to avoid 
magic numbers some macros are added to .

Signed-off-by: Maciej W. Rozycki 
---
Changes from v1:

- driver version 1.1.4, due to completed 700-C adapter variant support,

- DEC FDDIcontroller 700-C support verified and driver code updated
  accordingly: PMD types added and the associated debug message removed,

- the spelling of 700C corrected to 700-C throughout, according to board 
  marking and documentation,

- driver notes (defza.txt) updated, reworded and reformatted for 72
  columns,

- `fza_start_xmit' return type now `netdev_tx_t',

- switched from the removed `init_timer' interface to `timer_setup',

- reworked MMIO accesses according to memory ordering guarantees,

- outgoing SMT traffic packet capturing split off to 2/2,

- reformatted to shut up `checkpatch.pl',

- change description revised.

---
 Documentation/networking/00-INDEX  |2 
 Documentation/networking/defza.txt |   57 +
 MAINTAINERS|5 
 drivers/net/fddi/Kconfig   |   11 
 drivers/net/fddi/Makefile  |1 
 drivers/net/fddi/defza.c   | 1535 +
 drivers/net/fddi/defza.h   |  791 +++
 include/uapi/linux/if_fddi.h   |   21 
 8 files changed, 2420 insertions(+), 3 deletions(-)

linux-defza-1.1.4.patch
Index: net-next-20181008-4maxp64/Documentation/networking/00-INDEX
===
--- net-next-20181008-4maxp64.orig/Documentation/networking/00-INDEX
+++ net-next-20181008-4maxp64/Documentation/networking/00-INDEX
@@ -56,6 +56,8 @@ de4x5.txt
- the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver
 decnet.txt
- info on using the DECnet networking layer in Linux.
+defza.txt
+   - the DEC FDDIcontroller 700 (DEFZA-xx) TURBOchannel FDDI driver
 dl2k.txt
- README for D-Link DL2000-based Gigabit Ethernet Adapters (dl2k.ko).
 dm9000.txt
Index: net-next-20181008-4maxp64/Documentation/networking/defza.txt
===
--- /dev/null
+++ net-next-20181008-4maxp64/Documentation/networking/defza.txt
@@ -0,0 +1,57 @@
+Notes on the DEC FDDIcontroller 700 (DEFZA-xx) driver v.1.1.4.
+
+
+DEC FDDIcontroller 700 is DEC's first-generation TURBOchannel FDDI
+network card, designed in 1990 specifically for the DECstation 5000
+model 200 workstation.  The board is a single attachment station and
+it was manufactured in two variations, both of which are supported.
+
+First is the SAS MMF DEFZA-AA option, the original design implementing
+the standard MMF-PMD, however with a pair of ST connectors rather than
+the usual MIC connector.  The other one is the SAS ThinWire/STP DEFZA-CA
+option, denoted 700-C, with the network medium selectable by a switch
+between the DEC proprietary ThinWire-PMD using a BNC connector and the
+standard STP-PMD using a DE-9F connector.  This option can interface to
+a DECconcentrator 500 device and, in the case of the STP-PMD, also other
+FDDI equipment and was designed to make it easier to transition from
+existing IEEE 802.3 10BASE2 Ethernet and IEEE 802.5 Token Ring networks
+by providing means

[PATCH net-next v2 0/2] FDDI: DEC FDDIcontroller 700 TURBOchannel adapter support

[Maciej W. Rozycki]

Hi,

 This is an update to .  I 
believe I have addressed all the requests made in the previous review 
round.

 There is still one `checkpatch.pl' warning remaining:

WARNING: quoted string split across lines
#1652: FILE: drivers/net/fddi/defza.c:1442:
+   pr_info("%s: ROM rev. %.4s, firmware rev. %.4s, RMC rev. %.4s, "
+   "SMT ver. %u\n", fp->name, rom_rev, fw_rev, rmc_rev, smt_ver);

total: 0 errors, 1 warnings, 2458 lines checked

however I think the value of staying within 80 columns is higher than the 
value of having the string on a single line.  This is because with all the 
formatting specifiers there it is not directly greppable based on the 
final output produced to the kernel log on one hand, e.g.:

tc2: ROM rev. 1.0, firmware rev. 1.2, RMC rev. A, SMT ver. 1

while it can be easily tracked down by grepping for an obvious substring 
such as "RMC rev" on the other.

 The issue with MMIO barriers I discussed in the course of the original 
review turned out mostly irrelevant to this driver, because as I have 
learnt in a recent Alpha/Linux discussion starting here: 

 
our MMIO API mandates the `readX' and `writeX' accessors to be strongly 
ordered with respect to each other, even if that is not implicitly 
enforced by hardware.

 Consequently I have removed all the explicit ordering barriers and 
instead submitted a fix for MIPS MMIO implementation, which currently does 
not guarantee strong ordering (the MIPS architecture does not define bus
ordering rules except in terms of SYNC barriers), as recorded here: 
.  

 Enforcing strong MMIO ordering can be costly however and is often 
unnecessary, e.g. when using PIO to access network frame data in onboard 
packet memory.  I have therefore retained the information that would be 
lost by the removal of barriers, by defining accessor wrappers suffixed by 
`_o' and `_u', for accesses that have to be ordered and can be unordered 
respectively.

 If we ever have an API defined for weakly-ordered MMIO accesses, then 
these wrappers can be redefined accordingly.  Right now they all expand to 
the respective `_relaxed' accessors, because, again, enforcing the 
ordering WRT DMA transfers can be costly and we don't need it here except 
in one place, where I chose to use explicit `dma_rmb' instead.

 Similarly I have replaced the completion barriers with a read back from 
the respective MMIO location (all adapter MMIO registers can be read with 
no side effects incurred), which will serve its purpose on the basis of 
MMIO being strongly ordered (although a read from TURBOchannel is going to 
be slower than `iob', making the delay incurred unnecessarily longer).

 And last but not least, I have split off the SMT Tx network tap support 
to a separate change, 2/2 in this series, so that it does not block the 
driver proper and can be discussed separately.

 I think it has value in that it makes the view of the outgoing network 
traffic complete, as if one actually physically tapped into the outgoing 
line of the ring, between the station being examined and its downstream 
neighbour.  Without this part only traffic passed from applications 
through the whole protocol stack can be captured and this is only a part 
of the view.

 With the `dev_queue_xmit_nit' interface now exported it's only 
`ptype_all' that remains private, and to define a properly abstracted API 
I propose to provide am exported `dev_nit_active' predicate that tells 
whether any taps are active.  This predicate is then used accordingly.

 NB if there is a long-term maintenance concern about the `dev_nit_active' 
predicate, then well, corresponding inline code currently present in 
`xmit_one' has to be maintained anyway, and if the resulting changes 
require `defza' to be updated accordingly, then I am going to handle it; 
after some 20 years with Linux it's not that I am going to disappear 
anywhere anytime.  And once I am dead, which is inevitably going to happen 
sooner or later, then the driver can simply be ripped from the kernel.  
Though I suspect that at that point no DECstation Linux users may survive 
anymore, even though hardware, being as sturdy as it is, likely will.

 I have a patch for `tcpdump' to actually decode SMT frames, which I plan 
to upstream sometime.  Here's a sample of SMT traffic captured through the 
`defza' driver in a small network of 4 stations and no concentrators, 
printed in the most verbose mode:

01:16:59.138381 4f 00:60:b0:58:41:e7 00:60:b0:58:41:e7 73: SMT NIF ann vid:1 
tid:0270 sid:00-00-00-60-b0-58-41-e7 len:40: UNA: 00 00 00 06 0d 1a 02 ae 
StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 
00 00 00 01
01:17:00.332750 4f 08:00:2b:a3:a3:29 

Re: [PATCH] atm: idt77252: Replace mdelay with usleep_range in idt77252_preset

[Maciej W. Rozycki]

On Fri, 26 Jan 2018, Jia-Ju Bai wrote:

> diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
> index 0277f36..cea4bf2 100644
> --- a/drivers/atm/idt77252.c
> +++ b/drivers/atm/idt77252.c
> @@ -3563,7 +3563,7 @@ static int idt77252_preset(struct idt77252_dev *card)
>  
>   /* Software reset */
>   writel(SAR_CFG_SWRST, SAR_REG_CFG);
> - mdelay(1);
> + usleep_range(500, 1000);
>   writel(0, SAR_REG_CFG);
>  
>   IPRINTK("%s: Software resetted.\n", card->name);

 This is only called from the driver's ->probe method, so it looks to me 
indeed safe to sleep here.  A similar, more extensive clean-up seems due 
for 77252 older brother's driver nicstar.c.

 Out of curiosity I have looked up the SAR manual and it requires the 
SWRST bit to be asserted for at least 2 PCI clock cycles for the reset to 
be valid, so having the lower bound of .5ms still looks completely safe if 
not an overkill to me for real world applications where PCI is driven in 
the MHz clock range.

Reviewed-by: Maciej W. Rozycki <ma...@linux-mips.org>

  Maciej

Re: [PATCH 5/5] net: defxx: constify eisa_device_id

[Maciej W. Rozycki]

On Sat, 19 Aug 2017, Arvind Yadav wrote:

> eisa_device_id are not supposed to change at runtime. All functions
> working with eisa_device_id provided by  work with
> const eisa_device_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav <arvind.yadav...@gmail.com>
> ---

Reviewed-by: Maciej W. Rozycki <ma...@linux-mips.org>

  Maciej

Re: BPF relocations

[Maciej W. Rozycki]

On Fri, 12 May 2017, David Miller wrote:

> Internally, we have to emit some kind of relocation as GAS makes it's
> first pass over the instructions.

 Not really, you can defer that until the relaxation pass, e.g. to avoid 
figuring out what to do about forward local symbol references, especially 
in complex expressions that may eventually resolve to assembly constants.

 This is how MIPS16 assembly works for example, due to its dual regular vs 
extended instruction encoding, so that no artificial relocations had to be 
invented in GAS for the regular instructions, which never get relocations 
recorded against in an object file.  Any instruction that ends up needing 
a relocation, if supported (not all encodings do), gets converted to the 
extended form in the relaxation pass and only then a suitable fixup is 
attached to it.

 Of course that may not matter for your specific case, but I think it's 
worth noting so as to avoid people getting misled about how GAS works.

 FWIW,

  Maciej

Re: [PATCH v4 net-next] net: Implement fast csum_partial for x86_64

[Maciej W. Rozycki]

On Sun, 28 Feb 2016, Alexander Duyck wrote:

> I actually found the root cause.  The problem is in add32_with_carry3.
> 
> > +static inline unsigned int add32_with_carry3(unsigned int a, unsigned int 
> > b,
> > +unsigned int c)
> > +{
> > +   asm("addl %2,%0\n\t"
> > +   "adcl %3,%0\n\t"
> > +   "adcl $0,%0"
> > +   : "=r" (a)
> > +   : "" (a), "rm" (b), "rm" (c));
> > +
> > +   return a;
> > +}
> > +
> 
> You need to set the 'a' input variable attribute to "0" instead of ""
> and then things work for me correctly.

 Or alternatively you can reduce the number of operands by one, by using 
`"+r" (a)' as output, and then removing `a' as a separate input and 
renumbering references to `b' and `c' accordingly.  It would IMHO actually 
better match the in-place operation as well.

 FWIW,

  Maciej

Re: [PATCH 5/9] net: fddi/defxx: avoid warning about uninitialized variable use

[Maciej W. Rozycki]

On Wed, 27 Jan 2016, Arnd Bergmann wrote:

> This adds code to ensure that the BAR values are initialized
> even in the impossible case when a device gets probed that
> does not belong to any bus. This shuts up the warning.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/net/fddi/defxx.c | 5 +
>  1 file changed, 5 insertions(+)

 NAK, fixed already, commit 62f2aaabcf41 ("defxx: fix build warning").

 Thanks for looking into this problem though, always welcome!

  Maciej

Re: [PATCH] fddi: Fixup potential uninitialized bars

[Maciej W. Rozycki]

On Tue, 26 Jan 2016, Hannes Reinecke wrote:

> dfx_get_bars() allocates the various bars, depending on the
> bus type. But as the function itself returns void and there
> is no default selection there is a risk of the function
> returning without allocating any bars.
> This patch moves the entries around so that PCI is assumed
> to the the default bus, and adds a WARN_ON check if that
> should no be the case.
> And I've made some minor code reshuffles to keep checkpatch
> happy.
> 
> Signed-off-by: Hannes Reinecke 
> ---
>  drivers/net/fddi/defxx.c | 29 -
>  1 file changed, 16 insertions(+), 13 deletions(-)

 NAK, this has been fixed already with a much simpler change, commit 
62f2aaabcf41 ("defxx: fix build warning").  Exactly one of `dfx_bus_pci', 
`dfx_bus_eisa' or `dfx_bus_tc' will always be true or `dfx_register' will 
not have been called in the first place, so it's not even worth a BUG_ON 
IMHO.

 Thanks for looking into this problem though, always welcome!

  Maciej

Re: [PATCH v2] defxx: fix build warning

[Maciej W. Rozycki]

On Mon, 25 Jan 2016, Sudip Mukherjee wrote:

> We are getting many build warnings about:
> 'bar_start' may be used uninitialized
> and
> 'bar_len' may be used uninitialized
> 
> They are not actually uninitialized as dfx_get_bars() will initialize
> them properly. But still lets have them initialized just to satisfy the
> compiler (gcc 4.8.2).
> 
> Signed-off-by: Sudip Mukherjee <su...@vectorindia.org>
> ---

Acked-by: Maciej W. Rozycki <ma...@linux-mips.org>

 Thanks,

  Maciej

Re: [PATCH 3/3] defxx: fix build warning

[Maciej W. Rozycki]

On Mon, 25 Jan 2016, Sudip Mukherjee wrote:

> We are getting many build warning about:
> 'bar_start' may be used uninitialized
> and
> 'bar_len' may be used uninitialized
> 
> They are not actually uninitialized as dfx_get_bars() will initialize
> them properly. But still lets have them initialized just to satisfy the
> compiler.

 Which compiler/version is that?

> diff --git a/drivers/net/fddi/defxx.c b/drivers/net/fddi/defxx.c
> index 7f975a2..4113535 100644
> --- a/drivers/net/fddi/defxx.c
> +++ b/drivers/net/fddi/defxx.c
> @@ -533,8 +533,8 @@ static int dfx_register(struct device *bdev)
>   const char *print_name = dev_name(bdev);
>   struct net_device *dev;
>   DFX_board_t   *bp;  /* board pointer */
> - resource_size_t bar_start[3];   /* pointers to ports */
> - resource_size_t bar_len[3]; /* resource length */
> + resource_size_t bar_start[3] = {0, 0, 0};   /* pointers to ports */
> + resource_size_t bar_len[3] = {0, 0, 0}; /* resource length */
>   int alloc_size; /* total buffer size used */
>   struct resource *region;
>   int err = 0;

 Just setting the first element will do, the rest will then be implicitly 
zeroed, following the semantics of initialisers in C.  So just do:

resource_size_t bar_start[3] = {0}; /* pointers to ports */
resource_size_t bar_len[3] = {0};   /* resource length */

for brevity and to save formatting.

> @@ -3697,8 +3697,8 @@ static void dfx_unregister(struct device *bdev)
>   int dfx_bus_pci = dev_is_pci(bdev);
>   int dfx_bus_tc = DFX_BUS_TC(bdev);
>   int dfx_use_mmio = DFX_MMIO || dfx_bus_tc;
> - resource_size_t bar_start[3];   /* pointers to ports */
> - resource_size_t bar_len[3]; /* resource lengths */
> + resource_size_t bar_start[3] = {0, 0, 0};   /* pointers to ports */
> + resource_size_t bar_len[3] = {0, 0, 0}; /* resource lengths */
>   int alloc_size; /* total buffer size used */
>  
>   unregister_netdev(dev);

 Likewise here.  Please resend with the update requested and I'll ack it.

 Thanks for your submission!

  Maciej

Re: [PATCH] PHYLIB: Add BCM5482 PHY support

[Maciej W. Rozycki]

On Tue, 29 Jan 2008, Nate Case wrote:

 +static struct phy_driver bcm5482_driver = {
 +.phy_id  = 0x0143bcb0,
 + .phy_id_mask= 0xfff0,

 Please check formatting above and also I am a bit curious as to why the 
ID is so different from the other ones -- the number is meant to be based 
on the OUI assigned to the manufacturer.  Otherwise your addition is fine.

  Maciej
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] defxx.c: dfx_bus_init() is __devexit not __devinit

[Maciej W. Rozycki]

 The dfx_bus_uninit() call is called from dfx_unregister() which is 
__devexit and which is ultimately the -remove call for the device.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 It should be obvious.  Please apply.

  Maciej

patch-mips-2.6.23-rc5-20070904-defxx-devexit-0
diff -up --recursive --new-file 
linux-mips-2.6.23-rc5-20070904.macro/drivers/net/defxx.c 
linux-mips-2.6.23-rc5-20070904/drivers/net/defxx.c
--- linux-mips-2.6.23-rc5-20070904.macro/drivers/net/defxx.c2007-09-04 
04:55:41.0 +
+++ linux-mips-2.6.23-rc5-20070904/drivers/net/defxx.c  2007-10-12 
00:21:35.0 +
@@ -806,7 +806,7 @@ static void __devinit dfx_bus_init(struc
  *   Interrupts are disabled at the adapter bus-specific logic.
  */
 
-static void __devinit dfx_bus_uninit(struct net_device *dev)
+static void __devexit dfx_bus_uninit(struct net_device *dev)
 {
DFX_board_t *bp = netdev_priv(dev);
struct device *bdev = bp-bus_dev;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes

[Maciej W. Rozycki]

On Fri, 19 Oct 2007, Jarek Poplawski wrote:

 Actually I'm not convinced with this explanation. It seems to me that
 since there are such serious locking problems (especially with rntl),
 there could be once more considered a private workqueue. You've
 written earlier about being a lonely user of this code. But, since

 Well, this will change eventually when I submit the patch for Broadcom 
SiByte platforms so that sb1250-mac.c will be able to request an interrupt 
for the PHYs.  All the infrastructure is in place except from platform 
code to configure the SOC's GPIO line used for the interrupt input (when 
applicable) and let the driver know what the line actually is.

 Benjamin offered his help with changing to mutexes, which looks like
 very reasonable idea to me (probably I miss most of the points...),
 maybe it's very good opportunity to both: make this code better and
 double the user base! I'm interested in looking for such solution
 if Benjamin thinks there could be too few problems for him... So,
 let somebody tell us what could be wrong with this idea?

 I do not object and can certainly cooperate, but cannot make it a high 
priority work for me at the moment -- sorry.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes

[Maciej W. Rozycki]

On Thu, 18 Oct 2007, Maciej W. Rozycki wrote:

  1) phy_change() checks PHY_HALTED flag without lock; I think it's
  racy: eg. if it's done during phy_stop() it can check just before
  the flag is set and reenable interrupts just after phy_stop() ends.
 
  I remember having a look into it, but it was long ago and I cannot 
 immediately recall the conclusion.  Which means it is either broken or 
 deserves a comment as non-obvious.  I will have a look into it again, but 
 I am resource-starved a little at the moment, sorry.

 Well, I have now recalled what the issue is -- we just plainly and simply 
want to avoid a hardirq spinlock for the very reason we do not do all the 
processing in the hardirq handler.  The thing is we make accesses to the 
MDIO bus with the phydev lock held and it may take ages until these 
accesses will have completed.  And we cannot afford keeping interrupts 
disabled for so long.

 So the only way is to make the check for the HALTED state lockless and 
make sure any race condition is handled gracefully and does not lead to 
inconsistent behaviour.  Which I think as of what we have in the 
net-2.6.24 tree is the case, but there are never too many eyes to look at 
a piece of code, so if anybody feels like proving me wrong, then just go 
ahead!

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes

[Maciej W. Rozycki]

On Fri, 19 Oct 2007, Jarek Poplawski wrote:

 But then... your patch seems to make it possible, because it enables
 irq to the initial state of the counter. Of course, this could happen
 on closing only.

 That's because free_irq() does not disable the interrupt in the correct 
manner.  The scenario is more or less like this:

phy_interrupt() [depth == 0]
disable_irq()
depth++; status |= IRQ_DISABLED;
...
free_irq()  [depth == 1]
status |= IRQ_DISABLED;
...
phy_change()[depth == 1]
enable_irq()
depth--; status = ~IRQ_DISABLED;
oops!

Now if free_irq() correctly incremented the depth counter, then the last
enable_irq() would still decrement it, but with its initial value of 2 it 
would not change the status to reenable the line.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes

[Maciej W. Rozycki]

On Thu, 18 Oct 2007, Jarek Poplawski wrote:

 After rethinking, it looks like this last cancel should be useless.
 So, if phy_interrupt() schedules only if !PHY_HALTED and phy_change()
 does enable_irq() with no exeptions, it seems phy_interrupt() even
 without lock must see PHY_HALTED state before this free_irq() with
 possible DEBUG_SHIRQ call, then maybe only this safety:
 
   WARN_ON(work_pending(phydev-phy_queue));

 Good point.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes

[Maciej W. Rozycki]

On Wed, 17 Oct 2007, Jarek Poplawski wrote:

 I'm not sure free_irq() should maintain the depth count - rather warn
 on not zero. But, IMHO, any activity on freed irq seems suspicious to
 me (and doesn't look like very common), even if it's safe with current
 implementation.

 No way to avoid it with DEBUG_SHIRQ.

 Yes, these DEBUG_SHIRQ checks are suspicious to me too, but they seem
 to be reasonable only in the case of possible resent irqs (so not for
 all irqs). On the other hand, it seems, proper irq handler with proper
 hardware shouldn't have any problems with such a check.

 What do you mean by proper irq handler with proper hardware?  Using
softirqs (they used to be called bottom-halves) is actually a natural way 
of handling any interrupt which requires extensive processing.

 1) phy_change() checks PHY_HALTED flag without lock; I think it's
 racy: eg. if it's done during phy_stop() it can check just before
 the flag is set and reenable interrupts just after phy_stop() ends.

 I remember having a look into it, but it was long ago and I cannot 
immediately recall the conclusion.  Which means it is either broken or 
deserves a comment as non-obvious.  I will have a look into it again, but 
I am resource-starved a little at the moment, sorry.

 2) phy_change() doesn't reenable irq line after it sees returns
 with errors; IMHO it should at least write some warning, but maybe
 try some safety plan, so enable_irq() and try to disable interrupts
 and free_irq() on the next call (if it happens). (But, I can be very
 wrong with this - maybe it's OK and official way.)

 No way to do this safely -- at this point the device probably still has 
its interrupt output asserted and the register to clear it is 
inaccessible, so enabling the line will enter an infinite loop.  At this 
point the system is no longer stable, so it is better to keep at least 
some functionality, so that it may be attempted to be shut down cleanly, 
rather than make it completely irresponsive.  The alternative is panic().

 3) phy_interrupt() checks PHY_HALTED flag without lock too, but I'm
 not sure now if it could be dangerous after fixing #1; on the other
 hand even if we know it's not our regular interrupt, with current
 DEBUG_SHIRQ it could be easier to call schedule_work() anyway since
 we are sure it's before/in free_irq() yet.

  See #1 above.

 4) phy_interrupt() should check return value from schedule_work() and
 enable irq on 0.

 No -- the work already pending will do that.

 5) phy_stop_interrupts(): maybe I miss something, but it seems
 phy_stop() is required before this, so maybe there should be a
 comment on this?

 The API is documented in: Documentation/networking/phy.txt -- you are 
welcome to improve.  If you do not want to get into the gory details, just 
use the cooked interface and phy_disconnect() will do the dirty work for 
you.

 6) phy_stop_interrupts(): if I'm not wrong with #3 calling
 phy_disable_interrupts() looks like we are not sure this phy_stop()
 really works; than maybe a WARN_ON?

 WARN_ON what?

 7) phy_stop_interrupts(): after above mentioned changes in
 phy_interrupt(), and phy_changes() (always enable_irq()) I can't see
 any reason why there should be more than one skipped enable_irq(),
 so checking return from cancel_work_sync() shouldn't be enough
 instead of this atomic counter.

 CONFIG_DEBUG_SHIRQ.  Barring this option, cancel_work_sync() could have 
been moved to the front of free_irq().  I think I have seen this in 
reality, with the interrupt line left stuck disabled afterwards, but I 
will double check when I have an opportunity.  The approach implemented 
with this patch does work, which is the important bit, and if 
simplification is possible, then it may be applied later.

 8) phy_stop_interrupts(): I'm not sure this additional call from
 DEBUG_SHIRQ should be so dangerous, eg.:
 
   /*
* status == PHY_HALTED 
* interrupts are stopped after phy_stop()
*/
   if (cancel_work_sync(...))
   enable_irq();
 
   free_irq(...);
   /*
* possible schedule_work() from DEBUG_SHIRQ only,
* but proper check for PHY_HALTED is done;
* so, let's flush after this too:
*/
   cancel_work_sync();

 Well, if there is another handler registered on this line, you'll get 
your interrupt line stuck disabled.

 Of course, I don't know phy.c enough, so most of this can be terribly
 wrong, then feel free to forget about this - I don't expect you should
 waste any time for explaining me these things - after all they are
 doubts only.

 I am not sure I know phy.c well enough either, ;-) and your concerns are 
appreciated as interesting conclusions may develop.  If someone disagrees 
with what I have written here, they are welcome to speak out too.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes

[Maciej W. Rozycki]

On Thu, 18 Oct 2007, Jarek Poplawski wrote:

 Technically until free_irq returns a handler should respond to calls
 and with proper hardware it should have no problem with checking if
 it's its interrupt, even after disabling this hardware, because of
 possible races.

 Well, the hardirq handler can check it, no problem -- it is just it is so 
slow, the latency would be unacceptable.  The problem with the softirq 
handler is we do really not want it to be called after the driver has 
already been shut down and its structures freed.  It used to happen before 
this flush/cancel call was added with the usual effect (oops) as by then 
they may well have been stamped on already.

 But with a scenario like this:
 
 - disable_irq()
 - disable_my_hadrware_irq()
 - clear_my_hardware_irq()
 - free_irq()
 - enable_irq()
 
 it seems the handler should respond even after free_irq because there
 could be still interrupts to resend, originally generated by its
 hardware, so such behavior looks very suspicious, at least with some
 type of interrupts.

 These are softirqs, not hardware interrupts, so they are as such not 
related to *_irq() infrastructure.  The flaw is the depth count of IRQ 
lines is not maintained consistently.  This is, according to comments 
around the code in question, to cover up bugs elsewhere.  Not a brillant 
idea, I am afraid -- there should be no need to reset the depth upon 
request_irq() and likewise with free_irq(), but there you go.  I would be 
happy to investigate a possible solution and rewrite the necessary bits, 
but right now I am committed to other stuff, overdue already, sorry.

 The view could change if we supported hot-pluggable interrupt 
controllers, but it is not the case at the moment right now, so the 
interrupt lines are there to stay for the duration of the system lifespan 
and could be manipulated as necessary.

 So, I think, the idea of DEBUG_SHIRQ is generally right and very
 useful - but, of course, there could be exceptions, which btw. could
 try some hacks under DEBUG_SHIRQ too. And my opinion about
 'properness' was very general (not about phy) too, just like my
 'knowledge' of drivers.

 The idea is right, no question, but I am not quite sure it has been 
properly architected into our current design.  Actually I am almost sure 
of the reverse.  This is why I was (and still am) interested in feedback 
on it.

 Right! But then some warning could be useful, I presume.

 Of course; adding one to phy_error() should be straightforward.

   4) phy_interrupt() should check return value from schedule_work() and
   enable irq on 0.
  
   No -- the work already pending will do that.
 
 How? If schedule_work won't succeed because there is a pending one,
 we did disable_irq_nosync 2x, so we would stay at least 1x too deep!

 Correct and my note is misleading, sorry.

 The thing is we shouldn't have come here the second time in the first 
place (which is I think why the check is not there) as handlers for the 
same line are not allowed to run in parallel (cf. irq_desc-lock and 
IRQ_INPROGRESS).  Perhaps BUG_ON(!schedule_work()) would be appropriate, 
though I am not sure if we should handle every impossible condition we 
can imagine.  Quite a lot of hardirq handlers assume two instances will 
not run in parallel, so if it ever happened, then a serious breakage would 
unleash.

 But, I've enough of other concerns too, so nothing urgent here...

 The problem is at the moment I am still probably the only user of this 
code ;-) -- `grep' through the sources to see how many drivers request an 
IRQ for their PHY through phylib; unless something has changed very 
recently.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] flush_work_sync vs. flush_scheduled_work Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes

[Maciej W. Rozycki]

On Thu, 18 Oct 2007, Oleg Nesterov wrote:

 If we can't just cancel the work, can't we do something like
 
   if (cancel_work_sync(w))
   w-func(w);
 
 instead?

 We do an equivalent of this -- all that we care about that w-func(w) 
would do is enable_irq() and the rest we want to skip at this point.  We 
probably do not need the counter in the end though.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes

[Maciej W. Rozycki]

On Tue, 16 Oct 2007, Jarek Poplawski wrote:

 Yes, it's all right here. Sorry for bothering - I should've found this
 by myself.

 Ah, no problem -- even with the right keys you may sometimes get lost in 
the results.

 I've still some doubts about this possible enable_irq() after
 free_irq(). If it's the only handler the status would be changed again
 and at least some of this code in check_irq_resend() would be run, but
 I can miss something again or/and this doesn't matter, as well.

 Well, enable_irq() and disable_irq() themselves are nesting, so they are 
not a problem.  OTOH, free_irq() does not seem to maintain the depth count 
correctly, which looks like a bug to me and which could trigger regardless 
of whether flush_scheduled_work() or cancel_work_sync() was called.

 The reason is CONFIG_DEBUG_SHIRQ which makes a simulated interrupt event 
be sent at the end of free_irq().  It looks like a problem that is 
complementary to one I signalled here:

http://lkml.org/lkml/2007/9/12/82

with respect to request_irq(), where, similarly, such an interrupt event 
is sent at the beginning.  It looks like nobody was concerned back then, 
but perhaps it is time to do a better investigation now and propose a 
solution.

 I'll think about it and thanks for your inquisitiveness that has led to 
these conclusions.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes

[Maciej W. Rozycki]

On Mon, 15 Oct 2007, Jarek Poplawski wrote:

 Could you explain why cancel_work_sync() is better here than
 flush_scheduled_work() wrt. rtnl_lock()?

 Well, this is actually the bit that made cancel_work_sync() be written in 
the first place.  The short story is the netlink lock is most probably 
held at this point (depending on the usage of phy_disconnect()) and there 
is also an event waiting in the queue that requires the lock, so if 
flush_scheduled_work() is called here a deadlock will happen.

 Let me find a reference for a longer story...:

http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mipsi=Pine.LNX.4.64N.0610031509380.4642%40blysk.ds.pg.gda.pl

and then discussed again:

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0612.0/0593.html

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sb1250-mac: Driver model phylib update

[Maciej W. Rozycki]

On Mon, 24 Sep 2007, Andrew Morton wrote:

   Well, this is against Jeff's netdev-2.6 tree which hopefully is not as 
  crufty as Linus's old mainline; if it is not possible to queue this change 
  for 2.6.25 or suchlike, then I will try to resubmit later.
 
 Most of Jeff's netdev tree got dumped into Dave's net-2.6.24 tree.  That's
 the one you want to be raising patches against for the next few weeks.

 OK, thanks for clarification.  Then both patches already submitted:

patch-netdev-2.6.23-rc6-20070920-sb1250-mac-typedef-9
patch-netdev-2.6.23-rc6-20070920-sb1250-mac-29

apply cleanly to net-2.6.24 one on top of the other in this order.

 I can resubmit them -- where?  netdev?  As I say I am fine with 2.6.25 as 
the target.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sb1250-mac: Driver model phylib update

[Maciej W. Rozycki]

On Fri, 21 Sep 2007, Andrew Morton wrote:

   A driver model and phylib update.
 
 akpm:/usr/src/25 diffstat patches/git-net.patch | tail -n 1
  1013 files changed, 187667 insertions(+), 23587 deletions(-)
 
 Sorry, but raising networking patches against Linus's crufty
 old mainline tree just isn't viable at present.

 Well, this is against Jeff's netdev-2.6 tree which hopefully is not as 
crufty as Linus's old mainline; if it is not possible to queue this change 
for 2.6.25 or suchlike, then I will try to resubmit later.  Thanks for 
your attention though.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] sb1250-mac: Driver model phylib update

[Maciej W. Rozycki]

 A driver model and phylib update.  It includes the following changes:

1. Removal of unused module options.

2. Phylib support and the resulting removal of generic bits for handling
   the PHY.

3. Proper reserving of device resources and using ioremap()ped handles
   to access MAC registers rather than platform-specific macros.

4. Handling of the device using the driver model.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 This is a resubmission and this patch has waited for some time now as the 
original submission triggered some concerns on the way phylib handled 
interrupt-driven PHY units.  The issues were resolved a while ago already, 
but I was distracted by some other work, mainly in the toolchain area, so 
this got postponed this far.  For some background information -- as a 
reminder -- here is the original long explanation I gave back then:

 Here is a set of patches that update the sb1250-mac driver used for the 
onchip Gigabit Ethernet interfaces of the Broadcom SiByte family of SOCs 
including the BCM1250 and a couple of other members.  These are used, 
among others, on various Broadcom evaluation boards together with Broadcom 
Gigabit Ethernet PHY chips.  Changes include porting the driver to the 
driver model as a platform device, support for phylib, including the 
BCM54xx PHYs in the interrupt mode, proper resource managment and a couple 
of minor clean-ups.

 Apart from changes to networking code, there are a few required in the
architecture-specific areas and therefore I am sending these changes to
Ralf and the linux-mips list as well.  It might also involve a few more
interested parties in the discussion.

 The changes were tested with a Broadcom SWARM board, which includes a
BCM1250 part which has 3 MAC units on chip, of which 2 are usable, with
BCM5421 PHY chips attached (both wired to the same interrupt line, which
made testing whether IRQ sharing works properly in phylib possible).
Link partners included a 1000base and a 100base interface doing
autonegotiation as well as a 10base one doing none.

 Other Broadcom boards that I know of may have these or BCM5411 or BCM5461
chips.  The lack of documentation or at least actual pieces of hardware
makes the use of interrupts impossible for all but the SWARM, the Sentosa
and the Shorty (with the latter unsupported by Linux).

 All the bits except from the mentioned architecture-specific fix -- the 
firmware of the SWARM gets the polarity of the PHY IRQ line wrong, which 
has to be reprogrammed in the SOC -- have found their way into Linux 
already.  The polarity fix is not critical for the update provided here as 
the update has been written such that with the current state of affairs 
the driver will use the polled mode of phylib operation.

 I will provide the architecture-specific fix later on, probably once this 
update has propagated back to the linux-mips.org tree (suggestions as to 
why I should do otherwise certainly welcome).  This way if any problems 
are seen due to the switch of the PHY to the interrupt-driven mode, they 
can be sorted out independently of this change.

 This change applies to the current netdev-2.6.git#upstream tree, on top 
of patch-netdev-2.6.23-rc6-20070920-sb1250-mac-typedef-9 submitted 
yesterday.

 Please apply.

  Maciej

patch-netdev-2.6.23-rc6-20070920-sb1250-mac-29
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070920.macro/drivers/net/Kconfig 
linux-netdev-2.6.23-rc6-20070920/drivers/net/Kconfig
--- linux-netdev-2.6.23-rc6-20070920.macro/drivers/net/Kconfig  2007-09-20 
17:55:14.0 +
+++ linux-netdev-2.6.23-rc6-20070920/drivers/net/Kconfig2007-09-20 
20:31:42.0 +
@@ -2126,6 +2126,7 @@ config R8169_VLAN
 config SB1250_MAC
tristate SB1250 Gigabit Ethernet support
depends on SIBYTE_SB1xxx_SOC
+   select PHYLIB
---help---
  This driver supports Gigabit Ethernet interfaces based on the
  Broadcom SiByte family of System-On-a-Chip parts.  They include
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070920.macro/drivers/net/sb1250-mac.c 
linux-netdev-2.6.23-rc6-20070920/drivers/net/sb1250-mac.c
--- linux-netdev-2.6.23-rc6-20070920.macro/drivers/net/sb1250-mac.c 
2007-09-20 18:09:18.0 +
+++ linux-netdev-2.6.23-rc6-20070920/drivers/net/sb1250-mac.c   2007-09-20 
21:06:55.0 +
@@ -1,5 +1,6 @@
 /*
  * Copyright (C) 2001,2002,2003,2004 Broadcom Corporation
+ * Copyright (c) 2006, 2007  Maciej W. Rozycki
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -18,7 +19,12 @@
  *
  * This driver is designed for the Broadcom SiByte SOC built-in
  * Ethernet controllers. Written by Mitch Lichtenberg at Broadcom Corp.
+ *
+ * Updated to the driver model and the PHY abstraction layer
+ * by Maciej W. Rozycki.
  */
+
+#include linux/bug.h
 #include linux/module.h
 #include linux/kernel.h
 #include linux

Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes

[Maciej W. Rozycki]

On Thu, 20 Sep 2007, Andrew Morton wrote:

 You always put boring, crappy, insufficient text in the for-the-changelog
 section and interesting, useful, sufficient text in the not-for-the-changelog
 section.

 I'll swap the sections in the future then. ;-)  Frankly I was not sure 
whether the changelog was happy about being fed with lengthy explanations 
and it has not spoken out.

 I have to admit this is a habit carried over from the FSF-style ChangeLog 
-- where the enforced rule is actually *not* to provide any explanation 
for why changes are done and only describe what has been modified (with 
any discussion around archived in the respective mailing list).

 But you can't fool me!  I have an editor and I fix it up.

 Thank you and sorry for the extra work I caused you -- I shall keep your 
suggestion in mind in the future.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sb1250-mac.c: De-typedef, de-volatile, de-etc...

[Maciej W. Rozycki]

On Thu, 20 Sep 2007, Jeff Garzik wrote:

  You may be pleased (or less so) to hear that the version of sb1250-mac.c in
  your tree does not even build (because of
  42d53d6be113f974d8152979c88e1061b953bd12) and the patch below does not
  address it.  I ran out of time in the evening, but I will send you a fix
  shortly.  To be honest I think even with bulk changes it may be worth
  checking whether they do not break stuff. ;-)
 
 hrm.  I cannot get this to apply on top of linux-2.6.git,
 netdev-2.6.git#upstream (prior to net-2.6.24 rebase) or
 netdev-2.6.git#upstream (after net-2.6.24 rebase)

 It applies on top of current -mm.  It seems to apply to a copy of 
netdev-2.6.git#upstream that I have got, but I am probably missing 
something...  If I try to clone your repository again I get:

$ git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/linux-netdev-2.6.git linux
Initialized empty Git repository in 
/home/macro/GIT-other/linux-netdev/linux/.git/
fatal: The remote end hung up unexpectedly
fetch-pack from 
'git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/linux-netdev-2.6.git' 
failed.
$

For linux-2.6.git the patch-mips-2.6.23-rc5-20070904-sb1250-mac-typedef-7 
version applies as submitted originally; I can resubmit this one if you 
like.

 I am slowly getting lost and I have another big chunk for sb1250-mac.c 
waiting to be put on top of these...

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sb1250-mac.c: De-typedef, de-volatile, de-etc...

[Maciej W. Rozycki]

 Remove typedefs, volatiles and convert kmalloc()/memset() pairs to
kcalloc().  Also reformat the surrounding clutter.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
On Thu, 20 Sep 2007, Jeff Garzik wrote:

 Remove the linux- prefix.

 Hmm, it looks like a bad application of `sed' by myself.  Sorry for the 
noise.

  Maciej

patch-netdev-2.6.23-rc6-20070920-sb1250-mac-typedef-9
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070920.macro/drivers/net/sb1250-mac.c 
linux-netdev-2.6.23-rc6-20070920/drivers/net/sb1250-mac.c
--- linux-netdev-2.6.23-rc6-20070920.macro/drivers/net/sb1250-mac.c 
2007-09-20 17:55:14.0 +
+++ linux-netdev-2.6.23-rc6-20070920/drivers/net/sb1250-mac.c   2007-09-20 
18:09:18.0 +
@@ -140,17 +140,17 @@ MODULE_PARM_DESC(int_timeout_rx, RX tim
  * */
 
 
-typedef enum { sbmac_speed_auto, sbmac_speed_10,
-  sbmac_speed_100, sbmac_speed_1000 } sbmac_speed_t;
+enum sbmac_speed { sbmac_speed_auto, sbmac_speed_10,
+  sbmac_speed_100, sbmac_speed_1000 };
 
-typedef enum { sbmac_duplex_auto, sbmac_duplex_half,
-  sbmac_duplex_full } sbmac_duplex_t;
+enum sbmac_duplex { sbmac_duplex_auto, sbmac_duplex_half,
+   sbmac_duplex_full };
 
-typedef enum { sbmac_fc_auto, sbmac_fc_disabled, sbmac_fc_frame,
-  sbmac_fc_collision, sbmac_fc_carrier } sbmac_fc_t;
+enum sbmac_fc { sbmac_fc_auto, sbmac_fc_disabled, sbmac_fc_frame,
+   sbmac_fc_collision, sbmac_fc_carrier } sbmac_fc_t;
 
-typedef enum { sbmac_state_uninit, sbmac_state_off, sbmac_state_on,
-  sbmac_state_broken } sbmac_state_t;
+enum sbmac_state { sbmac_state_uninit, sbmac_state_off, sbmac_state_on,
+  sbmac_state_broken };
 
 
 /**
@@ -176,55 +176,61 @@ typedef enum { sbmac_state_uninit, sbmac
  *  DMA Descriptor structure
  * */
 
-typedef struct sbdmadscr_s {
+struct sbdmadscr {
uint64_t  dscr_a;
uint64_t  dscr_b;
-} sbdmadscr_t;
-
-typedef unsigned long paddr_t;
+};
 
 /**
  *  DMA Controller structure
  * */
 
-typedef struct sbmacdma_s {
+struct sbmacdma {
 
/*
 * This stuff is used to identify the channel and the registers
 * associated with it.
 */
-
-   struct sbmac_softc *sbdma_eth;  /* back pointer to associated MAC */
-   int  sbdma_channel; /* channel number */
-   int  sbdma_txdir;   /* direction (1=transmit) */
-   int  sbdma_maxdescr;/* total # of descriptors in ring */
+   struct sbmac_softc  *sbdma_eth; /* back pointer to associated
+  MAC */
+   int sbdma_channel;  /* channel number */
+   int sbdma_txdir;/* direction (1=transmit) */
+   int sbdma_maxdescr; /* total # of descriptors
+  in ring */
 #ifdef CONFIG_SBMAC_COALESCE
-   int  sbdma_int_pktcnt;  /* # descriptors rx/tx before 
interrupt*/
-   int  sbdma_int_timeout; /* # usec rx/tx interrupt */
+   int sbdma_int_pktcnt;
+   /* # descriptors rx/tx
+  before interrupt */
+   int sbdma_int_timeout;
+   /* # usec rx/tx interrupt */
 #endif
-
-   volatile void __iomem *sbdma_config0;   /* DMA config register 0 */
-   volatile void __iomem *sbdma_config1;   /* DMA config register 1 */
-   volatile void __iomem *sbdma_dscrbase;  /* Descriptor base address */
-   volatile void __iomem *sbdma_dscrcnt;   /* Descriptor count register */
-   volatile void __iomem *sbdma_curdscr;   /* current descriptor address */
-   volatile void __iomem *sbdma_oodpktlost;/* pkt drop (rx only) */
-
+   void __iomem*sbdma_config0; /* DMA config register 0 */
+   void __iomem*sbdma_config1; /* DMA config register 1 */
+   void __iomem*sbdma_dscrbase;
+   /* descriptor base address */
+   void __iomem*sbdma_dscrcnt; /* descriptor count register */
+   void __iomem*sbdma_curdscr; /* current descriptor
+  address */
+   void __iomem*sbdma_oodpktlost;
+   /* pkt drop (rx only) */
 
/*
 * This stuff is for maintenance of the ring

[PATCH] PHYLIB: IRQ event workqueue handling fixes

[Maciej W. Rozycki]

 Keep track of disable_irq_nosync() invocations and call enable_irq() the 
right number of times if work has been cancelled that would include them.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 Now that the call to flush_work_keventd() (problematic because of 
rtnl_mutex being held) has been replaced by cancel_work_sync() another 
issue has arisen and been left unresolved.  As the MDIO bus cannot be 
accessed from the interrupt context the PHY interrupt handler uses 
disable_irq_nosync() to prevent from looping and schedules some work to be 
done as a softirq, which, apart from handling the state change of the 
originating PHY, is responsible for reenabling the interrupt.  Now if the 
interrupt line is shared by another device and a call to the softirq 
handler has been cancelled, that call to enable_irq() never happens and 
the other device cannot use its interrupt anymore as its stuck disabled.

 I decided to use a counter rather than a flag because there may be more 
than one call to phy_change() cancelled in the queue -- a real one and a 
fake one triggered by free_irq() if DEBUG_SHIRQ is used, if nothing else.  
Therefore because of its nesting property enable_irq() has to be called 
the right number of times to match the number disable_irq_nosync() was 
called and restore the original state.  This DEBUG_SHIRQ feature is also 
the reason why free_irq() has to be called before cancel_work_sync().

 While at it I updated the comment about phy_stop_interrupts() being 
called from `keventd' -- this is no longer relevant as the use of 
cancel_work_sync() makes such an approach unnecessary.  OTOH a similar 
comment referring to flush_scheduled_work() in phy_stop() still applies as 
using cancel_work_sync() there would be dangerous.

 Checked with checkpatch.pl and at the run time (with and without 
DEBUG_SHIRQ).

 Please apply.

  Maciej
 
patch-mips-2.6.23-rc5-20070904-phy-irq-fix-9
diff -up --recursive --new-file 
linux-mips-2.6.23-rc5-20070904.macro/drivers/net/phy/phy.c 
linux-mips-2.6.23-rc5-20070904/drivers/net/phy/phy.c
--- linux-mips-2.6.23-rc5-20070904.macro/drivers/net/phy/phy.c  2007-09-16 
17:17:20.0 +
+++ linux-mips-2.6.23-rc5-20070904/drivers/net/phy/phy.c2007-09-18 
14:28:07.0 +
@@ -7,7 +7,7 @@
  * Author: Andy Fleming
  *
  * Copyright (c) 2004 Freescale Semiconductor, Inc.
- * Copyright (c) 2006  Maciej W. Rozycki
+ * Copyright (c) 2006, 2007  Maciej W. Rozycki
  *
  * This program is free software; you can redistribute  it and/or modify it
  * under  the terms of  the GNU General  Public License as published by the
@@ -35,6 +35,7 @@
 #include linux/timer.h
 #include linux/workqueue.h
 
+#include asm/atomic.h
 #include asm/io.h
 #include asm/irq.h
 #include asm/uaccess.h
@@ -561,6 +562,7 @@ static irqreturn_t phy_interrupt(int irq
 * queue will write the PHY to disable and clear the
 * interrupt, and then reenable the irq line. */
disable_irq_nosync(irq);
+   atomic_inc(phydev-irq_disable);
 
schedule_work(phydev-phy_queue);
 
@@ -631,6 +633,7 @@ int phy_start_interrupts(struct phy_devi
 
INIT_WORK(phydev-phy_queue, phy_change);
 
+   atomic_set(phydev-irq_disable, 0);
if (request_irq(phydev-irq, phy_interrupt,
IRQF_SHARED,
phy_interrupt,
@@ -661,13 +664,22 @@ int phy_stop_interrupts(struct phy_devic
if (err)
phy_error(phydev);
 
+   free_irq(phydev-irq, phydev);
+
/*
-* Finish any pending work; we might have been scheduled to be called
-* from keventd ourselves, but cancel_work_sync() handles that.
+* Cannot call flush_scheduled_work() here as desired because
+* of rtnl_lock(), but we do not really care about what would
+* be done, except from enable_irq(), so cancel any work
+* possibly pending and take care of the matter below.
 */
cancel_work_sync(phydev-phy_queue);
-
-   free_irq(phydev-irq, phydev);
+   /*
+* If work indeed has been cancelled, disable_irq() will have
+* been left unbalanced from phy_interrupt() and enable_irq()
+* has to be called so that other devices on the line work.
+*/
+   while (atomic_dec_return(phydev-irq_disable) = 0)
+   enable_irq(phydev-irq);
 
return err;
 }
@@ -694,6 +706,7 @@ static void phy_change(struct work_struc
phydev-state = PHY_CHANGELINK;
spin_unlock(phydev-lock);
 
+   atomic_dec(phydev-irq_disable);
enable_irq(phydev-irq);
 
/* Reenable interrupts */
@@ -707,6 +720,7 @@ static void phy_change(struct work_struc
 
 irq_enable_err:
disable_irq(phydev-irq);
+   atomic_inc(phydev-irq_disable);
 phy_err:
phy_error(phydev);
 }
diff -up --recursive --new-file 
linux-mips-2.6.23-rc5-20070904.macro/include/linux/phy.h 
linux-mips-2.6.23-rc5-20070904/include/linux

[PATCH] PHYLIB: Fix an interrupt loop potential when halting

[Maciej W. Rozycki]

 Ensure the PHY_HALTED state is not entered with the IRQ asserted as it 
could lead to an interrupt loop.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 There is a small window in phy_stop(), where the state of the PHY machine 
indicates it has been halted, but its interrupt output might still be 
unmasked.  If an interrupt goes active right at this moment it will loop 
as the phy_interrupt() handler exits immediately with IRQ_NONE if the 
halted state is seen.  It is unsafe to extend the phydev spinlock to cover 
phy_interrupt().  It is safe to swap the order of the actions though as 
all the competing places to unmask the interrupt output of the PHY, which 
are phy_change() and phy_timer() are already covered with the lock as is 
the sequence in question.

 Checked with checkpatch.pl and at the run time.

 Please apply.

  Maciej
 
patch-mips-2.6.23-rc5-20070904-phy-halt-0
diff -up --recursive --new-file 
linux-mips-2.6.23-rc5-20070904.macro/drivers/net/phy/phy.c 
linux-mips-2.6.23-rc5-20070904/drivers/net/phy/phy.c
--- linux-mips-2.6.23-rc5-20070904.macro/drivers/net/phy/phy.c  2007-09-04 
04:55:42.0 +
+++ linux-mips-2.6.23-rc5-20070904/drivers/net/phy/phy.c2007-09-16 
17:17:20.0 +
@@ -722,8 +722,6 @@ void phy_stop(struct phy_device *phydev)
if (PHY_HALTED == phydev-state)
goto out_unlock;
 
-   phydev-state = PHY_HALTED;
-
if (phydev-irq != PHY_POLL) {
/* Disable PHY Interrupts */
phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED);
@@ -732,6 +730,8 @@ void phy_stop(struct phy_device *phydev)
phy_clear_interrupt(phydev);
}
 
+   phydev-state = PHY_HALTED;
+
 out_unlock:
spin_unlock(phydev-lock);
 
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] PHYLIB: Spinlock fixes for softirqs

[Maciej W. Rozycki]

 Use spin_lock_bh()/spin_unlock_bh() for the phydev lock throughout as it 
is used in phy_timer() that is called as a softirq and all the other 
operations may happen in the user context.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 There has been a change recently that did such a conversion for some of 
the operations on the lock, but some have been left intact.  Many of them, 
perhaps all, may be called in the user context and I was able to trigger 
recursive spinlock acquisition indeed, so I think for the sake of 
long-term maintenance it is best to convert them all, even if 
unnecessarily for one or two -- better safe than sorry.

 Perhaps one in phy_timer() could actually be skipped as only called as a 
softirq -- I can send an update if that sounds like a good idea.

 Checked with checkpatch.pl and at the runtime.

 Please apply,

  Maciej

patch-netdev-2.6.23-rc6-20070913-phy-spinlock-8 
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/phy/phy.c 
linux-netdev-2.6.23-rc6-20070913/drivers/net/phy/phy.c
--- linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/phy/phy.c
2007-09-13 17:27:52.0 +
+++ linux-netdev-2.6.23-rc6-20070913/drivers/net/phy/phy.c  2007-09-16 
17:26:02.0 +
@@ -423,7 +423,7 @@ int phy_start_aneg(struct phy_device *ph
 {
int err;
 
-   spin_lock(phydev-lock);
+   spin_lock_bh(phydev-lock);
 
if (AUTONEG_DISABLE == phydev-autoneg)
phy_sanitize_settings(phydev);
@@ -444,7 +444,7 @@ int phy_start_aneg(struct phy_device *ph
}
 
 out_unlock:
-   spin_unlock(phydev-lock);
+   spin_unlock_bh(phydev-lock);
return err;
 }
 EXPORT_SYMBOL(phy_start_aneg);
@@ -489,10 +489,10 @@ void phy_stop_machine(struct phy_device 
 {
del_timer_sync(phydev-phy_timer);
 
-   spin_lock(phydev-lock);
+   spin_lock_bh(phydev-lock);
if (phydev-state  PHY_UP)
phydev-state = PHY_UP;
-   spin_unlock(phydev-lock);
+   spin_unlock_bh(phydev-lock);
 
phydev-adjust_state = NULL;
 }
@@ -536,9 +536,9 @@ static void phy_force_reduction(struct p
  */
 void phy_error(struct phy_device *phydev)
 {
-   spin_lock(phydev-lock);
+   spin_lock_bh(phydev-lock);
phydev-state = PHY_HALTED;
-   spin_unlock(phydev-lock);
+   spin_unlock_bh(phydev-lock);
 }
 
 /**
@@ -689,10 +689,10 @@ static void phy_change(struct work_struc
if (err)
goto phy_err;
 
-   spin_lock(phydev-lock);
+   spin_lock_bh(phydev-lock);
if ((PHY_RUNNING == phydev-state) || (PHY_NOLINK == phydev-state))
phydev-state = PHY_CHANGELINK;
-   spin_unlock(phydev-lock);
+   spin_unlock_bh(phydev-lock);
 
enable_irq(phydev-irq);
 
@@ -717,7 +717,7 @@ phy_err:
  */
 void phy_stop(struct phy_device *phydev)
 {
-   spin_lock(phydev-lock);
+   spin_lock_bh(phydev-lock);
 
if (PHY_HALTED == phydev-state)
goto out_unlock;
@@ -733,7 +733,7 @@ void phy_stop(struct phy_device *phydev)
}
 
 out_unlock:
-   spin_unlock(phydev-lock);
+   spin_unlock_bh(phydev-lock);
 
/*
 * Cannot call flush_scheduled_work() here as desired because
@@ -781,7 +781,7 @@ static void phy_timer(unsigned long data
int needs_aneg = 0;
int err = 0;
 
-   spin_lock(phydev-lock);
+   spin_lock_bh(phydev-lock);
 
if (phydev-adjust_state)
phydev-adjust_state(phydev-attached_dev);
@@ -947,7 +947,7 @@ static void phy_timer(unsigned long data
break;
}
 
-   spin_unlock(phydev-lock);
+   spin_unlock_bh(phydev-lock);
 
if (needs_aneg)
err = phy_start_aneg(phydev);
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/phy/phy_device.c 
linux-netdev-2.6.23-rc6-20070913/drivers/net/phy/phy_device.c
--- linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/phy/phy_device.c 
2007-09-13 17:27:52.0 +
+++ linux-netdev-2.6.23-rc6-20070913/drivers/net/phy/phy_device.c   
2007-09-16 17:27:48.0 +
@@ -670,9 +670,9 @@ static int phy_remove(struct device *dev
 
phydev = to_phy_device(dev);
 
-   spin_lock(phydev-lock);
+   spin_lock_bh(phydev-lock);
phydev-state = PHY_DOWN;
-   spin_unlock(phydev-lock);
+   spin_unlock_bh(phydev-lock);
 
if (phydev-drv-remove)
phydev-drv-remove(phydev);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sb1250-mac.c: De-typedef, de-volatile, de-etc...

[Maciej W. Rozycki]

 Remove typedefs, volatiles and convert kmalloc()/memset() pairs to
kcalloc().  Also reformat the surrounding clutter.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
On Thu, 13 Sep 2007, Jeff Garzik wrote:

 Net driver patches should apply on top of netdev-2.6.git#upstream, which is
 where changes to net drivers are queued for the next release.

 I can see Andrew has done some changes to the patch and applied it 
anyway, but here's a version I generated against your tree.  Please feel 
free to choose either.

 You may be pleased (or less so) to hear that the version of sb1250-mac.c 
in your tree does not even build (because of 
42d53d6be113f974d8152979c88e1061b953bd12) and the patch below does not 
address it.  I ran out of time in the evening, but I will send you a fix 
shortly.  To be honest I think even with bulk changes it may be worth 
checking whether they do not break stuff. ;-)

  Maciej

patch-netdev-2.6.23-rc6-20070913-sb1250-mac-typedef-8
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/sb1250-mac.c 
linux-netdev-2.6.23-rc6-20070913/drivers/net/sb1250-mac.c
--- linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/sb1250-mac.c 
2007-09-13 17:27:52.0 +
+++ linux-netdev-2.6.23-rc6-20070913/drivers/net/sb1250-mac.c   2007-09-13 
23:44:45.0 +
@@ -140,17 +140,17 @@ MODULE_PARM_DESC(int_timeout_rx, RX tim
  * */
 
 
-typedef enum { sbmac_speed_auto, sbmac_speed_10,
-  sbmac_speed_100, sbmac_speed_1000 } sbmac_speed_t;
+enum sbmac_speed { sbmac_speed_auto, sbmac_speed_10,
+  sbmac_speed_100, sbmac_speed_1000 };
 
-typedef enum { sbmac_duplex_auto, sbmac_duplex_half,
-  sbmac_duplex_full } sbmac_duplex_t;
+enum sbmac_duplex { sbmac_duplex_auto, sbmac_duplex_half,
+   sbmac_duplex_full };
 
-typedef enum { sbmac_fc_auto, sbmac_fc_disabled, sbmac_fc_frame,
-  sbmac_fc_collision, sbmac_fc_carrier } sbmac_fc_t;
+enum sbmac_fc { sbmac_fc_auto, sbmac_fc_disabled, sbmac_fc_frame,
+   sbmac_fc_collision, sbmac_fc_carrier } sbmac_fc_t;
 
-typedef enum { sbmac_state_uninit, sbmac_state_off, sbmac_state_on,
-  sbmac_state_broken } sbmac_state_t;
+enum sbmac_state { sbmac_state_uninit, sbmac_state_off, sbmac_state_on,
+  sbmac_state_broken };
 
 
 /**
@@ -176,55 +176,61 @@ typedef enum { sbmac_state_uninit, sbmac
  *  DMA Descriptor structure
  * */
 
-typedef struct sbdmadscr_s {
+struct sbdmadscr {
uint64_t  dscr_a;
uint64_t  dscr_b;
-} sbdmadscr_t;
-
-typedef unsigned long paddr_t;
+};
 
 /**
  *  DMA Controller structure
  * */
 
-typedef struct sbmacdma_s {
+struct sbmacdma {
 
/*
 * This stuff is used to identify the channel and the registers
 * associated with it.
 */
-
-   struct sbmac_softc *sbdma_eth;  /* back pointer to associated MAC */
-   int  sbdma_channel; /* channel number */
-   int  sbdma_txdir;   /* direction (1=transmit) */
-   int  sbdma_maxdescr;/* total # of descriptors in ring */
+   struct sbmac_softc  *sbdma_eth; /* back pointer to associated
+  MAC */
+   int sbdma_channel;  /* channel number */
+   int sbdma_txdir;/* direction (1=transmit) */
+   int sbdma_maxdescr; /* total # of descriptors
+  in ring */
 #ifdef CONFIG_SBMAC_COALESCE
-   int  sbdma_int_pktcnt;  /* # descriptors rx/tx before 
interrupt*/
-   int  sbdma_int_timeout; /* # usec rx/tx interrupt */
-#endif
-
-   volatile void __iomem *sbdma_config0;   /* DMA config register 0 */
-   volatile void __iomem *sbdma_config1;   /* DMA config register 1 */
-   volatile void __iomem *sbdma_dscrbase;  /* Descriptor base address */
-   volatile void __iomem *sbdma_dscrcnt;   /* Descriptor count register */
-   volatile void __iomem *sbdma_curdscr;   /* current descriptor address */
-   volatile void __iomem *sbdma_oodpktlost;/* pkt drop (rx only) */
-
+   int sbdma_int_pktcnt;
+   /* # descriptors rx/tx
+  before interrupt */
+   int sbdma_int_timeout;
+   /* # usec rx/tx interrupt */
+#endif
+   void __iomem*sbdma_config0; /* DMA config register 0 */
+   void __iomem

[PATCH] NET_SB1250_MAC: Update Kconfig entry

[Maciej W. Rozycki]

 The SB1250 network interfaces are Gigabit Ethernet ones.  Move the 
Kconfig entry to the appropriate section and add some help text.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 It should be obvious; I hope the help text will be useful to somebody and 
will prevent from misclassifying the interface again in the future.

 Please apply,

  Maciej

patch-netdev-2.6.23-rc6-20070913-sb1250-mac-kconfig-0
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/Kconfig 
linux-netdev-2.6.23-rc6-20070913/drivers/net/Kconfig
--- linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/Kconfig  2007-09-13 
17:27:52.0 +
+++ linux-netdev-2.6.23-rc6-20070913/drivers/net/Kconfig2007-09-14 
00:02:05.0 +
@@ -466,10 +466,6 @@ config MIPS_AU1X00_ENET
  If you have an Alchemy Semi AU1X00 based system
  say Y.  Otherwise, say N.
 
-config NET_SB1250_MAC
-   tristate SB1250 Ethernet support
-   depends on SIBYTE_SB1xxx_SOC
-
 config SGI_IOC3_ETH
bool SGI IOC3 Ethernet
depends on PCI  SGI_IP27
@@ -2157,6 +2153,18 @@ config R8169_VLAN
  
  If in doubt, say Y.
 
+config NET_SB1250_MAC
+   tristate SB1250 Gigabit Ethernet support
+   depends on SIBYTE_SB1xxx_SOC
+   ---help---
+ This driver supports Gigabit Ethernet interfaces based on the
+ Broadcom SiByte family of System-On-a-Chip parts.  They include
+ the BCM1120, BCM1125, BCM1125H, BCM1250, BCM1255, BCM1280, BCM1455
+ and BCM1480 chips.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sb1250-mac.
+
 config SIS190
tristate SiS190/SiS191 gigabit ethernet support
depends on PCI
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] NET_SB1250_MAC: Rename to SB1250_MAC

[Maciej W. Rozycki]

 Rename NET_SB1250_MAC to SB1250_MAC to follow the convention.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 The NET prefix seems to be used mainly for device groups (NET_ISA, 
NET_VENDOR_*, etc.) rather than single drivers and adds no information.  I 
suggest it to be removed.

 Depends on patch-netdev-2.6.23-rc6-20070913-sb1250-mac-kconfig-0.

 Please consider,

  Maciej

patch-netdev-2.6.23-rc6-20070913-sb1250-mac-config-0
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070913.macro/arch/mips/configs/bigsur_defconfig 
linux-netdev-2.6.23-rc6-20070913/arch/mips/configs/bigsur_defconfig
--- linux-netdev-2.6.23-rc6-20070913.macro/arch/mips/configs/bigsur_defconfig   
2007-09-04 04:55:19.0 +
+++ linux-netdev-2.6.23-rc6-20070913/arch/mips/configs/bigsur_defconfig 
2007-09-14 00:22:18.0 +
@@ -574,7 +574,7 @@ CONFIG_MII=y
 # CONFIG_HAMACHI is not set
 # CONFIG_YELLOWFIN is not set
 # CONFIG_R8169 is not set
-CONFIG_NET_SB1250_MAC=y
+CONFIG_SB1250_MAC=y
 # CONFIG_SIS190 is not set
 # CONFIG_SKGE is not set
 # CONFIG_SKY2 is not set
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070913.macro/arch/mips/configs/sb1250-swarm_defconfig 
linux-netdev-2.6.23-rc6-20070913/arch/mips/configs/sb1250-swarm_defconfig
--- 
linux-netdev-2.6.23-rc6-20070913.macro/arch/mips/configs/sb1250-swarm_defconfig 
2007-09-04 04:55:19.0 +
+++ linux-netdev-2.6.23-rc6-20070913/arch/mips/configs/sb1250-swarm_defconfig   
2007-09-14 00:22:29.0 +
@@ -566,7 +566,7 @@ CONFIG_MII=y
 # CONFIG_HAMACHI is not set
 # CONFIG_YELLOWFIN is not set
 # CONFIG_R8169 is not set
-CONFIG_NET_SB1250_MAC=y
+CONFIG_SB1250_MAC=y
 # CONFIG_SIS190 is not set
 # CONFIG_SKGE is not set
 # CONFIG_SKY2 is not set
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/Kconfig 
linux-netdev-2.6.23-rc6-20070913/drivers/net/Kconfig
--- linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/Kconfig  2007-09-14 
00:02:05.0 +
+++ linux-netdev-2.6.23-rc6-20070913/drivers/net/Kconfig2007-09-14 
00:21:06.0 +
@@ -2153,7 +2153,7 @@ config R8169_VLAN
  
  If in doubt, say Y.
 
-config NET_SB1250_MAC
+config SB1250_MAC
tristate SB1250 Gigabit Ethernet support
depends on SIBYTE_SB1xxx_SOC
---help---
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/Makefile 
linux-netdev-2.6.23-rc6-20070913/drivers/net/Makefile
--- linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/Makefile 2007-09-13 
17:27:52.0 +
+++ linux-netdev-2.6.23-rc6-20070913/drivers/net/Makefile   2007-09-14 
00:21:20.0 +
@@ -107,7 +107,7 @@ obj-$(CONFIG_E2100) += e2100.o 8390.o
 obj-$(CONFIG_ES3210) += es3210.o 8390.o
 obj-$(CONFIG_LNE390) += lne390.o 8390.o
 obj-$(CONFIG_NE3210) += ne3210.o 8390.o
-obj-$(CONFIG_NET_SB1250_MAC) += sb1250-mac.o
+obj-$(CONFIG_SB1250_MAC) += sb1250-mac.o
 obj-$(CONFIG_B44) += b44.o
 obj-$(CONFIG_FORCEDETH) += forcedeth.o
 obj-$(CONFIG_NE_H8300) += ne-h8300.o
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] sb1250-mac.c: Fix stats references

[Maciej W. Rozycki]

 Fix build errors resulting from a recent commit that added references to 
stats through dev from sbdma_rx_process() and sbdma_tx_process(), but 
no definitions of that variable.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 This is probably the simplest fix possible, though at this point it is of 
question whether it is still struct sbmac_softc * that should be passed 
to these functions.  I'll leave it to another occasion though.

 Applies under patch-netdev-2.6.23-rc6-20070913-sb1250-mac-typedef-8.

 Please apply,

  Maciej

patch-netdev-2.6.23-rc6-20070913-sb1250-mac-fix-1
diff -up --recursive --new-file 
linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/sb1250-mac.c 
linux-netdev-2.6.23-rc6-20070913/drivers/net/sb1250-mac.c
--- linux-netdev-2.6.23-rc6-20070913.macro/drivers/net/sb1250-mac.c 
2007-09-13 17:27:52.0 +
+++ linux-netdev-2.6.23-rc6-20070913/drivers/net/sb1250-mac.c   2007-09-14 
12:06:15.0 +
@@ -1187,6 +1187,7 @@ static void sbmac_netpoll(struct net_dev
 static int sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d,
  int work_to_do, int poll)
 {
+   struct net_device *dev = sc-sbm_dev;
int curidx;
int hwidx;
sbdmadscr_t *dsc;
@@ -1348,6 +1349,7 @@ done:
 
 static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d, int poll)
 {
+   struct net_device *dev = sc-sbm_dev;
int curidx;
int hwidx;
sbdmadscr_t *dsc;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sb1250-mac.c: De-typedef, de-volatile, de-etc...

[Maciej W. Rozycki]

On Wed, 12 Sep 2007, Jeff Garzik wrote:

  Remove typedefs, volatiles and convert kmalloc()/memset() pairs to
  kcalloc().  Also reformat the surrounding clutter.
  
  Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
  ---
 
 ACK, but patch does not apply cleanly to netdev-2.6.git#upstream (nor -mm)

 Hmm, works fine with linux-2.6.git#master.  I do not recall any recent 
activity with this driver -- I wonder what the difference is.  Let me 
see...

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] sb1250-mac.c: De-typedef, de-volatile, de-etc...

[Maciej W. Rozycki]

 Remove typedefs, volatiles and convert kmalloc()/memset() pairs to
kcalloc().  Also reformat the surrounding clutter.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 Per your request, Andrew, a while ago.  It builds, runs, passes 
checkpatch.pl and sparse.  No semantic changes.

 Please apply,

  Maciej

patch-mips-2.6.23-rc5-20070904-sb1250-mac-typedef-7
diff -up --recursive --new-file 
linux-mips-2.6.23-rc5-20070904.macro/drivers/net/sb1250-mac.c 
linux-mips-2.6.23-rc5-20070904/drivers/net/sb1250-mac.c
--- linux-mips-2.6.23-rc5-20070904.macro/drivers/net/sb1250-mac.c   
2007-07-10 04:57:46.0 +
+++ linux-mips-2.6.23-rc5-20070904/drivers/net/sb1250-mac.c 2007-09-10 
01:01:09.0 +
@@ -140,17 +140,17 @@ MODULE_PARM_DESC(int_timeout_rx, RX tim
  * */
 
 
-typedef enum { sbmac_speed_auto, sbmac_speed_10,
-  sbmac_speed_100, sbmac_speed_1000 } sbmac_speed_t;
+enum sbmac_speed { sbmac_speed_auto, sbmac_speed_10,
+  sbmac_speed_100, sbmac_speed_1000 };
 
-typedef enum { sbmac_duplex_auto, sbmac_duplex_half,
-  sbmac_duplex_full } sbmac_duplex_t;
+enum sbmac_duplex { sbmac_duplex_auto, sbmac_duplex_half,
+   sbmac_duplex_full };
 
-typedef enum { sbmac_fc_auto, sbmac_fc_disabled, sbmac_fc_frame,
-  sbmac_fc_collision, sbmac_fc_carrier } sbmac_fc_t;
+enum sbmac_fc { sbmac_fc_auto, sbmac_fc_disabled, sbmac_fc_frame,
+   sbmac_fc_collision, sbmac_fc_carrier } sbmac_fc_t;
 
-typedef enum { sbmac_state_uninit, sbmac_state_off, sbmac_state_on,
-  sbmac_state_broken } sbmac_state_t;
+enum sbmac_state { sbmac_state_uninit, sbmac_state_off, sbmac_state_on,
+  sbmac_state_broken };
 
 
 /**
@@ -176,55 +176,61 @@ typedef enum { sbmac_state_uninit, sbmac
  *  DMA Descriptor structure
  * */
 
-typedef struct sbdmadscr_s {
+struct sbdmadscr {
uint64_t  dscr_a;
uint64_t  dscr_b;
-} sbdmadscr_t;
-
-typedef unsigned long paddr_t;
+};
 
 /**
  *  DMA Controller structure
  * */
 
-typedef struct sbmacdma_s {
+struct sbmacdma {
 
/*
 * This stuff is used to identify the channel and the registers
 * associated with it.
 */
-
-   struct sbmac_softc *sbdma_eth;  /* back pointer to associated MAC */
-   int  sbdma_channel; /* channel number */
-   int  sbdma_txdir;   /* direction (1=transmit) */
-   int  sbdma_maxdescr;/* total # of descriptors in ring */
+   struct sbmac_softc  *sbdma_eth; /* back pointer to associated
+  MAC */
+   int sbdma_channel;  /* channel number */
+   int sbdma_txdir;/* direction (1=transmit) */
+   int sbdma_maxdescr; /* total # of descriptors
+  in ring */
 #ifdef CONFIG_SBMAC_COALESCE
-   int  sbdma_int_pktcnt;  /* # descriptors rx/tx before 
interrupt*/
-   int  sbdma_int_timeout; /* # usec rx/tx interrupt */
-#endif
-
-   volatile void __iomem *sbdma_config0;   /* DMA config register 0 */
-   volatile void __iomem *sbdma_config1;   /* DMA config register 1 */
-   volatile void __iomem *sbdma_dscrbase;  /* Descriptor base address */
-   volatile void __iomem *sbdma_dscrcnt;   /* Descriptor count register */
-   volatile void __iomem *sbdma_curdscr;   /* current descriptor address */
-   volatile void __iomem *sbdma_oodpktlost;/* pkt drop (rx only) */
-
+   int sbdma_int_pktcnt;
+   /* # descriptors rx/tx
+  before interrupt */
+   int sbdma_int_timeout;
+   /* # usec rx/tx interrupt */
+#endif
+   void __iomem*sbdma_config0; /* DMA config register 0 */
+   void __iomem*sbdma_config1; /* DMA config register 1 */
+   void __iomem*sbdma_dscrbase;
+   /* descriptor base address */
+   void __iomem*sbdma_dscrcnt; /* descriptor count register */
+   void __iomem*sbdma_curdscr; /* current descriptor
+  address */
+   void __iomem*sbdma_oodpktlost;
+   /* pkt drop (rx only) */
 
/*
 * This stuff is for maintenance of the ring
 */
-
-   sbdmadscr_t

Re: [PATCH] Prefix each line of multiline printk(KERN_level foo\nbar) with KERN_level

[Maciej W. Rozycki]

On Sun, 26 Aug 2007, Geert Uytterhoeven wrote:

 What I mean is that probably there used to be a printk() call starting with
 `\n'. Then someone added a `KERN_ERR' in front of it.

 I gather '\n' at the beginning is to assure the following line is output 
on a separate line rather than as a continuation of another one which may 
have been output without a trailing '\n'.  A situation where printk() is 
called with a string containing no trailing '\n' may be discouraged, but 
there are some more or less justified exceptions.  For example the SCSI 
disk spin-up code is one.

 Therefore it may be reasonable for more critical messages -- perhaps not 
ones at KERN_ERR, but certainly KERN_CRIT and higher ones -- that may 
potentially happen asynchronously to start with '\n'.  In this case a call 
would look like this:

printk(\n KERN_CRIT The actual message.\n);

Of course based on console_loglevel and default_message_level the 
leading '\n' may still get swallowed from what gets printed to the console 
terminal, but in reality I do not think that poses a problem, as these 
both can be set by a system administrator according to the local policy.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] defxx: Use __maybe_unused rather than a local hack

[Maciej W. Rozycki]

 This is a change to remove a local hack in favour to __maybe_unused that 
has been recently added.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
Hi,

 It should be obvious.  The code builds, therefore it works.

 Please apply,

  Maciej

patch-mips-2.6.22-20070710-defxx-unused-0
diff -up --recursive --new-file 
linux-mips-2.6.22-20070710.macro/drivers/net/defxx.c 
linux-mips-2.6.22-20070710/drivers/net/defxx.c
--- linux-mips-2.6.22-20070710.macro/drivers/net/defxx.c2007-07-10 
04:56:16.0 +
+++ linux-mips-2.6.22-20070710/drivers/net/defxx.c  2007-07-20 
00:05:14.0 +
@@ -200,6 +200,7 @@
 
 /* Include files */
 #include linux/bitops.h
+#include linux/compiler.h
 #include linux/delay.h
 #include linux/dma-mapping.h
 #include linux/eisa.h
@@ -240,8 +241,6 @@ static char version[] __devinitdata =
  */
 #define NEW_SKB_SIZE (PI_RCV_DATA_K_SIZE_MAX+128)
 
-#define __unused __attribute__ ((unused))
-
 #ifdef CONFIG_PCI
 #define DFX_BUS_PCI(dev) (dev-bus == pci_bus_type)
 #else
@@ -375,7 +374,7 @@ static inline void dfx_outl(DFX_board_t 
 
 static void dfx_port_write_long(DFX_board_t *bp, int offset, u32 data)
 {
-   struct device __unused *bdev = bp-bus_dev;
+   struct device __maybe_unused *bdev = bp-bus_dev;
int dfx_bus_tc = DFX_BUS_TC(bdev);
int dfx_use_mmio = DFX_MMIO || dfx_bus_tc;
 
@@ -399,7 +398,7 @@ static inline void dfx_inl(DFX_board_t *
 
 static void dfx_port_read_long(DFX_board_t *bp, int offset, u32 *data)
 {
-   struct device __unused *bdev = bp-bus_dev;
+   struct device __maybe_unused *bdev = bp-bus_dev;
int dfx_bus_tc = DFX_BUS_TC(bdev);
int dfx_use_mmio = DFX_MMIO || dfx_bus_tc;
 
@@ -866,7 +865,7 @@ static void __devinit dfx_bus_uninit(str
 
 static void __devinit dfx_bus_config_check(DFX_board_t *bp)
 {
-   struct device __unused *bdev = bp-bus_dev;
+   struct device __maybe_unused *bdev = bp-bus_dev;
int dfx_bus_eisa = DFX_BUS_EISA(bdev);
int status; /* return code from adapter 
port control call */
u32 host_data;  /* LW data returned from port 
control call */
@@ -3624,8 +3623,8 @@ static void __devexit dfx_unregister(str
 }
 
 
-static int __devinit __unused dfx_dev_register(struct device *);
-static int __devexit __unused dfx_dev_unregister(struct device *);
+static int __devinit __maybe_unused dfx_dev_register(struct device *);
+static int __devexit __maybe_unused dfx_dev_unregister(struct device *);
 
 #ifdef CONFIG_PCI
 static int __devinit dfx_pci_register(struct pci_dev *,
@@ -3699,7 +3698,7 @@ static struct tc_driver dfx_tc_driver = 
 };
 #endif /* CONFIG_TC */
 
-static int __devinit __unused dfx_dev_register(struct device *dev)
+static int __devinit __maybe_unused dfx_dev_register(struct device *dev)
 {
int status;
 
@@ -3709,7 +3708,7 @@ static int __devinit __unused dfx_dev_re
return status;
 }
 
-static int __devexit __unused dfx_dev_unregister(struct device *dev)
+static int __devexit __maybe_unused dfx_dev_unregister(struct device *dev)
 {
put_device(dev);
dfx_unregister(dev);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] defxx: Fix the handling of ioremap() failures

[Maciej W. Rozycki]

 If ioremap_nocache() is unfortunate enough to fail, the error code is not 
set correctly leading to a false success from dfx_register().  This change 
fixes the problem.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---

 Please apply.

  Maciej

patch-mips-2.6.21-20070502-defxx-ioremap-0
diff -up --recursive --new-file 
linux-mips-2.6.21-20070502.macro/drivers/net/defxx.c 
linux-mips-2.6.21-20070502/drivers/net/defxx.c
--- linux-mips-2.6.21-20070502.macro/drivers/net/defxx.c2007-02-21 
05:56:25.0 +
+++ linux-mips-2.6.21-20070502/drivers/net/defxx.c  2007-05-16 
21:26:43.0 +
@@ -566,6 +566,7 @@ static int __devinit dfx_register(struct
bp-base.mem = ioremap_nocache(bar_start, bar_len);
if (!bp-base.mem) {
printk(KERN_ERR %s: Cannot map MMIO\n, print_name);
+   err = -ENOMEM;
goto err_out_region;
}
} else {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] declance: Remove a dangling spin_unlock_irq() thingy

[Maciej W. Rozycki]

 The spin_unlock_irq() invocation in lance_start_xmit() has no matching 
locking request.  The call is already protected by netif_tx_lock, so 
remove the statement.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 Please apply.

  Maciej

patch-mips-2.6.18-20060920-declance-lock-0
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/declance.c 
linux-mips-2.6.18-20060920/drivers/net/declance.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/declance.c 2006-09-20 
20:50:22.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/declance.c   2007-05-19 
21:14:36.0 +
@@ -915,8 +915,6 @@ static int lance_start_xmit(struct sk_bu
/* Kick the lance: transmit now */
writereg(ll-rdp, LE_C0_INEA | LE_C0_TDMD);
 
-   spin_unlock_irq(lp-lock);
-
dev-trans_start = jiffies;
dev_kfree_skb(skb);
 
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] RFC: Broadcom PHY forcing fix

[Maciej W. Rozycki]

Kumar,

 I've got a BCM5461 that requires this fix to be able to force the speeds 
 on the PHY.  Not sure if its needed on the other variants or not.  The 
 problem is the genphy_config_aneg resets the PHY when forcing the speed 
 and once we reset the BCM5461 it doesn't remember any of its settings.

 I recall seeing a similar problem before and having checked with the IEEE 
spec I believe it's the generic code that is incorrect.  Following is my 
fix to address this problem.  Please try and see if it works for you.

 I am waiting for 2.6.20 to happen before I recheck my list of patches 
related to the BCM1250 MAC and the PHY library and (re)submit whatever is 
still relevant.  This patch is one of candidates.

  Maciej

patch-mips-2.6.18-20060920-phy-forcing-1
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/phy/phy.c 
linux-mips-2.6.18-20060920/drivers/net/phy/phy.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/phy.c  2006-08-05 
04:58:46.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/phy.c2006-09-25 
03:03:45.0 +
@@ -713,6 +713,8 @@ static void phy_timer(unsigned long data
} else {
phydev-state = PHY_NOLINK;
netif_carrier_off(phydev-attached_dev);
+   phydev-link_timeout =
+   PHY_NOLINK_TIMEOUT;
}
 
phydev-adjust_link(phydev-attached_dev);
@@ -759,6 +761,9 @@ static void phy_timer(unsigned long data
phydev-state = PHY_RUNNING;
netif_carrier_on(phydev-attached_dev);
phydev-adjust_link(phydev-attached_dev);
+   } else if (0 == phydev-link_timeout--) {
+   phydev-autoneg = AUTONEG_ENABLE;
+   needs_aneg = 1;
}
break;
case PHY_FORCING:
@@ -797,6 +802,7 @@ static void phy_timer(unsigned long data
} else {
phydev-state = PHY_NOLINK;
netif_carrier_off(phydev-attached_dev);
+   phydev-link_timeout = PHY_NOLINK_TIMEOUT;
}
 
phydev-adjust_link(phydev-attached_dev);
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/phy/phy_device.c 
linux-mips-2.6.18-20060920/drivers/net/phy/phy_device.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/phy_device.c   
2006-09-20 20:50:26.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/phy_device.c 2006-09-25 
01:51:34.0 +
@@ -325,10 +325,18 @@ EXPORT_SYMBOL(genphy_config_advert);
  *   Please see phy_sanitize_settings() */
 int genphy_setup_forced(struct phy_device *phydev)
 {
-   int ctl = BMCR_RESET;
+   int ctl;
 
phydev-pause = phydev-asym_pause = 0;
 
+   ctl = phy_read(phydev, MII_BMCR);
+
+   ctl = ~(BMCR_ANENABLE | BMCR_ANRESTART);
+
+   ctl = ~(BMCR_ISOLATE);
+
+   ctl = ~(BMCR_SPEED1000 | BMCR_SPEED100 | BMCR_FULLDPLX);
+
if (SPEED_1000 == phydev-speed)
ctl |= BMCR_SPEED1000;
else if (SPEED_100 == phydev-speed)
@@ -336,16 +344,8 @@ int genphy_setup_forced(struct phy_devic
 
if (DUPLEX_FULL == phydev-duplex)
ctl |= BMCR_FULLDPLX;
-   
-   ctl = phy_write(phydev, MII_BMCR, ctl);
-
-   if (ctl  0)
-   return ctl;
 
-   /* We just reset the device, so we'd better configure any
-* settings the PHY requires to operate */
-   if (phydev-drv-config_init)
-   ctl = phydev-drv-config_init(phydev);
+   ctl = phy_write(phydev, MII_BMCR, ctl);
 
return ctl;
 }
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/include/linux/phy.h 
linux-mips-2.6.18-20060920/include/linux/phy.h
--- linux-mips-2.6.18-20060920.macro/include/linux/phy.h2006-08-29 
04:58:59.0 +
+++ linux-mips-2.6.18-20060920/include/linux/phy.h  2006-09-29 
14:19:10.0 +
@@ -50,6 +50,7 @@
 #define PHY_STATE_TIME 1
 #define PHY_FORCE_TIMEOUT  10
 #define PHY_AN_TIMEOUT 10
+#define PHY_NOLINK_TIMEOUT 3
 
 #define PHY_MAX_ADDR 32
 
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] RFC: Broadcom PHY forcing fix

[Maciej W. Rozycki]

On Fri, 26 Jan 2007, Kumar Gala wrote:

 It looks like phy_timer has changed a bit in 2.6.20-rc6, what exactly was the
 intent of these changes?

 As I wrote, I'll have a look at these patches after 2.6.20 again.  These 
bits are from September (see the timestamps) and some of them may well 
have become irrelevant.

 The additional timeout was meant to let the driver go back to 
autonegotiation once a cycle through all the forced speeds has failed.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.20-rc1 #2 03/10] defxx: TURBOchannel support

[Maciej W. Rozycki]

 This is a set of changes to add TURBOchannel support to the defxx driver.
As at this point the EISA support in the driver has become the only not
having been converted to the driver model, I took the opportunity to
convert it as well.  Plus support for MMIO in addition to PIO operation as
TURBOchannel requires it anyway.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
On Wed, 20 Dec 2006, Andrew Morton wrote:

   This is a set of changes to add TURBOchannel support to the defxx driver.  
 
 my, what a lot of rejects.

 Hmm, I missed somebody having done quite a nice job of removing trailing 
white space.  Actually the formatting of the whole driver does not fit 
that of Linux very well, but I'm tempted to make functional changes first 
and only then cover the beauty. ;-)

  patch-mips-2.6.18-20060920-defta-69
 
 2.6.18?

 It should not matter -- I do not rename patches created from my tree if 
they still apply (which is obviously not the case here, but that's a fault 
elsewhere on my side).

 Here's a new version.  The result differs to my mips-2.6.18-20060920 
version by white space mostly (the rest being the regs argument having 
been removed from the interrupt handler).  Please apply and sorry for the 
hassle.

  Maciej

patch-2.6.20-rc1-defta-70
diff -up --recursive --new-file linux-2.6.20-rc1.macro/drivers/net/Kconfig 
linux-2.6.20-rc1/drivers/net/Kconfig
--- linux-2.6.20-rc1.macro/drivers/net/Kconfig  2006-12-14 01:14:23.0 
+
+++ linux-2.6.20-rc1/drivers/net/Kconfig2006-12-21 14:54:42.0 
+
@@ -2522,7 +2522,7 @@ config RIONET_RX_SIZE
 
 config FDDI
bool FDDI driver support
-   depends on (PCI || EISA)
+   depends on (PCI || EISA || TC)
help
  Fiber Distributed Data Interface is a high speed local area network
  design; essentially a replacement for high speed Ethernet. FDDI can
@@ -2532,11 +2532,31 @@ config FDDI
  will say N.
 
 config DEFXX
-   tristate Digital DEFEA and DEFPA adapter support
-   depends on FDDI  (PCI || EISA)
-   help
- This is support for the DIGITAL series of EISA (DEFEA) and PCI
- (DEFPA) controllers which can connect you to a local FDDI network.
+   tristate Digital DEFTA/DEFEA/DEFPA adapter support
+   depends on FDDI  (PCI || EISA || TC)
+   ---help---
+ This is support for the DIGITAL series of TURBOchannel (DEFTA),
+ EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
+ to a local FDDI network.
+
+ To compile this driver as a module, choose M here: the module
+ will be called defxx.  If unsure, say N.
+
+config DEFXX_MMIO
+   bool
+   prompt Use MMIO instead of PIO if PCI || EISA
+   depends on DEFXX
+   default n if PCI || EISA
+   default y
+   ---help---
+ This instructs the driver to use EISA or PCI memory-mapped I/O
+ (MMIO) as appropriate instead of programmed I/O ports (PIO).
+ Enabling this gives an improvement in processing time in parts
+ of the driver, but it may cause problems with EISA (DEFEA)
+ adapters.  TURBOchannel does not have the concept of I/O ports,
+ so MMIO is always used for these (DEFTA) adapters.
+
+ If unsure, say N.
 
 config SKFP
tristate SysKonnect FDDI PCI support
diff -up --recursive --new-file linux-2.6.20-rc1.macro/drivers/net/defxx.c 
linux-2.6.20-rc1/drivers/net/defxx.c
--- linux-2.6.20-rc1.macro/drivers/net/defxx.c  2006-12-14 01:14:23.0 
+
+++ linux-2.6.20-rc1/drivers/net/defxx.c2006-12-21 14:54:42.0 
+
@@ -10,10 +10,12 @@
  *
  * Abstract:
  *   A Linux device driver supporting the Digital Equipment Corporation
- *   FDDI EISA and PCI controller families.  Supported adapters include:
+ *   FDDI TURBOchannel, EISA and PCI controller families.  Supported
+ *   adapters include:
  *
- * DEC FDDIcontroller/EISA (DEFEA)
- * DEC FDDIcontroller/PCI  (DEFPA)
+ * DEC FDDIcontroller/TURBOchannel (DEFTA)
+ * DEC FDDIcontroller/EISA (DEFEA)
+ * DEC FDDIcontroller/PCI  (DEFPA)
  *
  * The original author:
  *   LVS   Lawrence V. Stefani [EMAIL PROTECTED]
@@ -193,24 +195,27 @@
  * 14 Aug 2004 macro   Fix device names reported.
  * 14 Jun 2005 macro   Use irqreturn_t.
  * 23 Oct 2006 macro   Big-endian host support.
+ * 14 Dec 2006 macro   TURBOchannel support.
  */
 
 /* Include files */
-
-#include linux/module.h
-#include linux/kernel.h
-#include linux/string.h
-#include linux/errno.h
-#include linux/ioport.h
-#include linux/slab.h
-#include linux/interrupt.h
-#include linux/pci.h
+#include linux/bitops.h
 #include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/eisa.h
+#include linux/errno.h
+#include linux/fddidevice.h
 #include linux/init.h
+#include linux

[PATCH 2.6.20-rc1 04/10] EISA registration with !CONFIG_EISA

[Maciej W. Rozycki]

 This is a change for the EISA bus support to permit drivers to call 
un/registration functions even if EISA support has not been enabled.  This 
is similar to what PCI (and now TC) does and reduces the need for #ifdef 
clutter.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---

 This is required by the updated defxx driver.

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-eisa-register-0
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/include/linux/eisa.h 
linux-mips-2.6.18-20060920/include/linux/eisa.h
--- linux-mips-2.6.18-20060920.macro/include/linux/eisa.h   2003-10-10 
04:00:31.0 +
+++ linux-mips-2.6.18-20060920/include/linux/eisa.h 2006-12-14 
22:43:31.0 +
@@ -67,10 +67,20 @@ struct eisa_driver {
 
 #define to_eisa_driver(drv) container_of(drv,struct eisa_driver, driver)
 
+/* These external functions are only available when EISA support is enabled. */
+#ifdef CONFIG_EISA
+
 extern struct bus_type eisa_bus_type;
 int eisa_driver_register (struct eisa_driver *edrv);
 void eisa_driver_unregister (struct eisa_driver *edrv);
 
+#else /* !CONFIG_EISA */
+
+static inline int eisa_driver_register (struct eisa_driver *edrv) { return 0; }
+static inline void eisa_driver_unregister (struct eisa_driver *edrv) { }
+
+#endif /* !CONFIG_EISA */
+
 /* Mimics pci.h... */
 static inline void *eisa_get_drvdata (struct eisa_device *edev)
 {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.20-rc1 03/10] defxx: TURBOchannel support

[Maciej W. Rozycki]

 This is a set of changes to add TURBOchannel support to the defxx driver.  
As at this point the EISA support in the driver has become the only not 
having been converted to the driver model, I took the opportunity to 
convert it as well.  Plus support for MMIO in addition to PIO operation as 
TURBOchannel requires it anyway.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---

 These changes have been tested at the run time with TC and PCI variations 
of the board.  EISA support has only been verified to build correctly.  I 
do believe I got it mostly right, but if there is somebody interested in 
keeping the DEFEA supported, then please send me results of testing or, 
for long-term testing, I would not mind accepting such a board either. ;-)

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-defta-69
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/Kconfig 
linux-mips-2.6.18-20060920/drivers/net/Kconfig
--- linux-mips-2.6.18-20060920.macro/drivers/net/Kconfig2006-09-10 
04:55:24.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/Kconfig  2006-12-15 
22:45:17.0 +
@@ -2443,7 +2443,7 @@ config RIONET_RX_SIZE
 
 config FDDI
bool FDDI driver support
-   depends on (PCI || EISA)
+   depends on (PCI || EISA || TC)
help
  Fiber Distributed Data Interface is a high speed local area network
  design; essentially a replacement for high speed Ethernet. FDDI can
@@ -2453,11 +2453,31 @@ config FDDI
  will say N.
 
 config DEFXX
-   tristate Digital DEFEA and DEFPA adapter support
-   depends on FDDI  (PCI || EISA)
-   help
- This is support for the DIGITAL series of EISA (DEFEA) and PCI
- (DEFPA) controllers which can connect you to a local FDDI network.
+   tristate Digital DEFTA/DEFEA/DEFPA adapter support
+   depends on FDDI  (PCI || EISA || TC)
+   ---help---
+ This is support for the DIGITAL series of TURBOchannel (DEFTA),
+ EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
+ to a local FDDI network.
+
+ To compile this driver as a module, choose M here: the module
+ will be called defxx.  If unsure, say N.
+
+config DEFXX_MMIO
+   bool
+   prompt Use MMIO instead of PIO if PCI || EISA
+   depends on DEFXX
+   default n if PCI || EISA
+   default y
+   ---help---
+ This instructs the driver to use EISA or PCI memory-mapped I/O
+ (MMIO) as appropriate instead of programmed I/O ports (PIO).
+ Enabling this gives an improvement in processing time in parts
+ of the driver, but it may cause problems with EISA (DEFEA)
+ adapters.  TURBOchannel does not have the concept of I/O ports,
+ so MMIO is always used for these (DEFTA) adapters.
+
+ If unsure, say N.
 
 config SKFP
tristate SysKonnect FDDI PCI support
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c 
linux-mips-2.6.18-20060920/drivers/net/defxx.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c2006-10-23 
22:58:19.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/defxx.c  2006-12-20 
00:22:01.0 +
@@ -10,10 +10,12 @@
  *
  * Abstract:
  *   A Linux device driver supporting the Digital Equipment Corporation
- *   FDDI EISA and PCI controller families.  Supported adapters include:
+ *   FDDI TURBOchannel, EISA and PCI controller families.  Supported
+ *   adapters include:
  *
- * DEC FDDIcontroller/EISA (DEFEA)
- * DEC FDDIcontroller/PCI  (DEFPA)
+ * DEC FDDIcontroller/TURBOchannel (DEFTA)
+ * DEC FDDIcontroller/EISA (DEFEA)
+ * DEC FDDIcontroller/PCI  (DEFPA)
  *
  * The original author:
  *   LVS   Lawrence V. Stefani [EMAIL PROTECTED]
@@ -193,24 +195,27 @@
  * 14 Aug 2004 macro   Fix device names reported.
  * 14 Jun 2005 macro   Use irqreturn_t.
  * 23 Oct 2006 macro   Big-endian host support.
+ * 14 Dec 2006 macro   TURBOchannel support.
  */
 
 /* Include files */
-
-#include linux/module.h
-#include linux/kernel.h
-#include linux/string.h
-#include linux/errno.h
-#include linux/ioport.h
-#include linux/slab.h
-#include linux/interrupt.h
-#include linux/pci.h
+#include linux/bitops.h
 #include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/eisa.h
+#include linux/errno.h
+#include linux/fddidevice.h
 #include linux/init.h
+#include linux/interrupt.h
+#include linux/ioport.h
+#include linux/kernel.h
+#include linux/module.h
 #include linux/netdevice.h
-#include linux/fddidevice.h
+#include linux/pci.h
 #include linux/skbuff.h
-#include linux/bitops.h
+#include linux/slab.h
+#include linux/string.h
+#include linux/tc.h
 
 #include asm/byteorder.h
 #include asm/io.h
@@ -219,8 +224,8 @@
 
 /* Version

[PATCH 2.6.20-rc1 05/10] if_fddi.h: Add a missing inclusion

[Maciej W. Rozycki]

 This is a change to include linux/netdevice.h in linux/if_fddi.h 
which is needed for struct fddi_statistics.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-if_fddi-netdev-0
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/include/linux/if_fddi.h 
linux-mips-2.6.18-20060920/include/linux/if_fddi.h
--- linux-mips-2.6.18-20060920.macro/include/linux/if_fddi.h2006-09-20 
20:51:20.0 +
+++ linux-mips-2.6.18-20060920/include/linux/if_fddi.h  2006-12-14 
04:36:58.0 +
@@ -103,6 +103,8 @@ struct fddihdr
} __attribute__ ((packed));
 
 #ifdef __KERNEL__
+#include linux/netdevice.h
+
 /* Define FDDI statistics structure */
 struct fddi_statistics {
 
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Network drivers that don't suspend on interface down

[Maciej W. Rozycki]

On Wed, 20 Dec 2006, Matthew Garrett wrote:

 As far as I can tell, the following network devices don't put the 
 hardware into D3 on interface down:
[...]
 defxx

 No support in the hardware for that.  Even revision 3 of the board which 
is the last one and the only to support PCI 2.2 says:

Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

;-)

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.20-rc1 01/10] TURBOchannel update to the driver model

[Maciej W. Rozycki]

 This is a set of changes to convert support for the TURBOchannel bus to 
the driver model.  It implements the usual set of calls similar to what 
other bus drivers have: tc_register_driver(), tc_unregister_driver(), etc.  
All the platform-specific bits have been removed and headers from 
asm-mips/dec/ have been merged into linux/tc.h, which should be included 
by drivers.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-tc-sysfs-78
diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/MAINTAINERS 
linux-mips-2.6.18-20060920/MAINTAINERS
--- linux-mips-2.6.18-20060920.macro/MAINTAINERS2006-09-20 
04:56:08.0 +
+++ linux-mips-2.6.18-20060920/MAINTAINERS  2006-11-30 01:54:54.0 
+
@@ -2910,6 +2910,11 @@ L:   [EMAIL PROTECTED]
 W: http://vtun.sourceforge.net/tun
 S: Maintained
 
+TURBOCHANNEL SUBSYSTEM
+P: Maciej W. Rozycki
+M: [EMAIL PROTECTED]
+S: Maintained
+
 U14-34F SCSI DRIVER
 P: Dario Ballabio
 M: [EMAIL PROTECTED]
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/tc/Makefile 
linux-mips-2.6.18-20060920/drivers/tc/Makefile
--- linux-mips-2.6.18-20060920.macro/drivers/tc/Makefile2003-06-05 
04:03:00.0 +
+++ linux-mips-2.6.18-20060920/drivers/tc/Makefile  2006-10-03 
21:01:58.0 +
@@ -4,7 +4,7 @@
 
 # Object file lists.
 
-obj-$(CONFIG_TC) += tc.o
+obj-$(CONFIG_TC) += tc.o tc-driver.o
 obj-$(CONFIG_ZS) += zs.o
 obj-$(CONFIG_VT) += lk201.o lk201-map.o lk201-remap.o
 
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/tc/tc-driver.c 
linux-mips-2.6.18-20060920/drivers/tc/tc-driver.c
--- linux-mips-2.6.18-20060920.macro/drivers/tc/tc-driver.c 1970-01-01 
00:00:00.0 +
+++ linux-mips-2.6.18-20060920/drivers/tc/tc-driver.c   2006-12-19 
22:29:49.0 +
@@ -0,0 +1,110 @@
+/*
+ * TURBOchannel driver services.
+ *
+ * Copyright (c) 2005  James Simmons
+ * Copyright (c) 2006  Maciej W. Rozycki
+ *
+ * Loosely based on drivers/dio/dio-driver.c and
+ * drivers/pci/pci-driver.c.
+ *
+ * This file is subject to the terms and conditions of the GNU
+ * General Public License.  See the file COPYING in the main
+ * directory of this archive for more details.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/tc.h
+
+/**
+ * tc_register_driver - register a new TC driver
+ * @drv: the driver structure to register
+ *
+ * Adds the driver structure to the list of registered drivers
+ * Returns a negative value on error, otherwise 0.
+ * If no error occurred, the driver remains registered even if
+ * no device was claimed during registration.
+ */
+int tc_register_driver(struct tc_driver *tdrv)
+{
+   return driver_register(tdrv-driver);
+}
+EXPORT_SYMBOL(tc_register_driver);
+
+/**
+ * tc_unregister_driver - unregister a TC driver
+ * @drv: the driver structure to unregister
+ *
+ * Deletes the driver structure from the list of registered TC drivers,
+ * gives it a chance to clean up by calling its remove() function for
+ * each device it was responsible for, and marks those devices as
+ * driverless.
+ */
+void tc_unregister_driver(struct tc_driver *tdrv)
+{
+   driver_unregister(tdrv-driver);
+}
+EXPORT_SYMBOL(tc_unregister_driver);
+
+/**
+ * tc_match_device - tell if a TC device structure has a matching
+ *   TC device ID structure
+ * @tdrv: the TC driver to earch for matching TC device ID strings
+ * @tdev: the TC device structure to match against
+ *
+ * Used by a driver to check whether a TC device present in the
+ * system is in its list of supported devices.  Returns the matching
+ * tc_device_id structure or %NULL if there is no match.
+ */
+const struct tc_device_id *tc_match_device(struct tc_driver *tdrv,
+  struct tc_dev *tdev)
+{
+   const struct tc_device_id *id = tdrv-id_table;
+
+   if (id) {
+   while (id-name[0] || id-vendor[0]) {
+   if (strcmp(tdev-name, id-name) == 0 
+   strcmp(tdev-vendor, id-vendor) == 0)
+   return id;
+   id++;
+   }
+   }
+   return NULL;
+}
+EXPORT_SYMBOL(tc_match_device);
+
+/**
+ * tc_bus_match - Tell if a device structure has a matching
+ *TC device ID structure
+ * @dev: the device structure to match against
+ * @drv: the device driver to search for matching TC device ID strings
+ *
+ * Used by a driver to check whether a TC device present in the
+ * system is in its list of supported devices.  Returns 1 if there
+ * is a match or 0 otherwise.
+ */
+static int tc_bus_match(struct device *dev, struct device_driver *drv)
+{
+   struct tc_dev *tdev = to_tc_dev(dev);
+   struct tc_driver *tdrv = to_tc_driver(drv);
+   const struct tc_device_id *id;
+
+   id

[PATCH 2.6.20-rc1 00/10] TURBOchannel update to the driver model

[Maciej W. Rozycki]

Hello,

 It has been much longer than expected, but finally it is here!  This 
series of patches converts support for the TURBOchannel bus to the driver 
model.  As a nice side effect, the generic part of the code is now really 
generic, that is no more dependencies on MIPS specifics under drivers/tc/ 
and platform specific code for MIPS got moved where it belongs.  As to 
whether other relevant platforms will add TURBOchannel support or not I 
cannot tell right now. ;-)

 All the changes have been successfully tested with a DECstation 5000/133 
and the necessary bits of additional hardware as appropriate.  Where 
drivers supporting different bus attachments were concerned, they were 
built for configurations enabling all the other buses supported and 
run-time checked if possible.

 And last but not least, thanks to James Simmons for beginning this work a 
while ago as his code was great to start with.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.6.18] declance: Support the I/O ASIC LANCE w/o TURBOchannel

[Maciej W. Rozycki]

On Fri, 1 Dec 2006, Andrew Morton wrote:

  can you (or Andrew) please resend your patches against 2.6.19?
  
 
 I have then all (I think) queued up.  Will send once I've done a round
 of build-testing.

 Thanks a lot, Andrew.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.18] declance: Fix RX ownership handover

[Maciej W. Rozycki]

 The change for PMAD support introduced a bug, where the ownership of RX 
descriptors was given back to the LANCE in the wrong way.  Occasional 
lockups would happen as a result.  This is a fix for this problem.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 Tested with the onboard LANCE of a DECstation 5000/133.

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-pmax-lance-rx-fix-0
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/declance.c 
linux-mips-2.6.18-20060920/drivers/net/declance.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/declance.c 2006-11-23 
02:55:34.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/declance.c   2006-11-30 
02:26:34.0 +
@@ -628,7 +628,6 @@ static int lance_rx(struct net_device *d
/* Return the packet to the pool */
*rds_ptr(rd, mblength, lp-type) = 0;
*rds_ptr(rd, length, lp-type) = -RX_BUFF_SIZE | 0xf000;
-   *rds_ptr(rd, rmd1, lp-type) = LE_R1_OWN;
*rds_ptr(rd, rmd1, lp-type) =
((lp-rx_buf_ptr_lnc[entry]  16)  0xff) | LE_R1_OWN;
lp-rx_new = (entry + 1)  RX_RING_MOD_MASK;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.18] declance: Support the I/O ASIC LANCE w/o TURBOchannel

[Maciej W. Rozycki]

 The onboard LANCE of I/O ASIC systems is not a TURBOchannel device, at 
least from the software point of view.  Therefore it does not rely on any 
kernel TURBOchannel bus services and can be supported even if support for 
TURBOchannel has not been enabled in the configuration.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
 Tested with the onboard LANCE of a DECstation 5000/133.

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-declance-tc-0
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/declance.c 
linux-mips-2.6.18-20060920/drivers/net/declance.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/declance.c 2006-11-23 
02:55:34.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/declance.c   2006-11-30 
02:31:19.0 +
@@ -1068,7 +1068,6 @@ static int __init dec_lance_init(const i
lp-type = type;
lp-slot = slot;
switch (type) {
-#ifdef CONFIG_TC
case ASIC_LANCE:
dev-base_addr = CKSEG1ADDR(dec_kn_slot_base + IOASIC_LANCE);
 
@@ -1112,7 +,7 @@ static int __init dec_lance_init(const i
 CPHYSADDR(dev-mem_start)  3);
 
break;
-
+#ifdef CONFIG_TC
case PMAD_LANCE:
claim_tc_card(slot);
 
@@ -1143,7 +1142,6 @@ static int __init dec_lance_init(const i
 
break;
 #endif
-
case PMAX_LANCE:
dev-irq = dec_interrupt[DEC_IRQ_LANCE];
dev-base_addr = CKSEG1ADDR(KN01_SLOT_BASE + KN01_LANCE);
@@ -1298,10 +1296,8 @@ static int __init dec_lance_probe(void)
/* Then handle onboard devices. */
if (dec_interrupt[DEC_IRQ_LANCE] = 0) {
if (dec_interrupt[DEC_IRQ_LANCE_MERR] = 0) {
-#ifdef CONFIG_TC
if (dec_lance_init(ASIC_LANCE, -1) = 0)
count++;
-#endif
} else if (!TURBOCHANNEL) {
if (dec_lance_init(PMAX_LANCE, -1) = 0)
count++;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes

[Maciej W. Rozycki]

On Mon, 23 Oct 2006, Maciej W. Rozycki wrote:

  I'm not too enthusiastic about requiring the ethernet drivers to call
  phy_disconnect in a separate thread after close is called.  Assuming 
  there's
  not some sort of squash work queue function that can be invoked with
  rtnl_lock held, I think phy_disconnect should schedule itself to flush the
  queue.  This would also require that mdiobus_unregister hold off on freeing
  phydevs if any of the phys were still waiting for pending flush_pending 
  calls
  to finish.  Which would, in turn, require mdiobus_unregister to schedule
  cleaning up memory for some later time.
 
  This could work, indeed.
 
  I'm not enthusiastic about that implementation, either, but it maintains the
  abstractions I consider important for this code.  The ethernet driver should
  not need to know what structures the PHY lib uses to implement its interrupt
  handling, and how to work around their failings, IMHO.
 
  Agreed.

 So what's the plan?

 Here's a new version of the patch that addresses your other concerns.

  Maciej

patch-mips-2.6.18-20060920-phy-irq-18
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/phy/phy.c 
linux-mips-2.6.18-20060920/drivers/net/phy/phy.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/phy.c  2006-08-05 
04:58:46.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/phy.c2006-11-30 
17:58:37.0 +
@@ -7,6 +7,7 @@
  * Author: Andy Fleming
  *
  * Copyright (c) 2004 Freescale Semiconductor, Inc.
+ * Copyright (c) 2006  Maciej W. Rozycki
  *
  * This program is free software; you can redistribute  it and/or modify it
  * under  the terms of  the GNU General  Public License as published by the
@@ -32,6 +33,8 @@
 #include linux/mii.h
 #include linux/ethtool.h
 #include linux/phy.h
+#include linux/timer.h
+#include linux/workqueue.h
 
 #include asm/io.h
 #include asm/irq.h
@@ -484,6 +487,9 @@ static irqreturn_t phy_interrupt(int irq
 {
struct phy_device *phydev = phy_dat;
 
+   if (PHY_HALTED == phydev-state)
+   return IRQ_NONE;/* It can't be ours.  */
+
/* The MDIO bus is not allowed to be written in interrupt
 * context, so we need to disable the irq here.  A work
 * queue will write the PHY to disable and clear the
@@ -577,6 +583,13 @@ int phy_stop_interrupts(struct phy_devic
if (err)
phy_error(phydev);
 
+   /*
+* Finish any pending work; we might have been scheduled
+* to be called from keventd ourselves, though.
+*/
+   if (!current_is_keventd())
+   flush_scheduled_work();
+
free_irq(phydev-irq, phydev);
 
return err;
@@ -596,14 +609,17 @@ static void phy_change(void *data)
goto phy_err;
 
spin_lock(phydev-lock);
+
if ((PHY_RUNNING == phydev-state) || (PHY_NOLINK == phydev-state))
phydev-state = PHY_CHANGELINK;
-   spin_unlock(phydev-lock);
 
enable_irq(phydev-irq);
 
/* Reenable interrupts */
-   err = phy_config_interrupt(phydev, PHY_INTERRUPT_ENABLED);
+   if (PHY_HALTED != phydev-state)
+   err = phy_config_interrupt(phydev, PHY_INTERRUPT_ENABLED);
+
+   spin_unlock(phydev-lock);
 
if (err)
goto irq_enable_err;
@@ -624,15 +640,15 @@ void phy_stop(struct phy_device *phydev)
if (PHY_HALTED == phydev-state)
goto out_unlock;
 
-   if (phydev-irq != PHY_POLL) {
-   /* Clear any pending interrupts */
-   phy_clear_interrupt(phydev);
+   phydev-state = PHY_HALTED;
 
+   if (phydev-irq != PHY_POLL) {
/* Disable PHY Interrupts */
phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED);
-   }
 
-   phydev-state = PHY_HALTED;
+   /* Clear any pending interrupts */
+   phy_clear_interrupt(phydev);
+   }
 
 out_unlock:
spin_unlock(phydev-lock);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.18] defxx: Big-endian hosts support

[Maciej W. Rozycki]

 The PDQ DMA engine requires a different byte-swapping mode for big-endian
hosts; also the MAC address which is read from a register through PIO has
to be byte-swapped.  These changes have been verified with DEFPA-DC (PCI)
boards and a Broadcom BCM91250A (MIPS CPU based) host.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---

On Mon, 23 Oct 2006, Christoph Hellwig wrote:

 On Mon, Oct 23, 2006 at 01:53:17PM +0100, Maciej W. Rozycki wrote:
  +   data = cpu_to_le32(data);
 
 This is rather ugly and not provable by static typechecking.  Please
 always use spearate variables/structs for device and host endian values,
 and run the resulting driver through sparse to make sure everything is
 correct.

 Hmm, I'm not sure why this would matter, but as it does not change the 
generated code, then I see no problem either.

 [Note that there is no such notion as the device and host endian value 
here -- the contents of the register are just a string of bytes which has 
to have its byte addresses preserved when transferring to memory and hence 
the swapping already done by inl() has to be undone.]

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-defxx-eb-4
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c 
linux-mips-2.6.18-20060920/drivers/net/defxx.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c2006-09-20 
20:50:22.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/defxx.c  2006-10-23 
22:58:19.0 +
@@ -192,6 +192,7 @@
  * 04 Aug 2003 macro   Converted to the DMA API.
  * 14 Aug 2004 macro   Fix device names reported.
  * 14 Jun 2005 macro   Use irqreturn_t.
+ * 23 Oct 2006 macro   Big-endian host support.
  */
 
 /* Include files */
@@ -218,8 +219,8 @@
 
 /* Version information string should be updated prior to each new release!  */
 #define DRV_NAME defxx
-#define DRV_VERSION v1.08
-#define DRV_RELDATE 2005/06/14
+#define DRV_VERSION v1.09
+#define DRV_RELDATE 2006/10/23
 
 static char version[] __devinitdata =
DRV_NAME :  DRV_VERSION   DRV_RELDATE
@@ -808,10 +809,10 @@ static int __devinit dfx_driver_init(str
 const char *print_name)
 {
DFX_board_t *bp = dev-priv;
-   int alloc_size; /* total buffer 
size needed */
-   char*top_v, *curr_v;/* virtual addrs into memory 
block */
-   dma_addr_t  top_p, curr_p;  /* physical addrs into 
memory block */
-   u32 data;   /* host data 
register value */
+   int alloc_size; /* total buffer size needed */
+   char *top_v, *curr_v;   /* virtual addrs into memory block */
+   dma_addr_t top_p, curr_p;   /* physical addrs into memory block */
+   u32 data, le32; /* host data register value */
 
DBG_printk(In dfx_driver_init...\n);
 
@@ -860,7 +861,8 @@ static int __devinit dfx_driver_init(str
   print_name);
return(DFX_K_FAILURE);
}
-   memcpy(bp-factory_mac_addr[0], data, sizeof(u32));
+   le32 = cpu_to_le32(data);
+   memcpy(bp-factory_mac_addr[0], le32, sizeof(u32));
 
if (dfx_hw_port_ctrl_req(bp, PI_PCTRL_M_MLA, PI_PDATA_A_MLA_K_HI, 0,
 data) != DFX_K_SUCCESS) {
@@ -868,7 +870,8 @@ static int __devinit dfx_driver_init(str
   print_name);
return(DFX_K_FAILURE);
}
-   memcpy(bp-factory_mac_addr[4], data, sizeof(u16));
+   le32 = cpu_to_le32(data);
+   memcpy(bp-factory_mac_addr[4], le32, sizeof(u16));
 
/*
 * Set current address to factory address
@@ -1086,27 +1089,23 @@ static int dfx_adap_init(DFX_board_t *bp
}
 
/*
-* Set base address of Descriptor Block and bring adapter to 
DMA_AVAILABLE state
+* Set the base address of Descriptor Block and bring adapter
+* to DMA_AVAILABLE state.
 *
-* Note: We also set the literal and data swapping requirements in this
-*   command.  Since this driver presently runs on Intel 
platforms
-*   which are Little Endian, we'll tell the adapter to 
byte swap
-*   data only.  This code will need to change when we 
support
-*   Big Endian systems (eg. PowerPC).
+* Note: We also set the literal and data swapping requirements
+*   in this command.
 *
-* Assumption: 32-bit physical address of descriptor block is 8Kbyte
-* aligned.  That is, bits 0-12 of the address must be zero.
+* Assumption: 32-bit physical address of descriptor block
+*   is 8Kbyte aligned.
 */
-
-   if (dfx_hw_port_ctrl_req(bp

[PATCH 2.6.18] defxx: Big-endian hosts support

[Maciej W. Rozycki]

 The PDQ DMA engine requires a different byte-swapping mode for big-endian 
hosts; also the MAC address which is read from a register through PIO has 
to be byte-swapped.  These changes have been verified with DEFPA-DC (PCI) 
boards and a Broadcom BCM91250A (MIPS CPU based) host.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---

 Please apply.

  Maciej

patch-mips-2.6.18-20060920-defxx-eb-3
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c 
linux-mips-2.6.18-20060920/drivers/net/defxx.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c2006-09-20 
20:50:22.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/defxx.c  2006-10-23 
00:43:03.0 +
@@ -192,6 +192,7 @@
  * 04 Aug 2003 macro   Converted to the DMA API.
  * 14 Aug 2004 macro   Fix device names reported.
  * 14 Jun 2005 macro   Use irqreturn_t.
+ * 23 Oct 2006 macro   Big-endian host support.
  */
 
 /* Include files */
@@ -218,8 +219,8 @@
 
 /* Version information string should be updated prior to each new release!  */
 #define DRV_NAME defxx
-#define DRV_VERSION v1.08
-#define DRV_RELDATE 2005/06/14
+#define DRV_VERSION v1.09
+#define DRV_RELDATE 2006/10/23
 
 static char version[] __devinitdata =
DRV_NAME :  DRV_VERSION   DRV_RELDATE
@@ -860,6 +861,7 @@ static int __devinit dfx_driver_init(str
   print_name);
return(DFX_K_FAILURE);
}
+   data = cpu_to_le32(data);
memcpy(bp-factory_mac_addr[0], data, sizeof(u32));
 
if (dfx_hw_port_ctrl_req(bp, PI_PCTRL_M_MLA, PI_PDATA_A_MLA_K_HI, 0,
@@ -868,6 +870,7 @@ static int __devinit dfx_driver_init(str
   print_name);
return(DFX_K_FAILURE);
}
+   data = cpu_to_le32(data);
memcpy(bp-factory_mac_addr[4], data, sizeof(u16));
 
/*
@@ -1086,27 +1089,23 @@ static int dfx_adap_init(DFX_board_t *bp
}
 
/*
-* Set base address of Descriptor Block and bring adapter to 
DMA_AVAILABLE state
+* Set the base address of Descriptor Block and bring adapter
+* to DMA_AVAILABLE state.
 *
-* Note: We also set the literal and data swapping requirements in this
-*   command.  Since this driver presently runs on Intel 
platforms
-*   which are Little Endian, we'll tell the adapter to 
byte swap
-*   data only.  This code will need to change when we 
support
-*   Big Endian systems (eg. PowerPC).
+* Note: We also set the literal and data swapping requirements
+*   in this command.
 *
-* Assumption: 32-bit physical address of descriptor block is 8Kbyte
-* aligned.  That is, bits 0-12 of the address must be zero.
+* Assumption: 32-bit physical address of descriptor block
+*   is 8Kbyte aligned.
 */
-
-   if (dfx_hw_port_ctrl_req(bp,
-   PI_PCTRL_M_INIT,
-   (u32) 
(bp-descr_block_phys | PI_PDATA_A_INIT_M_BSWAP_DATA),
-   0,
-   NULL) != DFX_K_SUCCESS)
-   {
-   printk(%s: Could not set descriptor block address!\n, 
bp-dev-name);
-   return(DFX_K_FAILURE);
-   }
+   if (dfx_hw_port_ctrl_req(bp, PI_PCTRL_M_INIT,
+(u32)(bp-descr_block_phys |
+  PI_PDATA_A_INIT_M_BSWAP_INIT),
+0, NULL) != DFX_K_SUCCESS) {
+   printk(%s: Could not set descriptor block address!\n,
+  bp-dev-name);
+   return DFX_K_FAILURE;
+   }
 
/* Set transmit flush timeout value */
 
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/defxx.h 
linux-mips-2.6.18-20060920/drivers/net/defxx.h
--- linux-mips-2.6.18-20060920.macro/drivers/net/defxx.h2004-11-16 
05:57:00.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/defxx.h  2006-10-23 
00:27:28.0 +
@@ -25,6 +25,7 @@
  * macros to DEFXX.C.
  * 12-Sep-96   LVS Removed packet request header 
pointers.
  * 04 Aug 2003 macro   Converted to the DMA API.
+ * 23 Oct 2006 macro   Big-endian host support.
  */
 
 #ifndef _DEFXX_H_
@@ -1344,7 +1345,7 @@ typedef struct
 
 /* Register definition structures are defined for both big and little endian 
systems */
 
-#ifndef  BIG_ENDIAN
+#ifndef __BIG_ENDIAN
 
 /* Little endian format of Type 1 Producer register */
 
@@ -1402,7 +1403,11 @@ typedef union

Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes

[Maciej W. Rozycki]

On Fri, 20 Oct 2006, Andy Fleming wrote:

 I've been trying to figure out this problem since you posted this, and I'm not
 sure I understand it fully (And I apologize profusely for the horror that is
 the PHY interrupt handling code.  I'd love to rewrite it if there's some

 First of all I don't see much of the need to use soft timers with an 
interrupt-driven PHY.  Most of the state changes could be invoked straight 
from phy_change(), perhaps with an exception for the autonegotiation 
timeout.

 cleaner way.).  But let me see if I can follow the chain of reasoning that led
 to this patch, and see if we can figure out a solution that doesn't involve
 creating a work queue just for bringing down the PHY.

 Avoiding a separate work queue was my intent as well.

 1) Invoking phy_stop is meant to stop the system from looking for PHY status
 updates.  Currently, another PHY sharing the interrupt can cause the HALTED
 PHY to reenable interrupts.  Checking for HALTED in the interrupt handler
 fixes this, but it's incorrect.  The phy_interrupt handler does not grab the
 lock, and so you could get this:
 
 phy_stop
   lock
   clear any pending interrupts
   disable interrupts on this PHY
 --- interrupt from another PHY causes this PHY's interrupt handler to be
 invoked
   HALTED isn't set, so phy_change is scheduled
 --- set HALTED, unlock
 
 scheduled work is done:
   interrupt is reenabled
 
 Sadly, I think the only way to fix this problem is to have phy_change check
 for HALTED, and react appropriately.

 Please have a look at how I have rewritten phy_stop() to avoid this 
problem with no need for a lock -- HALTED is set first and only then 
interrupts are masked and cleared for this PHY.  It can be done without 
locking because the interrupt handler is strictly a consumer and 
phy_stop() is strictly a producer and we do not care about any other 
transitions [1].

 2) The PHY lib doesn't clear out remaining work in the work queue when it's
 bringing down a PHY.  This is clearly wrong, but I'm confused how *any* driver
 does this?  It seems to me that any network driver which has a work queue is
 going to be unable to flush the pending work when it is brought down.  So
 what's the solution to this?

 The only driver that seems to care is tg3.c and it gets away by other 
means.  Note that network drivers can quite easily handle and ignore 
deferred interrupt work as long as it arrives before they are removed from 
memory.  All that is required is calling flush_scheduled_work() from their 
module_exit() call at the very latest.

 I'm not too enthusiastic about requiring the ethernet drivers to call
 phy_disconnect in a separate thread after close is called.  Assuming there's
 not some sort of squash work queue function that can be invoked with
 rtnl_lock held, I think phy_disconnect should schedule itself to flush the
 queue.  This would also require that mdiobus_unregister hold off on freeing
 phydevs if any of the phys were still waiting for pending flush_pending calls
 to finish.  Which would, in turn, require mdiobus_unregister to schedule
 cleaning up memory for some later time.

 This could work, indeed.

 I'm not enthusiastic about that implementation, either, but it maintains the
 abstractions I consider important for this code.  The ethernet driver should
 not need to know what structures the PHY lib uses to implement its interrupt
 handling, and how to work around their failings, IMHO.

 Agreed.

 @@ -484,6 +487,9 @@ static irqreturn_t phy_interrupt(int irq
  {
   struct phy_device *phydev = phy_dat;
 
 +if (PHY_HALTED == phydev-state)
 +return IRQ_NONE;/* It can't be ours.  */
 +
 
 
 As I mentioned, this doesn't protect it, since it doesn't grab the lock.  And
 it can't grab the lock, or we'd have to disable interrupts while doing phy
 transactions.  And we can't do that, because one design goal is to allow some
 bus drivers to use interrupts to signal that the transaction has completed.
 Admittedly, this is still quite broken right now.  I'm looking into using
 semaphores, on the theory that I can sleep when I grab them.  But that would
 still prevent taking the semaphore in the interrupt controller.  This needs to
 be moved to phy_change (which you have done, anyway), and we just have to let
 the actual handler figure out whether it's safe to do anything.

 There is no problem with accessing the state here -- see above[1] and
below[2].

 @@ -577,6 +583,13 @@ int phy_stop_interrupts(struct phy_devic
   if (err)
phy_error(phydev);
 
 +/*
 + * Finish any pending work; we might have been scheduled
 + * to be called from keventd ourselves, though.
 + */
 +if (!current_is_keventd())
 +flush_scheduled_work();
 +
 
 
 And this is what is making you move your call to phy_disconnect to a work
 queue function, right?  Does this make it so phy_stop_interrupts (and anything
 that calls it) can't be called with rtnl_lock held? 

Re: BCM5461 phy issue in 10M/Full duplex

[Maciej W. Rozycki]

On Wed, 18 Oct 2006, Rick Jones wrote:

  I believe, but need to double check, that if I leave the BCM5461 in
  autoneg, and foce the switch to 10M/full that the BCM5461 will  autoneg at
  10M/half duplex.
 
 Indeed, if one side is hardcoded, autoneg will fail and the side trying to
 autoneg is required by the specs (not that I know chapter and verse to quote
 from the IEE stuff :( to go into half-duplex.

 Rather than forcing a PHY into 10Mbps, you may limit its advertised list 
of speeds/duplex settings and let autonegotiation do the rest.  It depends 
on how smart code to manage your switch is; it's certainly doable with 
Linux (you can do it with `mii-tool'; not sure about `ethtool') as long as 
the NIC driver supports the necessary ioctls.

 Was 10M/Fullduplex ever standardized?  If not I could see where kit might not
 be willing/able to autoneg to that.

 It is standard.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes

[Maciej W. Rozycki]

On Mon, 16 Oct 2006, Andrew Morton wrote:

 Vaguely.  Why doesn't it deadlock if !current_is_keventd()?  I mean,
 whether or not the caller is keventd, the flush_scheduled_work() caller
 will still be dependent upon rtnl_lock() being acquirable.

 This !current_is_keventd() condition is just what it is, i.e. a check 
whether phy_stop_interrupts() has been scheduled through keventd or not.  
If it has, then flush_scheduled_work() cannot be called; it is not needed 
anyway.  Otherwise phy_stop_interrupts() has to make sure no deferred 
calls to phy_change() will be made once it has finished.

 In all cases the assumption is the caller has made sure rtnl_lock() is 
not held at the time phy_stop_interrupts() is called.  That's the very 
reason for scheduling phy_disconnect() (and hence phy_stop_interrupts()) 
through keventd.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes

[Maciej W. Rozycki]

Andrew,

 I don't get it.  If some code does
 
   rtnl_lock();
   flush_scheduled_work();
 
 and there's some work scheduled which does rtnl_lock() then it'll deadlock.
 
 But it'll deadlock whether or not the caller of flush_scheduled_work() is
 keventd.
 
 Calling flush_scheduled_work() under locks is generally a bad idea.

 Indeed -- this is why I avoid it.

 I'd have thought that was still deadlockable.  Could you describe the
 deadlock more completely please?

 The simplest sequence of calls that prevents races here is as follows:

unregister_netdev();
  rtnl_lock();
  unregister_netdevice();
dev_close();
  sbmac_close();
phy_stop();
phy_disconnect();
  phy_stop_interrupts();
phy_disable_interrupts();
flush_scheduled_work();
free_irq();
  phy_detach();
mdiobus_unregister();
  rtnl_unlock();

We want to call flush_scheduled_work() from phy_stop_interrupts(), because 
there may still be calls to phy_change() waiting for the keventd to 
process and mdiobus_unregister() frees structures needed by phy_change().  
This may deadlock because of the call to rtnl_lock() though.

 So the modified sequence I have implemented is as follows:

unregister_netdev();
  rtnl_lock();
  unregister_netdevice();
dev_close();
  sbmac_close();
phy_stop();
schedule_work(); [sbmac_phy_disconnect()]
  rtnl_unlock();

and then:

sbmac_phy_disconnect();
  phy_disconnect();
phy_stop_interrupts();
  phy_disable_interrupts();
  free_irq();
phy_detach();
  mdiobus_unregister();

This guarantees calls to phy_change() for this PHY unit will not be run 
after mdiobus_unregister(), because any such calls have been placed in the 
queue before sbmac_phy_disconnect() (phy_stop() prevents the interrupt 
handler from issuing new calls to phy_change()).

 We still need flush_scheduled_work() to be called from 
phy_stop_interrupts() though, in case some other MAC driver calls 
phy_disconnect() (or phy_stop_interrupts(), depending on the abstraction 
layer of phylib used) directly rather than using keventd.  This is 
possible if phy_disconnect() is called from the driver's module_exit() 
call, which may make sense for devices that are known not to have their 
MII interface available as an external connector.  Hence the:

if (!current_is_keventd())
  flush_scheduled_work();

sequence in phy_stop_interrupts().  Of course, we can force all drivers 
using phylib (in the interrupt mode) to call phy_disconnect() through 
keventd instead.

 Does it sound clearer?

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes

[Maciej W. Rozycki]

On Thu, 5 Oct 2006, Andrew Morton wrote:

  2. The driver uses schedule_work() for handling interrupts, but does not 
 make sure any pending work scheduled thus has been completed before 
 driver's structures get freed from memory.  This is especially 
 important as interrupts may keep arriving if the line is shared with 
 another PHY.
  
 The solution is to ignore phy_interrupt() calls if the reported device 
 has already been halted and calling flush_scheduled_work() from 
 phy_stop_interrupts() (but guarded with current_is_keventd() in case 
 the function has been called through keventd from the MAC device's 
 close call to avoid a deadlock on the netlink lock).
  
 
 eww, hack.
 
 Also not module-friendly:
 
 WARNING: current_is_keventd [drivers/net/phy/libphy.ko] undefined!
 
 Does this
 
 static void flush_cpu_workqueue(struct cpu_workqueue_struct *cwq)
 {
   if (cwq-thread == current) {
   /*
* Probably keventd trying to flush its own queue. So simply run
* it by hand rather than deadlocking.
*/
   run_workqueue(cwq);
 
 not work???

 It does, too well even! -- in the case I am trying to take care of we are 
run with rtnl_mutex held as a result of rtnl_lock() called from 
unregister_netdev() and there is some work already in the workqueue 
(linkwatch_event(), apparently) wanting to acquire the same lock.  Hence a 
deadlock.  It seems problematic elsewhere as well -- see tg3.c -- but a 
different way to deal with it has been found there.

 I am not that fond of this solution, but at least it works, unlike 
calling flush_scheduled_work() here, which deadlocks the current CPU in my 
system instantly.  Any suggestions as to how to do this differently?  
Perhaps linkwatch_event() should be scheduled differently (using a 
separate workqueue?)...  Or does dev_close() have to be called under this 
lock from unregister_netdevice()?  Perhaps code like this would do:

while (dev-flags  IFF_UP) {
rtnl_unlock();
dev_close(dev);
rtnl_lock();
}

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.18 4/6]: sb1250-mac: Driver model phylib support

[Maciej W. Rozycki]

 This is an update including the following changes:

1. Some help text for Kconfig.

2. Removal of unused module options.

3. Phylib support and the resulting removal of generic bits for handling 
   the PHY.

4. Proper reserving of device resources and using ioremap()ped handles
   to access MAC registers rather than platform-specific macros.

5. Handling of the device using the driver model.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---

 This revision fixes the problem with drivers/net/Kconfig.

 Please consider.

  Maciej

patch-2.6.18-sb1250-mac-16
diff -up --recursive --new-file linux-2.6.18.macro/drivers/net/Kconfig 
linux-2.6.18/drivers/net/Kconfig
--- linux-2.6.18.macro/drivers/net/Kconfig  2006-09-20 03:42:06.0 
+
+++ linux-2.6.18/drivers/net/Kconfig2006-10-05 15:50:20.0 +
@@ -456,6 +456,15 @@ config MIPS_AU1X00_ENET
 config NET_SB1250_MAC
tristate SB1250 Ethernet support
depends on NET_ETHERNET  SIBYTE_SB1xxx_SOC
+   select PHYLIB
+   ---help---
+ This driver supports gigabit Ethernet interfaces based on the
+ Broadcom SiByte family of System-On-a-Chip parts.  They include
+ the BCM1120, BCM1125, BCM1125H, BCM1250, BCM1255, BCM1280, BCM1455
+ and BCM1480 chips.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sb1250-mac.
 
 config SGI_IOC3_ETH
bool SGI IOC3 Ethernet
diff -up --recursive --new-file linux-2.6.18.macro/drivers/net/sb1250-mac.c 
linux-2.6.18/drivers/net/sb1250-mac.c
--- linux-2.6.18.macro/drivers/net/sb1250-mac.c 2006-09-20 03:42:06.0 
+
+++ linux-2.6.18/drivers/net/sb1250-mac.c   2006-10-05 15:48:50.0 
+
@@ -1,5 +1,6 @@
 /*
  * Copyright (C) 2001,2002,2003,2004 Broadcom Corporation
+ * Copyright (c) 2006  Maciej W. Rozycki
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -18,7 +19,11 @@
  *
  * This driver is designed for the Broadcom SiByte SOC built-in
  * Ethernet controllers. Written by Mitch Lichtenberg at Broadcom Corp.
+ *
+ * Updated to the driver model and the PHY abstraction layer
+ * by Maciej W. Rozycki.
  */
+
 #include linux/module.h
 #include linux/kernel.h
 #include linux/string.h
@@ -32,9 +37,18 @@
 #include linux/skbuff.h
 #include linux/init.h
 #include linux/bitops.h
-#include asm/processor.h /* Processor type for cache alignment. 
*/
-#include asm/io.h
+#include linux/err.h
+#include linux/ethtool.h
+#include linux/mii.h
+#include linux/phy.h
+#include linux/platform_device.h
+#include linux/platform_device.h
+#include linux/workqueue.h
+
+#include asm/bug.h
 #include asm/cache.h
+#include asm/io.h
+#include asm/processor.h /* Processor type for cache alignment. */
 
 /* This is only here until the firmware is ready.  In that case,
the firmware leaves the ethernet address in the register for us. */
@@ -48,7 +62,7 @@
 
 /* These identify the driver base version and may not be removed. */
 #if 0
-static char version1[] __devinitdata =
+static char version1[] __initdata =
 sb1250-mac.c:1.00 1/11/2001 Written by Mitch Lichtenberg\n;
 #endif
 
@@ -57,8 +71,6 @@ static char version1[] __devinitdata =
 
 #define CONFIG_SBMAC_COALESCE
 
-#define MAX_UNITS 4/* More are supported, limit only on options */
-
 /* Time in jiffies before concluding the transmitter is hung. */
 #define TX_TIMEOUT  (2*HZ)
 
@@ -74,26 +86,6 @@ static int debug = 1;
 module_param(debug, int, S_IRUGO);
 MODULE_PARM_DESC(debug, Debug messages);
 
-/* mii status msgs */
-static int noisy_mii = 1;
-module_param(noisy_mii, int, S_IRUGO);
-MODULE_PARM_DESC(noisy_mii, MII status messages);
-
-/* Used to pass the media type, etc.
-   Both 'options[]' and 'full_duplex[]' should exist for driver
-   interoperability.
-   The media type is usually passed in 'options[]'.
-*/
-#ifdef MODULE
-static int options[MAX_UNITS] = {-1, -1, -1, -1};
-module_param_array(options, int, NULL, S_IRUGO);
-MODULE_PARM_DESC(options, 1- __MODULE_STRING(MAX_UNITS));
-
-static int full_duplex[MAX_UNITS] = {-1, -1, -1, -1};
-module_param_array(full_duplex, int, NULL, S_IRUGO);
-MODULE_PARM_DESC(full_duplex, 1- __MODULE_STRING(MAX_UNITS));
-#endif
-
 #ifdef CONFIG_SBMAC_COALESCE
 static int int_pktcnt = 0;
 module_param(int_pktcnt, int, S_IRUGO);
@@ -104,6 +96,7 @@ module_param(int_timeout, int, S_IRUGO);
 MODULE_PARM_DESC(int_timeout, Timeout value);
 #endif
 
+#include asm/sibyte/board.h
 #include asm/sibyte/sb1250.h
 #if defined(CONFIG_SIBYTE_BCM1x55) || defined(CONFIG_SIBYTE_BCM1x80)
 #include asm/sibyte/bcm1480_regs.h
@@ -126,22 +119,43 @@ MODULE_PARM_DESC(int_timeout, Timeout v
 #error invalid SiByte MAC configuation
 #endif
 
+#ifdef K_INT_PHY
+#define SBMAC_PHY_INT  K_INT_PHY
+#else
+#define SBMAC_PHY_INT  PHY_POLL
+#endif

[PATCH 2.6.18 7/6]: sb1250-mac: Remove typedef obfuscation

[Maciej W. Rozycki]

 This is a set of changes to remove unneeded type definitions that only 
make code less obvious.  It applies to all enum and struct types as 
well as to potentially unsafe use of them within sizeof().

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---

 This applies on top of 4/6.  Please consider.

  Maciej

patch-mips-2.6.18-20060920-sb1250-mac-typedef-3
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/sb1250-mac.c 
linux-mips-2.6.18-20060920/drivers/net/sb1250-mac.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/sb1250-mac.c   2006-09-28 
02:51:29.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/sb1250-mac.c 2006-10-05 
16:18:41.0 +
@@ -129,33 +129,33 @@ MODULE_PARM_DESC(int_timeout, Timeout v
  *  Simple types
  * */
 
-typedef enum {
+enum sbmac_speed {
sbmac_speed_none = 0,
sbmac_speed_10 = SPEED_10,
sbmac_speed_100 = SPEED_100,
sbmac_speed_1000 = SPEED_1000,
-} sbmac_speed_t;
+};
 
-typedef enum {
+enum sbmac_duplex {
sbmac_duplex_none = -1,
sbmac_duplex_half = DUPLEX_HALF,
sbmac_duplex_full = DUPLEX_FULL,
-} sbmac_duplex_t;
+};
 
-typedef enum {
+enum sbmac_fc {
sbmac_fc_none,
sbmac_fc_disabled,
sbmac_fc_frame,
sbmac_fc_collision,
sbmac_fc_carrier,
-} sbmac_fc_t;
+};
 
-typedef enum {
+enum sbmac_state {
sbmac_state_uninit,
sbmac_state_off,
sbmac_state_on,
sbmac_state_broken,
-} sbmac_state_t;
+};
 
 
 /**
@@ -181,52 +181,58 @@ typedef enum {
  *  DMA Descriptor structure
  * */
 
-typedef struct sbdmadscr_s {
+struct sbdmadscr {
uint64_t  dscr_a;
uint64_t  dscr_b;
-} sbdmadscr_t;
-
-typedef unsigned long paddr_t;
+};
 
 /**
  *  DMA Controller structure
  * */
 
-typedef struct sbmacdma_s {
+struct sbmacdma {
 
/*
 * This stuff is used to identify the channel and the registers
 * associated with it.
 */
-
-   struct sbmac_softc *sbdma_eth;  /* back pointer to associated 
MAC */
-   int  sbdma_channel; /* channel number */
-   int  sbdma_txdir;   /* direction (1=transmit) */
-   int  sbdma_maxdescr;/* total # of descriptors in 
ring */
+   struct sbmac_softc  *sbdma_eth; /* back pointer to associated
+  MAC */
+   int sbdma_channel;  /* channel number */
+   int sbdma_txdir;/* direction (1=transmit) */
+   int sbdma_maxdescr; /* total # of descriptors
+  in ring */
 #ifdef CONFIG_SBMAC_COALESCE
-   int  sbdma_int_pktcnt;  /* # descriptors rx/tx before 
interrupt*/
-   int  sbdma_int_timeout; /* # usec rx/tx interrupt */
+   int sbdma_int_pktcnt;
+   /* # descriptors rx/tx
+  before interrupt */
+   int sbdma_int_timeout;
+   /* # usec rx/tx interrupt */
 #endif
-
-   volatile void __iomem *sbdma_config0;   /* DMA config register 0 */
-   volatile void __iomem *sbdma_config1;   /* DMA config register 1 */
-   volatile void __iomem *sbdma_dscrbase;  /* Descriptor base address */
-   volatile void __iomem *sbdma_dscrcnt; /* Descriptor count register 
*/
-   volatile void __iomem *sbdma_curdscr;   /* current descriptor address */
+   volatile void __iomem   *sbdma_config0; /* DMA config register 0 */
+   volatile void __iomem   *sbdma_config1; /* DMA config register 1 */
+   volatile void __iomem   *sbdma_dscrbase;
+   /* descriptor base address */
+   volatile void __iomem   *sbdma_dscrcnt; /* descriptor count register */
+   volatile void __iomem   *sbdma_curdscr; /* current descriptor
+  address */
 
/*
 * This stuff is for maintenance of the ring
 */
-
-   sbdmadscr_t *sbdma_dscrtable;   /* base of descriptor table */
-   sbdmadscr_t *sbdma_dscrtable_end; /* end of descriptor table */
-
-   struct sk_buff **sbdma_ctxtable;/* context table, one per descr */
-
-   paddr_t  sbdma_dscrtable_phys; /* and also the phys addr */
-   sbdmadscr_t *sbdma_addptr;  /* next dscr for sw to add */
-   sbdmadscr_t *sbdma_remptr;  /* next dscr for sw to remove */
-} sbmacdma_t

[PATCH 2.6.18 8/6]: sb1250-mac: Fix an incorrect use of kfree()

[Maciej W. Rozycki]

 The pointer obtained by kmalloc() is treated with ALIGN() before passing 
it to kfree().  This may or may not cause problems depending on the 
minimum alignment enforced by kmalloc() and is ugly anyway.  This change 
records the original pointer returned by kmalloc() so that kfree() may 
safely use it.

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---

 This applies on top of the typedef change (7/6).  Please consider.

  Maciej

patch-mips-2.6.18-20060920-sb1250-mac-kfree-0
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/sb1250-mac.c 
linux-mips-2.6.18-20060920/drivers/net/sb1250-mac.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/sb1250-mac.c   2006-10-05 
16:18:41.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/sb1250-mac.c 2006-10-04 
23:07:27.0 +
@@ -220,6 +220,7 @@ struct sbmacdma {
/*
 * This stuff is for maintenance of the ring
 */
+   void*sbdma_dscrtable_un;
struct sbdmadscr*sbdma_dscrtable;
/* base of descriptor table */
struct sbdmadscr*sbdma_dscrtable_end;
@@ -640,15 +641,16 @@ static void sbdma_initctx(struct sbmacdm
 
d-sbdma_maxdescr = maxdescr;
 
-   d-sbdma_dscrtable = kmalloc((d-sbdma_maxdescr + 1) *
-sizeof(*d-sbdma_dscrtable), GFP_KERNEL);
+   d-sbdma_dscrtable_un = kmalloc((d-sbdma_maxdescr + 1) *
+   sizeof(*d-sbdma_dscrtable),
+   GFP_KERNEL);
 
/*
 * The descriptor table must be aligned to at least 16 bytes or the
 * MAC will corrupt it.
 */
d-sbdma_dscrtable = (struct sbdmadscr *)
-ALIGN((unsigned long)d-sbdma_dscrtable,
+ALIGN((unsigned long)d-sbdma_dscrtable_un,
   sizeof(*d-sbdma_dscrtable));
 
memset(d-sbdma_dscrtable, 0,
@@ -1309,9 +1311,9 @@ static int sbmac_initctx(struct sbmac_so
 
 static void sbdma_uninitctx(struct sbmacdma *d)
 {
-   if (d-sbdma_dscrtable) {
-   kfree(d-sbdma_dscrtable);
-   d-sbdma_dscrtable = NULL;
+   if (d-sbdma_dscrtable_un) {
+   kfree(d-sbdma_dscrtable_un);
+   d-sbdma_dscrtable = d-sbdma_dscrtable_un = NULL;
}
 
if (d-sbdma_ctxtable) {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 2/6] 2.6.18: sb1250-mac: Missing inclusions from linux/phy.h

[Maciej W. Rozycki]

Hello,

 The linux/phy.h uses some types and macros defined in 
linux/ethtool.h, linux/mii.h, linux/timer.h and linux/workqueue.h, 
but fails to include these headers.

 Please consider.

  Maciej

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]

patch-mips-2.6.18-20060920-include-phy-16
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/include/linux/phy.h 
linux-mips-2.6.18-20060920/include/linux/phy.h
--- linux-mips-2.6.18-20060920.macro/include/linux/phy.h2006-08-29 
04:58:59.0 +
+++ linux-mips-2.6.18-20060920/include/linux/phy.h  2006-10-03 
14:18:05.0 +
@@ -20,6 +20,10 @@
 
 #include linux/spinlock.h
 #include linux/device.h
+#include linux/ethtool.h
+#include linux/mii.h
+#include linux/timer.h
+#include linux/workqueue.h
 
 #define PHY_BASIC_FEATURES (SUPPORTED_10baseT_Half | \
 SUPPORTED_10baseT_Full | \
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 4/6] 2.6.18: sb1250-mac: The actual driver update

[Maciej W. Rozycki]

Hello,

 This is the actual driver update.  It includes the following changes:

1. Some help text for Kconfig.

2. Removal of unused module options.

3. Phylib support and the resulting removal of generic bits for handling 
   the PHY.

4. Proper reserving of device resources and using ioremap()ped handles
   to access MAC registers rather than platform-specific macros.

5. Handling of the device using the driver model.

 Please consider.

  Maciej

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]

patch-mips-2.6.18-20060920-sb1250-mac-15
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/Kconfig 
linux-mips-2.6.18-20060920/drivers/net/Kconfig
--- linux-mips-2.6.18-20060920.macro/drivers/net/Kconfig2006-09-10 
04:55:24.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/Kconfig  2006-09-28 
02:35:44.0 +
@@ -2030,6 +2030,15 @@ config R8169_NAPI
 config NET_SB1250_MAC
tristate SB1250 Ethernet support
depends on SIBYTE_SB1xxx_SOC
+   select PHYLIB
+   ---help---
+ This driver supports gigabit Ethernet interfaces based on the
+ Broadcom SiByte family of System-On-a-Chip parts.  They include
+ the BCM1120, BCM1125, BCM1125H, BCM1250, BCM1255, BCM1280, BCM1455
+ and BCM1480 chips.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sb1250-mac.
 
 config R8169_VLAN
bool VLAN support
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/sb1250-mac.c 
linux-mips-2.6.18-20060920/drivers/net/sb1250-mac.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/sb1250-mac.c   2006-09-20 
20:50:26.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/sb1250-mac.c 2006-09-28 
02:51:29.0 +
@@ -1,5 +1,6 @@
 /*
  * Copyright (C) 2001,2002,2003,2004 Broadcom Corporation
+ * Copyright (c) 2006  Maciej W. Rozycki
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -18,7 +19,11 @@
  *
  * This driver is designed for the Broadcom SiByte SOC built-in
  * Ethernet controllers. Written by Mitch Lichtenberg at Broadcom Corp.
+ *
+ * Updated to the driver model and the PHY abstraction layer
+ * by Maciej W. Rozycki.
  */
+
 #include linux/module.h
 #include linux/kernel.h
 #include linux/string.h
@@ -32,9 +37,18 @@
 #include linux/skbuff.h
 #include linux/init.h
 #include linux/bitops.h
-#include asm/processor.h /* Processor type for cache alignment. 
*/
-#include asm/io.h
+#include linux/err.h
+#include linux/ethtool.h
+#include linux/mii.h
+#include linux/phy.h
+#include linux/platform_device.h
+#include linux/platform_device.h
+#include linux/workqueue.h
+
+#include asm/bug.h
 #include asm/cache.h
+#include asm/io.h
+#include asm/processor.h /* Processor type for cache alignment. */
 
 /* This is only here until the firmware is ready.  In that case,
the firmware leaves the ethernet address in the register for us. */
@@ -48,7 +62,7 @@
 
 /* These identify the driver base version and may not be removed. */
 #if 0
-static char version1[] __devinitdata =
+static char version1[] __initdata =
 sb1250-mac.c:1.00 1/11/2001 Written by Mitch Lichtenberg\n;
 #endif
 
@@ -57,8 +71,6 @@ static char version1[] __devinitdata =
 
 #define CONFIG_SBMAC_COALESCE
 
-#define MAX_UNITS 4/* More are supported, limit only on options */
-
 /* Time in jiffies before concluding the transmitter is hung. */
 #define TX_TIMEOUT  (2*HZ)
 
@@ -74,26 +86,6 @@ static int debug = 1;
 module_param(debug, int, S_IRUGO);
 MODULE_PARM_DESC(debug, Debug messages);
 
-/* mii status msgs */
-static int noisy_mii = 1;
-module_param(noisy_mii, int, S_IRUGO);
-MODULE_PARM_DESC(noisy_mii, MII status messages);
-
-/* Used to pass the media type, etc.
-   Both 'options[]' and 'full_duplex[]' should exist for driver
-   interoperability.
-   The media type is usually passed in 'options[]'.
-*/
-#ifdef MODULE
-static int options[MAX_UNITS] = {-1, -1, -1, -1};
-module_param_array(options, int, NULL, S_IRUGO);
-MODULE_PARM_DESC(options, 1- __MODULE_STRING(MAX_UNITS));
-
-static int full_duplex[MAX_UNITS] = {-1, -1, -1, -1};
-module_param_array(full_duplex, int, NULL, S_IRUGO);
-MODULE_PARM_DESC(full_duplex, 1- __MODULE_STRING(MAX_UNITS));
-#endif
-
 #ifdef CONFIG_SBMAC_COALESCE
 static int int_pktcnt = 0;
 module_param(int_pktcnt, int, S_IRUGO);
@@ -104,6 +96,7 @@ module_param(int_timeout, int, S_IRUGO);
 MODULE_PARM_DESC(int_timeout, Timeout value);
 #endif
 
+#include asm/sibyte/board.h
 #include asm/sibyte/sb1250.h
 #if defined(CONFIG_SIBYTE_BCM1x55) || defined(CONFIG_SIBYTE_BCM1x80)
 #include asm/sibyte/bcm1480_regs.h
@@ -126,22 +119,43 @@ MODULE_PARM_DESC(int_timeout, Timeout v
 #error invalid SiByte MAC configuation
 #endif
 
+#ifdef K_INT_PHY
+#define SBMAC_PHY_INT  K_INT_PHY
+#else
+#define SBMAC_PHY_INT  PHY_POLL
+#endif

[patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes

[Maciej W. Rozycki]

Hello,

 This patch fixes a couple of problems discovered with interrupt handling 
in the phylib core, namely:

1. The driver uses timer and workqueue calls, but does not include 
   linux/timer.h nor linux/workqueue.h.

2. The driver uses schedule_work() for handling interrupts, but does not 
   make sure any pending work scheduled thus has been completed before 
   driver's structures get freed from memory.  This is especially 
   important as interrupts may keep arriving if the line is shared with 
   another PHY.

   The solution is to ignore phy_interrupt() calls if the reported device 
   has already been halted and calling flush_scheduled_work() from 
   phy_stop_interrupts() (but guarded with current_is_keventd() in case 
   the function has been called through keventd from the MAC device's 
   close call to avoid a deadlock on the netlink lock).

 Please consider.

  Maciej

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]

patch-mips-2.6.18-20060920-phy-irq-16
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/phy/phy.c 
linux-mips-2.6.18-20060920/drivers/net/phy/phy.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/phy.c  2006-08-05 
04:58:46.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/phy.c2006-10-03 
14:19:21.0 +
@@ -7,6 +7,7 @@
  * Author: Andy Fleming
  *
  * Copyright (c) 2004 Freescale Semiconductor, Inc.
+ * Copyright (c) 2006  Maciej W. Rozycki
  *
  * This program is free software; you can redistribute  it and/or modify it
  * under  the terms of  the GNU General  Public License as published by the
@@ -32,6 +33,8 @@
 #include linux/mii.h
 #include linux/ethtool.h
 #include linux/phy.h
+#include linux/timer.h
+#include linux/workqueue.h
 
 #include asm/io.h
 #include asm/irq.h
@@ -484,6 +487,9 @@ static irqreturn_t phy_interrupt(int irq
 {
struct phy_device *phydev = phy_dat;
 
+   if (PHY_HALTED == phydev-state)
+   return IRQ_NONE;/* It can't be ours.  */
+
/* The MDIO bus is not allowed to be written in interrupt
 * context, so we need to disable the irq here.  A work
 * queue will write the PHY to disable and clear the
@@ -577,6 +583,13 @@ int phy_stop_interrupts(struct phy_devic
if (err)
phy_error(phydev);
 
+   /*
+* Finish any pending work; we might have been scheduled
+* to be called from keventd ourselves, though.
+*/
+   if (!current_is_keventd())
+   flush_scheduled_work();
+
free_irq(phydev-irq, phydev);
 
return err;
@@ -603,7 +616,8 @@ static void phy_change(void *data)
enable_irq(phydev-irq);
 
/* Reenable interrupts */
-   err = phy_config_interrupt(phydev, PHY_INTERRUPT_ENABLED);
+   if (PHY_HALTED != phydev-state)
+   err = phy_config_interrupt(phydev, PHY_INTERRUPT_ENABLED);
 
if (err)
goto irq_enable_err;
@@ -624,18 +638,24 @@ void phy_stop(struct phy_device *phydev)
if (PHY_HALTED == phydev-state)
goto out_unlock;
 
-   if (phydev-irq != PHY_POLL) {
-   /* Clear any pending interrupts */
-   phy_clear_interrupt(phydev);
+   phydev-state = PHY_HALTED;
 
+   if (phydev-irq != PHY_POLL) {
/* Disable PHY Interrupts */
phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED);
-   }
 
-   phydev-state = PHY_HALTED;
+   /* Clear any pending interrupts */
+   phy_clear_interrupt(phydev);
+   }
 
 out_unlock:
spin_unlock(phydev-lock);
+
+   /*
+* Cannot call flush_scheduled_work() here as desired because
+* of rtnl_lock(), but PHY_HALTED shall guarantee phy_change()
+* will not reenable interrupts.
+*/
 }
 
 
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 1/6] 2.6.18: sb1250-mac: Broadcom PHY support

[Maciej W. Rozycki]

Hello,

 This patch adds support for interrupt-driven operation of the Broadcom 
Gigabit Ethernet PHYs.  I have included device IDs for the parts used on 
Broadcom SiByte evaluation boards; more can be added as a need arises.  
They are apparently generally software-compatible with one another.

 Please consider.

  Maciej

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]

patch-mips-2.6.18-20060920-broadcom-phy-15
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/phy/Kconfig 
linux-mips-2.6.18-20060920/drivers/net/phy/Kconfig
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/Kconfig2006-09-20 
20:50:26.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/Kconfig  2006-09-23 
14:39:08.0 +
@@ -56,6 +56,12 @@ config SMSC_PHY
---help---
  Currently supports the LAN83C185 PHY
 
+config BROADCOM_PHY
+   tristate Drivers for Broadcom PHYs
+   depends on PHYLIB
+   ---help---
+ Currently supports the BCM5411, BCM5421 and BCM5461 PHYs.
+
 config FIXED_PHY
tristate Drivers for PHY emulation on fixed speed/link
depends on PHYLIB
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/phy/Makefile 
linux-mips-2.6.18-20060920/drivers/net/phy/Makefile
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/Makefile   2006-09-20 
20:50:26.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/Makefile 2006-09-22 
22:55:37.0 +
@@ -10,4 +10,5 @@ obj-$(CONFIG_LXT_PHY) += lxt.o
 obj-$(CONFIG_QSEMI_PHY)+= qsemi.o
 obj-$(CONFIG_SMSC_PHY) += smsc.o
 obj-$(CONFIG_VITESSE_PHY)  += vitesse.o
+obj-$(CONFIG_BROADCOM_PHY) += broadcom.o
 obj-$(CONFIG_FIXED_PHY)+= fixed.o
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/drivers/net/phy/broadcom.c 
linux-mips-2.6.18-20060920/drivers/net/phy/broadcom.c
--- linux-mips-2.6.18-20060920.macro/drivers/net/phy/broadcom.c 1970-01-01 
00:00:00.0 +
+++ linux-mips-2.6.18-20060920/drivers/net/phy/broadcom.c   2006-09-28 
01:47:11.0 +
@@ -0,0 +1,175 @@
+/*
+ * drivers/net/phy/broadcom.c
+ *
+ * Broadcom BCM5411, BCM5421 and BCM5461 Gigabit Ethernet
+ * transceivers.
+ *
+ * Copyright (c) 2006  Maciej W. Rozycki
+ *
+ * Inspired by code written by Amy Fong.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/phy.h
+
+#define MII_BCM54XX_ECR0x10/* BCM54xx extended control 
register */
+#define MII_BCM54XX_ECR_IM 0x1000  /* Interrupt mask */
+#define MII_BCM54XX_ECR_IF 0x0800  /* Interrupt force */
+
+#define MII_BCM54XX_ESR0x11/* BCM54xx extended status 
register */
+#define MII_BCM54XX_ESR_IS 0x1000  /* Interrupt status */
+
+#define MII_BCM54XX_ISR0x1a/* BCM54xx interrupt status 
register */
+#define MII_BCM54XX_IMR0x1b/* BCM54xx interrupt mask 
register */
+#define MII_BCM54XX_INT_CRCERR 0x0001  /* CRC error */
+#define MII_BCM54XX_INT_LINK   0x0002  /* Link status changed */
+#define MII_BCM54XX_INT_SPEED  0x0004  /* Link speed change */
+#define MII_BCM54XX_INT_DUPLEX 0x0008  /* Duplex mode changed */
+#define MII_BCM54XX_INT_LRS0x0010  /* Local receiver status changed */
+#define MII_BCM54XX_INT_RRS0x0020  /* Remote receiver status changed */
+#define MII_BCM54XX_INT_SSERR  0x0040  /* Scrambler synchronization error */
+#define MII_BCM54XX_INT_UHCD   0x0080  /* Unsupported HCD negotiated */
+#define MII_BCM54XX_INT_NHCD   0x0100  /* No HCD */
+#define MII_BCM54XX_INT_NHCDL  0x0200  /* No HCD link */
+#define MII_BCM54XX_INT_ANPR   0x0400  /* Auto-negotiation page received */
+#define MII_BCM54XX_INT_LC 0x0800  /* All counters below 128 */
+#define MII_BCM54XX_INT_HC 0x1000  /* Counter above 32768 */
+#define MII_BCM54XX_INT_MDIX   0x2000  /* MDIX status change */
+#define MII_BCM54XX_INT_PSERR  0x4000  /* Pair swap error */
+
+MODULE_DESCRIPTION(Broadcom PHY driver);
+MODULE_AUTHOR(Maciej W. Rozycki);
+MODULE_LICENSE(GPL);
+
+static int bcm54xx_config_init(struct phy_device *phydev)
+{
+   int reg, err;
+
+   reg = phy_read(phydev, MII_BCM54XX_ECR);
+   if (reg  0)
+   return reg;
+
+   /* Mask interrupts globally.  */
+   reg |= MII_BCM54XX_ECR_IM;
+   err = phy_write(phydev, MII_BCM54XX_ECR, reg);
+   if (err  0)
+   return err;
+
+   /* Unmask events we are interested in.  */
+   reg = ~(MII_BCM54XX_INT_DUPLEX |
+   MII_BCM54XX_INT_SPEED |
+   MII_BCM54XX_INT_LINK);
+   err = phy_write(phydev, MII_BCM54XX_IMR, reg);
+   if (err  0)
+   return err

[patch 5/6] 2.6.18: sb1250-mac: Interrupt wiring for PHYs

[Maciej W. Rozycki]

Hello,

 This patch defines the wiring for the PHY interrupt lines for the 
supported Broadcom SiByte boards for which documentation is available.

 Please consider.

  Maciej

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]

patch-mips-2.6.18-20060920-sibyte-phy-irq-15
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/include/asm-mips/sibyte/sentosa.h 
linux-mips-2.6.18-20060920/include/asm-mips/sibyte/sentosa.h
--- linux-mips-2.6.18-20060920.macro/include/asm-mips/sibyte/sentosa.h  
2006-09-20 20:51:12.0 +
+++ linux-mips-2.6.18-20060920/include/asm-mips/sibyte/sentosa.h
2006-09-25 21:08:37.0 +
@@ -37,4 +37,8 @@
 /* GPIOs */
 #define K_GPIO_DBG_LED  0
 
+#ifdef CONFIG_SIBYTE_SENTOSA
+#define K_INT_PHY  K_INT_PCI_INTD
+#endif
+
 #endif /* __ASM_SIBYTE_SENTOSA_H */
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/include/asm-mips/sibyte/swarm.h 
linux-mips-2.6.18-20060920/include/asm-mips/sibyte/swarm.h
--- linux-mips-2.6.18-20060920.macro/include/asm-mips/sibyte/swarm.h
2006-09-20 20:51:12.0 +
+++ linux-mips-2.6.18-20060920/include/asm-mips/sibyte/swarm.h  2006-09-25 
21:56:49.0 +
@@ -67,4 +67,9 @@
 #define K_INT_PC_READY  (K_INT_GPIO_0 + K_GPIO_PC_READY)
 #endif
 
+#ifdef CONFIG_SIBYTE_SWARM
+#define K_GPIO_PHY 2
+#define K_INT_PHY  (K_INT_GPIO_0 + K_GPIO_PHY)
+#endif
+
 #endif /* __ASM_SIBYTE_SWARM_H */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 0/6] 2.6.18: sb1250-mac: Driver model phylib update

[Maciej W. Rozycki]

Hello,

 Here is a set of patches that update the sb1250-mac driver used for the 
onchip Gigabit Ethernet interfaces of the Broadcom SiByte family of SOCs 
including the BCM1250 and a couple of other members.  These are used, 
among others, on various Broadcom evaluation boards together with Broadcom 
Gigabit Ethernet PHY chips.  Changes include porting the driver to the 
driver model as a platform device, support for phylib, including the 
BCM54xx PHYs in the interrupt mode, proper resource managment and a couple 
of minor clean-ups.

 Apart from changes to networking code, there are a few required in the 
architecture-specific areas and therefore I am sending these changes to 
Ralf and the linux-mips list as well.  It might also involve a few more 
interested parties in the discussion.

 The changes were tested with a Broadcom SWARM board, which includes a 
BCM1250 part which has 3 MAC units on chip, of which 2 are usable, with 
BCM5421 PHY chips attached (both wired to the same interrupt line, which 
made testing whether IRQ sharing works properly in phylib possible).  
Link partners included a 1000base and a 100base interface doing 
autonegotiation as well as a 10base one doing none.

 Other Broadcom boards that I know of may have these or BCM5411 or BCM5461 
chips.  The lack of documentation or at least actual pieces of hardware 
makes the use of interrupts impossible for all but the SWARM, the Sentosa 
and the Shorty (with the latter unsupported by Linux).

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch 6/6] 2.6.18: sb1250-mac: PHY interrupt polarity fixup

[Maciej W. Rozycki]

Hello,

 This change makes the PHY interrupt actually work as intended on the 
SWARM board, where the CFE firmware leaves the GPIO line at the power-on 
polarity, which is suitable for active-high interrupts, but not quite so 
for this one (the interrupt force bit in the PHY works much better for 
stress-testing interrupt handling; use that one instead if needed).

 Please consider.

  Maciej

Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]

patch-mips-2.6.18-20060920-swarm-setup-15
diff -up --recursive --new-file 
linux-mips-2.6.18-20060920.macro/arch/mips/sibyte/swarm/setup.c 
linux-mips-2.6.18-20060920/arch/mips/sibyte/swarm/setup.c
--- linux-mips-2.6.18-20060920.macro/arch/mips/sibyte/swarm/setup.c 
2006-07-12 04:59:56.0 +
+++ linux-mips-2.6.18-20060920/arch/mips/sibyte/swarm/setup.c   2006-09-28 
02:37:31.0 +
@@ -1,6 +1,7 @@
 /*
  * Copyright (C) 2000, 2001, 2002, 2003, 2004 Broadcom Corporation
  * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
+ * Copyright (c) 2006  Maciej W. Rozycki
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -106,6 +107,8 @@ int swarm_be_handler(struct pt_regs *reg
 
 void __init plat_mem_setup(void)
 {
+   u64 invert;
+
 #if defined(CONFIG_SIBYTE_BCM1x55) || defined(CONFIG_SIBYTE_BCM1x80)
bcm1480_setup();
 #elif defined(CONFIG_SIBYTE_SB1250) || defined(CONFIG_SIBYTE_BCM112X)
@@ -114,6 +117,16 @@ void __init plat_mem_setup(void)
 #error invalid SiByte board configuation
 #endif
 
+   /*
+* The PHY interrupt on the SWARM is active low,
+* but CFE gets it wrong (or not at all, probably).
+*/
+#ifdef K_GPIO_PHY
+   invert = __raw_readq(IOADDR(A_GPIO_INPUT_INVERT));
+   invert |= 1  K_GPIO_PHY;
+   __raw_writeq(invert, IOADDR(A_GPIO_INPUT_INVERT));
+#endif
+
panic_timeout = 5;  /* For debug.  */
 
board_time_init = swarm_time_init;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mii-tool gigabit support.

[Maciej W. Rozycki]

On Wed, 27 Sep 2006, Auke Kok wrote:

  Older equipment, which may still be in use here and there, allowed
  full-duplex operation, but no auto-negotiation.  The duplex setting was
  either fixed or selectable in a system-specific manner.  In such a case you
  certainly want your modern other end to be forced to full-duplex, but still
  let it detect the link speed, so that you do not have to do reconfiguration
  whenever you move a link between a 10base-T and a 100base-Tx port.
 
 in this case the new addition to ethtool will not help as it only changes the
 modes that the NIC will advertise. In this specific case you will need to turn
 of advertising/autonegotiation and force a speed/duplex pair anyway.

 My whole point is to keep the speed negotiation enabled.  If you force a 
given speed and the partner only supports a different one, you will get no 
link.

 Advertising all half-duplex modes to a partner that does not do
 autonegotiation is (by spec I think) an unsupported configuration (i.e.
 undetermined behaviour).

 Yes, but more reasonable PHYs will autosense the link speed if allowed 
to, even if the partner is not capable of negotiating.  It is useful, so 
why should we limit people so that they cannot do it?

 And as I wrote, it is not half-duplex operation that is problematic as it 
is the default if the partner does not negotiate anyway.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mii-tool gigabit support.

[Maciej W. Rozycki]

On Wed, 27 Sep 2006, Rick Jones wrote:

  Another scenario: forcing the NIC to negotiate only full-duplex speeds. Not
  only fun if you try it against a hub, but possibly useful.
[...]
 I'm just worried (as in Fear Uncertainty and Doubt) that having people set the
 allowed things to negotiate isn't really any more robust than stright-up
 hardcodes and perpetuates the (IMO) myth that one shouldn't autoneg on general
 principle.

 Older equipment, which may still be in use here and there, allowed 
full-duplex operation, but no auto-negotiation.  The duplex setting was 
either fixed or selectable in a system-specific manner.  In such a case 
you certainly want your modern other end to be forced to full-duplex, but 
still let it detect the link speed, so that you do not have to do 
reconfiguration whenever you move a link between a 10base-T and a 
100base-Tx port.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add Broadcom PHY support

[Maciej W. Rozycki]

On Tue, 19 Sep 2006, Amy Fong wrote:

  And... where are the users of this phy driver?
[...]
 This phy driver is used by the WRS's sbc8560 (bcm5421s) and sbc843x 
 (bcm5461s) via the gianfar driver.

 And sb1250-mac.c would be happy to use it too.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add Broadcom PHY support

[Maciej W. Rozycki]

On Tue, 19 Sep 2006, Jeff Garzik wrote:

   And sb1250-mac.c would be happy to use it too.
 
 would be happy to != is using.   I don't want to add a phy driver until
 there are already active users in the kernel.

 Fair enough, but Amy may be looking forward to seeing yet another piece 
of code using the new driver. ;-)

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Diff between Linus' and linux-mips git: declance

[Maciej W. Rozycki]

On Mon, 20 Feb 2006, Martin Michlmayr wrote:

 Updated patch, please apply.
 
 
 [PATCH] Remove delta between Linus' and linux-mips git trees in declance
 
 There are three changes between the Linus' and linux-mips git trees
 regarding the declaner driver.  The first change is certainly correct
 (as it is consistent with the rest of the file) and should be applied
 to mainline; the other change seems correct too.  And the third is
 cosmetic.
 
 Signed-off-by: Martin Michlmayr [EMAIL PROTECTED]

Acked-by: Maciej W. Rozycki [EMAIL PROTECTED]

  Maciej
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html