On Tue, Aug 20, 2019 at 10:22:18PM +, charles.h...@dellteam.com wrote:
> This change moves ACPI functionality out of the Realtek r8152 driver to
> its own source and header file, making it available to other drivers as
> needed now and into the future. At the time this ACPI snippet was
> intro
On Tue, Aug 20, 2019 at 10:18:42PM +, charles.h...@dellteam.com wrote:
> The core USB driver message.c is missing get/set address functionality
> that stops ifconfig from being able to push MAC addresses out to USB
> based ethernet devices. Without this functionality, some USB devices
> stop r
On Wed, Feb 06, 2019 at 12:51:06PM -0800, Moritz Fischer wrote:
> Move the DT based link GPIO parsing to of_mdio and let the places
> that register a fixed_phy pass in a GPIO descriptor or NULL.
>
> This allows fixed_phy on non-DT platforms to have link GPIOs, too.
>
> Signed-off-by: Moritz Fisch
> I wonder, if I use the phylib functions instead of the ad-hoc ones in
> the MAC driver, is there still a problem with synchronization ?
You would need to look deep into phylib. When does it reset the PHY?
Configure auto-neg, setup interrupts, etc? It looks like both are
going to do this, so i ex
> > All this crossover code should be moved into the PHY driver.
>
> Fine, this can be done in a subsequent patch though, right ? I'd like to
> keep the changes small, so if something breaks, it could be bisected easily.
Hi Marek
The problem is, do you have a regression because of the changes yo
> static int get_mdix_status(struct net_device *net)
> {
> struct usbnet *dev = netdev_priv(net);
> + struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0]);
> u32 val;
> int buf;
>
> - buf = smsc95xx_mdio_read(dev->net, dev->mii.phy_id, SPECIAL_CTRL_STS)
On Thu, Jan 03, 2019 at 02:10:33AM +0100, Marek Vasut wrote:
> Replace the ad-hoc reimplementation of genphy_soft_reset() and
> genphy_config_aneg() with the generic functions.
phylib will either call the phy driver specific reset function, or
genphy_soft_reset. The same is also true for configuri
On Thu, Jan 03, 2019 at 02:10:30AM +0100, Marek Vasut wrote:
> Add code to detect and connect to PHY. The internal PHY of the SMSC95xx
> is a regular SMSC LAN8700 and the driver only supports the internal PHY,
> so just use the SMSC PHY driver to configure the PHY. Note that the
> driver does a lot
On Sun, Dec 23, 2018 at 11:43:05AM +0100, Marek Vasut wrote:
> On 12/23/18 11:23 AM, Andrew Lunn wrote:
> >>> +static int smsc95xx_phy_address(struct usbnet *dev)
> >>> +{
> >>> + u32 read_buf;
> >>> + int ret, id1, id2, phyad;
> >&g
> > +static int smsc95xx_phy_address(struct usbnet *dev)
> > +{
> > + u32 read_buf;
> > + int ret, id1, id2, phyad;
> > +
> > + ret = smsc95xx_read_reg(dev, HW_CFG, &read_buf);
> > + if (ret < 0)
> > + return ret;
> > +
> > + /* Check if using external PHY, if not, use internal
> NORMAL_TEMP and CRITICAL_TEMP values are actually a hysteresis. In
> cool down case only after TEMP_NORMAL temperature link will be
> flipped back again.
Ah, yes, sorry, i read that wrong.
Andrew
On Wed, Dec 12, 2018 at 01:50:08PM +, Igor Russkikh wrote:
> From: Dmitry Bezrukov
>
> Add necessary defines to read phy registers and temparature
Hi Igor
[Puts tongue in cheek]
I thought the firmware was supposed to manage the PHY.
So maybe the better fix is to add code to allow firmware
On Wed, Dec 12, 2018 at 01:50:10PM +, Igor Russkikh wrote:
> From: Dmitry Bezrukov
>
> Lab testing shows that chip may get overheated when
> network link is connected on high speed (2.5G/5G).
>
> Default hardware design uses only passive heatsink without a cooler,
> and that makes things wor
> Production dongles will always have firmware fully controlling all the phy.
> Thus, I think in next series we'll just cut off all the direct phy
> access code.
O.K, but that is also a shame. The PHY i have has all sorts of nice
things, MACSEC, temperature sensors, PTP, cable tests logic,
etc. Wi
> We've considered that, but then thought about the following case:
>
> After such a sleep state where partner's capabilities were considered,
> user may move with the unit and replug it into different link partner with
> other, incompatible speed mask. That will anyway lead to wol link failure.
> > Thats again because of this product has tightly integrated MAC+Phy.
> > MAC FW controls system interface and reports/alters link state
> > as a joint state on copper and SIF (even in dpa direct phy mode).
> >
> > We can't extract phy api into a standalone fully functional phylib
> > therefore
> +static int aqc111_suspend(struct usb_interface *intf, pm_message_t message)
> +{
> +
> + if (aqc111_data->dpa) {
> + aqc111_set_phy_speed(dev, AUTONEG_ENABLE, SPEED_100);
So this is better, you leave auto-neg enabled. But you really should
be taking the link par
On Tue, Nov 13, 2018 at 02:44:45PM +, Igor Russkikh wrote:
> From: Dmitry Bezrukov
>
> Add full hardware initialization sequence and link configuration logic
Hi Igor
I'm still not convinced the PHY driver should be embedded in the MAC
driver, rather than using phylink.
If i remember correc
On Tue, Nov 13, 2018 at 02:45:13PM +, Igor Russkikh wrote:
> +static int aqc111_get_link_ksettings(struct net_device *net,
> + struct ethtool_link_ksettings *elk)
> +{
> + struct usbnet *dev = netdev_priv(net);
> + struct aqc111_data *aqc111_data = dev->
On Mon, Oct 08, 2018 at 09:09:54AM +, Igor Russkikh wrote:
> Hi Andrew,
>
> >>
> >> + struct aqc111_data *aqc111_data = (struct aqc111_data *)dev->data[0];
> >
> > Having to do this cast all the time is quiet ugly. It seems like some
> > other usb_net drivers use netdev_priv().
>
> As I s
On Tue, Oct 09, 2018 at 02:34:36PM +, Igor Russkikh wrote:
> Hi Andrew,
>
> >> + if (ret < 0)
> >> + goto out;
> >> +
> >> + memcpy(dev->net->dev_addr, buf, ETH_ALEN);
> >> + memcpy(dev->net->perm_addr, dev->net->dev_addr, ETH_ALEN);
> >
> > Is this really the permanent address? I
On Mon, Oct 08, 2018 at 02:12:59PM +, Igor Russkikh wrote:
> Hi Andrew,
>
> >> + if (aqc111_data->dpa) {
> >> + aqc111_set_phy_speed(dev, AUTONEG_DISABLE, SPEED_100);
> >
> > I don't think that works. You should leave AUTONEG on, but only
> > advertise SPEED_100 and
On Mon, Oct 08, 2018 at 09:09:54AM +, Igor Russkikh wrote:
> Hi Andrew,
>
> >>
> >> + struct aqc111_data *aqc111_data = (struct aqc111_data *)dev->data[0];
> >
> > Having to do this cast all the time is quiet ugly. It seems like some
> > other usb_net drivers use netdev_priv().
>
> As I s
On Mon, Oct 08, 2018 at 09:29:26AM +, Igor Russkikh wrote:
> Hi Andrew,
>
> >>aqc111_read_fw_version(dev, aqc111_data);
> >> + aqc111_data->autoneg = AUTONEG_ENABLE;
> >> + aqc111_data->advertised_speed = (usb_speed == USB_SPEED_SUPER) ?
> >> + SPEED_500
On Fri, Oct 05, 2018 at 10:24:37AM +, Igor Russkikh wrote:
> This patchset introduces support for new multigig ethernet to USB dongle,
> developed jointly by Aquantia (Phy) and ASIX (USB MAC).
>
> The driver has similar structure with other ASIX MAC drivers (AX88179), but
> with a number of im
> + if (aqc111_data->dpa) {
> + aqc111_set_phy_speed(dev, AUTONEG_DISABLE, SPEED_100);
I don't think that works. You should leave AUTONEG on, but only
advertise SPEED_100 and trigger auto-neg. If you force it to 100,
there is no guarantee the peer will figure out wh
> +static int aqc111_set_link_ksettings(struct net_device *net,
> + const struct ethtool_link_ksettings *elk)
> +{
> + struct usbnet *dev = netdev_priv(net);
> + enum usb_device_speed usb_speed = dev->udev->speed;
> + struct aqc111_data *aqc111_data = (s
> @@ -202,6 +319,9 @@ static int aqc111_bind(struct usbnet *dev, struct
> usb_interface *intf)
> dev->net->netdev_ops = &aqc111_netdev_ops;
>
> aqc111_read_fw_version(dev, aqc111_data);
> + aqc111_data->autoneg = AUTONEG_ENABLE;
> + aqc111_data->advertised_speed = (usb_speed
On Fri, Oct 05, 2018 at 10:25:22AM +, Igor Russkikh wrote:
> From: Dmitry Bezrukov
>
> Implement get_drvinfo, set/get_msglevel, get_link callbacks
>
> Signed-off-by: Dmitry Bezrukov
> Signed-off-by: Igor Russkikh
> ---
> drivers/net/usb/aqc111.c | 30 ++
> 1 fi
> @@ -994,6 +1083,7 @@ static int aqc111_rx_fixup(struct usbnet *dev, struct
> sk_buff *skb)
> new_skb->truesize = new_skb->len + sizeof(struct sk_buff);
> if (aqc111_data->rx_checksum)
> aqc111_rx_checksum(new_skb, &pkt_desc);
> +
>
> +static void aqc111_set_rx_mode(struct net_device *net)
> +{
> + struct usbnet *dev = netdev_priv(net);
> + struct aqc111_data *aqc111_data = (struct aqc111_data *)dev->data[0];
> + u8 *m_filter = ((u8 *)dev->data) + 12;
Please could you explain is.
Thanks
An
> +static int aqc111_change_mtu(struct net_device *net, int new_mtu)
> +{
> + struct usbnet *dev = netdev_priv(net);
> + u16 reg16 = 0;
> + u8 buf[5];
> +
> + if (new_mtu <= 0 || new_mtu > 16334) {
> + netdev_info(net, "Invalid MTU %d requested, hw max 16334",
> +
> +static int aqc111_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
> +{
> + struct sk_buff *new_skb = NULL;
> + u32 skb_len = 0;
> + u32 desc_offset = 0; /*RX Header Offset*/
> + u32 start_of_descs = 0;
> + u16 pkt_count = 0;
> + u32 pkt_total_offset = 0;
> + struct
> +static struct sk_buff *aqc111_tx_fixup(struct usbnet *dev, struct sk_buff
> *skb,
> +gfp_t flags)
> +{
> + struct aq_tx_packet_desc tx_hdr;
> + int frame_size = dev->maxpacket;
> + int headroom = 0;
> + int tailroom = 0;
> + int padding_si
On Fri, Oct 05, 2018 at 10:24:58AM +, Igor Russkikh wrote:
> From: Dmitry Bezrukov
>
> Signed-off-by: Dmitry Bezrukov
> Signed-off-by: Igor Russkikh
> ---
> drivers/net/usb/aqc111.c | 51
>
> drivers/net/usb/aqc111.h | 1 +
> 2 files chang
On Fri, Oct 05, 2018 at 10:24:53AM +, Igor Russkikh wrote:
> From: Dmitry Bezrukov
>
> Implement PHY power up/down sequences.
> AQC111, depending on FW used, may has PHY being controlled either
> directly (dpa = 1) or via vendor command interface (dpa = 0).
Hi Igor
dpa is not a very descrip
On Fri, Oct 05, 2018 at 10:24:55AM +, Igor Russkikh wrote:
> From: Dmitry Bezrukov
>
> Add full hardware initialization sequence and link configuration logic
Hi Igor, Dmitry
Please could you explain why you decided to not use drivers/net/phy?
The previous patch introduced basically what you
On Tue, Oct 02, 2018 at 10:26:42AM +0100, Ben Dooks wrote:
> Add a configuration option for the default state of turbo mode
> on the smsc95xx networking driver. Some systems it is better
> to default this to off as it causes significant increases in
> soft-irq load.
>
> Signed-off-by: Ben Dooks
>
On Wed, May 16, 2018 at 10:54:12AM +0200, Geert Uytterhoeven wrote:
> Hi Florian,
>
> Thanks for your series!
> I like the effect on simplifying drivers.
>
> On Wed, May 16, 2018 at 1:56 AM, Florian Fainelli
> wrote:
> > This patch series updates of_mdiobus_register() such that when the
> > de
applications without an EEPROM or programmed OTP.
>
> Document the supported properties in a bindings file.
>
> Signed-off-by: Phil Elwell
Reviewed-by: Andrew Lunn
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message
+ (len > 3) * HW_CFG_LED3_EN_;
> + lan78xx_write_reg(dev, HW_CFG, reg);
> + }
> + }
> +
Humm. Not nice. But i cannot think of a cleaner way of doing this.
Reviewed-by: Andrew Lunn
Andrew
--
To unsubscribe from this l
On Wed, Apr 18, 2018 at 04:45:22PM +0100, Phil Elwell wrote:
> Add support for DT property "microchip,led-modes", a vector of zero
> to four cells (u32s) in the range 0-15, each of which sets the mode
> for one of the LEDs. Some possible values are:
>
> 0=link/activity 1=link1000/acti
> @@ -2097,6 +2098,25 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
> (void)lan78xx_set_eee(dev->net, &edata);
> }
>
> + if (!of_property_read_u32_array(dev->udev->dev.of_node,
> + "microchip,led-modes",
> +
On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
> The Microchip LAN78XX family of devices are Ethernet controllers with
> a USB interface. Despite being discoverable devices it can be useful to
> be able to configure them from Device Tree, particularly in low-cost
> applications withou
On Thu, Apr 12, 2018 at 02:55:35PM +0100, Phil Elwell wrote:
> Add support for DT property "microchip,led-modes", a vector of two
> cells (u32s) in the range 0-15, each of which sets the mode for one
> of the two LEDs. Some possible values are:
>
> 0=link/activity 1=link1000/activity
On Thu, Apr 12, 2018 at 03:10:57PM +0100, Phil Elwell wrote:
> Hi Andrew,
>
> On 12/04/2018 15:04, Andrew Lunn wrote:
> > On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
> >> The Microchip LAN78XX family of devices are Ethernet controllers with
> >&g
On Thu, Apr 12, 2018 at 02:55:34PM +0100, Phil Elwell wrote:
> Add two new Device Tree properties:
> * microchip,eee-enabled - a boolean to enable EEE
> * microchip,tx-lpi-timer - time in microseconds to wait after TX goes
>idle before entering the low power state
>
Hi Phil
> - ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
> - ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
> + mac_addr = of_get_mac_address(dev->udev->dev.of_node);
It might be better to use the higher level eth_platform_get_mac_address(
On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
> The Microchip LAN78XX family of devices are Ethernet controllers with
> a USB interface. Despite being discoverable devices it can be useful to
> be able to configure them from Device Tree, particularly in low-cost
> applications withou
On Wed, Apr 11, 2018 at 10:59:17AM +0100, Phil Elwell wrote:
> lan78xx_read_otp tries to return -EINVAL in the event of invalid OTP
> content, but the value gets overwritten before it is returned and the
> read goes ahead anyway. Make the read conditional as it should be
> and preserve the error co
On Mon, Apr 02, 2018 at 10:21:01PM +0900, Masahiro Yamada wrote:
> 2018-04-02 21:04 GMT+09:00 Andrew Lunn :
> >> The maintainer of DWC3, Felipe Balbi, requested to
> >> split the glue layer driver into small parts such as
> >> reset, regulator, phy, etc.
> >
> The maintainer of DWC3, Felipe Balbi, requested to
> split the glue layer driver into small parts such as
> reset, regulator, phy, etc.
What exactly did Felipe ask for? Did he ask that the patch be split
up, one patch per reset, regulator, phy etc?
Are all these resources used just by the DWC3?
> @@ -2082,8 +2082,6 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
>
> dev->fc_autoneg = phydev->autoneg;
>
> - phy_start(phydev);
> -
> netif_dbg(dev, ifup, dev->net, "phy initialised successfully");
>
> return 0;
> @@ -2512,9 +2510,7 @@ static int lan78xx_ope
On Sat, Mar 10, 2018 at 07:22:55PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sat, 10 Mar 2018 19:05:45 +0100
>
> Two update suggestions were taken into account
> from static source code analysis.
Hi Markus
How about re-writing this driver to use phylib. The whole of
ax88179
> diff --git a/drivers/net/cris/eth_v10.c b/drivers/net/cris/eth_v10.c
> index da02041..017f48c 100644
> --- a/drivers/net/cris/eth_v10.c
> +++ b/drivers/net/cris/eth_v10.c
> @@ -1417,10 +1417,9 @@ static int e100_get_link_ksettings(struct net_device
> *dev,
> {
> struct net_local *np = net
C: David Miller
> Signed-off-by: Martin Wetterwald
Reviewed-by: Andrew Lunn
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Martin
> @@ -2032,7 +2032,7 @@ static struct sk_buff *smsc95xx_tx_fixup(struct usbnet
> *dev,
> skb_push(skb, 4);
> tx_cmd_b = (u32)(skb->len - 4);
> if (csum)
> - tx_cmd_b |= TX_CMD_B_CSUM_ENABLE;
> + tx_cmd_b |= TX_CMD_B_CSUM_EN;
This changed seems
> Thanks. When I posted this last time around (19th Jan) I mentioned
> about marking the old _indirect() accessors with __deprecated - is
> that still something we want to do?
>
> I haven't tested this against net-next yet, so I don't know if there
> are any new users of the indirect accessors -
On Sun, Mar 19, 2017 at 11:00:29AM +, Russell King wrote:
> lan78xx appears to use phylib in a rather weird way, accessing the PHY
> partly through phylib, and partly by makign direct accesses to it,
Hi Russell
s/makign/making
Andrew
--
To unsubscribe from this list: send the line "u
the function name. Same
> applies for the write methods.
Hi Russell
This all looks good, apart from the one typo i spotted.
Reviewed-by: Andrew Lunn
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
eeded: this is the purpose of the first patch.
>
> The second patch allows to build the driver for the ARM64 Armada SoCs.
>
> The last one enables the EHCI in the device tree.
>
> This second version takes into account the review from Andrew Lunn and
> Thomas Petazzoni.
Hi
On Wed, Mar 08, 2017 at 05:24:22PM +0100, Gregory CLEMENT wrote:
> The mvebu ARM64 SoCs no more select PLAT_ORION but some of them as the
> Armada 37xx use the EHCI orion controller. This patch allow to build
> the driver when ARCH_MVEBU is selected.
The mvebu ARM64 SoCs no longer selects PLAT_ORI
Hi Gregory
> - Add a new compatoble string for the Armada 3700 SoCs
compatible
>
> - add sbuscfg support for orion usb controller driver. For the SoCs
> without hlock, need to program BAWR/BARD/AHBBRST fields in the sbuscfg
> register to guarantee the AHB master's burst would not overrun or
> > It is same, how to handle two network cards which tell us, that they
> > have same MAC addresses.
> >
>
> The kernel handles this just fine. In doing this patch I checked to see
> what it does in that scenario. Two devices are made. systemd doesn't
> rename the second device via the MAC na
lue if hex2bin succesful but invalid ether addr
>
> Have things calmed down enough now that I can apply this?
Hi David
I think the code has reaching the level of maturity needed for
acceptance. So for the code quality:
Reviewed-by: Andrew Lunn
What is still open is do we want to accept it
> + /* returns _AUXMAC_#AABBCCDDEEFF# */
> + status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, &buffer);
> + obj = (union acpi_object *)buffer.pointer;
> + if (ACPI_SUCCESS(status)) {
> + if (obj->type != ACPI_TYPE_BUFFER ||
> + obj->string.length !
On Thu, Jun 02, 2016 at 07:04:32PM +, mario_limoncie...@dell.com wrote:
> > -Original Message-
> > From: Andrew Lunn [mailto:and...@lunn.ch]
> > Sent: Thursday, June 2, 2016 2:03 PM
> > To: Limonciello, Mario
> > Cc: gre...@linuxfoundation.org; hayesw.
> > And you want to check this for all Dell devices? Please be model
> > specific, I doubt a bunch of Dell servers wants to run this code...
> >
>
> Tracking model specific is really going to turn into a giant list never
> ending list.
> To drill down more specifically, I can match on chassis t
> >
> > > + pr_info("r8152: Using system auxiliary MAC address");
> >
> > It would be great to write also mac address into that pr_info
And since there could be multiple r8152 in the system, it would be
good to indicate which of them is having its MAC changed. So
netdev_info() or dev_inf
On Wed, Jun 01, 2016 at 04:50:44PM -0500, Mario Limonciello wrote:
> Dell systems with Type-C ports have support for a persistent system
> specific MAC address when used with Dell Type-C docks and dongles.
> This means a dock plugged into two different systems will show different
> (but persistent)
> In other words, the full-speed hub is restricting the USB to
> Ethernet Adaptor to a 12Mbps (half-duplex) bandwidth to support
> Ethernet 100Mbps (full-duplex) traffic. That is not going to work
> very well because Ethernet frames (perhaps partial Ethernet frames)
> need to be discarded within th
> So, would you like to accept the generic solution like below:
>
> - Create a generic power sequence driver, and it will be probed
> according to compatible string at device tree. At its probe,
> we can create a power sequence structure, and let this structure
> as the private data for this power
On Fri, Mar 04, 2016 at 10:02:42AM +0800, Peter Chen wrote:
> On Thu, Mar 03, 2016 at 02:54:55PM -0600, Rob Herring wrote:
> > On Thu, Mar 3, 2016 at 4:01 AM, Peter Chen wrote:
> > > Some hard-wired USB devices need to do power sequence to let the
> > > device work normally, the typical power sequ
> > > diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> > > index 053bac9..55120ef 100644
> > > --- a/drivers/usb/chipidea/host.c
> > > +++ b/drivers/usb/chipidea/host.c
> > > @@ -109,15 +109,25 @@ static int host_start(struct ci_hdrc *ci)
> > > struct ehci_hcd *ehci;
> > >
On Thu, Mar 03, 2016 at 06:01:15PM +0800, Peter Chen wrote:
> From: Peter Chen
>
> Since the hcd (chipidea core device) has no device node, so
> if we want to describe the child node under the hcd, we had
> to put it under its parent's node (glue layer device), and
> in the code, we need to let t
sis with CoverityScan
>
> Fixes: e7f4dc3536a400 ("mdio: Move allocation of interrupts into core")
> Signed-off-by: Colin Ian King
Reviewed-by: Andrew Lunn
Thanks
Andrew
> ---
> drivers/net/usb/ax88172a.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
> One final update on this topic: the kernel config was missing the
> CONFIG_USB_EHCI_ROOT_HUB_TT option. It turns out that the USB IP embeded a
> Transaction Translator and there is a check in ehci_halt() that aborts the
> routine in case of a Transaction Translator in the ehci controller. The che
On Fri, Jun 05, 2015 at 04:34:54PM +0200, Valentin Longchamp wrote:
> Hello,
>
> I am currently bringing up the USB 2.0 Host controller of the Bobcat's
> (98DX4122
> Marvell switch) internal kirkwood CPU on a variation of Keymile's km_kirwood
> hardware (kirkwood-km_kirkwood.dts).
>
> When the d
On Wed, Apr 22, 2015 at 04:14:33PM +, Jan Kaisrlik wrote:
> 2015-04-21 17:51 GMT+00:00 Florian Fainelli :
> > On 21/04/15 10:39, Andrew Lunn wrote:
> >>>> I would however say that sysfs is the wrong API. The linux network
> >>>> stack uses netlink for mo
> > I would however say that sysfs is the wrong API. The linux network
> > stack uses netlink for most configuration activities. So i would
> > suggest adding a netlink binding to DSA, and place the code in
> > net/dsa/, not within an MDIO driver.
>
> I suppose we could do that, but that sounds li
> My goal in reworking this weird DSA device/driver model is that you
> could just register your switch devices as an enhanced
> phy_driver/spi_driver/pci_driver etc..., such that libphy-ready drivers
> could just take advantage of that when they scan/detect their MDIO buses
> and find a switch. We
Hi Jan
Interesting work, but i think the architecture is wrong.
DSA needs an Ethernet device, an MDIO bus, and information about ports
on the switch. The MDIO bus and the Ethernet need no knowledge of
DSA. So putting your DSA configuration code in the MDIO driver is
wrong.
The problem you have i
On Tue, Jan 20, 2015 at 09:30:28PM +0100, Maxime Ripard wrote:
> Hi Andrew,
>
> On Mon, Jan 19, 2015 at 10:35:07PM +0100, Andrew Lunn wrote:
> > On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote:
> > > Hi all,
> > >
> > > This serie
On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote:
> Hi all,
>
> This serie enables the Armada 385 AP XHCI controller.
>
> Since the controller uses a GPIO-controlled VBUS, we used the
> phy-generic driver, and made the needed additions to the xhci-plat
> driver to retrieve a USB phy.
On Wed, Jul 16, 2014 at 10:25:55AM +0200, Antoine Ténart wrote:
> Add a reset controller for Marvell Berlin SoCs which is used by the
> USB PHYs drivers (for now).
>
> Signed-off-by: Antoine Ténart
> Signed-off-by: Sebastian Hesselbarth
> Acked-by: Philipp Zabel
> ---
> drivers/reset/Makefile
On Fri, May 23, 2014 at 07:22:48PM +0530, Kishon Vijay Abraham I wrote:
> hI,
>
> On Friday 23 May 2014 07:06 PM, Andrew Lunn wrote:
> >> Do you want one .txt file per driver, or can we combine binding
> >> documentations into one file? There should already be a mvebu-p
> Do you want one .txt file per driver, or can we combine binding
> documentations into one file? There should already be a mvebu-phy.txt,
> which contains the sata phy usable on some of the Armada SoC families.
> This binding could be appended to it.
Ah. Humm, well! It seems the patch adding the
On Fri, May 23, 2014 at 02:54:02PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Friday 16 May 2014 09:52 PM, Gregory CLEMENT wrote:
> > Armada 375 comes with an USB2 host and device controller and an USB3
> > controller. The USB cluster control register allows to manage common
> > features of
On Wed, May 07, 2014 at 11:40:06AM +0200, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
>
> On Tue, 6 May 2014 15:33:41 +0200, Andrew Lunn wrote:
>
> > > + priv->phy = devm_phy_get(&pdev->dev, "usb");
> > > + if (!IS_ERR(priv->phy)) {
> >
On Tue, May 06, 2014 at 02:14:12AM +0200, Gregory CLEMENT wrote:
> The Armada 375 SoC comes with an USB2 host and device controller and
> an USB3 controller. The USB cluster control register allows to manage
> common features of both USB controllers. It uses the generic PHY
> framework
>
> Signed-
On Tue, May 06, 2014 at 02:14:03AM +0200, Gregory CLEMENT wrote:
> The Marvell Armada 38x SoCs contains two xHCI host. This commit adds
> the Device Tree description of those interfaces at the SoC level, and
> also enables the two USB3 ports on the Armada 385 DB platform and one
> USB3 port on the
On Tue, May 06, 2014 at 02:13:57AM +0200, Gregory CLEMENT wrote:
> This commit allows to use the PHY provided through the device tree. It
> will be useful for the Armada 375 SoCs. if no PHY is provided then the
> behavior of the driver is unchanged.
>
> Signed-off-by: Gregory CLEMENT
> ---
> dri
On Fri, Apr 25, 2014 at 04:07:12PM +0200, Gregory CLEMENT wrote:
> The Armada 375 SoC comes with an USB2 host and device controller and
> an USB3 controller. The USB cluster control register allows to manage
> common features of both USB controllers.
>
> Signed-off-by: Gregory CLEMENT
> ---
> ar
On Fri, Apr 25, 2014 at 04:07:03PM +0200, Gregory CLEMENT wrote:
> The Marvell Armada 38x SoCs contain two xHCI host. This commit adds
> the Device Tree description of those interfaces at the SoC level, and
> also enables the two USB3 ports on the Armada 385 DB platform and one
> USB3 port on the A
> > +* We can't use usb2 and usb3 in the same time, so let's
> > +* disbale usb2 and complain about it to the user askinf
>
> typos: disable, asking
And it should be "at the same time", not in.
Andrew
--
To unsubscribe from this list: send the line "un
On Fri, Apr 25, 2014 at 04:07:00PM +0200, Gregory CLEMENT wrote:
> Some platform (such as the Armada 38x ones) can gate the clock of
> their USB controller. This patch add the support for the clock, by
> enabling them during probe and disabling them on remove.
>
> As not all platforms have clock s
> I hope it's OK that I submit the patch with the below changes to Greg
> for inclusion in v3.14. Let me know if you prefer to respin yourself.
Hi Johan
The patch looks good.
Acked-by: Andrew Lunn
> Thanks for all your work with fixing up and mainlining this driver!
And than
Add the missing C_CMSPAR(tty) macro.
Signed-off-by: Andrew Lunn
---
include/linux/tty.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 97d660ed70c1..e53e90ed3f19 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -137,6 +137,7
This is optional and the driver appears to work O.K. with
older firmware in the devices ROM.
This driver is based on the MOXA driver and retains MOXAs copyright.
Signed-off-by: Andrew Lunn
---
v1->v2
Remove debug module parameter.
Add missing \n to dev_dbg() strings.
Consistent dev_d
> > +* endpoint, with a multiplex header. The second bulk in is
> > +* used for events. Throw away all but the first two bulk in
> > +* urbs.
> > +*/
> > + for (i = 2; i < serial->num_bulk_in; ++i) {
> > + port = serial->port[i];
> > + for (j = 0; j < ARRAY_SIZ
1 - 100 of 135 matches
Mail list logo
