aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/wan/slic_ds26522.c
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2017-02-07 10:51:48 -0500
committerDavid S. Miller <davem@davemloft.net>2017-02-07 10:51:48 -0500
commit521613c5684068f2003d38b84c9a317b3d53948d (patch)
tree17cede934139d91fbf58cfb5cf7dacac6a58ff6c /drivers/net/wan/slic_ds26522.c
parentnet: dsa: mv88e6xxx: Refactor remaining port setup (diff)
parentARM: orion: Register DSA switch as a MDIO device (diff)
downloadlinux-dev-521613c5684068f2003d38b84c9a317b3d53948d.tar.xz
linux-dev-521613c5684068f2003d38b84c9a317b3d53948d.zip
Merge branch 'dsa2-pdata'
Florian Fainelli says: ==================== net: dsa: Support for pdata in dsa2 This is not exactly new, and was sent before, although back then, I did not have an user of the pre-declared MDIO board information, but now we do. Note that I have additional changes queued up to have b53 register platform data for MIPS bcm47xx and bcm63xx. Yes I know that we should have the Orion platforms eventually be converted to Device Tree, but until that happens, I don't want any remaining users of the old "dsa" platform device (hence the previous DTS submissions for ARM/mvebu) and, there will be platforms out there that most likely won't never see DT coming their way (BCM47xx is almost 100% sure, BCM63xx maybe not in a distant future). We would probably want the whole series to be merged via David Miller's tree to simplify things. Thanks! Changes in v5: - dropped changes to drivers/base/ because after more than a month, we cannot get any answer from Greg KH Changes in v4: - Changed device_find_class() to device_find_in_class_name() - Added kerneldoc above device_find_in_class_name() to explain what it does and the calling convention regarding device reference counts - Changed dev_to_net_device to device_to_net_device() added comments about what it does and the caller conventions regarding reference counts Changes in v3: - Tested EPROBE_DEFER from a mockup MDIO/DSA switch driver and everything is fine, once the driver finally probes we have access to platform data as expected - added comment above dsa_port_is_valid() that port->name is mandatory for platform data cases - added an extra check in dsa_parse_member() for a NULL pdata pointer - fixed a bunch of checkpatch errors and warnings Changes in v2: - Rebased against latest net-next/master - Moved dev_find_class() to device_find_class() into drivers/base/core.c - Moved dev_to_net_device into net/core/dev.c - Utilize dsa_chip_data directly instead of dsa_platform_data - Augmented dsa_chip_data to be multi-CPU port ready Changes from last submission (few months back): - rebased against latest net-next - do not introduce dsa2_platform_data which was overkill and was meant to allow us to do exaclty the same things with platform data and Device Tree we use the existing dsa_platform_data instead - properly register MDIO devices when the MDIO bus is registered and associate platform_data with them - add a change to the Orion platform code to demonstrate how this can be used Thank you ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions