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

Asus Transformers patchset #119

Merged
merged 3 commits into from
Jan 22, 2022
Merged

Asus Transformers patchset #119

merged 3 commits into from
Jan 22, 2022

Conversation

clamor-s
Copy link
Contributor

No description provided.

Refer to 9ab9ecd.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
@@ -1469,6 +1471,8 @@
interrupt-parent = <&gpio>;
interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "host-wake";

reset-gpios = <&gpio TEGRA_GPIO(D, 3) GPIO_ACTIVE_LOW>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please explain how this was tested? This "reset-gpios" isn't used by the kernel's brcmfmac driver, AFAICS.

  1. I see that Chagall and Ouya use D3 in the wifi_pwrseq, it's likely to be correct.
  2. You need to check whether toggling D4 makes a real difference (WiFi doesn't work without enabling it) because this gpio may be physically unconnected on Transformers, similarly to other Tegra devices where reset gpio is connected to both RST and PWR-enb pins of BCM WiFi (Acer A500, Nexus7 and etc).
  3. If D4 really works, then it should be specified as vmmc-supply and D3 should go to the pwrseq.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then why this property is in yaml? There was tests a while ago. wifi_pwrseq uses D4, and vmmc-supply is D0. D3 as I remember did not make any difference, although downstream uses it as reset gpio (https://github.com/clamor-s/morpheus_kernel_asus_tf201/blob/kernel-rework/arch/arm/mach-tegra/board-cardhu-sdhci.c#L38). This is to your choice.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Downstream kernel specifies GPIOs for all board variants, some of those GPIOs may do nothing depending on a board. If D3 does nothing on Transformers, then we shouldn't use it.

I'll merge this PR and drop this patch on rebase.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure

Comment on lines -15 to +17
mmc0 = "/mmc@78000600"; /* eMMC */
mmc1 = "/mmc@78000000"; /* uSD slot */
mmc2 = "/mmc@78000400"; /* WiFi */
mmc0 = &sdmmc4; /* eMMC */
mmc1 = &sdmmc1; /* uSD slot */
mmc2 = &sdmmc3; /* WiFi */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All such label changes should be squashed into a single patch and applied to all boards uniformly. I'll keep this patch in grate-kernel for now, but it will need to be extended if we'll want to merge it into upstream. You may continue working on it with further patches.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only tf has this change, tf101 and chagall have labels, but t30 transformers for some reasons did not fit. Idk why.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was in this way when sent to upstream, but reviewers decided to change it. I wonder why?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thierryreding didn't want to apply patch that added labels to dtsi because some labels were unused.

@digetx
Copy link
Member

digetx commented Jan 22, 2022

Thanks!

@digetx digetx merged commit 79b46ff into grate-driver:master Jan 22, 2022
@clamor-s clamor-s deleted the patch branch January 27, 2022 18:54
okias pushed a commit to okias/linux that referenced this pull request Jan 11, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  grate-driver#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  grate-driver#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  grate-driver#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  grate-driver#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  grate-driver#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  grate-driver#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  grate-driver#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  grate-driver#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  grate-driver#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  grate-driver#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  grate-driver#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  grate-driver#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  #486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
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.

3 participants