Add check of 4-byte address mode support when parsing SFDP 4bait. Some
flash will provide a 4bait table and the spi-nor core will convert the
address mode to 4-byte without checking whether it's actually supported
or not by the controller. For example, the 16M s25fs128s1 provides the
4bait and will be convert to 4-byte address mode, which makes it unusable
on hisi-sfc-v3xx on hip08 platform.
Add the check before convert the address mode when parsing the 4bait will
solve this issue.
Yicong …
[View More]Yang (2):
mtd: spi-nor: check 4-byte address support when parsing 4bait
spi: hisi-sfc-v3xx: add address mode check
drivers/mtd/spi-nor/sfdp.c | 48 +++++++++++++++++++++++++++++++++++++++++
drivers/spi/spi-hisi-sfc-v3xx.c | 25 ++++++++++++++++++++-
2 files changed, 72 insertions(+), 1 deletion(-)
--
2.8.1
[View Less]
Hi ARM-SoC team,
Please consider to pull the following changes.
Thanks!
Best Regards,
Wei
---
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
are available in the git repository at:
git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-for-5.12v2
for you to fetch changes up to b6e141eec86b730dfeddb888af7d3e0247530ef1:
arm64: dts: hisilicon: hi3670.dtsi: add I2C settings (2021-01-29 16:40:07 +0800)
----…
[View More]------------------------------------------------------------
ARM64: DT: Hisilicon ARM64 DT updates for 5.12
- Further cleanups of the hisilicon DTS to align with the dtschema
- Add or update the I2C, pinctrl and reset nodes for Hikey970
----------------------------------------------------------------
Mauro Carvalho Chehab (3):
arm64: dts: hisilicon: hi3670.dtsi: add iomcu_rst
arm64: dts: hisilicon: hikey970-pinctrl.dtsi: add missing pinctrl settings
arm64: dts: hisilicon: hi3670.dtsi: add I2C settings
Zhen Lei (6):
arm64: dts: hisilicon: separate each group of data in the property "ranges"
arm64: dts: hisilicon: place clock-names "bus" before "core"
arm64: dts: hisilicon: normalize the node name of the module thermal
arm64: dts: hisilicon: normalize the node name of the localbus
arm64: dts: hisilicon: avoid irrelevant nodes being mistakenly identified as PHY nodes
arm64: dts: hisilicon: delete unused property smmu-cb-memtype
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 6 +-
arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 77 +++
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 8 +-
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8 +-
.../arm64/boot/dts/hisilicon/hikey970-pinctrl.dtsi | 632 ++++++++++++++++++++-
arch/arm64/boot/dts/hisilicon/hip05.dtsi | 2 +-
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 6 +-
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 9 +-
8 files changed, 714 insertions(+), 34 deletions(-)
[View Less]
Hi Team,
I have a question about bonding. During testing bonding mode 4
scenarios, I find that there is a very low probability that
the pointer is null. The following information is displayed:
[99359.795934] bond0: (slave eth13.2001): Port 2 did not find a suitable aggregator
[99359.796960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
[99359.798127] Mem abort info:
[99359.798526] ESR = 0x96000004
[99359.798938] EC = 0x25: DABT (current EL), IL = 32 …
[View More]bits
[99359.799673] SET = 0, FnV = 0
[99359.800106] EA = 0, S1PTW = 0
[99359.800554] Data abort info:
[99359.800952] ISV = 0, ISS = 0x00000004
[99359.801522] CM = 0, WnR = 0
[99359.801970] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000c64e6000
[99359.802876] [0000000000000020] pgd=0000000000000000
[99359.803555] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[99359.804369] Modules linked in: bonding hns3(-) hclgevf hnae3 [last unloaded: bonding]
[99359.805494] CPU: 1 PID: 951 Comm: kworker/u10:2 Not tainted 5.7.0-rc4+ #1
[99359.806455] Hardware name: linux,dummy-virt (DT)
[99359.807107] Workqueue: bond0 bond_3ad_state_machine_handler [bonding]
[99359.808056] pstate: 60c00005 (nZCv daif +PAN +UAO)
[99359.808722] pc : bond_3ad_state_machine_handler+0x7fc/0xdb8 [bonding]
[99359.809652] lr : bond_3ad_state_machine_handler+0x7f4/0xdb8 [bonding]
[99359.810535] sp : ffff80001882bd20
[99359.811012] x29: ffff80001882bd20 x28: ffff000085939a38
[99359.811791] x27: ffff00008649bb68 x26: 00000000aaaaaaab
[99359.812871] x25: ffff800009401000 x24: ffff800009408de4
[99359.814049] x23: ffff80001882bd98 x22: ffff00008649b880
[99359.815210] x21: 0000000000000000 x20: ffff000085939a00
[99359.816401] x19: ffff00008649b880 x18: ffff800012572988
[99359.817637] x17: 0000000000000000 x16: 0000000000000000
[99359.818870] x15: ffff80009882b987 x14: 726f746167657267
[99359.820090] x13: 676120656c626174 x12: 697573206120646e
[99359.821374] x11: 696620746f6e2064 x10: 696420322074726f
[99359.822659] x9 : 50203a2931303032 x8 : 0000000000081391
[99359.823891] x7 : ffff8000108e3ad0 x6 : ffff8000128858bb
[99359.825109] x5 : 0000000000000000 x4 : 0000000000000000
[99359.826262] x3 : 00000000ffffffff x2 : 906b329bb5362a00
[99359.827394] x1 : 906b329bb5362a00 x0 : 0000000000000000
[99359.828540] Call trace:
[99359.829071] bond_3ad_state_machine_handler+0x7fc/0xdb8 [bonding]
[99359.830367] process_one_work+0x15c/0x4a0
[99359.831216] worker_thread+0x50/0x478
[99359.832022] kthread+0x130/0x160
[99359.832716] ret_from_fork+0x10/0x18
[99359.833487] Code: 910c0021 95f704bb f9403f80 b5ffe300 (f9401000)
[99359.834742] ---[ end trace c7a8e02914afc4e0 ]---
[99359.835817] Kernel panic - not syncing: Fatal exception in interrupt
[99359.837334] SMP: stopping secondary CPUs
[99359.838277] Kernel Offset: disabled
[99359.839086] CPU features: 0x080002,22208218
[99359.840053] Memory Limit: none
[99359.840783] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
The test procedure is as follows:
1. Configure bonding and set it to mode 4.
echo "4" > /sys/class/net/bond0/bonding/mode
ifconfig bond0 up
2. Configure two VLANs and add them to the bonding in step 1.
vconfig add eth0 2001
vconfig add eth1 2001
ifenslave bond0 eth0.2001 eth1.2001
3. Unload the network device driver and bonding driver.
rmmod hns3
rmmod hclge
rmmod hnae3
rmmod bonding.ko
4. Repeat the preceding steps for a long time.
By checking the logic in ad_port_selection_logic(), I find that
if enter the branch "Port %d did not find a suitable aggregator",
the value of port->aggregator will be NULL, causing the problem.
So I'd like to ask what circumstances will be involved in this
branch, and what should be done in this case?
The detailed code analysis is as follows:
static void ad_port_selection_logic(struct port *port, bool *update_slave_arr)
{
[...]
/* if the port is connected to other aggregator, detach it */
if (port->aggregator) {
/* detach the port from its former aggregator */
temp_aggregator = port->aggregator;
for (curr_port = temp_aggregator->lag_ports; curr_port;
last_port = curr_port,
curr_port = curr_port->next_port_in_aggregator) {
if (curr_port == port) {
temp_aggregator->num_of_ports--;
/* if it is the first port attached to the
* aggregator
*/
if (!last_port) {
temp_aggregator->lag_ports =
port->next_port_in_aggregator;
} else {
/* not the first port attached to the
* aggregator
*/
last_port->next_port_in_aggregator =
port->next_port_in_aggregator;
}
/* clear the port's relations to this
* aggregator
*/
port->aggregator = NULL;
----analysis: set port->aggregator NULL at the beginning of ad_port_selection_logic().
port->next_port_in_aggregator = NULL;
port->actor_port_aggregator_identifier = 0;
slave_dbg(bond->dev, port->slave->dev, "Port %d left LAG %d\n",
port->actor_port_number,
temp_aggregator->aggregator_identifier);
/* if the aggregator is empty, clear its
* parameters, and set it ready to be attached
*/
if (!temp_aggregator->lag_ports)
ad_clear_agg(temp_aggregator);
break;
}
}
if (!curr_port) {
/* meaning: the port was related to an aggregator
* but was not on the aggregator port list
*/
net_warn_ratelimited("%s: (slave %s): Warning: Port %d was related to aggregator %d but was not on its port list\n",
port->slave->bond->dev->name,
port->slave->dev->name,
port->actor_port_number,
port->aggregator->aggregator_identifier);
}
}
/* search on all aggregators for a suitable aggregator for this port */
bond_for_each_slave(bond, slave, iter) {
aggregator = &(SLAVE_AD_INFO(slave)->aggregator);
/* keep a free aggregator for later use(if needed) */
if (!aggregator->lag_ports) {
if (!free_aggregator)
free_aggregator = aggregator;
----analysis: Save free_aggregator if found a free aggregator. But in this case, no free aggregator is available.
continue;
}
/* check if current aggregator suits us */
if (((aggregator->actor_oper_aggregator_key == port->actor_oper_port_key) && /* if all parameters match AND */
MAC_ADDRESS_EQUAL(&(aggregator->partner_system), &(port->partner_oper.system)) &&
(aggregator->partner_system_priority == port->partner_oper.system_priority) &&
(aggregator->partner_oper_aggregator_key == port->partner_oper.key)
) &&
((!MAC_ADDRESS_EQUAL(&(port->partner_oper.system), &(null_mac_addr)) && /* partner answers */
!aggregator->is_individual) /* but is not individual OR */
)
) {
/* attach to the founded aggregator */
port->aggregator = aggregator;
----analysis: If a proper aggregator is found, port->aggregator is assigned here.
port->actor_port_aggregator_identifier =
port->aggregator->aggregator_identifier;
port->next_port_in_aggregator = aggregator->lag_ports;
port->aggregator->num_of_ports++;
aggregator->lag_ports = port;
slave_dbg(bond->dev, slave->dev, "Port %d joined LAG %d (existing LAG)\n",
port->actor_port_number,
port->aggregator->aggregator_identifier);
/* mark this port as selected */
port->sm_vars |= AD_PORT_SELECTED;
found = 1;
----analysis: Set found to 1 if port->aggregator is assigned.
break;
}
}
/* the port couldn't find an aggregator - attach it to a new
* aggregator
*/
if (!found) {
if (free_aggregator) {
/* assign port a new aggregator */
port->aggregator = free_aggregator;
----analysis: No proper free_aggregator is found. Therefore, port->aggregator cannot be assigned here.
port->actor_port_aggregator_identifier =
port->aggregator->aggregator_identifier;
/* update the new aggregator's parameters
* if port was responsed from the end-user
*/
if (port->actor_oper_port_key & AD_DUPLEX_KEY_MASKS)
/* if port is full duplex */
port->aggregator->is_individual = false;
else
port->aggregator->is_individual = true;
port->aggregator->actor_admin_aggregator_key =
port->actor_admin_port_key;
port->aggregator->actor_oper_aggregator_key =
port->actor_oper_port_key;
port->aggregator->partner_system =
port->partner_oper.system;
port->aggregator->partner_system_priority =
port->partner_oper.system_priority;
port->aggregator->partner_oper_aggregator_key = port->partner_oper.key;
port->aggregator->receive_state = 1;
port->aggregator->transmit_state = 1;
port->aggregator->lag_ports = port;
port->aggregator->num_of_ports++;
/* mark this port as selected */
port->sm_vars |= AD_PORT_SELECTED;
slave_dbg(bond->dev, port->slave->dev, "Port %d joined LAG %d (new LAG)\n",
port->actor_port_number,
port->aggregator->aggregator_identifier);
} else {
slave_err(bond->dev, port->slave->dev,
"Port %d did not find a suitable aggregator\n",
port->actor_port_number);
----analysis: The fault scenario goes to this branch, and port->aggregator remains NULL.
}
}
/* if all aggregator's ports are READY_N == TRUE, set ready=TRUE
* in all aggregator's ports, else set ready=FALSE in all
* aggregator's ports
*/
__set_agg_ports_ready(port->aggregator,
__agg_ports_are_ready(port->aggregator));
----analysis: port->aggregator is still NULL, which causes problem.
aggregator = __get_first_agg(port);
ad_agg_selection_logic(aggregator, update_slave_arr);
if (!port->aggregator->is_active)
port->actor_oper_port_state &= ~LACP_STATE_SYNCHRONIZATION;
}
Thanks.
[View Less]
This is a collection of misc patches picked up during the latest dev
cycle, targeted at 5.12 .
Features include:
- Some tidy-up from after recent change to expose HW queues on v2 HW
- Add trace FIFO DFX debugfs support
- Flush wq for driver removal
- Add ability to enable debugfs support as a kernel config option
Thanks!
John Garry (2):
scsi: hisi_sas: Remove deferred probe check in hisi_sas_v2_probe()
scsi: hisi_sas: Don't check .nr_hw_queues in hisi_sas_task_prep()
Luo Jiaxing (3):
…
[View More]scsi: hisi_sas: Enable debugfs support by default
scsi: hisi_sas: Flush workqueue in hisi_sas_v3_remove()
scsi: hisi_sas: Add trace FIFO debugfs support
drivers/scsi/hisi_sas/Kconfig | 6 +
drivers/scsi/hisi_sas/hisi_sas.h | 15 ++
drivers/scsi/hisi_sas/hisi_sas_main.c | 19 +-
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 12 --
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 252 +++++++++++++++++++++++++
5 files changed, 286 insertions(+), 18 deletions(-)
--
2.26.2
[View Less]
Hi All,
I'm confusing at the VLAN validation mechanism of RoCEv2.
Assuming that we have two nodes with an HCA that supports RoCE v2. And we add
a VLAN (id = 1) on each nodes, but they are of different network segments. The
IP and VLAN configuration are as follows:
NODE_A NODE_B
+--------+---------------+------+ +--------+---------------+------+
| device | IP | VLAN | | device | IP | VLAN |
+--------+----…
[View More]-----------+------+ +--------+---------------+------+
| eth0 | 192.168.97.1 | 0 | /----| eth0 | 192.168.100.2 | 0 |
+--------+---------------+------+ / +--------+---------------+------+
| eth0.1 | 192.168.100.3 | 1 |---/ | eth0.1 | 192.168.98.2 | 1 |
+--------+---------------+------+ +--------+---------------+------+
Now I try to ping eth0 on NODE_B from eth0.1 on NODE_A, of cource it fails
becauce these devices are using different VLAN ID.
Then I do some tests on RoCE, the first one is a simple RC send test:
NODE_A: ib_send_bw -d mlx5_0 -x 5 (the sgid 5 belongs to eth0.1)
NODE_B: ib_send_bw -d mlx5_0 -x 3 <server ip> (the sgid 3 belongs to eth0)
The result is as expected, the RoCEv2 packet with unmatched VLAN ID was
dropped. I think the reason is that for RC service, the VLAN information
of a QP is recorded in QPC, and the HCA can check it when receiving a packet.
But when I run a simple UD send test:
NODE_A: ib_send_bw -d mlx5_0 -x 5 -c UD (the sgid 5 belongs to eth0.1)
NODE_B: ib_send_bw -d mlx5_0 -x 3 -c UD <server ip> (the sgid 3 belongs to eth0)
The test ends without error successfully. So the question is, RoCEv2 is based
on Ethernet, shouldn't a RoCEv2 node check the VLAN ID of every incoming
packets?
UD is connectionless-oriented, an UD QP won't record VLAN info in it's QPC,
so how to achieve the checking mechanism? Or a UD QP should just ignore the
unmatched VLAN ID?
I didn't find any info from the IB specification, I'd appreciate it if someone
could help explain it.
Thanks
Weihang
[View Less]