Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nvme: Do a clean NVMe shutdown #1

Closed
wants to merge 3 commits into from
Closed

nvme: Do a clean NVMe shutdown #1

wants to merge 3 commits into from

Conversation

marcan
Copy link
Member

@marcan marcan commented Mar 2, 2022

The brute-force controller disable method can end up racing controller
initilization and causing a crash when we shut down Apple ANS2 NVMe
controllers. Do a proper controlled shutdown, which does block until
things are quiesced properly.

Signed-off-by: Hector Martin marcan@marcan.st

kettenis and others added 3 commits February 28, 2022 22:22
When the device tree indicates support for role switching through
the "usb-role-switch" property, take the "role-switch-default-mode"
property into account when deciding which role to put the
controller into.

This makes USB devices work on Apple M1 systems where the device
tree may include a "dr_mode" property that is set to "otg", but
where we need to put the controller into "host" mode to see
devices connected to the type-C ports.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
This synchronizes the device trees with those that are in the
process of being upstreamed into Linux. These now match the
current state of the device trees on the asahi branch of the
Asahi Linux github repository.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
The brute-force controller disable method can end up racing controller
initilization and causing a crash when we shut down Apple ANS2 NVMe
controllers. Do a proper controlled shutdown, which does block until
things are quiesced properly.

Signed-off-by: Hector Martin <marcan@marcan.st>
@kettenis kettenis force-pushed the asahi branch 3 times, most recently from 3d69392 to 7d52d11 Compare March 4, 2022 22:48
@kettenis kettenis force-pushed the asahi branch 2 times, most recently from 65dd76b to 64cabe2 Compare March 11, 2022 19:49
@kettenis
Copy link
Collaborator

Cherry picked the relevant commit from this PR.

@kettenis kettenis closed this Mar 11, 2022
kettenis pushed a commit that referenced this pull request Sep 6, 2022
There are three different kinds of EEPROM possibly present on boards.
  1. 1byte address. For those we should avoid 2byte address in order
     not to rewrite the data. Second byte of the address can potentially
     be interpreted as the data to write.
  2. 2byte address with defined behaviour. When we try to use 1byte
     address they just return "FF FF FF FF ... FF"
  3. 2byte address with undefined behaviour (for instance, 24LC32AI).
     When we try to use 1byte address, then their internal read
     pointer is changed to some value. Subsequential reads may be
     broken.

To gracefully handle both case #1 and case #3 we read all required
data from EEPROM at once (about 80 bytes). So either all the data is
valid or we fallback to 2byte address.

Cc: Nishanth Menon <nm@ti.com>
Fixes: a58147c ("board: ti: common: board_detect: Do 1byte address checks first.")
Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Acked-by: Nishanth Menon <nm@ti.com>
kettenis pushed a commit that referenced this pull request Jul 10, 2023
Since commit de39dc7 ("arm: armv7-a: Compile and tune for armv7-a
instead of armv5") is used -march=armv7-a option for Omap3 platforms.

With directive ".arch_extension sec" it is possible for -march=armv7-a to
directly use ARM SMC instruction.

So enable ".arch_extension sec" in Omap3 lowlevel_init.S and replace hand
assembled ".word 0xe1600071" by "SMC #1".

Since commit 51d0638 ("arm: omap-common: add secure smc entry") same
pattern is already used in arch/arm/cpu/armv7/omap-common/lowlevel_init.S.

Signed-off-by: Pali Rohár <pali@kernel.org>
marcan pushed a commit that referenced this pull request Oct 26, 2023
Add support for the USB 3.0 devices in rk3588:
- USB DRD(dual role device) 3.0 #0 as usbdrd3_0 which is available in
rk3588s
- USB DRD(dual role device) 3.0 #1 as usbdrd3_1 which is available in
rk3588 only
- USB DP PHY (combo USB3.0 and DisplayPort Alt Mode ) #0 phy interface
as usbdp_phy0
- USB DP PHY (combo USB3.0 and DisplayPort Alt Mode ) #1 phy interface
as usbdp_phy1
- USB 2.0 phy #2 , the USB 3.0 device can work with this phy in USB 2.0
mode
- associated GRFs (general register files) for the devices.

Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
[eugen.hristev@collabora.com: move nodes to right place, adapt from latest
linux kernel]
Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants