323467 |
11-Sep-2017 |
ian |
MFC r321708-r321712, r321721, r321726-r321727, r321746, r321751, r321791-r321792, r321795, r321798, r321821, r321823, r321826, r321828, r321841, r321934, r322025-r322026, r322282, r322431, r322473, r322475-r322479
Lots of i2c RTC driver stuff...
r321708: Replace the pcf8563 i2c RTC driver with a new nxprtc driver which handles all the chips in the NXP PCA212x and PCA/PCF85xx series. In addition to supporting more chips, this driver uses the countdown timer on the chips as a fractional seconds counter, giving it a resolution of about 15 milliseconds.
r321709: Fix building this driver on non-FDT platforms.
r321710: Add a few missing i2c devices that build fine on all arches.
r321711: Move the device descriptions onto the device lines, so they cut and paste nicely into other config files.
r321712: Add the i2c RTC drivers found on various arm systems.
r321721: Switch from using iic_transfer() to iicdev_readfrom/writeto(), mostly so that transfers will be done with proper ownership of the bus. No behavioral changes.
r321726: Bugfixes and enhancements...
Don't enable the oscillator when it is found to be stopped at init time, just let the first setting of valid time start it. But still report a dead battery if it's stopped at init time.
Don't force the chip into 24hr mode, just cope with whatever mode it is already in.
Align the RTC clock to top of second when setting it.
r321727: Fix AM/PM mode handling. The bits to mask off in the hours register changes between 12/24 hour mode. Also fix conversion between 12 and 24 hour mode. It's not as easy as adding/subtracting 12, because the clock doesn't roll over 11->0, it rolls over 12->1; 0 isn't a valid hour in AM/PM mode.
r321746: Use the new clock_schedule() to arrange for clock_settime() to be called at the right time to keep the RTC hardware time in sync, instead of using pause_sbt() to sleep until the right time.
r321751: Remove now-unused variable.
r321791: Switch from using iic_transfer() to iicdev_readfrom/writeto(), mostly so that transfers will be done with proper ownership of the bus. No behavioral changes. Also add a detach() method.
r321792: Add a detach() method.
r321795: Check the clock-halted flag every time the clock is read, not just once at startup. The flag stays set until the clock is loaded with good time, so we need to keep saying the time is invalid until that happens.
r321798: Restore a few rather important lines of code that got fumbled in r321746.
r321821: No need to call getnanotime() now that the waiting is done by the central subr_rtc code, switch from CLOCKF_SETTIME_NO_TS to CLOCKF_SETTIME_NO_ADJ so that we get fed a timestamp, but it's not adjusted to compensate for inaccuracy in setting time.
r321823: Bugfixes and enhancements...
Don't enable the oscillator when it is found to be stopped at init time, just let the first setting of valid time start it. But still report a dead battery if it's stopped at init time.
Don't force the chip into 24hr mode, just cope with whatever mode it is already in.
Schedule the clock_settime() callbacks to align the RTC clock to top of second when setting it.
r321826: Restructure the SUBDIR list as 1-per-line and alphabetize, so it will be easier to add new things (and see what changed) in the future.
r321828: Build iicbus/{ds1307,ds3231,nxprtc} as modules.
r321841: Add a driver for the Intersil ISL12xx family of i2c RTC chips.
Supports ISL1209, ISL1218, ISL1219, ISL1220, ISL1221 (just basic RTC functionality, not all the other fancy stuff the chips can do).
r321934: Add missing ofw_bus_if.h src file.
r322025: Switch to iicdev_readfrom/writeto() to do xfers with proper bus ownership.
Tested by: manu@
r322026: Add missing header file to SRCS.
Reported by: manu@
r322282: Remove the ds133x and s35390a i2c RTC drivers for now. They both do i2c transfers in their probe() or attach() routines, and that doesn't work when the low-level controller requires interrupts to be functional.
The DS133x family of chips is nearly identical to the DS1307 and support for them should be added to that driver, then the ds133x driver can be deleted. The s35390a driver just needs a non-trivial workover. In both cases that work will be done and committed separately.
r322431: Bid for the device with BUS_PROBE_GENERIC, because this is very much a generic driver with minimal feature support for a large number of chips. More featureful per-chip drivers might exist (especially out-of-tree) and those should win the bidding even if they use BUS_PROBE_DEFAULT.
r322473: Add a new driver, ds13rtc, that handles all DS13xx series i2c RTC chips.
This driver supports only basic timekeeping functionality. It completely replaces the ds133x driver. It can also replace the ds1374 driver, but that will take a few other changes in MIPS code and config, and will be committed separately. It does NOT replace the existing ds1307 driver, which provides access to some of the extended features on the 1307 chip, such as controlling the square wave output signal. If both ds1307 and ds13rtc drivers are present, the ds1307 driver will outbid and win control of the device.
This driver can be configured with FDT data, or by using hints on non-FDT systems. In addition to the standard hints for i2c devices, it requires a "chiptype" string of the form "dallas,ds13xx" where 'xx' is the chip id (i.e., the same format as FDT compat strings).
r322475: Change "chiptype" to "compatible". Making the hint name the same as the FDT property name should make it easier to document the list of names accepted by both configuration mechanisms.
r322476: Remove the old ds1374 driver and use the ds13rtc driver instead. Adjust several mips config files accordingly.
r322477: Minor fixes and enhancements for the s35390a i2c RTC driver...
- Add FDT probe code. - Do i2c transfers with exclusive bus ownership. - Use config_intrhook_oneshot() to defer chip setup because some i2c busses can't do transfers without interrupts. - Add a detach() routine. - Add to module build.
r322478: Add back the drivers for Dallas/Maxim ds13xx and Seiko S35390x now that they've been rewritten/fixed to not cause panics by doing i2c transfers before interrupts are available.
PR: 221227
r322479: Add hinted attachment for non-FDT systems. Also, print a message if setting up the timer fails, because on some types of chips that's the first attempt to access the device. If the chip is missing/non-responsive then you'd get a driver that attached and didn't register the rtc, with no clue about why. On other chip types there are inits that come before timer setup, and they already print messages about errors. |
297000 |
18-Mar-2016 |
jhibbits |
Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.
On some architectures, u_long isn't large enough for resource definitions. Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but type `long' is only 32-bit. This extends rman's resources to uintmax_t. With this change, any resource can feasibly be placed anywhere in physical memory (within the constraints of the driver).
Why uintmax_t and not something machine dependent, or uint64_t? Though it's possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on 32-bit architectures. 64-bit architectures should have plenty of RAM to absorb the increase on resource sizes if and when this occurs, and the number of resources on memory-constrained systems should be sufficiently small as to not pose a drastic overhead. That being said, uintmax_t was chosen for source clarity. If it's specified as uint64_t, all printf()-like calls would either need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t aren't horrible, but it would also bake into the API for resource_list_print_type() either a hidden assumption that entries get cast to uintmax_t for printing, or these calls would need the PRI*64 macros. Since source code is meant to be read more often than written, I chose the clearest path of simply using uintmax_t.
Tested on a PowerPC p5020-based board, which places all device resources in 0xfxxxxxxxx, and has 8GB RAM. Regression tested on qemu-system-i386 Regression tested on qemu-system-mips (malta profile)
Tested PAE and devinfo on virtualbox (live CD)
Special thanks to bz for his testing on ARM.
Reviewed By: bz, jhb (previous) Relnotes: Yes Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D4544
|
275732 |
12-Dec-2014 |
jmg |
Add some new modes to OpenCrypto. These modes are AES-ICM (can be used for counter mode), and AES-GCM. Both of these modes have been added to the aesni module.
Included is a set of tests to validate that the software and aesni module calculate the correct values. These use the NIST KAT test vectors. To run the test, you will need to install a soon to be committed port, nist-kat that will install the vectors. Using a port is necessary as the test vectors are around 25MB.
All the man pages were updated. I have added a new man page, crypto.7, which includes a description of how to use each mode. All the new modes and some other AES modes are present. It would be good for someone else to go through and document the other modes.
A new ioctl was added to support AEAD modes which AES-GCM is one of them. Without this ioctl, it is not possible to test AEAD modes from userland.
Add a timing safe bcmp for use to compare MACs. Previously we were using bcmp which could leak timing info and result in the ability to forge messages.
Add a minor optimization to the aesni module so that single segment mbufs don't get copied and instead are updated in place. The aesni module needs to be updated to support blocked IO so segmented mbufs don't have to be copied.
We require that the IV be specified for all calls for both GCM and ICM. This is to ensure proper use of these functions.
Obtained from: p4: //depot/projects/opencrypto Relnotes: yes Sponsored by: FreeBSD Foundation Sponsored by: NetGate
|
263102 |
13-Mar-2014 |
glebius |
Since 32-bit if_baudrate isn't enough to describe a baud rate of a 10 Gbit interface, in the r241616 a crutch was provided. It didn't work well, and finally we decided that it is time to break ABI and simply make if_baudrate a 64-bit value. Meanwhile, the entire struct if_data was reviewed.
o Remove the if_baudrate_pf crutch.
o Make all fields of struct if_data fixed machine independent size. The notion of data (packet counters, etc) are by no means MD. And it is a bug that on amd64 we've got a 64-bit counters, while on i386 32-bit, which at modern speeds overflow within a second.
This also removes quite a lot of COMPAT_FREEBSD32 code.
o Give 16 bit for the ifi_datalen field. This field was provided to make future changes to if_data less ABI breaking. Unfortunately the 8 bit size of it had effectively limited sizeof if_data to 256 bytes.
o Give 32 bits to ifi_mtu and ifi_metric. o Give 64 bits to the rest of fields, since they are counters.
__FreeBSD_version bumped.
Discussed with: emax Sponsored by: Netflix Sponsored by: Nginx, Inc.
|
222813 |
07-Jun-2011 |
attilio |
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever value. Anyway, as long as several structures in the kernel are statically allocated and sized as MAXCPU, it is suggested to keep it as low as possible for the time being.
Technical notes on this commit itself: - More functions to handle with cpuset_t objects are introduced. The most notable are cpusetobj_ffs() (which calculates a ffs(3) for a cpuset_t object), cpusetobj_strprint() (which prepares a string representing a cpuset_t object) and cpusetobj_strscan() (which creates a valid cpuset_t starting from a string representation). - pc_cpumask and pc_other_cpus are target to be removed soon. With the moving from cpumask_t to cpuset_t they are now inefficient and not really useful. Anyway, for the time being, please note that access to pcpu datas is protected by sched_pin() in order to avoid migrating the CPU while reading more than one (possible) word - Please note that size of cpuset_t objects may differ between kernel and userland. While this is not directly related to the patch itself, it is good to understand that concept and possibly use the patch as a reference on how to deal with cpuset_t objects in userland, when accessing kernland members. - KTR_CPUMASK is changed and now is represented through a string, to be set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but private testing has been done until to MAXCPU=128 on a real 8x8x2(htt) machine (amd64).
Please note that the FreeBSD version is not yet bumped because of the upcoming pcpu changes. However, note that this patch is not targeted for MFC.
People to thank for the time spent on this patch: - sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested several revision of the patches and really helped in improving stability of this work. - marius fixed several bugs in the sparc64 implementation and reviewed patches related to ktr. - jeff and jhb discussed the basic approach followed. - kib and marcel made targeted review on some specific part of the patch. - marius, art, nwhitehorn and andreast reviewed MD specific part of the patch. - marius, andreast, gonzo, nwhitehorn and jceel tested MD specific implementations of the patch. - Other people have made contributions on other patches that have been already committed and have been listed separately.
Companies that should be mentioned for having participated at several degrees: - Yahoo! for having offered the machines used for testing on big count of CPUs. - The FreeBSD Foundation for having sponsored my devsummit attendance, which has been instrumental. - Sandvine for having offered offices and infrastructure during development.
(I really hope I didn't forget anyone, if it happened I apologize in advance).
|
215701 |
22-Nov-2010 |
dim |
After some off-list discussion, revert a number of changes to the DPCPU_DEFINE and VNET_DEFINE macros, as these cause problems for various people working on the affected files. A better long-term solution is still being considered. This reversal may give some modules empty set_pcpu or set_vnet sections, but these are harmless.
Changes reverted:
------------------------------------------------------------------------ r215318 | dim | 2010-11-14 21:40:55 +0100 (Sun, 14 Nov 2010) | 4 lines
Instead of unconditionally emitting .globl's for the __start_set_xxx and __stop_set_xxx symbols, only emit them when the set_vnet or set_pcpu sections are actually defined.
------------------------------------------------------------------------ r215317 | dim | 2010-11-14 21:38:11 +0100 (Sun, 14 Nov 2010) | 3 lines
Apply the STATIC_VNET_DEFINE and STATIC_DPCPU_DEFINE macros throughout the tree.
------------------------------------------------------------------------ r215316 | dim | 2010-11-14 21:23:02 +0100 (Sun, 14 Nov 2010) | 2 lines
Add macros to define static instances of VNET_DEFINE and DPCPU_DEFINE.
|
213893 |
15-Oct-2010 |
marius |
Convert the PHY drivers to honor the mii_flags passed down and convert the NIC drivers as well as the PHY drivers to take advantage of the mii_attach() introduced in r213878 to get rid of certain hacks. For the most part these were: - Artificially limiting miibus_{read,write}reg methods to certain PHY addresses; we now let mii_attach() only probe the PHY at the desired address(es) instead. - PHY drivers setting MIIF_* flags based on the NIC driver they hang off from, partly even based on grabbing and using the softc of the parent; we now pass these flags down from the NIC to the PHY drivers via mii_attach(). This got us rid of all such hacks except those of brgphy() in combination with bce(4) and bge(4), which is way beyond what can be expressed with simple flags.
While at it, I took the opportunity to change the NIC drivers to pass up the error returned by mii_attach() (previously by mii_phy_probe()) and unify the error message used in this case where and as appropriate as mii_attach() actually can fail for a number of reasons, not just because of no PHY(s) being present at the expected address(es).
Reviewed by: jhb, yongari
|
211893 |
27-Aug-2010 |
jchandra |
Revamp XLR interrupt handling, the previous scheme does not work well on SMP.
We used to route all PIC based interrupts to cpu 0, and used the per-CPU interrupt mask to enable/disable interrupts. But the interrupt threads can run on any cpu on SMP, and the interrupt thread will re-enable the interrupts on the CPU it runs on when it is done, and not on cpu0 where the PIC will still send interrupts to.
The fix is move the disable/enable for PIC based interrupts to PIC, we will ack on PIC only when the interrupt thread is done, and we do not use the per-CPU interrupt mask.
The changes also introduce a way for subsystems to add a function that will be called to clear the interrupt on the subsystem. Currently This is used by the PCI/PCIe for doing additional work during the interrupt handling.
|