FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F12.4 2020-02-20T01:42:11Z 2020-02-20T01:42:11Z Konstantin Belousov kib@FreeBSD.org 2020-02-20T01:42:11Z urn:sha1:697a9a2476efd65f989165d464537d7347a4aa0c amdsbwd, intpm: Add Hygon Dhyana support. 2019-06-06T11:38:53Z Andriy Gapon avg@FreeBSD.org 2019-06-06T11:38:53Z urn:sha1:b28f237bc53416d07673fb6d523d7c3d7069d581 PIIX4_SMBHSTSTAT_ERR can be set for several reasons that, unfortunately, cannot be distinguished, but the most typical case is a missing or hung slave (SMB_ENOACK). PIIX4_SMBHSTSTAT_FAIL means failed or killed / aborted transaction, so it's previous mapping to SMB_ENOACK was not ideal. After this change an smb(4) access to a missing slave results in ENXIO rather than EIO. To me, that seems to be more appropriate. 2018-09-26T17:12:14Z Warner Losh imp@FreeBSD.org 2018-09-26T17:12:14Z urn:sha1:329e817fcc97aa847765c5171cc89a81a0b25527 Remove unused and easy to misuse PNP macro parameter Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS). Approved by: re (glen) 2018-08-19T00:46:22Z Conrad Meyer cem@FreeBSD.org 2018-08-19T00:46:22Z urn:sha1:b8e771e97a39a88bbf6ebf8f31dcc820c91fe355 I was not aware Warner was making or planning to make forward progress in this area and have since been informed of that. It's easy to apply/reapply when churn dies down. 2018-08-19T00:22:21Z Conrad Meyer cem@FreeBSD.org 2018-08-19T00:22:21Z urn:sha1:faa319436f0d548cff97c2c8c763538997b63f34 Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS). 2017-12-22T17:53:27Z Warner Losh imp@FreeBSD.org 2017-12-22T17:53:27Z urn:sha1:d2064cf0303dbd5585de1a36ae54504a13349e65 2017-09-14T15:34:45Z Conrad Meyer cem@FreeBSD.org 2017-09-14T15:34:45Z urn:sha1:a64bf59c499c36895b9018d4124f3fcd71ac2cb8 An eventual devd(8) or other component should be able to scan buses and automatically load drivers that match device ids described in this metadata. Reviewed by: imp Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12364 2017-09-13T17:43:18Z Conrad Meyer cem@FreeBSD.org 2017-09-13T17:43:18Z urn:sha1:e5dc78af1126ce3f31f6289d4b3a4a84082384a9 On some AMD FCH devices driven by intpm(4) (read: mine), the SMBus I/O port range is split in two and the low range is only 0x10 wide. intpm(4) does not access any registers above 0x0f, so there is no need for the wider range. Discussed with: avg Sponsored by: Dell EMC Isilon 2017-09-13T16:43:31Z Conrad Meyer cem@FreeBSD.org 2017-09-13T16:43:31Z urn:sha1:02e015aa38043db953b91c07794b02f7f74d5b5c Reported by: avg Sponsored by: Dell EMC Isilon 2017-09-13T16:23:59Z Conrad Meyer cem@FreeBSD.org 2017-09-13T16:23:59Z urn:sha1:54d89ef11406ec275d9071a10236ff4de6633484 Attempts to use the driver without an io_res result in immediate panic. Sponsored by: Dell EMC Isilon