e list such that "pcs7" boards can be special cased in the
> future if they need the quirk. All prior Intel board ids "<
> board_ahci_pcs7" should proceed with applying the quirk.
>
> Reported-by: Andreas Friedrich
> Reported-by: Stephen Douthit
> Fixes: c312
On 8/30/19 12:00 PM, Dan Williams wrote:
> On Fri, Aug 30, 2019 at 8:47 AM Stephen Douthit
> wrote:
>>
>> On 8/29/19 7:30 PM, Dan Williams wrote:
>>> The Linux ahci driver has historically implemented a configuration fixup
>>> for platforms / platform-firmware
found in the
> future. The logic in ahci_intel_pcs_quirk() looks for all Intel AHCI
> instances with "legacy" board-ids and otherwise skips the quirk if the
> board was matched by class-code.
>
> Reported-by: Stephen Douthit
> Cc: Christoph Hellwig
> Signed
On 8/19/19 10:17 PM, Dan Williams wrote:
> On Mon, Aug 19, 2019 at 9:30 AM Stephen Douthit
> wrote:
>>
>> On 8/14/19 1:17 PM, Dan Williams wrote:
>>>> Can you get someone from the controller design team to give us a clear
>>>> answer on
On 8/14/19 1:17 PM, Dan Williams wrote:
>> Can you get someone from the controller design team to give us a clear
>> answer on a revision where this PCS change happened?
>>
>> It would be nice if we could just check PCI_REVISION_ID or something
>> similar.
>
> I don't think such a reliable
On 8/14/19 12:09 PM, Dan Williams wrote:
> On Wed, Aug 14, 2019 at 7:34 AM Stephen Douthit
> wrote:
>>
>> On 8/13/19 6:07 PM, Dan Williams wrote:
>>> On Tue, Aug 13, 2019 at 12:31 AM Christoph Hellwig
>>> wrote:
>>>>
>>>>
On 8/13/19 6:07 PM, Dan Williams wrote:
> On Tue, Aug 13, 2019 at 12:31 AM Christoph Hellwig wrote:
>>
>> On Mon, Aug 12, 2019 at 12:31:35PM -0700, Dan Williams wrote:
>>> It seems platforms / controllers that fail to run the option-rom
>>> should be quirked by device-id, but the PCS register
On 8/12/19 2:06 PM, Christoph Hellwig wrote:
> On Mon, Aug 12, 2019 at 05:49:29PM +0000, Stephen Douthit wrote:
>> Does anyone know the background of the original PCS workaround?
>
> Based on a few git-blame iterations on history.git the original PCS
> handling (just when initi
On 8/12/19 12:29 PM, Dan Williams wrote:
> On Mon, Aug 12, 2019 at 6:03 AM Stephen Douthit
> wrote:
>>
>> On 8/10/19 3:43 AM, Christoph Hellwig wrote:
>>> On Thu, Aug 08, 2019 at 08:24:31PM +, Stephen Douthit wrote:
>>>> Intel moved the PCS register
On 8/10/19 3:43 AM, Christoph Hellwig wrote:
> On Thu, Aug 08, 2019 at 08:24:31PM +0000, Stephen Douthit wrote:
>> Intel moved the PCS register from 0x92 to 0x94 on Denverton for some
>> reason, so now we get to check the device ID before poking it on reset.
>
> And now you
Intel moved the PCS register from 0x92 to 0x94 on Denverton for some
reason, so now we get to check the device ID before poking it on reset.
Signed-off-by: Stephen Douthit
---
drivers/ata/ahci.c | 42 +++---
1 file changed, 39 insertions(+), 3 deletions
Result of sed -i 's/\(0x[0-9a-fA-F]\{1,\}\)/\L\1/' drivers/ata/ahci.c
No functional change intended.
Signed-off-by: Stephen Douthit
---
drivers/ata/ahci.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index
v2: Fix case of hex values
Stephen Douthit (2):
ata: ahci: Lookup PCS register offset based on PCI device ID
ata: ahci: Cleanup hex values to use lowercase everywhere
drivers/ata/ahci.c | 62 --
1 file changed, 49 insertions(+), 13 deletions
Not all of the mmio regions used in dnv_rd_reg() are the same size. The
MCHBAR window is 32KB and the sideband ports are 64KB. Pass the correct
size to ioremap() depending on which resource we're reading from.
Signed-off-by: Stephen Douthit
---
drivers/edac/pnd2_edac.c | 7 ++-
1 file changed
On 8/8/19 11:46 PM, Jens Axboe wrote:
> On 8/8/19 1:24 PM, Stephen Douthit wrote:
>> Intel moved the PCS register from 0x92 to 0x94 on Denverton for some
>> reason, so now we get to check the device ID before poking it on reset.
>>
>> Signed-off-by: Stephen Douthit
>
On 8/8/19 5:05 PM, Luck, Tony wrote:
> - base = ioremap((resource_size_t)addr, 0x1);
> + base = ioremap((resource_size_t)addr, 0x8000);
>
> Changing one magic value for another. :-(
Ok, I'll give it a name.
> Do different BIOS do different things? I don't recall
] mapping multiple BARs
ioremap() the correct size on Denverton platforms to get rid of those
warnings.
Signed-off-by: Stephen Douthit
---
drivers/edac/pnd2_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/pnd2_edac.c b/drivers/edac/pnd2_edac.c
index 903a4f1fadcc
Intel moved the PCS register from 0x92 to 0x94 on Denverton for some
reason, so now we get to check the device ID before poking it on reset.
Signed-off-by: Stephen Douthit
---
drivers/ata/ahci.c | 42 +++---
1 file changed, 39 insertions(+), 3 deletions
nable bit in the LPC controllers PCI config space.
Signed-off-by: Stephen Douthit
---
drivers/idle/intel_idle.c | 35 ++-
include/linux/pci_ids.h | 1 +
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.
from upstream.
-Steve
--
From: Stephen Douthit <steph...@adiengineering.com>
commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream.
According to Table 15-14 of the C2000 EDS (Intel doc #510524) the
rx data pointed to by the descriptor dptr contains the byte count.
from upstream.
-Steve
--
From: Stephen Douthit
commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream.
According to Table 15-14 of the C2000 EDS (Intel doc #510524) the
rx data pointed to by the descriptor dptr contains the byte count.
desc->rxbytes reports all bytes r
ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
The ipmi_ssif driver still works with this patch, so no issues for
SMBus block reads.
Tested-by: Step
ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
The ipmi_ssif driver still works with this patch, so no issues for
SMBus block reads.
Tested-by: Stephen Douthit
On 10/05/2017 10:13 AM, Pontus Andersson wrote:
On Thu, Oct 05, 2017 at 02:41:33PM +0200, Wolfram Sang wrote:
On Mon, Oct 02, 2017 at 02:45:19PM +0200, Pontus Andersson wrote:
Commit b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for
block reads") broke I2C block reads. It aimed
On 10/05/2017 10:13 AM, Pontus Andersson wrote:
On Thu, Oct 05, 2017 at 02:41:33PM +0200, Wolfram Sang wrote:
On Mon, Oct 02, 2017 at 02:45:19PM +0200, Pontus Andersson wrote:
Commit b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for
block reads") broke I2C block reads. It aimed
On 8/14/2017 3:31 PM, Wolfram Sang wrote:
> On Mon, Aug 07, 2017 at 05:10:58PM -0400, Stephen Douthit wrote:
>> Hello all,
>>
>> We ran into an issue where the ipmi_ssif and i2c-ismt drivers don't
>> agree on the format for data returned by i2c_smbus_read_block_data()
&
On 8/14/2017 3:31 PM, Wolfram Sang wrote:
> On Mon, Aug 07, 2017 at 05:10:58PM -0400, Stephen Douthit wrote:
>> Hello all,
>>
>> We ran into an issue where the ipmi_ssif and i2c-ismt drivers don't
>> agree on the format for data returned by i2c_smbus_read_block_data()
&
e 0xad 0xbe 0xef
This was discovered while developing a BMC solution relying on the
ipmi_ssif.c driver which was trying to interpret the bogus length
field as part of the IPMI response.
Signed-off-by: Stephen Douthit <steph...@adiengineering.com>
Tested-by: Dan Priamo <d...@adiengineering.com>
---
e 0xad 0xbe 0xef
This was discovered while developing a BMC solution relying on the
ipmi_ssif.c driver which was trying to interpret the bogus length
field as part of the IPMI response.
Signed-off-by: Stephen Douthit
Tested-by: Dan Priamo
---
drivers/i2c/busses/i2c-ismt.c | 4 ++--
1 file changed, 2 inserti
Hello all,
We ran into an issue where the ipmi_ssif and i2c-ismt drivers don't
agree on the format for data returned by i2c_smbus_read_block_data()
Looking at the traffic on the wire with a beagle analyzer:
-
Packet Details (Values in hex; [S] = Start condition;
[P] =
Hello all,
We ran into an issue where the ipmi_ssif and i2c-ismt drivers don't
agree on the format for data returned by i2c_smbus_read_block_data()
Looking at the traffic on the wire with a beagle analyzer:
-
Packet Details (Values in hex; [S] = Start condition;
[P] =
Compare the number of bytes actually seen on the wire to the byte
count field returned by the slave device.
Previously we just overwrote the byte count returned by the slave
with the real byte count and let the caller figure out if the
message was sane.
Signed-off-by: Stephen Douthit <st
Compare the number of bytes actually seen on the wire to the byte
count field returned by the slave device.
Previously we just overwrote the byte count returned by the slave
with the real byte count and let the caller figure out if the
message was sane.
Signed-off-by: Stephen Douthit
Tested
33 matches
Mail list logo
