- 12 Jan, 2020 10 commits
-
-
Linus Walleij authored
Use the netdevice struct device .parent field when calling dma_pool_create(): the .dma_coherent_mask and .dma_mask pertains to the bus device on the hardware (platform) bus in this case, not the struct device inside the network device. This makes the pool allocation work. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Linus Walleij authored
In order to probe this ethernet interface from the device tree all physical MMIO regions must be passed as resources. Begin this rewrite by first passing the port base address as a resource for all platforms using this driver, remap it in the driver and avoid using any reference of the statically mapped virtual address in the driver. Signed-off-by:
-
Linus Walleij authored
Simplify and correct a bunch of messages using printk directly to use the netdev_* macros. I have not changed all of them, just the low-hanging fruit. Signed-off-by:
-
Linus Walleij authored
Use "ndev" for the struct net_device and "dev" for the struct device in probe() and remove(). Add the local "dev" pointer for later use in refactoring. Take this opportunity to fix inverse christmas tree coding style. Signed-off-by:
-
Linus Walleij authored
The IXP4xx driver was initializing the MDIO bus before even probing, in the callbacks supposed to be used for setting up the module itself, and with the side effect of trying to register the MDIO bus as soon as this module was loaded or compiled into the kernel whether the device was discovered or not. This does not work with multiplatform environments. To get rid of this: set up the MDIO bus from the probe() callback and remove it in the remove() callback. Rename the probe() and remove() calls to reflect the most common conventions. Since there is a bit of checking for the ethernet feature to be present in the MDIO registering function, making the whole module not even be registered if we can't find an MDIO bus, we need something similar: register the MDIO bus when the corresponding ethernet is probed, and return -EPROBE_DEFER on the other interfaces until this happens. If no MDIO bus is present on any of the registered interfaces we will eventually bail out. None of the platforms I've seen has e.g. MDIO on EthB and only uses EthC, there is always a Ethernet hardware on the NPE (B, C) that has the MDIO bus, we just might have to wait for it. Signed-off-by:
-
Arnd Bergmann authored
The platform data is needed to compile the driver as standalone, so move it to a global location along with similar files. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
The ixp46x ptp driver has a somewhat unusual setup, where the ptp driver and the ethernet driver are in different directories but access the same registers that are defined a platform specific header file. Moving everything into drivers/net/ makes it look more like most other ptp drivers and allows compile-testing this driver on other targets. Signed-off-by:
-
Arnd Bergmann authored
The ixp4xx_hss driver needs the platform data definition and the system clock rate to be compiled. Move both into a new platform_data header file. This is a prerequisite for compile testing, but turning on compile testing requires further patches to isolate the SoC headers. Signed-off-by:
-
Arnd Bergmann authored
Change the driver to use portable integer types to avoid warnings during compile testing: drivers/net/wan/ixp4xx_hss.c:863:21: error: cast to 'u32 *' (aka 'unsigned int *') from smaller integer type 'int' [-Werror,-Wint-to-pointer-cast] memcpy_swab32(mem, (u32 *)((int)skb->data & ~3), bytes / 4); ^ drivers/net/wan/ixp4xx_hss.c:979:12: error: incompatible pointer types passing 'u32 *' (aka 'unsigned int *') to parameter of type 'dma_addr_t *' (aka 'unsigned long long *') [-Werror,-Wincompatible-pointer-types] &port->desc_tab_phys))) ^~~~~~~~~~~~~~~~~~~~ include/linux/dmapool.h:27:20: note: passing argument to parameter 'handle' here dma_addr_t *handle); ^ Signed-off-by: -
Jonathan Lemon authored
On modern hardware with a large number of cpus and using XDP, the current MSIX limit is insufficient. Bump the limit in order to allow more queues. Signed-off-by:
Jonathan Lemon <jonathan.lemon@gmail.com> Reviewed-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Reviewed-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
- 11 Jan, 2020 30 commits
-
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: add some misc update about reset issue This series includes some misc update relating to reset issue. [patch 1/7] & [patch 2/7] splits hclge_reset()/hclgevf_reset() into two parts: preparing and rebuilding. Since the procedure of FLR should be separated out from the reset task([patch 3/7 & patch 3/7]), then the FLR's processing can reuse these codes. pci_error_handlers.reset_prepare() is void type function, so [patch 6/7] & [patch 7/7] factor some codes related to PF function reset to make the preparing done before .reset_prepare() return. BTW, [patch 5/7] enlarges the waiting time of reset for matching the hardware's. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
hclge_reset_prepare_down() is only used to inform VF that PF is going to do function reset, then using hclge_func_reset_sync_vf() in hclge_reset_prepare_wait() to query whether VF is ready before asserting PF function reset. To make the code more readable, this patch uses a new function hclge_function_reset_notify_vf() to do this job. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Huazhong Tan authored
When synchronizes with VFs fail before PF function reset, PF driver should go on its function reset, otherwise it can not run normally anymore. So, hclge_func_reset_sync_vf() should not affect the processing of PF reset, this patch modifies its return type to void. Signed-off-by:
-
Huazhong Tan authored
When the load of firmware is high, its reset task may takes more time(which will be as long as 35 seconds). So this patch modifies HCLGE_RESET_WAIT_CNT to match the firmware's. Signed-off-by:
-
Huazhong Tan authored
Currently, the actual work of VF FLR is handled in the reset task, which is asynchronous. So in some case, if the preparing and rebuilding are not done, then the VF FLR will trigger some problems, for example, makes hardware go into chaos. So this patch separates the process of VF FLR from reset task, and adds a semaphore to serialize this reset and others. When FLR's preparing fails, if there has other higher level reset pending or failing times less than the HCLGE_FLR_RETRY_CNT, this preparing should be retried, otherwise it will get into a wrong state. BTW, while the hardware reports misc interrupt during pcie_flr(), the driver can not receive this interrupt anymore, so disable it when hclgevf_flr_prepare() return, and re-enable it when enter hclgevf_flr_done(). Avoid declaring internal function hclgevf_enable_vector(), this patch also moves its definition forward, and removes unused enum hnae3_flr_state. Signed-off-by:
-
Huazhong Tan authored
Currently, the actual work of PF FLR is handled in the reset task, which is asynchronous. So in some case, if the preparing and rebuilding are not done, then the PF FLR will trigger some problems, for example, makes hardware go into chaos. So this patch separates the process of PF FLR from reset task, and adds a semaphore to serialize this reset and others. When FLR's preparing fails, if there has other higher level reset pending or failing times less than the HCLGE_FLR_RETRY_CNT, this preparing should be retried, otherwise PF and its VF may get into wrong state. BTW, while the hardware reports misc interrupt during pcie_flr(), the driver can not receive this interrupt anymore, so disable it when hclge_flr_prepare() return, and re-enable it when enter hclge_flr_done(). Signed-off-by:
-
Huazhong Tan authored
hclgevf_reset() is a little bloated, and the process of VF FLR will be separated from the reset task later. So this patch splits hclgevf_reset() into hclgevf_reset_prepare() and hclge_reset_rebuild(), then FLR can also reuse these two functions. Also moves HNAE3_UP_CLIENT into hclgevf_reset_stack(). Signed-off-by:
-
Huazhong Tan authored
hclge_reset() is a little bloated, and the process of PF FLR will be separated from the reset task later. So this patch splits hclge_reset() into hclge_reset_prepare() and hclge_reset_rebuild(), then FLR can also reuse these two functions. BTW, since hclge_clear_reset_cause() and hclge_reset_prepare_up() will not affect the device, so in hclge_reset_rebuild(), these functions are called without rtnl_lock. Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/sfc/mcdi_functions.c: In function 'efx_mcdi_ev_init': drivers/net/ethernet/sfc/mcdi_functions.c:79:28: warning: variable 'nic_data' set but not used [-Wunused-but-set-variable] commit 4438b587 ("sfc: move MCDI event queue management code") introduces this unused variable. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
YueHaibing authored
Remove duplicated include. Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Jonathan Lemon authored
When running in XDP mode, pages come from the page pool, and should be freed back to the same pool or specifically detached. Currently, when the driver re-initializes, the page pool destruction is delayed forever since it thinks there are oustanding pages. Fixes: 322b87ca ("bnxt_en: add page_pool support") Signed-off-by:
Andy Gospodarek <gospo@broadcom.com> Signed-off-by:
-
David S. Miller authored
Jacob Keller says: ==================== devlink documentation refactor This series updates the devlink documentation, with a few primary goals * move all of the devlink documentation into a dedicated subfolder * convert that documentation to the reStructuredText format * merge driver-specific documentations into a single file per driver * add missing documentation, including per-driver and devlink generally For each driver, I took the time to review the code and add further documentation on the various features it currently supports. Additionally, I added new documentation files for some of the features such as devlink-dpipe, devlink-resource, and devlink-regions. Note for the region snapshot triggering, I kept that as a separate patch as that is based on work that has not yet been merged to net-next, and may change. I also improved the existing documentation for devlink-info and devlink-param by adding a bit more of an introduction when converting it to the rst format. ==================== Signed-off-by: -
Jacob Keller authored
Now that devlink regions can be triggered via DEVLINK_CMD_REGION_TRIGGER, document this in the devlink-region.rst file. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Jacob Keller authored
Primarily based on the DPIPE netdev conference paper, introduce a new file to document the dpipe interface. This likely needs further improvement, but is at least a good overall start. Signed-off-by:
-
Jacob Keller authored
Take the little bit of documentation for resources from various commit messages and combine it into a new devlink-resource.rst file. This could probably be expanded on even further by someone with more knowledge of how the devlink resources work. Signed-off-by:
-
Jacob Keller authored
Rename the trap-specific netdevimsim.rst file, and expand it to include documentation of all the devlink features currently implemented by the netdevsim driver code. Signed-off-by:
-
Jacob Keller authored
The IONIC device driver allocates a devlink and reports versions. Add documentation for this driver. Signed-off-by:
Shannon Nelson <snelson@pensandi.io> Signed-off-by:
-
Jacob Keller authored
Also document the regions created by the mlx4 driver. This is currently the only in-tree driver that creates devlink region snapshots. Signed-off-by:
-
Jacob Keller authored
The qed driver recently added devlink support with a single devlink parameter. Add a driver-specific file to document the devlink features that the qed driver supports. Signed-off-by:
-
Jacob Keller authored
The mlx5 and mlxsw drivers have driver-specific documentation for the devlink features they support. No such file was added for mlx4. Add a file to document the mlx4 devlink support. Initially it contains only the devlink parameters. Signed-off-by:
-
Jacob Keller authored
Add the set of info versions reported by each device driver, including a description of what the version represents, and what modes (fixed, running, stored) it reports. Signed-off-by:
-
Jacob Keller authored
Several drivers document what parameters they support in a devlink-params-*.txt file. This file is supposed to contain both the list of generic parameters implemented by the driver, as well as a list of driver-specific parameters and their descriptions. It would also be good if the driver documentation included other driver-specific implementations, such as info versions, devlink regions, and so forth. Convert all of these documentation files to reStructuredText, and rename them to just the driver name. Future changes will include other driver-specific implementations. Each file will contain a table for the generic parameters implemented, as well as a separate table for the driver-specific parameters. Future sections such as for devlink info versions will be added to these files. This avoids creating additional devlink-<feature>-<driver> files for each devlink feature, reducing clutter in the documentation folder. Signed-off-by:
-
Jacob Keller authored
Mention that drivers must support devlink-reload in order for driverinit parameters to function properly Signed-off-by:
-
Jacob Keller authored
A few generic devlink parameters have been added, but never documented. Fix that now. Signed-off-by:
-
Jacob Keller authored
Convert the generic parameters descriptions into the reStructuredText format. Signed-off-by:
-
Jacob Keller authored
Rename the devlink-info-versions.rst file to a plain devlink-info.rst file. Add additional paragraphs explaining what devlink-info is for, and the expectation that drivers use the generic names where plausible. Note that drivers which use non-standard info version names ought to document these in a driver-specific info-versions.rst file. Signed-off-by:
-
Jacob Keller authored
Update the devlink-health documentation to use the newer ReStructuredText format. Note that it's unclear what OOB stood for, and it has been left as-is without a proper first-use expansion of the acronym. Signed-off-by:
-
Jacob Keller authored
Combine the documentation for devlink into a subfolder, and provide an index.rst file that can be used to generally describe devlink. Signed-off-by:
-
Jacob Keller authored
The "fw.psid" devlink info version is documented in devlink-info.rst, and used by one driver. However, there is no associated macro for this firmware version like there is for others. Add one now. Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: factor out chip-specific PHY configuration to a separate source file Basically every chip version needs its own PHY configuration. To improve maintainability of the driver move all these PHY configurations to a separate source file. To allow this we first have to change all PHY configurations to use phylib functions wherever possible. ==================== Signed-off-by:
-
