* [PATCH 1/8] net/macb: check all address registers sets
From: Joachim Eastwood @ 2012-11-07 18:14 UTC (permalink / raw)
To: nicolas.ferre, davem; +Cc: plagnioj, netdev, Joachim Eastwood
In-Reply-To: <1352312097-31320-1-git-send-email-manabian@gmail.com>
The macb driver in u-boot uses the first register set while
the at91_ether driver in u-boot uses the second register set.
By checking all register set, like at91_ether does, this code
can be shared between the drivers.
This only changes behavior on macb if no vaild address
is found in the first register set.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/ethernet/cadence/macb.c | 35 ++++++++++++++++++++---------------
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 13c3c33..3b609be 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -114,23 +114,28 @@ static void __init macb_get_hwaddr(struct macb *bp)
u32 bottom;
u16 top;
u8 addr[6];
+ int i;
- bottom = macb_or_gem_readl(bp, SA1B);
- top = macb_or_gem_readl(bp, SA1T);
-
- addr[0] = bottom & 0xff;
- addr[1] = (bottom >> 8) & 0xff;
- addr[2] = (bottom >> 16) & 0xff;
- addr[3] = (bottom >> 24) & 0xff;
- addr[4] = top & 0xff;
- addr[5] = (top >> 8) & 0xff;
-
- if (is_valid_ether_addr(addr)) {
- memcpy(bp->dev->dev_addr, addr, sizeof(addr));
- } else {
- netdev_info(bp->dev, "invalid hw address, using random\n");
- eth_hw_addr_random(bp->dev);
+ /* Check all 4 address register for vaild address */
+ for (i = 0; i < 4; i++) {
+ bottom = macb_or_gem_readl(bp, SA1B + i * 8);
+ top = macb_or_gem_readl(bp, SA1T + i * 8);
+
+ addr[0] = bottom & 0xff;
+ addr[1] = (bottom >> 8) & 0xff;
+ addr[2] = (bottom >> 16) & 0xff;
+ addr[3] = (bottom >> 24) & 0xff;
+ addr[4] = top & 0xff;
+ addr[5] = (top >> 8) & 0xff;
+
+ if (is_valid_ether_addr(addr)) {
+ memcpy(bp->dev->dev_addr, addr, sizeof(addr));
+ return;
+ }
}
+
+ netdev_info(bp->dev, "invalid hw address, using random\n");
+ eth_hw_addr_random(bp->dev);
}
static int macb_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
--
1.8.0
^ permalink raw reply related
* [PATCH 0/8] at91_ether share stats/address setting with macb
From: Joachim Eastwood @ 2012-11-07 18:14 UTC (permalink / raw)
To: nicolas.ferre, davem; +Cc: plagnioj, netdev, Joachim Eastwood
Patch 1-2 add support for some special at91_ether features to macb address setting code. This will allow us to have one address setting function that can be shared.
Patch 4 removes the at91_ether address set/get code and make use of the exported functions for macb.
Patch 5 remove the at91_ether statistics functions and replace them with equivalent function from macb.
Patch 6 removes an unused member from the at91_ether/macb private struct.
Patch 7 is a clean up of the print outs from at91_ether.
Patch 8 is a misc clean up patch which fixes some comment and style issues.
Most of the code left in at91_ether now deal with configuration and DMA rx/tx which is hard to share with macb since this is specific for the IP block in AT91RM9200.
Next I'll work on adding PHY GPIO interrupt to the macb driver. at91_ether had this functionality before it began using mdio functions from macb.
Joachim Eastwood (8):
net/macb: check all address registers sets
net/macb: support reversed hw addr
net/macb: export macb_set_hwaddr and macb_get_hwaddr
net/at91_ether: use macb functions for get/set hwaddr
net/at91_ether: use stat function from macb
net/at91_ether: drop board_data private struct member
net/at91_ether: clean up print outs
net/at91_ether: fix comment and style issues
drivers/net/ethernet/cadence/at91_ether.c | 289 +++++++-----------------------
drivers/net/ethernet/cadence/macb.c | 54 ++++--
drivers/net/ethernet/cadence/macb.h | 10 +-
3 files changed, 109 insertions(+), 244 deletions(-)
--
1.8.0
^ permalink raw reply
* mmap RX_RING socket issue 32b application running on 64b kernel.
From: Ronny Meeus @ 2012-11-07 17:58 UTC (permalink / raw)
To: netdev
I have an application using raw Ethernet sockets in combination with
the mmaped RX_RING.
The application is running on a Cavium MIPS processor (64bit) and the
application code is compiled with the N32 ABI.
Since the ring buffer is shared between the Linux kernel and the
application there is a conflict in the way the data is presented.
Each buffer in the ring has a header that has following structure:
(File http://lxr.free-electrons.com/source/include/linux/if_packet.h )
103 struct tpacket_hdr {
104 unsigned long tp_status;
105 unsigned int tp_len;
106 unsigned int tp_snaplen;
107 unsigned short tp_mac;
108 unsigned short tp_net;
109 unsigned int tp_sec;
110 unsigned int tp_usec;
111 };
The status field indicates that the buffer belongs to the kernel or to
the user. Note that an unsigned long is used to represent the field.
In the kernel the long is 64 bit while in application space the long
is only 32bit, so the bits do not match.
After adapting the code to take this into account my program works well.
In my test program I have defined a new struct where I change the
“unsigned long” into an “unsigned long long”:
struct tpacket_hdr_64 {
unsigned long long tp_status;
unsigned int tp_len;
unsigned int tp_snaplen;
unsigned short tp_mac;
unsigned short tp_net;
unsigned int tp_sec;
unsigned int tp_usec;
};
In my opinion this is not a correct solution. It should be solved
somewhere in the include file I used so that it is transparent for the
application.
Please comment.
---
Ronny
^ permalink raw reply
* Re: [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crashusers
From: Dave Jones @ 2012-11-07 17:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Julius Werner, linux-kernel, netdev, Patrick McHardy,
Hideaki YOSHIFUJI, James Morris, Alexey Kuznetsov,
David S. Miller, Sameer Nanda, Mandeep Singh Baines, Eric Dumazet
In-Reply-To: <1352307902.3140.4588.camel@edumazet-glaptop>
On Wed, Nov 07, 2012 at 09:05:02AM -0800, Eric Dumazet wrote:
> On Wed, 2012-11-07 at 11:43 -0500, Dave Jones wrote:
>
> > dude, look at the bug reports I just pointed you at.
> > People _are_ aware there are bugs there.
> >
> If I remember well, I helped to fix some of them.
indeed, and I commend you for it. I want to help you fix more ;)
> > > I understand a distro maintainer has its own choices, but for upstream
> > > kernel we want to have early reports.
> >
> > I'm running out of ways to word this, but I'll try again.
> > You won't get those early reports if you turn this into a BUG().
> >
> > > This bug is fatal and a security issue. BUG() is appropriate.
> >
> > turning a bug into a remote DoS is also a security issue.
>
> Apparently in some cases we can loop and fill the syslog, or
> else Julius wouldnt have sent a patch.
>
> So the proper fix is to emit this message only once, and to find
> a way to alert the user security is compromised.
>
> So if BUG() isnt good, just use WARN_ON_ONCE()
>
> I feel that WARN_ON_ONCE() wont be clear enough to the user, especially
> if we recover from this by closing the tcp session, exactly as if we
> received a proper FIN.
Judging by the mangled traces we've seen, further reports after the initial
one aren't too useful anyway. Automated detectors like abrt should be
able to pick up these traces from the logs on the next reboot.
(Which would probably be better than it trying to file them immediately over
the network when the tcp layer is so confused)
sidenote: If the integrity of the tcp layer is in question, maybe some kind of
localised version of BUG() that just shuts down that subsystem might
be something worth persueing.
> Really if you object a BUG() here, I cant understand you didnt shout to
> other BUG() uses in the kernel.
When I see them, I call them. But I am just one person, and usage of that
macro is like a disease.
Dave
^ permalink raw reply
* Re: [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crashusers
From: Eric Dumazet @ 2012-11-07 17:05 UTC (permalink / raw)
To: Dave Jones
Cc: Julius Werner, linux-kernel, netdev, Patrick McHardy,
Hideaki YOSHIFUJI, James Morris, Alexey Kuznetsov,
David S. Miller, Sameer Nanda, Mandeep Singh Baines, Eric Dumazet
In-Reply-To: <20121107164358.GA20495@redhat.com>
On Wed, 2012-11-07 at 11:43 -0500, Dave Jones wrote:
> dude, look at the bug reports I just pointed you at.
> People _are_ aware there are bugs there.
>
If I remember well, I helped to fix some of them.
> If you turn that into a BUG() those reports would never have been filed.
> How is that increasing awareness ? People are going to see wedged computers,
> and hit the reset button. If we're lucky, we'll get photos of someone lucky
> enough to have hit it while at the console, not in X. But this is a huge
> step backwards for debugability.
>
> > I understand a distro maintainer has its own choices, but for upstream
> > kernel we want to have early reports.
>
> I'm running out of ways to word this, but I'll try again.
> You won't get those early reports if you turn this into a BUG().
>
> > This bug is fatal and a security issue. BUG() is appropriate.
>
> turning a bug into a remote DoS is also a security issue.
>
Apparently in some cases we can loop and fill the syslog, or
else Julius wouldnt have sent a patch.
So the proper fix is to emit this message only once, and to find
a way to alert the user security is compromised.
So if BUG() isnt good, just use WARN_ON_ONCE()
I feel that WARN_ON_ONCE() wont be clear enough to the user, especially
if we recover from this by closing the tcp session, exactly as if we
received a proper FIN.
Really if you object a BUG() here, I cant understand you didnt shout to
other BUG() uses in the kernel.
^ permalink raw reply
* Re: [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crashusers
From: Dave Jones @ 2012-11-07 16:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: Julius Werner, linux-kernel, netdev, Patrick McHardy,
Hideaki YOSHIFUJI, James Morris, Alexey Kuznetsov,
David S. Miller, Sameer Nanda, Mandeep Singh Baines, Eric Dumazet
In-Reply-To: <1352305752.3140.4449.camel@edumazet-glaptop>
On Wed, Nov 07, 2012 at 08:29:12AM -0800, Eric Dumazet wrote:
> On Wed, 2012-11-07 at 10:54 -0500, Dave Jones wrote:
>
> > It sounds more appropriate to me, instead of silently wedging the box.
> > At least with that approach we have a chance of finding out what happened.
>
> Its quite the opposite.
>
> If bug is still there 6 months after the commits that broke the drivers,
> (making an old bug visible) that means that people never realized the
> bug was there.
dude, look at the bug reports I just pointed you at.
People _are_ aware there are bugs there.
If you turn that into a BUG() those reports would never have been filed.
How is that increasing awareness ? People are going to see wedged computers,
and hit the reset button. If we're lucky, we'll get photos of someone lucky
enough to have hit it while at the console, not in X. But this is a huge
step backwards for debugability.
> I understand a distro maintainer has its own choices, but for upstream
> kernel we want to have early reports.
I'm running out of ways to word this, but I'll try again.
You won't get those early reports if you turn this into a BUG().
> This bug is fatal and a security issue. BUG() is appropriate.
turning a bug into a remote DoS is also a security issue.
Dave
^ permalink raw reply
* Re: [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crashusers
From: Eric Dumazet @ 2012-11-07 16:29 UTC (permalink / raw)
To: Dave Jones
Cc: Julius Werner, linux-kernel, netdev, Patrick McHardy,
Hideaki YOSHIFUJI, James Morris, Alexey Kuznetsov,
David S. Miller, Sameer Nanda, Mandeep Singh Baines, Eric Dumazet
In-Reply-To: <20121107155434.GA17677@redhat.com>
On Wed, 2012-11-07 at 10:54 -0500, Dave Jones wrote:
> It sounds more appropriate to me, instead of silently wedging the box.
> At least with that approach we have a chance of finding out what happened.
Its quite the opposite.
If bug is still there 6 months after the commits that broke the drivers,
(making an old bug visible) that means that people never realized the
bug was there.
I understand a distro maintainer has its own choices, but for upstream
kernel we want to have early reports.
This bug is fatal and a security issue. BUG() is appropriate.
If the driver cant be fixed, it should be marked broken.
So I personally NACKed patch to hide the bug, trying to be friendly to
the user.
^ permalink raw reply
* [PATCH net-next] phylib: mdio: Add sysfs attribute for PHY identifiers.
From: Nick Bowler @ 2012-11-07 16:20 UTC (permalink / raw)
To: netdev
This adds a phy_id sysfs attribute to MDIO devices, containing the
32-bit PHY identifier reported by the device. This attribute can
be useful when debugging problems related to phy drivers. Other
enumerable buses already have similar attributes.
Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
---
Documentation/ABI/testing/sysfs-bus-mdio | 9 +++++++++
drivers/net/phy/mdio_bus.c | 14 ++++++++++++++
2 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-mdio
diff --git a/Documentation/ABI/testing/sysfs-bus-mdio b/Documentation/ABI/testing/sysfs-bus-mdio
new file mode 100644
index 000000000000..6349749ebc29
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-mdio
@@ -0,0 +1,9 @@
+What: /sys/bus/mdio_bus/devices/.../phy_id
+Date: November 2012
+KernelVersion: 3.8
+Contact: netdev@vger.kernel.org
+Description:
+ This attribute contains the 32-bit PHY Identifier as reported
+ by the device during bus enumeration, encoded in hexadecimal.
+ This ID is used to match the device with the appropriate
+ driver.
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index c1ef3000ea60..044b5326459f 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -431,10 +431,24 @@ static struct dev_pm_ops mdio_bus_pm_ops = {
#endif /* CONFIG_PM */
+static ssize_t
+phy_id_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct phy_device *phydev = to_phy_device(dev);
+
+ return sprintf(buf, "0x%.8lx\n", (unsigned long)phydev->phy_id);
+}
+
+static struct device_attribute mdio_dev_attrs[] = {
+ __ATTR_RO(phy_id),
+ __ATTR_NULL
+};
+
struct bus_type mdio_bus_type = {
.name = "mdio_bus",
.match = mdio_bus_match,
.pm = MDIO_BUS_PM_OPS,
+ .dev_attrs = mdio_dev_attrs,
};
EXPORT_SYMBOL(mdio_bus_type);
--
1.7.8.6
^ permalink raw reply related
* Re: [PATCH net-next] mlx4: change TX coalescing defaults
From: Eric Dumazet @ 2012-11-07 16:05 UTC (permalink / raw)
To: Amir Vadai; +Cc: David Miller, netdev, Yevgeny Petrilin, Or Gerlitz, Vimalkumar
In-Reply-To: <CAPcc5Pj0ffeb8O8YW3SAS21=+ub8ypc34=YaAxTB-qh9DGeawQ@mail.gmail.com>
On Wed, 2012-11-07 at 17:30 +0200, Amir Vadai wrote:
> Acked.
>
> BTW, a mail will be sent - I'm replacing Yevgeny Petrilin as mlx4_en maintainer.
>
OK, thanks.
BTW proper way to Ack a patch so that its automatically taken into
account by tools is to use :
Acked-by: Amir Vadai <amirv@mellanox.com>
^ permalink raw reply
* Re: [PATCH] tcp: Replace infinite loop on recvmsg bug with proper crash
From: Dave Jones @ 2012-11-07 15:54 UTC (permalink / raw)
To: Julius Werner
Cc: linux-kernel, netdev, Patrick McHardy, Hideaki YOSHIFUJI,
James Morris, Alexey Kuznetsov, David S. Miller, Sameer Nanda,
Mandeep Singh Baines, Eric Dumazet
In-Reply-To: <CAODwPW-636Sn3B4CYajvrgccXxresZwPLg2UFz6xDDk9-FfTYQ@mail.gmail.com>
On Tue, Nov 06, 2012 at 05:51:19PM -0800, Julius Werner wrote:
> > We've had reports of this WARN against the Fedora kernel for a while.
> > Had this been immediately followed by a BUG(), we'd have never seen those traces at all,
> > and just got "my machine just locked up" reports instead.
> >
> > The proper fix here is to find out why we're getting into this state.
>
> Are you sure you don't mean the WARN below that ("recvmsg bug 2")
> instead? I don't think this one can happen without eventually running
> into the syslog overflow issue I described.
bug2 is more common (And usually is accompanied by mangled traces),
but we have reports of the first WARN too..
https://bugzilla.redhat.com/show_bug.cgi?id=841769
https://bugzilla.redhat.com/show_bug.cgi?id=845853
https://bugzilla.redhat.com/show_bug.cgi?id=846991
https://bugzilla.redhat.com/show_bug.cgi?id=860039
(I note that none of these reports mention "also, my hard disk is now full")
> I agree that the underlying cause must be fixed too, but as we will
> always have bugs in the kernel I think proper handling when it does
> happen is also important (and filling the hard disk with junk is
> obviously not the best approach). If you think a full panic is too
> extreme, I have an alternative version of this patch that logs the
> WARN once, closes the socket, and returns EBADFD from the syscall...
> would you think that is more appropriate?
It sounds more appropriate to me, instead of silently wedging the box.
At least with that approach we have a chance of finding out what happened.
Dave
^ permalink raw reply
* Re: [PATCH V4 0/7] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
From: Benoit Cousson @ 2012-11-07 15:45 UTC (permalink / raw)
To: Mugunthan V N
Cc: davem, Paul Walmsley, netdev, devicetree-discuss@lists.ozlabs.org,
linux-arm-kernel, linux-omap
In-Reply-To: <509A7D39.8050506@ti.com>
Hi Mugunthan,
On 11/07/2012 04:24 PM, Mugunthan V N wrote:
> On 11/6/2012 11:02 PM, Mugunthan V N wrote:
>> This patch-series adds support for,
>>
>> [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's
>>
>> [2/7]: Adds parent<->child relation between CPSW & MDIO module inside
>> cpsw
>> driver, as in case of AM33XX, the resources are shared and common
>> register bit-field is provided to control module/clock
>> enable/disable,
>> makes it difficult to handle common resource.
>>
>> So the solution here is, to create parent<->child relation
>> between them.
>>
>> [3/7]: Add hwmod entry for MDIO module, required for MDIO driver.
>>
>> [4/7]: cpsw: simplify the setup of the register pointers
>>
>> [5/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi,
>> am335x-evm.dts and am335x-bone.dts file
>>
>> [6/7]: Enable CPSW support to omap2plus_defconfig
>>
>> [7/7]: cpsw: Kernel warn fix during suspend
>>
>> This patch series has been created on top of net-next/master and tested
>> on BeagleBone platform for NFS boot and basic ping test cases.
>>
>> Changes from V3:
>> * Removed unnecessary flags in Davinci MDIO Hwmod entry.
>>
>> Mugunthan V N (4):
>> ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
>> arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
>> ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support
>> net: cpsw: halt network stack before halting the device during
>> suspend
>>
>> Richard Cochran (1):
>> cpsw: simplify the setup of the register pointers
>>
>> Vaibhav Hiremath (2):
>> net: davinci_mdio: Fix typo mistake in calling runtime-pm api
>> net: cpsw: Add parent<->child relation support between cpsw and mdio
>>
>> Documentation/devicetree/bindings/net/cpsw.txt | 34 ----
>> arch/arm/boot/dts/am335x-bone.dts | 8 +
>> arch/arm/boot/dts/am335x-evm.dts | 8 +
>> arch/arm/boot/dts/am33xx.dtsi | 42 +++++
>> arch/arm/configs/omap2plus_defconfig | 3 +
>> arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 31 ++++
>> drivers/net/ethernet/ti/cpsw.c | 231
>> ++++++++++--------------
>> drivers/net/ethernet/ti/davinci_mdio.c | 2 +-
>> include/linux/platform_data/cpsw.h | 19 --
>> 9 files changed, 192 insertions(+), 186 deletions(-)
>>
> Paul/Benoit
>
> Do you any comments
The DTS looks better thanks to Richard cleanup.
But you did not take into account the minor cosmetic comments I did last
time.
Could you just clean the DTS based on last time comments and change the
subject to be compliant with the other ones and I will take it in my
for_3.8/dts_part2 branch.
Thanks,
Benoit
^ permalink raw reply
* Re: [PATCH net-next] mlx4: change TX coalescing defaults
From: Amir Vadai @ 2012-11-07 15:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Yevgeny Petrilin, Or Gerlitz, Vimalkumar
In-Reply-To: <1352168442.3140.32.camel@edumazet-glaptop>
Acked.
BTW, a mail will be sent - I'm replacing Yevgeny Petrilin as mlx4_en maintainer.
(sorry for the previous non plain text mail)
Amir
On Tue, Nov 6, 2012 at 4:20 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> From: Eric Dumazet <edumazet@google.com>
>
> mlx4 currently uses a too high tx coalescing setting, deferring
> TX completion interrupts by up to 128 us.
>
> With the recent skb_orphan() removal in commit 8112ec3b872,
> performance of a single TCP flow is capped to ~4 Gbps, unless
> we increase tcp_limit_output_bytes.
>
> I suggest using 16 us instead of 128 us, allowing a finer control.
>
> Performance of a single TCP flow is restored to previous levels,
> while keeping TCP small queues fully enabled with default sysctl.
>
> This patch is also a BQL prereq.
>
> Reported-by: Vimalkumar <j.vimal@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Yevgeny Petrilin <yevgenyp@mellanox.com>
> Cc: Or Gerlitz <ogerlitz@mellanox.com>
> ---
> By the way, is BQL addition planned for this driver ?
>
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index edd9cb8..2b23ca2 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -870,7 +870,7 @@ static void mlx4_en_set_default_moderation(struct
> mlx4_en_priv *priv)
> /* If we haven't received a specific coalescing setting
> * (module param), we set the moderation parameters as follows:
> * - moder_cnt is set to the number of mtu sized packets to
> - * satisfy our coelsing target.
> + * satisfy our coalescing target.
> * - moder_time is set to a fixed value.
> */
> priv->rx_frames = MLX4_EN_RX_COAL_TARGET;
> diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> index 9d27e42..8a5e70d 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> +++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> @@ -126,7 +126,7 @@ enum {
> #define MLX4_EN_RX_COAL_TIME 0x10
>
> #define MLX4_EN_TX_COAL_PKTS 16
> -#define MLX4_EN_TX_COAL_TIME 0x80
> +#define MLX4_EN_TX_COAL_TIME 0x10
>
> #define MLX4_EN_RX_RATE_LOW 400000
> #define MLX4_EN_RX_COAL_TIME_LOW 0
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4 0/7] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
From: Mugunthan V N @ 2012-11-07 15:24 UTC (permalink / raw)
To: b-cousson, davem, Paul Walmsley
Cc: netdev, devicetree-discuss@lists.ozlabs.org, linux-arm-kernel,
linux-omap
In-Reply-To: <1352223159-27504-1-git-send-email-mugunthanvnm@ti.com>
On 11/6/2012 11:02 PM, Mugunthan V N wrote:
> This patch-series adds support for,
>
> [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's
>
> [2/7]: Adds parent<->child relation between CPSW & MDIO module inside cpsw
> driver, as in case of AM33XX, the resources are shared and common
> register bit-field is provided to control module/clock enable/disable,
> makes it difficult to handle common resource.
>
> So the solution here is, to create parent<->child relation between them.
>
> [3/7]: Add hwmod entry for MDIO module, required for MDIO driver.
>
> [4/7]: cpsw: simplify the setup of the register pointers
>
> [5/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi,
> am335x-evm.dts and am335x-bone.dts file
>
> [6/7]: Enable CPSW support to omap2plus_defconfig
>
> [7/7]: cpsw: Kernel warn fix during suspend
>
> This patch series has been created on top of net-next/master and tested
> on BeagleBone platform for NFS boot and basic ping test cases.
>
> Changes from V3:
> * Removed unnecessary flags in Davinci MDIO Hwmod entry.
>
> Mugunthan V N (4):
> ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
> arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
> ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support
> net: cpsw: halt network stack before halting the device during
> suspend
>
> Richard Cochran (1):
> cpsw: simplify the setup of the register pointers
>
> Vaibhav Hiremath (2):
> net: davinci_mdio: Fix typo mistake in calling runtime-pm api
> net: cpsw: Add parent<->child relation support between cpsw and mdio
>
> Documentation/devicetree/bindings/net/cpsw.txt | 34 ----
> arch/arm/boot/dts/am335x-bone.dts | 8 +
> arch/arm/boot/dts/am335x-evm.dts | 8 +
> arch/arm/boot/dts/am33xx.dtsi | 42 +++++
> arch/arm/configs/omap2plus_defconfig | 3 +
> arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 31 ++++
> drivers/net/ethernet/ti/cpsw.c | 231 ++++++++++--------------
> drivers/net/ethernet/ti/davinci_mdio.c | 2 +-
> include/linux/platform_data/cpsw.h | 19 --
> 9 files changed, 192 insertions(+), 186 deletions(-)
>
Paul/Benoit
Do you any comments
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH 1/1] isdn: Make CONFIG_ISDN depend on CONFIG_NETDEVICES
From: Alan Cox @ 2012-11-07 15:04 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-kernel, davem, Karsten Keil, netdev
In-Reply-To: <1352282103-13665-1-git-send-email-lee.jones@linaro.org>
On Wed, 7 Nov 2012 10:55:03 +0100
Lee Jones <lee.jones@linaro.org> wrote:
> It doesn't make much sense to enable ISDN services if you don't
> intend to connect to a network.
I would disagree. However what I don't understand and you've not
explained is why the current code is a bug or a problem ?
This seems to be a make-work inconvenience causing patch that serves no
useful purpose ?
Alan
^ permalink raw reply
* [PATCH trivial] ndisc: fix a typo in a comment in ndisc_recv_na()
From: Nicolas Dichtel @ 2012-11-07 15:05 UTC (permalink / raw)
To: netdev; +Cc: davem, Nicolas Dichtel
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/ndisc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index ae0cf81..a2e50dc 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -906,7 +906,7 @@ static void ndisc_recv_na(struct sk_buff *skb)
if (lladdr && !memcmp(lladdr, dev->dev_addr, dev->addr_len) &&
net->ipv6.devconf_all->forwarding && net->ipv6.devconf_all->proxy_ndp &&
pneigh_lookup(&nd_tbl, net, &msg->target, dev, 0)) {
- /* XXX: idev->cnf.prixy_ndp */
+ /* XXX: idev->cnf.proxy_ndp */
goto out;
}
--
1.7.12
^ permalink raw reply related
* [PATCH net] cxgb4: Fix initialization of SGE_CONTROL register
From: Vipul Pandya @ 2012-11-07 13:45 UTC (permalink / raw)
To: netdev; +Cc: davem, divy, dm, Vipul Pandya, Jay Hernandez
INGPADBOUNDARY_MASK is already shifted. No need to shift it again. On reloading
a driver it was resulting in a bad SGE FL MTU sizes [1536, 9088] error. This
only causes an issue on systems that have L1 cache size of 32B, 128B, 512B,
2048B or 4096B.
Signed-off-by: Jay Hernandez <jay@chelsio.com>
Signed-off-by: Vipul Pandya <vipul@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 01fa5b7..730ae2c 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -2831,7 +2831,7 @@ int t4_fixup_host_params(struct adapter *adap, unsigned int page_size,
HOSTPAGESIZEPF7(sge_hps));
t4_set_reg_field(adap, SGE_CONTROL,
- INGPADBOUNDARY(INGPADBOUNDARY_MASK) |
+ INGPADBOUNDARY_MASK |
EGRSTATUSPAGESIZE_MASK,
INGPADBOUNDARY(fl_align_log - 5) |
EGRSTATUSPAGESIZE(stat_len != 64));
--
1.7.1
^ permalink raw reply related
* [PATCH -next] ksz884x: use module_pci_driver to simplify the code
From: Wei Yongjun @ 2012-11-07 12:54 UTC (permalink / raw)
To: davem; +Cc: yongjun_wei, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Use the module_pci_driver() macro to make the code simpler
by eliminating module_init and module_exit calls.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/ethernet/micrel/ksz884x.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ksz884x.c b/drivers/net/ethernet/micrel/ksz884x.c
index e558edd..e4ba868 100644
--- a/drivers/net/ethernet/micrel/ksz884x.c
+++ b/drivers/net/ethernet/micrel/ksz884x.c
@@ -7251,18 +7251,7 @@ static struct pci_driver pci_device_driver = {
.remove = pcidev_exit
};
-static int __init ksz884x_init_module(void)
-{
- return pci_register_driver(&pci_device_driver);
-}
-
-static void __exit ksz884x_cleanup_module(void)
-{
- pci_unregister_driver(&pci_device_driver);
-}
-
-module_init(ksz884x_init_module);
-module_exit(ksz884x_cleanup_module);
+module_pci_driver(pci_device_driver);
MODULE_DESCRIPTION("KSZ8841/2 PCI network driver");
MODULE_AUTHOR("Tristram Ha <Tristram.Ha@micrel.com>");
^ permalink raw reply related
* [PATCH -next] tcm_vhost: remove unused variable in vhost_scsi_allocate_cmd()
From: Wei Yongjun @ 2012-11-07 12:53 UTC (permalink / raw)
To: mst; +Cc: netdev, yongjun_wei, kvm, virtualization
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
The variable se_sess is initialized but never used
otherwise, so remove the unused variable.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/vhost/tcm_vhost.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
index 23c138f..551fff0 100644
--- a/drivers/vhost/tcm_vhost.c
+++ b/drivers/vhost/tcm_vhost.c
@@ -415,14 +415,12 @@ static struct tcm_vhost_cmd *vhost_scsi_allocate_cmd(
{
struct tcm_vhost_cmd *tv_cmd;
struct tcm_vhost_nexus *tv_nexus;
- struct se_session *se_sess;
tv_nexus = tv_tpg->tpg_nexus;
if (!tv_nexus) {
pr_err("Unable to locate active struct tcm_vhost_nexus\n");
return ERR_PTR(-EIO);
}
- se_sess = tv_nexus->tvn_se_sess;
tv_cmd = kzalloc(sizeof(struct tcm_vhost_cmd), GFP_ATOMIC);
if (!tv_cmd) {
^ permalink raw reply related
* [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
From: David Woodhouse @ 2012-11-07 12:52 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: netdev, linux-kernel, Chas Williams - CONTRACTOR, davem
In-Reply-To: <1352240222-363-1-git-send-email-krzysiek@podlesie.net>
[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]
Now that we can return zero from pppoatm_send() for reasons *other* than
the queue being full, that means we can't depend on a subsequent call to
pppoatm_pop() waking the queue, and we might leave it stalled
indefinitely.
Fix this by immediately scheduling the wakeup tasklet. As documented
already elsewhere, the PPP channel's ->downl lock protects against the
wakeup happening too soon and effectively being missed.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
----
Untested.
With this sorted, Acked-By: David Woodhouse <David.Woodhouse@intel.com<
to the other seven. Thanks.
diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
index 7507c20..56ad541 100644
--- a/net/atm/pppoatm.c
+++ b/net/atm/pppoatm.c
@@ -283,11 +283,11 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
vcc = ATM_SKB(skb)->vcc;
bh_lock_sock(sk_atm(vcc));
if (sock_owned_by_user(sk_atm(vcc)))
- goto nospace;
+ goto nospace_sched_wakeup;
if (test_bit(ATM_VF_RELEASED, &vcc->flags)
- || test_bit(ATM_VF_CLOSE, &vcc->flags)
- || !test_bit(ATM_VF_READY, &vcc->flags))
- goto nospace;
+ || test_bit(ATM_VF_CLOSE, &vcc->flags)
+ || !test_bit(ATM_VF_READY, &vcc->flags))
+ goto nospace_sched_wakeup;
switch (pvcc->encaps) { /* LLC encapsulation needed */
case e_llc:
@@ -328,7 +328,17 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
? DROP_PACKET : 1;
bh_unlock_sock(sk_atm(vcc));
return ret;
-nospace:
+ nospace_sched_wakeup:
+ /* If we're returning zero for reasons *other* than the queue
+ * being full, then we need to ensure that a wakeup will
+ * happen and not just leave the channel stalled for ever.
+ * Just schedule the wakeup tasklet directly. As observed in
+ * pppoatm_pop(), it'll take the channel's ->downl lock which
+ * is also held by our caller, so it can't happen "too soon"
+ * and cause us to effectively miss a wakeup.
+ */
+ tasklet_schedule(&pvcc->wakeup_tasklet);
+ nospace:
bh_unlock_sock(sk_atm(vcc));
/*
* We don't have space to send this SKB now, but we might have
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply related
* [PATCH 4/4] Make the wanxl firmware array const
From: David Howells @ 2012-11-07 12:37 UTC (permalink / raw)
To: khc; +Cc: netdev, linux
In-Reply-To: <20121107123709.4147.98018.stgit@warthog.procyon.org.uk>
Make the wanxl firmware array const so that it goes in the read-only section.
Signed-off-by: David Howells <dhowells@redhat.com>
---
drivers/net/wan/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/Makefile b/drivers/net/wan/Makefile
index b0a6163..df70248 100644
--- a/drivers/net/wan/Makefile
+++ b/drivers/net/wan/Makefile
@@ -54,7 +54,7 @@ quiet_cmd_build_wanxlfw = BLD FW $@
cmd_build_wanxlfw = \
$(CPP) -D__ASSEMBLY__ -Wp,-MD,$(depfile) -I$(srctree)/include/uapi $< | $(AS68K) -m68360 -o $(obj)/wanxlfw.o; \
$(LD68K) --oformat binary -Ttext 0x1000 $(obj)/wanxlfw.o -o $(obj)/wanxlfw.bin; \
- hexdump -ve '"\n" 16/1 "0x%02X,"' $(obj)/wanxlfw.bin | sed 's/0x ,//g;1s/^/static u8 firmware[]={/;$$s/,$$/\n};\n/' >$(obj)/wanxlfw.inc; \
+ hexdump -ve '"\n" 16/1 "0x%02X,"' $(obj)/wanxlfw.bin | sed 's/0x ,//g;1s/^/static const u8 firmware[]={/;$$s/,$$/\n};\n/' >$(obj)/wanxlfw.inc; \
rm -f $(obj)/wanxlfw.bin $(obj)/wanxlfw.o
$(obj)/wanxlfw.inc: $(src)/wanxlfw.S
^ permalink raw reply related
* [PATCH 3/4] Fix the wanxl firmware to include missing constants
From: David Howells @ 2012-11-07 12:37 UTC (permalink / raw)
To: khc; +Cc: netdev, linux
In-Reply-To: <20121107123709.4147.98018.stgit@warthog.procyon.org.uk>
Fix the wanxl firmware to include missing constants such as PARITY_NONE. It
should be #including the linux/hdlc/ioctl.h header.
To make this work, we also have to guard parts of ioctl.h with !__ASSEMBLY__.
Signed-off-by: David Howells <dhowells@redhat.com>
---
drivers/net/wan/Makefile | 2 +-
drivers/net/wan/wanxlfw.S | 1 +
include/uapi/linux/hdlc/ioctl.h | 3 +++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wan/Makefile b/drivers/net/wan/Makefile
index 4dac96b..b0a6163 100644
--- a/drivers/net/wan/Makefile
+++ b/drivers/net/wan/Makefile
@@ -52,7 +52,7 @@ endif
quiet_cmd_build_wanxlfw = BLD FW $@
cmd_build_wanxlfw = \
- $(CPP) -Wp,-MD,$(depfile) -I$(srctree)/include/uapi $< | $(AS68K) -m68360 -o $(obj)/wanxlfw.o; \
+ $(CPP) -D__ASSEMBLY__ -Wp,-MD,$(depfile) -I$(srctree)/include/uapi $< | $(AS68K) -m68360 -o $(obj)/wanxlfw.o; \
$(LD68K) --oformat binary -Ttext 0x1000 $(obj)/wanxlfw.o -o $(obj)/wanxlfw.bin; \
hexdump -ve '"\n" 16/1 "0x%02X,"' $(obj)/wanxlfw.bin | sed 's/0x ,//g;1s/^/static u8 firmware[]={/;$$s/,$$/\n};\n/' >$(obj)/wanxlfw.inc; \
rm -f $(obj)/wanxlfw.bin $(obj)/wanxlfw.o
diff --git a/drivers/net/wan/wanxlfw.S b/drivers/net/wan/wanxlfw.S
index 73aae2b..21565d5 100644
--- a/drivers/net/wan/wanxlfw.S
+++ b/drivers/net/wan/wanxlfw.S
@@ -35,6 +35,7 @@
*/
#include <linux/hdlc.h>
+#include <linux/hdlc/ioctl.h>
#include "wanxl.h"
/* memory addresses and offsets */
diff --git a/include/uapi/linux/hdlc/ioctl.h b/include/uapi/linux/hdlc/ioctl.h
index 5839723..e5dbbb0 100644
--- a/include/uapi/linux/hdlc/ioctl.h
+++ b/include/uapi/linux/hdlc/ioctl.h
@@ -34,6 +34,8 @@
#define LMI_CCITT 3 /* ITU-T Annex A */
#define LMI_CISCO 4 /* The "original" LMI, aka Gang of Four */
+#ifndef __ASSEMBLY__
+
typedef struct {
unsigned int clock_rate; /* bits per second */
unsigned int clock_type; /* internal, external, TX-internal etc. */
@@ -78,4 +80,5 @@ typedef struct {
/* PPP doesn't need any info now - supply length = 0 to ioctl */
+#endif /* __ASSEMBLY__ */
#endif /* __HDLC_IOCTL_H__ */
^ permalink raw reply related
* [PATCH 2/4] UAPI: (Scripted) Disintegrate include/linux/hdlc
From: David Howells @ 2012-11-07 12:37 UTC (permalink / raw)
To: khc; +Cc: netdev, linux
In-Reply-To: <20121107123709.4147.98018.stgit@warthog.procyon.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Michael Kerrisk <mtk.manpages@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Dave Jones <davej@redhat.com>
Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
---
include/linux/hdlc/Kbuild | 1
include/linux/hdlc/ioctl.h | 81 ---------------------------------------
include/uapi/linux/hdlc/Kbuild | 1
include/uapi/linux/hdlc/ioctl.h | 81 +++++++++++++++++++++++++++++++++++++++
4 files changed, 82 insertions(+), 82 deletions(-)
delete mode 100644 include/linux/hdlc/ioctl.h
create mode 100644 include/uapi/linux/hdlc/ioctl.h
diff --git a/include/linux/hdlc/Kbuild b/include/linux/hdlc/Kbuild
index 1fb2644..e69de29 100644
--- a/include/linux/hdlc/Kbuild
+++ b/include/linux/hdlc/Kbuild
@@ -1 +0,0 @@
-header-y += ioctl.h
diff --git a/include/linux/hdlc/ioctl.h b/include/linux/hdlc/ioctl.h
deleted file mode 100644
index 5839723..0000000
--- a/include/linux/hdlc/ioctl.h
+++ /dev/null
@@ -1,81 +0,0 @@
-#ifndef __HDLC_IOCTL_H__
-#define __HDLC_IOCTL_H__
-
-
-#define GENERIC_HDLC_VERSION 4 /* For synchronization with sethdlc utility */
-
-#define CLOCK_DEFAULT 0 /* Default setting */
-#define CLOCK_EXT 1 /* External TX and RX clock - DTE */
-#define CLOCK_INT 2 /* Internal TX and RX clock - DCE */
-#define CLOCK_TXINT 3 /* Internal TX and external RX clock */
-#define CLOCK_TXFROMRX 4 /* TX clock derived from external RX clock */
-
-
-#define ENCODING_DEFAULT 0 /* Default setting */
-#define ENCODING_NRZ 1
-#define ENCODING_NRZI 2
-#define ENCODING_FM_MARK 3
-#define ENCODING_FM_SPACE 4
-#define ENCODING_MANCHESTER 5
-
-
-#define PARITY_DEFAULT 0 /* Default setting */
-#define PARITY_NONE 1 /* No parity */
-#define PARITY_CRC16_PR0 2 /* CRC16, initial value 0x0000 */
-#define PARITY_CRC16_PR1 3 /* CRC16, initial value 0xFFFF */
-#define PARITY_CRC16_PR0_CCITT 4 /* CRC16, initial 0x0000, ITU-T version */
-#define PARITY_CRC16_PR1_CCITT 5 /* CRC16, initial 0xFFFF, ITU-T version */
-#define PARITY_CRC32_PR0_CCITT 6 /* CRC32, initial value 0x00000000 */
-#define PARITY_CRC32_PR1_CCITT 7 /* CRC32, initial value 0xFFFFFFFF */
-
-#define LMI_DEFAULT 0 /* Default setting */
-#define LMI_NONE 1 /* No LMI, all PVCs are static */
-#define LMI_ANSI 2 /* ANSI Annex D */
-#define LMI_CCITT 3 /* ITU-T Annex A */
-#define LMI_CISCO 4 /* The "original" LMI, aka Gang of Four */
-
-typedef struct {
- unsigned int clock_rate; /* bits per second */
- unsigned int clock_type; /* internal, external, TX-internal etc. */
- unsigned short loopback;
-} sync_serial_settings; /* V.35, V.24, X.21 */
-
-typedef struct {
- unsigned int clock_rate; /* bits per second */
- unsigned int clock_type; /* internal, external, TX-internal etc. */
- unsigned short loopback;
- unsigned int slot_map;
-} te1_settings; /* T1, E1 */
-
-typedef struct {
- unsigned short encoding;
- unsigned short parity;
-} raw_hdlc_proto;
-
-typedef struct {
- unsigned int t391;
- unsigned int t392;
- unsigned int n391;
- unsigned int n392;
- unsigned int n393;
- unsigned short lmi;
- unsigned short dce; /* 1 for DCE (network side) operation */
-} fr_proto;
-
-typedef struct {
- unsigned int dlci;
-} fr_proto_pvc; /* for creating/deleting FR PVCs */
-
-typedef struct {
- unsigned int dlci;
- char master[IFNAMSIZ]; /* Name of master FRAD device */
-}fr_proto_pvc_info; /* for returning PVC information only */
-
-typedef struct {
- unsigned int interval;
- unsigned int timeout;
-} cisco_proto;
-
-/* PPP doesn't need any info now - supply length = 0 to ioctl */
-
-#endif /* __HDLC_IOCTL_H__ */
diff --git a/include/uapi/linux/hdlc/Kbuild b/include/uapi/linux/hdlc/Kbuild
index aafaa5a..8c1d2cb 100644
--- a/include/uapi/linux/hdlc/Kbuild
+++ b/include/uapi/linux/hdlc/Kbuild
@@ -1 +1,2 @@
# UAPI Header export list
+header-y += ioctl.h
diff --git a/include/uapi/linux/hdlc/ioctl.h b/include/uapi/linux/hdlc/ioctl.h
new file mode 100644
index 0000000..5839723
--- /dev/null
+++ b/include/uapi/linux/hdlc/ioctl.h
@@ -0,0 +1,81 @@
+#ifndef __HDLC_IOCTL_H__
+#define __HDLC_IOCTL_H__
+
+
+#define GENERIC_HDLC_VERSION 4 /* For synchronization with sethdlc utility */
+
+#define CLOCK_DEFAULT 0 /* Default setting */
+#define CLOCK_EXT 1 /* External TX and RX clock - DTE */
+#define CLOCK_INT 2 /* Internal TX and RX clock - DCE */
+#define CLOCK_TXINT 3 /* Internal TX and external RX clock */
+#define CLOCK_TXFROMRX 4 /* TX clock derived from external RX clock */
+
+
+#define ENCODING_DEFAULT 0 /* Default setting */
+#define ENCODING_NRZ 1
+#define ENCODING_NRZI 2
+#define ENCODING_FM_MARK 3
+#define ENCODING_FM_SPACE 4
+#define ENCODING_MANCHESTER 5
+
+
+#define PARITY_DEFAULT 0 /* Default setting */
+#define PARITY_NONE 1 /* No parity */
+#define PARITY_CRC16_PR0 2 /* CRC16, initial value 0x0000 */
+#define PARITY_CRC16_PR1 3 /* CRC16, initial value 0xFFFF */
+#define PARITY_CRC16_PR0_CCITT 4 /* CRC16, initial 0x0000, ITU-T version */
+#define PARITY_CRC16_PR1_CCITT 5 /* CRC16, initial 0xFFFF, ITU-T version */
+#define PARITY_CRC32_PR0_CCITT 6 /* CRC32, initial value 0x00000000 */
+#define PARITY_CRC32_PR1_CCITT 7 /* CRC32, initial value 0xFFFFFFFF */
+
+#define LMI_DEFAULT 0 /* Default setting */
+#define LMI_NONE 1 /* No LMI, all PVCs are static */
+#define LMI_ANSI 2 /* ANSI Annex D */
+#define LMI_CCITT 3 /* ITU-T Annex A */
+#define LMI_CISCO 4 /* The "original" LMI, aka Gang of Four */
+
+typedef struct {
+ unsigned int clock_rate; /* bits per second */
+ unsigned int clock_type; /* internal, external, TX-internal etc. */
+ unsigned short loopback;
+} sync_serial_settings; /* V.35, V.24, X.21 */
+
+typedef struct {
+ unsigned int clock_rate; /* bits per second */
+ unsigned int clock_type; /* internal, external, TX-internal etc. */
+ unsigned short loopback;
+ unsigned int slot_map;
+} te1_settings; /* T1, E1 */
+
+typedef struct {
+ unsigned short encoding;
+ unsigned short parity;
+} raw_hdlc_proto;
+
+typedef struct {
+ unsigned int t391;
+ unsigned int t392;
+ unsigned int n391;
+ unsigned int n392;
+ unsigned int n393;
+ unsigned short lmi;
+ unsigned short dce; /* 1 for DCE (network side) operation */
+} fr_proto;
+
+typedef struct {
+ unsigned int dlci;
+} fr_proto_pvc; /* for creating/deleting FR PVCs */
+
+typedef struct {
+ unsigned int dlci;
+ char master[IFNAMSIZ]; /* Name of master FRAD device */
+}fr_proto_pvc_info; /* for returning PVC information only */
+
+typedef struct {
+ unsigned int interval;
+ unsigned int timeout;
+} cisco_proto;
+
+/* PPP doesn't need any info now - supply length = 0 to ioctl */
+
+#endif /* __HDLC_IOCTL_H__ */
^ permalink raw reply related
* [PATCH 1/4] UAPI: Fix compilation of the wanxl firmware blob.
From: David Howells @ 2012-11-07 12:37 UTC (permalink / raw)
To: khc; +Cc: netdev, linux
The wanxl firmware needs access to some bits of UAPI stuff, so the -I flag in
the Makefile needs adjusting to point at the UAPI headers.
Signed-off-by: David Howells <dhowells@redhat.com>
---
drivers/net/wan/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/Makefile b/drivers/net/wan/Makefile
index eac709b..4dac96b 100644
--- a/drivers/net/wan/Makefile
+++ b/drivers/net/wan/Makefile
@@ -52,7 +52,7 @@ endif
quiet_cmd_build_wanxlfw = BLD FW $@
cmd_build_wanxlfw = \
- $(CPP) -Wp,-MD,$(depfile) -I$(srctree)/include $< | $(AS68K) -m68360 -o $(obj)/wanxlfw.o; \
+ $(CPP) -Wp,-MD,$(depfile) -I$(srctree)/include/uapi $< | $(AS68K) -m68360 -o $(obj)/wanxlfw.o; \
$(LD68K) --oformat binary -Ttext 0x1000 $(obj)/wanxlfw.o -o $(obj)/wanxlfw.bin; \
hexdump -ve '"\n" 16/1 "0x%02X,"' $(obj)/wanxlfw.bin | sed 's/0x ,//g;1s/^/static u8 firmware[]={/;$$s/,$$/\n};\n/' >$(obj)/wanxlfw.inc; \
rm -f $(obj)/wanxlfw.bin $(obj)/wanxlfw.o
^ permalink raw reply related
* Optics (SFP) monitoring on ixgbe and igbe
From: Aurélien @ 2012-11-07 12:27 UTC (permalink / raw)
To: netdev
Hello,
I'm looking to propose a patch for optics monitoring on igbe and ixgbe
cards which support SFP and SFP+. I have one of each card. While
searching for previous work done by others on this domain, i found the
following:
https://github.com/jelaas/bifrost-build-x86_64/tree/master/all/kernel-x86_64-3.3.0-rc2-1
(the DOM-* files)
I did not yet test this patch (i'll do in a few days), but just by
looking at the patches, do you think this could get incorporated in
the current state, provided some administrative work is done, or would
it require more architectural rework / documentation / other ?
Could you point me to the next steps required for the functionality to
be merged in a future mainline kernel/ethtool ? Is there a better
place than netdev@ to discuss this matter ?
Thanks,
--
Aurélien Guillaume
^ permalink raw reply
* Re: [PATCH 02/10] arm: at91: move platfarm_data to include/linux/platform_data/atmel.h
From: Marc Kleine-Budde @ 2012-11-07 12:20 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-arm-kernel, Nicolas Ferre, linux-ide, linux-input,
linux-mmc, linux-can, netdev, linux-pcmcia, rtc-linux,
spi-devel-general, linux-serial, linux-usb, linux-fbdev
In-Reply-To: <1352287374-25176-2-git-send-email-plagnioj@jcrosoft.com>
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
On 11/07/2012 12:22 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: linux-ide@vger.kernel.org
> Cc: linux-input@vger.kernel.org
> Cc: linux-mmc@vger.kernel.org
> Cc: linux-can@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: linux-pcmcia@lists.infradead.org
> Cc: rtc-linux@googlegroups.com
> Cc: spi-devel-general@lists.sourceforge.net
> Cc: linux-serial@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Cc: linux-fbdev@vger.kernel.org
> ---
> HI all,
>
> If it's ok with everyone this will go via at91
> with the patch serie than clean up the include/mach
Fine with me.
> For preparation to switch to arm multiarch kernel
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> (for the CAN related changes)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox