- 09 Apr, 2013 17 commits
-
-
Nithin Sujir authored
When LFA is enabled, we don't reset the phy. But EEE settings changes don't take effect until the phy is reset. Add a phy reset when we detect a changed EEE setting. Signed-off-by:
Nithin Nayak Sujir <nsujir@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Nithin Sujir authored
Normally on driver load, we set the default settings for speed and flow control. However, if the default setting is not compatible with the current link state, we would autonegotiate and cause a link flap. To avoid this, we pull the current advertised settings into the config. A second scenario is if a user changes the speed/duplex/fc settings when the interface is down. In this case we must not pull the settings from the phy and overwrite user settings. We avoid that by checking the USER_CONFIGURED flag. Signed-off-by:
-
Nithin Sujir authored
This patch and the following two patches add support for link flap avoidance by maintaining the link on power down. This feature is required for management capable devices to have the management connection uninterrupted on driver reload, reboot and interface up/down. The other pros of this feature are - It speeds up boot up time by several seconds as DHCP addresses can be acquired faster. - It avoids lengthy Spanning Tree delay. On powerup the hardware brings up the phy with default settings. If the link is not up, the management software configures the phy to gigabit and starts autonegotiate. Subsequently, as long as the link is up, the driver and management refrain from resetting and/or changing any configuration that the link depends on. The LNK_FLAP_AVOID setting is an NVRAM user configurable bit and is disabled by default. If this setting is enabled, we skip powering down the phy and resetting it. A second NVRAM setting is 1G_ON_VAUX_OK (off by default). This adds support for gigabit link speed when device is on auxiliary power. Signed-off-by:
-
Michael Chan authored
Signed-off-by:
-
Michael Chan authored
Refactor for use in the next patch that adds sgmii phy support. Signed-off-by:
-
Nithin Sujir authored
When the user executes certain ethtool commands such as -s, -A, -G, -L, -r a phy reset or autonegotiate is performed which results in management traffic being interrupted. Add a warning in these cases. Signed-off-by:
-
Nithin Sujir authored
The current code unnecessarily resets the phy when we use ethtool to change the ring parameters or flow control settings. Remove the phy reset. Signed-off-by:
-
Michael Chan authored
The STM45PE20 pinstrap on 5762 devices supports multiple sizes. So treat it just like the ST45_USPT and the size will be read from 0xf0 via tg3_get_nvram_size(). Signed-off-by:
-
Nithin Sujir authored
In tg3_setup_copper_phy(), if autonegotiation is disabled, we need to relink only if the speed or duplex does not match the configured setting. If flow control does not match, a relink is not necessary as flow control is not a PHY setting. Later on, we'll call tg3_setup_flow_ctrl() to set up the MAC to the desired flow control settings if we're in full duplex mode. Signed-off-by:
-
Daniel Borkmann authored
This patch introduces an UAPI header for the SCTP protocol, so that we can facilitate the maintenance and development of user land applications or libraries, in particular in terms of header synchronization. To not break compatibility, some fragments from lksctp-tools' netinet/sctp.h have been carefully included, while taking care that neither kernel nor user land breaks, so both compile fine with this change (for lksctp-tools I tested with the old netinet/sctp.h header and with a newly adapted one that includes the uapi sctp header). lksctp-tools smoke test run through successfully as well in both cases. Suggested-by:
Neil Horman <nhorman@tuxdriver.com> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
Wei Yongjun authored
module_spi_driver() makes the code simpler by eliminating boilerplate code. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Zefan Li authored
The callers always pass current to sock_update_netprio(). Signed-off-by:
Li Zefan <lizefan@huawei.com> Acked-by:
-
Zefan Li authored
The callers always pass current to sock_update_classid(). Signed-off-by:
-
Zefan Li authored
We read the value but make no use of it. Signed-off-by:
-
Daniel Borkmann authored
Instead of invalidating all IPv6 addresses with global scope when one decides to use IPv6 tokens, we should only invalidate previous tokens and leave the rest intact until they expire eventually (or are intact forever). For doing this less greedy approach, we're adding a bool at the end of inet6_ifaddr structure instead, for two reasons: i) per-inet6_ifaddr flag space is already used up, making it wider might not be a good idea, since ii) also we do not necessarily need to export this information into user space. Suggested-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Daniel Borkmann authored
When we set the iftoken in inet6_set_iftoken(), we return -EINVAL when the device does not have flag IF_READY. This is however not necessary and rather an artificial usability barrier, since we simply can set the token despite that, and in case the device is ready, we just send out our rs, otherwise ifup et al. will do this for us anyway. Suggested-by:
-
Daniel Borkmann authored
Since we check for !ipv6_addr_any(&in6_dev->token) in addrconf_prefix_rcv(), make the token initialization on device setup more intuitive by using in6addr_any as an initializer. Suggested-by:
-
- 08 Apr, 2013 23 commits
-
-
Bjørn Mork authored
Receiving unhandled notifications is most certainly not an error and should not be logged as one. Knowing that the device sends notifications we don't handle is useful for developers, but there is very little a user can do about this. The message is therefore just annoying noise to most users with devices sending unhandled notifications like e.g. USB_CDC_NOTIFY_RESPONSE_AVAILABLE Cc: Alexey Orishko <alexey.orishko@stericsson.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Rami Rosen authored
This patch adds a new file, Documentation/cgroups/net_cls.txt, with info about net_cls cgroups, and updates the 00-INDEX accordingly. Signed-off-by:
Rami Rosen <ramirose@gmail.com> Signed-off-by:
-
Daniel Borkmann authored
This patch adds support for IPv6 tokenized IIDs, that allow for administrators to assign well-known host-part addresses to nodes whilst still obtaining global network prefix from Router Advertisements. It is currently in draft status. The primary target for such support is server platforms where addresses are usually manually configured, rather than using DHCPv6 or SLAAC. By using tokenised identifiers, hosts can still determine their network prefix by use of SLAAC, but more readily be automatically renumbered should their network prefix change. [...] The disadvantage with static addresses is that they are likely to require manual editing should the network prefix in use change. If instead there were a method to only manually configure the static identifier part of the IPv6 address, then the address could be automatically updated when a new prefix was introduced, as described in [RFC4192] for example. In such cases a DNS server might be configured with such a tokenised interface identifier of ::53, and SLAAC would use the token in constructing the interface address, using the advertised prefix. [...] http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02 The implementation is partially based on top of Mark K. Thompson's proof of concept. However, it uses the Netlink interface for configuration resp. data retrival, so that it can be easily extended in future. Successfully tested by myself. Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Cc: Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Giuseppe CAVALLARO authored
This patch is to prefetch, in the stmmac_rx, the whole dma_erx descriptor in case of using the extended descriptors. Signed-off-by:
Giuseppe Cavallaro <peppe.cavallaro@st.com> Signed-off-by:
-
Giuseppe CAVALLARO authored
recently many new supports have been added in the stmmac driver w/o taking care about where each new field had to be placed inside the private structure for guaranteeing the best cache usage. This is what I wanted in the beginning, so this patch reorganizes all the fields in order to keep adjacent fields for cache effect. I have also tried to optimize them by using pahole. V2: do not abuse with ____cacheline_aligned_in_smp and keep fields that potentially could stay in the same cache-line for better usage in SMP systems. Signed-off-by:
-
Giuseppe CAVALLARO authored
This patch tidies up the code. I have run Linden (and verified with checkpatch) many part of the driver trying to reorganize some sections respecting the codying-style rules in the points where it was not done. Signed-off-by:
-
Giuseppe CAVALLARO authored
this patch reviews/improves and adds some fixes in the code doc. Also kernel-doc passes w/o any warnings. Signed-off-by:
-
Giuseppe CAVALLARO authored
This patch reviews the driver documentation file; for example, there were some new fields (in the driver module parameter section) and the ptp files were not documented. Signed-off-by:
-
Byungho An authored
This patch modifies the pcs mode support for SGMII. Even though SGMII does auto-negotiation with phy, it needs stmmac_init_phy and stmmac_mdio_register function for initializing phy. Signed-off-by:
Byungho An <bh74.an@samsung.com> Signed-off-by:
-
Sebastian Hesselbarth authored
Using DT for mdiobus and ethernet-phy requires to know the PHY address, which is hard to guess if you don't know it. This patch extends of_mdiobus_register to scan mdiobus for PHYs if reg property of the corresponding node is not set. This also allows to have phy nodes in SoC DT files where the reg property can be overwritten in the board file later. To encourage people to finally set the actual phy address, the mdiobus scan is noisier than required. Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by:
-
Sebastian Hesselbarth authored
Marvell mdio driver uses internal registers that can be clock gated on some SoCs. This patch just adds optional clock handling, to allow to pass and enable the corresponding clock. Signed-off-by:
Florian Fainelli <florian@openwrt.org> Signed-off-by:
-
Lars-Peter Clausen authored
Use dev_pm_ops instead of the deprecated legacy suspend/resume callbacks. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Lars-Peter Clausen authored
By using module_spi_driver we can eliminate a few lines of boilerplate code. Signed-off-by:
-
Alan Ott authored
Two sections checked whether the current channel != the new channel without ever setting the current channel variables. 1. net/mac802154/tx.c: Prevent set_channel() from getting called every time a packet is sent. 2. net/mac802154/mib.c: Lock (pib_lock) accesses to current_channel and current_page and make sure they are updated when the channel has been changed. Signed-off-by:
Alan Ott <alan@signal11.us> Signed-off-by:
-
Alan Ott authored
On the MRF24J40, link-layer acknowledgment request and retry must be turned on explicitly for each packet. Turn this on in the hardware based on the FC_ACK_REQ bit being set in the packet. Also, now that failure to receive an ACK will cause the hardware to report failure of transmission, change the log level for this failure to debug level. Signed-off-by:
-
Mathias Krause authored
Hi Greg, I'm unsure if you or Dave should take that one as it's for one a TTY patch but also living under net/. So I'm uncertain and let you decide! Thanks, Mathias -- >8 -- Subject: [PATCH] TTY: ircomm, use GFP_KERNEL in ircomm_open() We're clearly running in non-atomic context as our only call site is able to call wait_event_interruptible(). So we're safe to use GFP_KERNEL here instead of GFP_ATOMIC. Signed-off-by:
Mathias Krause <minipli@googlemail.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Mathias Krause authored
The only call site of irda_connect_response() is irda_accept() -- a function called from user context only. Therefore it has no need for GFP_ATOMIC. Signed-off-by:
-
Mathias Krause authored
irda_create() is called from user context only, therefore has no need for GFP_ATOMIC. Signed-off-by:
-
Eric Dumazet authored
pskb_may_pull() can change skb->head, so we must init iph/greh after calling it. Bug added in commit c5441932 (GRE: Refactor GRE tunneling code.) Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
Sascha Herrmann authored
In at86rf230_probe() lp was first set to dev->priv and a few lines later dev->priv was set to lp again, without changing lp in between. The call to ieee802154_unregister_device() before err_irq: was unreachable. Signed-off-by:
Sascha Herrmann <sascha@ps.nvbi.de> Signed-off-by:
-
Stefan Assmann authored
If a feature is not supported by firmware no need to print an error message. This surpresses the following harmless message on boot up and ethtool query. enic: Error 1 devcmd 36 Signed-off-by:
Stefan Assmann <sassmann@kpanic.de> Signed-off-by:
-
Werner Almesberger authored
Check for NULL before calling the following operations from "struct ieee802154_mlme_ops": assoc_req, assoc_resp, disassoc_req, start_req, and scan_req. This fixes a current oops where those functions are called but not implemented. It also updates the documentation to clarify that they are now optional by design. If a call to an unimplemented function is attempted, the kernel returns EOPNOTSUPP via netlink. The following operations are still required: get_phy, get_pan_id, get_short_addr, and get_dsn. Note that the places where this patch changes the initialization of "ret" should not affect the rest of the code since "ret" was always set (again) before returning its value. Signed-off-by:
Werner Almesberger <werner@almesberger.net> Signed-off-by:
-
Werner Almesberger authored
It served no purpose: we never call it from anywhere in the stack and the only driver that did implement it (fakehard) merely provided a dummy value. There is also considerable doubt whether it would make sense to even attempt beacon processing at this level in the Linux kernel. Signed-off-by:
-
