| /linux-6.3-rc2/drivers/rtc/ |
| A D | rtc-bd70528.c | 35 u8 week; member
69 r->week &= ~BD70528_MASK_RTC_WEEK; in tm2rtc()
83 r->week |= bin2bcd(t->tm_wday); in tm2rtc()
105 t->tm_wday = bcd2bin(r->week & BD70528_MASK_RTC_WEEK); in rtc2tm()
|
| A D | rtc-ds1742.c | 84 unsigned int year, month, day, hour, minute, second, week; in ds1742_rtc_read_time() local
96 week = readb(ioaddr + RTC_DAY) & RTC_DAY_MASK; in ds1742_rtc_read_time()
105 tm->tm_wday = bcd2bin(week); in ds1742_rtc_read_time()
|
| A D | rtc-ds1553.c | 99 unsigned int year, month, day, hour, minute, second, week; in ds1553_rtc_read_time() local
111 week = readb(ioaddr + RTC_DAY) & RTC_DAY_MASK; in ds1553_rtc_read_time()
120 tm->tm_wday = bcd2bin(week); in ds1553_rtc_read_time()
|
| A D | rtc-stk17ta8.c | 98 unsigned int year, month, day, hour, minute, second, week; in stk17ta8_rtc_read_time() local
113 week = readb(ioaddr + RTC_DAY) & RTC_DAY_MASK; in stk17ta8_rtc_read_time()
122 tm->tm_wday = bcd2bin(week); in stk17ta8_rtc_read_time()
|
| A D | rtc-ds3232.c | 103 unsigned int week, twelve_hr, am_pm; in ds3232_read_time() local
113 week = buf[3]; in ds3232_read_time()
139 time->tm_wday = bcd2bin(week) - 1; in ds3232_read_time()
|
| /linux-6.3-rc2/Documentation/process/ |
| A D | maintainer-netdev.rst | 41 two week "merge window" where the main maintainers feed their new stuff
45 expected. After roughly a week of collecting fixes to the rc1 content,
48 state of churn), and a week after the last vX.Y-rcN was done, the
57 the dev cycle. If it was tagged rc7 a week ago, then a release is
75 Relating that to kernel development: At the beginning of the 2-week
|
| A D | kernel-docs.rst | 134 produced during the week.
|
| A D | handling-regressions.rst | 173 together for at least one week before Linus releases a new mainline version.
181 * Aim to fix regressions within one week after the culprit was identified, if
325 which regzbot normally sends out once a week on Sunday evening (UTC), which is a
|
| A D | maintainer-tip.rst | 411 window or even during the week before. Such patches should be submitted in
412 mergeable state *at* *least* a week before the merge window opens.
|
| A D | howto.rst | 249 - As soon as a new kernel is released a two week window is open,
268 release a new -rc kernel every week.
|
| A D | submitting-patches.rst | 339 receive comments within a week or so; if that does not happen, make sure
341 one week before resubmitting or pinging reviewers - possibly longer during
|
| A D | 2.Process.rst | 68 time. Linus releases new -rc kernels about once a week; a normal series
|
| /linux-6.3-rc2/tools/edid/ |
| A D | edid.S | 72 week: .byte WEEK label
|
| /linux-6.3-rc2/Documentation/doc-guide/ |
| A D | maintainer-profile.rst | 45 have not heard back within a week of sending a patch.
|
| /linux-6.3-rc2/Documentation/mm/damon/ |
| A D | maintainer-profile.rst | 52 hesitate to send a ping if you have not heard back within a week of sending a
|
| /linux-6.3-rc2/Documentation/nvdimm/ |
| A D | maintainer-entry-profile.rst | 57 In general, please wait up to one week before pinging for feedback. A
|
| /linux-6.3-rc2/Documentation/maintainer/ |
| A D | maintainer-entry-profile.rst | 58 week) that patches might be considered for merging and when patches need to
|
| /linux-6.3-rc2/drivers/video/fbdev/core/ |
| A D | fbmon.c | 303 specs->week = block[8]; in parse_vendor_block()
307 DPRINTK(" Year: %u Week %u\n", specs->year, specs->week); in parse_vendor_block()
|
| /linux-6.3-rc2/Documentation/arm/ |
| A D | arm.rst | 146 last week :-)
|
| /linux-6.3-rc2/include/linux/ |
| A D | fb.h | 75 __u32 week; /* Week Manufactured */ member
|
| /linux-6.3-rc2/Documentation/networking/device_drivers/ethernet/3com/ |
| A D | vortex.rst | 456 end up working on this problem for a week or more as the maintainer
|
| /linux-6.3-rc2/Documentation/scsi/ |
| A D | aic7xxx.rst | 396 408-957-2550, 24 hours a day, 7 days a week.
|
| A D | aic79xx.rst | 532 408-957-2550, 24 hours a day, 7 days a week.
|
| /linux-6.3-rc2/Documentation/bpf/ |
| A D | bpf_devel_QA.rst | 225 at the end of the week. In some cases pull requests could additionally
226 come also in the middle of the week depending on the current patch
|
| /linux-6.3-rc2/Documentation/admin-guide/ |
| A D | reporting-issues.rst | 819 cycle then is in its two-week long 'merge window'. The bulk of the changes and
866 are older than a week, as new mainline and stable kernels typically get released
867 at least once a week.
1344 should wait a week at maximum (or just two days if it's something urgent)
1435 If the second reminder again results in no reaction within a week, try to
1488 kernel.org front page for a week or two, but are unsuitable for testing and
|