+2
−3
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
Cherry-picked from dtc upstream commit e1f139ea4900fd0324c646822b4061fec6e08321. Having a 'bus-range' property for PCI bridges should not be required, so remove the warning when missing. There was some confusion with the Linux kernel printing a message that no property is present and the OS assigned the bus number. This message was intended to be informational rather than a warning. When the firmware doesn't enumerate the PCI bus and leaves it up to the OS to do, then it is perfectly fine for the OS to assign bus numbers and bus-range is not necessary. There are a few cases where bus-range is needed or useful as Arnd Bergmann summarized: - Traditionally Linux avoided using multiple PCI domains, but instead configured separate PCI host bridges to have non-overlapping bus ranges so we can present them to user space as a single domain, and run the kernel without CONFIG_PCI_DOMAINS. Specifying the bus ranges this way would and give stable bus numbers across boots when the probe order is not fixed. - On certain ARM64 systems, we must only use the first 128 bus numbers based on the way the IOMMU identifies the device with truncated bus/dev/fn number. There are probably others like this, with various limitations. - To leave some room for hotplugged devices, each slot on a host bridge can in theory get a range of bus numbers that are available when assigning bus numbers at boot time Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:Rob Herring <robh@kernel.org> Signed-off-by:
David Gibson <david@gibson.dropbear.id.au>
CRA Git | Maintained and supported by SUSTech CRA and CCSE