+26
−26
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
The current code for checking and fixing the weekday in ds1307_probe faces some issues: - This check is applied to all chips even if its applicable (AFAIK) to mcp794xx only - The check uses MCP794XX constants for registers and bits even though it's executed also on other chips (ok, this could be fixed easily) - It relies on tm_wday being properly populated when core calls set_time and set_alarm. This is not guaranteed at all. First two issue we could solve by moving the check to the mcp794xx-specific initialization (where also VBATEN flag is set). The proposed alternative is in the set_alarm path for mcp794xx only and calculates the alarm weekday based on the current weekday in the RTC timekeeping regs and the difference between alarm date and current date. So we are fine with any weekday even if it doesn't match the date. Still there are cases where this could fail, e.g.: - rtc date/time + weekday have power-on-reset default values - alarm is set to actual date/time + x - set_time is called (may change diff between rtc weekday and actual weekday) But similar issues we have with the current code too: - rtc date/time + weekday have power-on-reset default values - alarm is set to rtc date/time + x - set_time is called before the alarm triggers Using random rtc date/time with relative alarms simply can interfere with set_time. I'm not totally convinced of either option yet. Signed-off-by:Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com>
CRA Git | Maintained and supported by SUSTech CRA and CCSE