HS200 and HS400 speeds can be enabled either with 1.2, or 1.8V signaling voltage.
Because of that we have four cabability flags: MMC_CAP_MMC_HS200_120,
MMC_CAP_MMC_HS200_180, MMC_CAP_MMC_HS400_120, MMC_CAP_MMC_HS400_180.
MMC logic only enables HS200/HS400 mode if both flags are set for the corresponding speed.
Fix that by being more permissive in host timing cap check.
Reviewed by: manu, mw
MFC after: 2 weeks
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential revision: https://reviews.freebsd.org/D33130
In recent Hyper-V releases on Windows Server 2022, vPCI code does not
initialize the last 4 bit of device bar registers. This behavior change
could result weird problems cuasing PCI code failure when configuring
bars.
Just write all 1's to those bars whose probed values are not the same
as current read ones. This seems to make Hyper-V vPCI and
pci_write_bar() to cooperate correctly on these releases.
Reported by: khng@freebsd.org
Tested by: khng@freebsd.org
MFC after: 2 weeks
Sponsored by: Microsoft
Most prominently, add support for a transfer where a write with no-stop
flag is followed by a write with no-start flag. Logically, it's a
single larger write, but consumers may want to split it like that
because one part can be a register ID and the other part can be data to
be written to (or starting at) that register.
Such a transfer can be created by i2c tool and iic(4) driver, e.g., for
an EEPROM write at specific offset:
i2c -m tr -a 0x50 -d w -w 16 -o 0 -c 8 -v < /dev/random
This should be fixed by new code that handles the end of data transfer
for both reads and writes. It handles two existing conditions and one
new. Namely:
- the last message has been completed -- end of transfer;
- a message has been completed and the next one requires the start
condition;
- a message has been completed and the next one should be sent without
the start condition.
In the last case we simply switch to the next message and start sending
its data. Reads without the start condition are not supported yet,
though. That's because we NACK the last byte of the previous message,
so the device stops sending data. To fix this we will need to add a
look-ahead at the next message when handling the penultimate byte of the
current one.
This change also fixed a bug where msg_idx was not incremented after a
read message. Apparently, typically a read message is a last message in
a transfer, so the bug did not cause much trouble.
PR: 258994
MFC after: 3 weeks
Assert that we are not receiving data beyond the requested length.
Assert that we have not NACK-ed incoming data prematurely.
Abort the current transfer if the incoming data is NACK-ed or not
NACK-ed unexpectedly.
Add debug logging of received data to complement logging of sent data.
MFC after: 3 weeks
The write at the end of twsi_intr() already handles all cases, no need
to have another write for TWSI_STATUS_START / TWSI_STATUS_RPTD_START.
MFC after: 3 weeks
Previously the code set TWSI_CONTROL_ACK in twsi_transfer() based on
whether the first message had a length of one. That was done regardless
of whether the message was a read or write and what kind of messages
followed it.
Now the bit is set or cleared while handling TWSI_STATUS_ADDR_R_ACK
state transition based on the current (read) message.
The old code did not correctly work in a scenario where a single byte
was read from an EEPROM device with two byte addressing.
For example:
i2c -m tr -a 0x50 -d r -w 16 -o 0 -c 1 -v
The reason is that the first message (a write) has two bytes, so
TWSI_CONTROL_ACK was set and never cleared.
Since the controller did not send NACK the EEPROM sent more data resulting
in a buffer overrun.
While working on TWSI_STATUS_ADDR_R_ACK I also added support for
the zero-length read access and then I did the same for zero-length write
access.
While rare, those types of I2C transactions are completely valid and are
used by some devices.
PR: 258994
MFC after: 3 weeks
twsi_error() is a new function that stops the current transfer and sets
up softc when an error condition is detected.
TWSI_STATUS_DATA_WR_NACK, TWSI_STATUS_BUS_ERROR and
TWSI_STATUS_ARBITRATION_LOST are now handled explicitly rather than
via the catch-all unknown status.
Also, twsi_intr() now calls wakeup() in a single place when the
transfer is finished.
MFC after: 2 weeks
All accesses to softc are now done under a mutex to prevent data races
between the open context and the interrupt handler.
Additionally, the wait time in twsi_transfer is bounded now.
Previously we could get stuck there forever if an interrupt got lost.
MFC after: 2 weeks
Debug messages can now be enabled per driver instance via a new sysctl.
Also, debug messages in TWSI_READ and TWSI_WRITE require debug level
greater than 1 as they are mostly redundant because callers of those
functions already log most interesting results.
NB: the twsi drivers call their device iichb, so the new sysctl will
appear under dev.iichb.N.
MFC after: 1 week
Add a new ioctl to vt to make it possible to export RGB offsets
set by vt drivers. This is needed to fix colors on X and Mesa
on some machines, especially on modern PowerPC64 BE ones.
With the appropriate changes in SCFB, to use this ioctl to find
out the correct RGB offsets, this fixes wrong colors on Talos II
and Blackbird, when used with their built-in video cards.
Reviewed by: alfredo
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D29000
Currently agp(4) effectively assumes that only one driver instance
exists, as the generic attach routine attempts to create /dev/agpgart
and triggers a panic if it already exists. Instead, handle this
situation by creating /dev/agpgart<unit> and making /dev/agpgart an
alias of /dev/agpgart0 for compatibility.
PR: 187015
Reviewed by: imp, kib
Tested by: Yoshihiro Ota <ota@j.email.ne.jp> (earlier version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D33068
Instead of returning 0xffs some controllers, such as Layerscape generate
an external exception when someone attempts to read any register
of config space of a non-existing device other than PCIR_VENDOR.
This causes a kernel panic.
Fix it by bailing during device enumeration if a device vendor register
returns invalid value. (0xffff)
Use this opportunity to replace some hardcoded values with a macro.
I believe that this change won't have any unintended side-effects since
it is safe to assume that vendor == 0xffff -> hdr_type == 0xffff.
Sponsored by: Alstom
Obtained from: Semihalf
Reviewed by: jhb
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D33059
Belatedly remove twa(4). It was supposed to go before 13.0, but was
overlooked.
Sponsored by: Netflix
Relnotes: yes
Reviewed by: scottl
Differential Revision: https://reviews.freebsd.org/D33114
Belatedly remove esp(4). It was tagged as gone in 13, but was overlooked
until now.
Sponsored by: Netflix
Reviewed by: scottl
Differential Revision: https://reviews.freebsd.org/D33115
Belatedly remove amr(4). It was slated to depart before 13.0 but was
overlooked until now.
Sponsored by: Netflix
Relnotes: yes
Reviewed by: scottl
Differential Revision: https://reviews.freebsd.org/D33113
Belatedly remove iir(4). It was slated to go before 13, but was
overlooked.
Sponsored by: Netflix
Relnotes: yes
Reviewed by: scottl
Differential Revision: https://reviews.freebsd.org/D33112
We'd said this was going away in 13, but was overlooked. Belatedly
remove.
Sponsored by: Netflix
Relnotes: yes
Reviewed by: scottl
Differential Revision: https://reviews.freebsd.org/D33111
Since revision 3.0 this structure grown another field, breaking access
to the following data structures. This change fixes the PCIe errors
decoding on newer systems.
MFC after: 2 weeks
Since iavf(4) no longer shares code with ixl(4) as of commit
f2fbd56a8d07665bc0a5e8b7e40026b50a591e2a and now has its own directory,
remove these now-unused iavf(4)-only files.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D28638
The iavf(4) driver now uses a different source base from ixl(4), since
it will be the standard VF driver for new Intel Ethernet products going
forward, including ice(4). It continues to use the iflib framework
for network drivers.
Since it now uses a different source code base, this commit adds a new
sys/dev/iavf entry, but it re-uses the existing module name so no
configuration changes are necessary.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: kbowling@
Tested by: lukasz.szczepaniak@intel.com
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D28636
ACPI implementation of device_get_property would return "-1" when
property was found, but it's type wasn't supported.
This causes device_has_property to return false in that scenario, which
arguably could be considered as incorrect.
Fix that by returning "0" in that case.
Reviewed by: bz, mw
Tested by: mw
MFC after: 2 weeks
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D33103
Add driver for pcf85063 real time clock. Register set and get time
methods. Parse data obtained from bus according to specification
and fill kernel structures.
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential revision: https://reviews.freebsd.org/D32817
Driver for tca6408 gpio expander over i2c bus. Expose API for
manipulating pin's direction, state and polarity inversion.
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential revision: https://reviews.freebsd.org/D32819
