+1
−2
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
The fix in commit 1b128703 (gpio/omap: fix missing check in *_runtime_suspend()) exposed another bug in the context restore path. Currently, the per-bank context restore happens whenever the context loss count is different in runtime suspend and runtime resume *and* whenever the per-bank contex_loss_count == 0: if (context_lost_cnt_after != bank->context_loss_count || !context_lost_cnt_after) { omap_gpio_restore_context(bank); Restoring context when the context_lost_cnt_after == 0 is clearly wrong, since this will be true until the first off-mode transition (which could be never, if off-mode is never enabled.) This check causes the context to be restored on *every* runtime PM transition. Before commit 1b128703 (gpio/omap: fix missing check in *_runtime_suspend()), this code was never executed in non-OFF mode, so there were never spurious context restores happening. After that change though, spurious context restores could happen. To fix, simply remove the !context_lost_cnt_after check. It is not needed. This bug was found when noticing that the smc911x NIC on 3530/Overo was not working, and git bisect tracked it down to this patch. It seems that the spurious context restore was causing the smsc911x to not be properly probed on this platform. Tested-by:Tony Lindgren <tony@atomide.com> Acked-by:
Tarun Kanti DebBarma <tarun.kanti@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by:
Kevin Hilman <khilman@ti.com>
CRA Git | Maintained and supported by SUSTech CRA and CCSE