/* * linux/fs/isofs/util.c */ #include #include "isofs.h" /* * We have to convert from a MM/DD/YY format to the Unix ctime format. * We have to take into account leap years and all of that good stuff. * Unfortunately, the kernel does not have the information on hand to * take into account daylight savings time, but it shouldn't matter. * The time stored should be localtime (with or without DST in effect), * and the timezone offset should hold the offset required to get back * to GMT. Thus we should always be correct. */ int iso_date(char * p, int flag) { int year, month, day, hour, minute, second, tz; int crtime; year = p[0]; month = p[1]; day = p[2]; hour = p[3]; minute = p[4]; second = p[5]; if (flag == 0) tz = p[6]; /* High sierra has no time zone */ else tz = 0; if (year < 0) { crtime = 0; } else { crtime = mktime64(year+1900, month, day, hour, minute, second); /* sign extend */ if (tz & 0x80) tz |= (-1 << 8); /* * The timezone offset is unreliable on some disks, * so we make a sanity check. In no case is it ever * more than 13 hours from GMT, which is 52*15min. * The time is always stored in localtime with the * timezone offset being what get added to GMT to * get to localtime. Thus we need to subtract the offset * to get to true GMT, which is what we store the time * as internally. On the local system, the user may set * their timezone any way they wish, of course, so GMT * gets converted back to localtime on the receiving * system. * * NOTE: mkisofs in versions prior to mkisofs-1.10 had * the sign wrong on the timezone offset. This has now * been corrected there too, but if you are getting screwy * results this may be the explanation. If enough people * complain, a user configuration option could be added * to add the timezone offset in with the wrong sign * for 'compatibility' with older discs, but I cannot see how * it will matter that much. * * Thanks to kuhlmav@elec.canterbury.ac.nz (Volker Kuhlmann) * for pointing out the sign error. */ if (-52 <= tz && tz <= 52) crtime -= tz * 15 * 60; } return crtime; } 3e0fba427fb85317900e93c74e3be02a'>diff
path: root/drivers/usb/musb/da8xx.c
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2017-02-01 12:46:17 -0500
committerDavid S. Miller <davem@davemloft.net>2017-02-01 12:46:17 -0500
commit889711a03e0fba427fb85317900e93c74e3be02a (patch)
tree05af2eda6502a95cf11935cce1e9b25a1340e7ca /drivers/usb/musb/da8xx.c
parentff1176f6164f3d151ee64c05d3f7b6662a81b982 (diff)
parent7243a1af37a4dc9225004546d9d0756c529ad3ce (diff)
Merge tag 'wireless-drivers-next-for-davem-2017-02-01' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says: ==================== wireless-drivers-next patches for 4.11 It's nice to see rt2x00 development has becoming active, for example adding support for a new chip version. Also wcn36xx has been converted to use the recently merged QCOM_SMD subsystem. Otherwise new features and fixes it lots of drivers. Major changes: iwlwifi * some more work in preparation for A000 family support * add support for radiotap timestamps * some work on our firmware debugging capabilities wcn36xx * convert to a proper QCOM_SMD driver (from the platform_driver interface) ath10k * VHT160 support * dump Copy Engine registers during firmware crash * search board file extension from SMBIOS wil6210 * add disable_ap_sme module parameter rt2x00 * support RT3352 with external PA * support for RT3352 with 20MHz crystal * add support for RT5350 WiSoC brcmfmac * add support for BCM43455 sdio device rtl8xxxu * add support for D-Link DWA-131 rev E1, TP-Link TL-WN822N v4 and others ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/usb/musb/da8xx.c')