- 24 Sep, 2022 1 commit
-
-
Alex Elder authored
In two spots we use u32_replace_bits() to replace a set of bits in a register while preserving the rest. Both of those cases just zero the bits being replaced, and this can be done more simply without using that function. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 23 Sep, 2022 39 commits
-
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-6.1-20220923' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2022-09-23 The first 2 patches are by Ziyang Xuan and optimize registration and the sending in the CAN BCM protocol a bit. The next 8 patches target the gs_usb driver. 7 are by me and first fix the time hardware stamping support (added during this net-next cycle), rename a variable, convert the usb_control_msg + manual kmalloc()/kfree() to usb_control_msg_{send,rev}(), clean up the error handling and add switchable termination support. The patch by Rhett Aultman and Vasanth Sadhasivan convert the driver from usb_alloc_coherent()/usb_free_coherent() to kmalloc()/URB_FREE_BUFFER. The last patch is by Shang XiaoJing and removes an unneeded call to dev_err() from the ctucanfd driver. * tag 'linux-can-next-for-6.1-20220923' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: ctucanfd: Remove redundant dev_err call can: gs_usb: remove dma allocations can: gs_usb: add switchable termination support can: gs_usb: gs_make_candev(): clean up error handling can: gs_usb: convert from usb_control_msg() to usb_control_msg_{send,recv}() can: gs_usb: gs_cmd_reset(): rename variable holding struct gs_can pointer to dev can: gs_usb: gs_can_open(): initialize time counter before starting device can: gs_usb: add missing lock to protect struct timecounter::cycle_last can: gs_usb: gs_usb_get_timestamp(): fix endpoint parameter for usb_control_msg_recv() can: bcm: check the result of can_send() in bcm_can_tx() can: bcm: registration process optimization in bcm_module_init() ==================== Link: https://lore.kernel.org/r/20220923120859.740577-1-mkl@pengutronix.deSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Antoine Tenart says: ==================== net: macsec: remove the preparation phase when offloading operations It was reported[1] the 2-step phase offloading of MACsec operations did not fit well and device drivers were mostly ignoring the first phase (preparation). In addition the s/w fallback in case h/w rejected an operation, which could have taken advantage of this design, never was implemented and it's probably not a good idea anyway (at least unconditionnally). So let's remove this logic which only makes the code more complex for no advantage, before there are too many drivers providing MACsec offloading. This series removes the first phase (preparation) of the MACsec h/w offloading. The modifications are split per-driver and in a way that makes bissection working with logical steps; but I can squash some patches if needed. This was tested on the MSCC PHY but not on the Altantic nor mlx5e NICs. [1] https://lore.kernel.org/all/166322893264.61080.12133865599607623050@kwain/T/ ==================== Link: https://lore.kernel.org/r/20220921135118.968595-1-atenart@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Antoine Tenart authored
Now that the MACsec offloading preparation phase was removed from the MACsec core implementation as well as from drivers implementing it, we can safely remove the flag representing it. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Antoine Tenart authored
Remove checks on the prepare phase as it is now unused by the MACsec core implementation. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Antoine Tenart authored
Remove checks on the prepare phase as it is now unused by the MACsec core implementation. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Antoine Tenart authored
Remove checks on the prepare phase as it is now unused by the MACsec core implementation. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Antoine Tenart authored
The hardware offloading in MACsec was initially supported using 2 phases. This was proposed in the RFC as this could have allowed easier fallback to the software implementation if the hardware did not support a feature or had enough entries already. But this fallback wasn't implemented and might not be a good idea after all. In addition it turned out this logic didn't mapped well the hardware logic and device drivers were mostly ignoring the preparation phase. Let's remove this as it does not offer any advantage and is ignored by drivers. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Antoine Tenart authored
In preparation for removing the MACsec h/w offloading preparation phase, make it a no-op in the Atlantic driver. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Antoine Tenart authored
In preparation for removing the MACsec h/w offloading preparation phase, make it a no-op in the MSCC phy driver. Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Matthieu Baerts authored
It looks like this test has been accidentally dropped when resolving conflicts in this Makefile. Most probably because there were 3 different patches modifying this file in parallel: commit 152e8ec7 ("selftests/bonding: add a test for bonding lladdr target") commit bbb774d9 ("net: Add tests for bonding and team address list management") commit 2ffd5732 ("selftests: bonding: cause oops in bond_rr_gen_slave_id") The first one was applied in 'net-next' while the two other ones were recently applied in the 'net' tree. But that's alright, easy to fix by re-adding the missing one! Fixes: 0140a716 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net") Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Link: https://lore.kernel.org/r/20220923082306.2468081-1-matthieu.baerts@tessares.netSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Shang XiaoJing authored
devm_ioremap_resource() prints error message in itself. Remove the dev_err call to avoid redundant error message. Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Link: https://lore.kernel.org/all/20220923095835.14647-1-shangxiaojing@huawei.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Vasanth Sadhasivan authored
DMA allocated buffers are a precious resource. If there is no need for DMA allocations, then it might be worth to use non-dma allocated buffers. After testing the gs_usb driver with and without DMA allocation, there does not seem to be a significant change in latency or CPU utilization either way. Therefore, DMA allocation is not necessary and removed. Internal buffers used within urbs were managed and freed manually. These buffers are no longer needed to be managed by the driver. The URB_FREE_BUFFER flag, allows for the buffers in question to be automatically freed. Co-developed-by: Rhett Aultman <rhett.aultman@samsara.com> Signed-off-by: Rhett Aultman <rhett.aultman@samsara.com> Signed-off-by: Vasanth Sadhasivan <vasanth.sadhasivan@samsara.com> Link: https://lore.kernel.org/all/20220920154724.861093-2-rhett.aultman@samsara.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
The candleLight community is working on switchable termination support for the candleLight firmware. As the the Linux CAN framework supports switchable termination add this feature to the gs_usb driver. Devices supporting the feature should set the GS_CAN_FEATURE_TERMINATION and implement the GS_USB_BREQ_SET_TERMINATION and GS_USB_BREQ_GET_TERMINATION control messages. For now the driver assumes for activated termination the standard termination value of 120Ω. Link: https://lore.kernel.org/all/20220923074114.662045-1-mkl@pengutronix.de Link: https://github.com/candle-usb/candleLight_fw/issues/92 Link: https://github.com/candle-usb/candleLight_fw/pull/109 Link: https://github.com/candle-usb/candleLight_fw/pull/108 Cc: Daniel Trevitz <daniel.trevitz@wika.com> Cc: Ryan Edwards <ryan.edwards@gmail.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Introduce a label to free the allocated candev in case of an error and make use of if. Fix a memory leak if the extended bit timing cannot be read. Extend the error messages to print the number of the failing channel and the symbolic error name. Link: https://lore.kernel.org/all/20220921193902.575416-4-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Convert the driver to use usb_control_msg_{send,recv}() instead of usb_control_msg(). These functions allow the data to be placed on the stack. This makes the driver a lot easier as we don't have to deal with dynamically allocated memory. Link: https://lore.kernel.org/all/20220921193902.575416-3-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Most of the driver uses the variable "dev" to point to the struct gs_can. Use the same name in gs_cmd_reset(), too. Rename gsdev to dev. Fixes: d08e973a ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://lore.kernel.org/all/20220921193902.575416-2-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
On busy networks the CAN controller might receive CAN frames directly after starting it but before the timecounter is setup. This will lead to NULL pointer deref while converting the converting the CAN frame's timestamp with the timecounter. Close the race window by setting up the timecounter before starting the CAN controller. Fixes: 45dfa45f ("can: gs_usb: add RX and TX hardware timestamp support") Link: https://lore.kernel.org/all/20220921081329.385509-1-mkl@pengutronix.de Cc: John Whittington <git@jbrengineering.co.uk Tested-by: John Whittington <git@jbrengineering.co.uk> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
The struct timecounter::cycle_last is a 64 bit variable, read by timecounter_cyc2time(), and written by timecounter_read(). On 32 bit architectures this is not atomic. Add a spinlock to protect access to struct timecounter::cycle_last. In the gs_usb_timestamp_read() callback the lock is dropped to execute a sleeping synchronous USB transfer. This is safe, as the variable we want to protect is accessed during this call. Fixes: 45dfa45f ("can: gs_usb: add RX and TX hardware timestamp support") Link: https://lore.kernel.org/all/20220920100416.959226-3-mkl@pengutronix.de Cc: John Whittington <git@jbrengineering.co.uk> Tested-by: John Whittington <git@jbrengineering.co.uk> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
The 2nd argument of usb_control_msg_recv() is the "endpoint", usb_control_msg_recv() will internally convert the endpoint into a pipe with usb_rcvctrlpipe(). In gs_usb_get_timestamp() not the endpoint "0" is passed, but the pipe. This worked by accident as endpoint is a __u8 and the lowest 8 bits of the pipe are 0. Fix this copy/paste error by using the correct endpoint of "0". Fixes: 45dfa45f ("can: gs_usb: add RX and TX hardware timestamp support") Link: https://lore.kernel.org/all/20220920100416.959226-2-mkl@pengutronix.de Cc: John Whittington <git@jbrengineering.co.uk> Tested-by: John Whittington <git@jbrengineering.co.uk> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Ziyang Xuan <william.xuanziyang@huawei.com> says: Do some small optimization for can_bcm. v1: https://lore.kernel.org/all/cover.1662606045.git.william.xuanziyang@huawei.com Link: https://lore.kernel.org/all/cover.1663206163.git.william.xuanziyang@huawei.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Ziyang Xuan authored
If can_send() fail, it should not update frames_abs counter in bcm_can_tx(). Add the result check for can_send() in bcm_can_tx(). Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com> Link: https://lore.kernel.org/all/9851878e74d6d37aee2f1ee76d68361a46f89458.1663206163.git.william.xuanziyang@huawei.comAcked-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Ziyang Xuan authored
Now, register_netdevice_notifier() and register_pernet_subsys() are both after can_proto_register(). It can create CAN_BCM socket and process socket once can_proto_register() successfully, so it is possible missing notifier event or proc node creation because notifier or bcm proc directory is not registered or created yet. Although this is a low probability scenario, it is not impossible. Move register_pernet_subsys() and register_netdevice_notifier() to the front of can_proto_register(). In addition, register_pernet_subsys() and register_netdevice_notifier() may fail, check their results are necessary. Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com> Link: https://lore.kernel.org/all/823cff0ebec33fa9389eeaf8b8ded3217c32cb38.1663206163.git.william.xuanziyang@huawei.comAcked-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
David S. Miller authored
Horatiu Vultur says: ==================== net: lan966x: Add mqprio and taprio support Add support for offloading QoS features with tc command to lan966x. The offloaded QoS features are mqprio and taprio. v1->v2: - fix compilation warning - rename lan966x_taprio_enable/disable to lan966x_taprio_add/del ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Horatiu Vultur authored
Lan966x switch supports time-based egress shaping in hardware according to IEEE 802.1Qbv. Add support for TAS configuration on egress port of lan966x switch. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Horatiu Vultur authored
Add registers that are used by taprio to configure the HW. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Horatiu Vultur authored
Implement mqprio qdisc support using tc command. The HW supports 8 priority queues from highest (7) to lowest (0). Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Horatiu Vultur authored
Add a define for the number of priority queues on lan966x. Because there will be more checks for this, so instead of using hardcoded value all over the place add a define for this. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Minghao Chi authored
use kstrdup instead of open-coding it. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Acked-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Golle authored
Read link status from SGMII PCS for in-band managed 2500Base-X and 1000Base-X connection on a MAC port of the MT7531. This is needed to get the SFP cage working which is connected to SGMII interface of port 5 of the MT7531 switch IC on the Bananapi BPi-R3 board. While at it also handle an_complete for both the autoneg and the non-autoneg codepath. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Sean Anderson says: ==================== net: phy: Add support for rate matching This adds support for phy rate matching: when a phy adapts between differing phy interface and link speeds. It was originally submitted as part of [1], which is considered "v1" of this series. Several past discussions [2-4] around adding rate adaptation provide some context. Although in earlier versions of this series, userspace could disable rate matching, now it is only possible to determine the current rate adaptation type. Disabling or otherwise configuring rate adaptation has been left for future work. However, because currently only RATE_MATCH_PAUSE is implemented, it is possible to disable rate adaptation by modifying the advertisement appropriately. [1] https://lore.kernel.org/netdev/20220715215954.1449214-1-sean.anderson@seco.com/T/#t [2] https://lore.kernel.org/netdev/1579701573-6609-1-git-send-email-madalin.bucur@oss.nxp.com/ [3] https://lore.kernel.org/netdev/1580137671-22081-1-git-send-email-madalin.bucur@oss.nxp.com/ [4] https://lore.kernel.org/netdev/20200116181933.32765-1-olteanv@gmail.com/ Changes in v6: - Don't announce that we've enabled pause frames for rate adaptation - Merry Christmas - Rename rate adaptation to rate matching - Reword documentation, (hopefully) taking into account feedback Changes in v5: - Break off patch "net: phy: Add 1000BASE-KX interface mode" for separate submission. - Document phy_rate_adaptation_to_str - Drop patch "Add some helpers for working with mac caps"; it has been incorperated into the autonegotiation patch. - Move phylink_cap_from_speed_duplex to this commit - Rebase onto net-next/master - Remove unnecessary comma Changes in v4: - Export phy_rate_adaptation_to_str - Remove phylink_interface_max_speed, which was accidentally added - Split off the LS1046ARDB 1G fix Changes in v3: - Add phylink_cap_from_speed_duplex to look up the mac capability corresponding to the interface's speed. - Document MAC_(A)SYM_PAUSE - Include RATE_ADAPT_CRS; it's a few lines and it doesn't hurt. - Modify link settings directly in phylink_link_up, instead of doing things more indirectly via link_*. - Move unused defines to next commit (where they will be used) - Remove "Support differing link/interface speed/duplex". It has been rendered unnecessary due to simplification of the rate adaptation patches. Thanks Russell! - Rewrite cover letter to better reflect the opinions of the developers involved Changes in v2: - Add (read-only) ethtool support for rate adaptation - Add comments clarifying the register defines - Add locking to phy_get_rate_adaptation - Always use the rate adaptation setting to determine the interface speed/duplex (instead of sometimes using the interface mode). - Determine the interface speed and max mac speed directly instead of guessing based on the caps. - Move part of commit message to cover letter, as it gives a good overview of the whole series, and allows this patch to focus more on the specifics. - Reorder variables in aqr107_read_rate - Use int/defines instead of enum to allow for use in ioctls/netlink - Use the phy's rate adaptation setting to determine whether to use its link speed/duplex or the MAC's speed/duplex with MLO_AN_INBAND. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sean Anderson authored
This adds support for rate matching for phys similar to the AQR107. We assume that all phys using aqr107_read_status support rate matching. However, it could be possible to determine support based on the firmware revision if there are phys discovered which do not support rate matching. However, as rate matching is advertised in the datasheets for these phys, I suspect it is supported most boards. Despite the name, the "config" registers are updated with the current rate matching method (if any). Because they appear to be updated automatically, I don't know if these registers can be used to disable rate matching. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sean Anderson authored
These are documented in the AQR115 register reference. I haven't tested them, but perhaps they'll be useful to someone. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sean Anderson authored
This adds support for adjusting the advertisement for pause-based rate matching. This may result in a lossy link, since the final link settings are not adjusted. Asymmetric pause support is necessary. It would be possible for a MAC supporting only symmetric pause to use pause-based rate adaptation, but only if pause reception was enabled as well. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sean Anderson authored
If the phy is configured to use pause-based rate matching, ensure that the link is full duplex with pause frame reception enabled. As suggested, if pause-based rate matching is enabled by the phy, then pause reception is unconditionally enabled. The interface duplex is determined based on the rate matching type. When rate matching is enabled, so is the speed. We assume the maximum interface speed is used. This is only relevant for MLO_AN_PHY. For MLO_AN_INBAND, the MAC/PCS's view of the interface speed will be used. Although there are no RATE_ADAPT_CRS phys in-tree, it has been added for comparison (and the implementation is quite simple). Co-developed-by: Russell King <linux@armlinux.org.uk> Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sean Anderson authored
This adds support for rate matching (also known as rate adaptation) to the phy subsystem. The general idea is that the phy interface runs at one speed, and the MAC throttles the rate at which it sends packets to the link speed. There's a good overview of several techniques for achieving this at [1]. This patch adds support for three: pause-frame based (such as in Aquantia phys), CRS-based (such as in 10PASS-TS and 2BASE-TL), and open-loop-based (such as in 10GBASE-W). This patch makes a few assumptions and a few non assumptions about the types of rate matching available. First, it assumes that different phys may use different forms of rate matching. Second, it assumes that phys can use rate matching for any of their supported link speeds (e.g. if a phy supports 10BASE-T and XGMII, then it can adapt XGMII to 10BASE-T). Third, it does not assume that all interface modes will use the same form of rate matching. Fourth, it does not assume that all phy devices will support rate matching (even if some do). Relaxing or strengthening these (non-)assumptions could result in a different API. For example, if all interface modes were assumed to use the same form of rate matching, then a bitmask of interface modes supportting rate matching would suffice. For some better visibility into the process, the current rate matching mode is exposed as part of the ethtool ksettings. For the moment, only read access is supported. I'm not sure what userspace might want to configure yet (disable it altogether, disable just one mode, specify the mode to use, etc.). For the moment, since only pause-based rate adaptation support is added in the next few commits, rate matching can be disabled altogether by adjusting the advertisement. 802.3 calls this feature "rate adaptation" in clause 49 (10GBASE-R) and "rate matching" in clause 61 (10PASS-TL and 2BASE-TS). Aquantia also calls this feature "rate adaptation". I chose "rate matching" because it is shorter, and because Russell doesn't think "adaptation" is correct in this context. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sean Anderson authored
If we call phylink_caps_to_linkmodes directly from phylink_get_linkmodes, it is difficult to re-use this functionality in MAC drivers. This is because MAC drivers must then work with an ethtool linkmode bitmap, instead of with mac capabilities. Instead, let the caller of phylink_get_linkmodes do the conversion. To reflect this change, rename the function to phylink_get_capabilities. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sean Anderson authored
This function is convenient for MAC drivers. They can use it to add or remove particular link modes based on capabilities (such as if half duplex is not supported for a particular interface mode). Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sean Anderson authored
This documents the possible MLO_PAUSE_* settings which can result from different combinations of MAC_(A)SYM_PAUSE. Special note is paid to settings which can result from user configuration (MLO_PAUSE_AN). The autonegotiation results are more-or-less a direct consequence of IEEE 802.3 Table 28B-2. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Arınç ÜNAL says: ==================== dt-bindings and mt7621 devicetree changes This patch series removes old MediaTek bindings, improves mediatek,mt7530 and mt7621 memory controller bindings and improves mt7621 DTs. v4: - Keep memory-controller node name. - Change syscon to memory-controller on mt7621.dtsi. v3: - Explain the mt7621 memory controller binding change in more details. - Remove explaining the remaining DTC warnings from the patch log as there are new schemas submitted for them. v2: - Change memory controller node name to syscon on the schema example. - Keep cpu compatible string and syscon on the memory controller node. - Add Rob and Sergio's tags. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-