FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F12.3.0 2021-10-06T06:22:59Z 2021-10-06T06:22:59Z Gordon Bergling gbe@FreeBSD.org 2021-10-02T08:47:21Z urn:sha1:5a3a8be94a2e24f004a455faddb44403af38fba0 - s/setings/settings/ (cherry picked from commit fafb1c574d43b8c3acb510d925f599fee461c039) 2019-12-21T16:16:43Z Mark Johnston markj@FreeBSD.org 2019-12-21T16:16:43Z urn:sha1:5d7d470f08abeb4b494def0f82a80e414faa65f4 vnic: Relax PHY node matching after r336281. PR: 242654 2019-09-02T00:37:59Z Ed Maste emaste@FreeBSD.org 2019-09-02T00:37:59Z urn:sha1:893c7b6903888889be0df568483a4beef37c623a Reported by: Dr Silvio Cesare of InfoSect Sponsored by: The FreeBSD Foundation 2018-07-14T16:06:53Z Mark Johnston markj@FreeBSD.org 2018-07-14T16:06:53Z urn:sha1:f6982511f867bdcfcf85e25d6a2c8950f880e723 In some cases it seems that the PHY mode can only be identified by matching against the corresponding device node name in the FDT. r334880 broke this for the case where the node name contains a unit address. Fix the problem by allowing a match in that case. Reviewed by: andrew, sbruno Tested by: sbruno Differential Revision: https://reviews.freebsd.org/D16259 2018-06-09T14:47:49Z Andrew Turner andrew@FreeBSD.org 2018-06-09T14:47:49Z urn:sha1:c11862c030e4aa13688d367521e3988d17c69941 when parsing the phy type, however this is included in the length returned by OF_getprop. To fix this stop ignoring the terminator. PR: 228828 Reported by: sbruno Sponsored by: DARPA, AFRL 2018-04-09T22:06:16Z Oleksandr Tymoshenko gonzo@FreeBSD.org 2018-04-09T22:06:16Z urn:sha1:f7604b1b275455fc5506c3c83a4876f567bbc6b3 Change OF_getencprop_alloc semantics to be combination of malloc and OF_getencprop and return size of the property, not number of elements allocated. For the use cases where number of elements is preferred introduce OF_getencprop_alloc_multi helper function that copies semantics of OF_getencprop_alloc prior to this change. This is to make OF_getencprop_alloc and OF_getencprop_alloc_multi function signatures consistent with OF_getencprop_alloc and OF_getencprop_alloc_multi. Functionality-wise this patch is mostly rename of OF_getencprop_alloc to OF_getencprop_alloc_multi except two calls in ofw_bus_setup_iinfo where 1 was used as a block size. 2018-04-08T22:59:34Z Oleksandr Tymoshenko gonzo@FreeBSD.org 2018-04-08T22:59:34Z urn:sha1:217d17bcd3f525fbdf124cfbc926f8033da69805 OF_getprop_alloc takes element size argument and returns number of elements in the property. There are valid use cases for such behavior but mostly API consumers pass 1 as element size to get string properties. What API users would expect from OF_getprop_alloc is to be a combination of malloc + OF_getprop with the same semantic of return value. This patch modifies API signature to match these expectations. For the valid use cases with element size != 1 and to reduce modification scope new OF_getprop_alloc_multi function has been introduced that behaves the same way OF_getprop_alloc behaved prior to this patch. Reviewed by: ian, manu Differential Revision: https://reviews.freebsd.org/D14850 2018-03-20T00:03:49Z Oleksandr Tymoshenko gonzo@FreeBSD.org 2018-03-20T00:03:49Z urn:sha1:108117cc22335234f817584a42704258209ca78c OF_finddevices returns ((phandle_t)-1) in case of failure. Some code in existing drivers checked return value to be equal to 0 or less/equal to 0 which is also wrong because phandle_t is unsigned type. Most of these checks were for negative cases that were never triggered so trhere was no impact on functionality. Reviewed by: nwhitehorn MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D14645 2018-01-21T15:42:36Z Pedro F. Giffuni pfg@FreeBSD.org 2018-01-21T15:42:36Z urn:sha1:ac2fffa4b74cd83963f0d462c379c7f50eeabf20 Uses of mallocarray(9). The use of mallocarray(9) has rocketed the required swap to build FreeBSD. This is likely caused by the allocation size attributes which put extra pressure on the compiler. Given that most of these checks are superfluous we have to choose better where to use mallocarray(9). We still have more uses of mallocarray(9) but hopefully this is enough to bring swap usage to a reasonable level. Reported by: wosch PR: 225197 2018-01-13T22:30:30Z Pedro F. Giffuni pfg@FreeBSD.org 2018-01-13T22:30:30Z urn:sha1:26c1d774b55c4db79bca772941883244986e6f44 Focus on code where we are doing multiplications within malloc(9). None of these is likely to overflow, however the change is still useful as some static checkers can benefit from the allocation attributes we use for mallocarray. This initial sweep only covers malloc(9) calls with M_NOWAIT. No good reason but I started doing the changes before r327796 and at that time it was convenient to make sure the sorrounding code could handle NULL values.