On Thu, Nov 09, 2017 at 04:17:33PM +0000, Mark Brown wrote:
On Thu, Nov 09, 2017 at 04:09:12PM +0000, Levin, Alexander (Sasha Levin) wrote:
On Thu, Nov 09, 2017 at 11:07:44AM +0000, Mark Brown wrote:
This doesn't seem like a good idea - note how the changelog says that the transmit FIFO is at a different address, I'd expect this means that people won't be able to use the new compatible without a corresponding code change.
Interesting. I keep trying to automate DT patch selection to deal with issues as this, but it seems like there is always something...
I agree with Mark. I think it would make sense to pick 1bd92af877 as well to deal with this issue.
Yeah, if they both go in together it's fine by me (though it's a little more than just a device ID).
It's a quirk too :)
On Thu, Nov 09, 2017 at 04:28:05PM +0000, Levin, Alexander (Sasha Levin) wrote:
On Thu, Nov 09, 2017 at 04:17:33PM +0000, Mark Brown wrote:
On Thu, Nov 09, 2017 at 04:09:12PM +0000, Levin, Alexander (Sasha Levin) wrote:
On Thu, Nov 09, 2017 at 11:07:44AM +0000, Mark Brown wrote:
This doesn't seem like a good idea - note how the changelog says that the transmit FIFO is at a different address, I'd expect this means that people won't be able to use the new compatible without a corresponding code change.
Interesting. I keep trying to automate DT patch selection to deal with issues as this, but it seems like there is always something...
I agree with Mark. I think it would make sense to pick 1bd92af877 as well to deal with this issue.
Yeah, if they both go in together it's fine by me (though it's a little more than just a device ID).
It's a quirk too :)
Ok, but 1bd92af877 does not apply cleanly (or even not cleanly) to 4.9, can someone provide me a backport?
thanks,
greg k-h
On Fri, Nov 10, 2017 at 02:34:31PM +0100, gregkh@linuxfoundation.org wrote:
On Thu, Nov 09, 2017 at 04:28:05PM +0000, Levin, Alexander (Sasha Levin) wrote:
On Thu, Nov 09, 2017 at 04:17:33PM +0000, Mark Brown wrote:
On Thu, Nov 09, 2017 at 04:09:12PM +0000, Levin, Alexander (Sasha Levin) wrote:
On Thu, Nov 09, 2017 at 11:07:44AM +0000, Mark Brown wrote:
This doesn't seem like a good idea - note how the changelog says that the transmit FIFO is at a different address, I'd expect this means that people won't be able to use the new compatible without a corresponding code change.
Interesting. I keep trying to automate DT patch selection to deal with issues as this, but it seems like there is always something...
I agree with Mark. I think it would make sense to pick 1bd92af877 as well to deal with this issue.
Yeah, if they both go in together it's fine by me (though it's a little more than just a device ID).
It's a quirk too :)
Ok, but 1bd92af877 does not apply cleanly (or even not cleanly) to 4.9, can someone provide me a backport?
Sure, please pick the following 3 commits, should be no conflicts then:
- 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf - just dead code removal, avoids conflicts later. - 7762681a3ada5fca6017e75ea7f9cdac08fc50b9 - adds a basic quirks structure. - 1bd92af877abfeddcc4b83a35482ed4139591acf - adds support for H2 SoC.
On Fri, Nov 10, 2017 at 04:04:22PM +0000, alexander.levin@verizon.com wrote:
On Fri, Nov 10, 2017 at 02:34:31PM +0100, gregkh@linuxfoundation.org wrote:
On Thu, Nov 09, 2017 at 04:28:05PM +0000, Levin, Alexander (Sasha Levin) wrote:
On Thu, Nov 09, 2017 at 04:17:33PM +0000, Mark Brown wrote:
On Thu, Nov 09, 2017 at 04:09:12PM +0000, Levin, Alexander (Sasha Levin) wrote:
On Thu, Nov 09, 2017 at 11:07:44AM +0000, Mark Brown wrote:
This doesn't seem like a good idea - note how the changelog says that the transmit FIFO is at a different address, I'd expect this means that people won't be able to use the new compatible without a corresponding code change.
Interesting. I keep trying to automate DT patch selection to deal with issues as this, but it seems like there is always something...
I agree with Mark. I think it would make sense to pick 1bd92af877 as well to deal with this issue.
Yeah, if they both go in together it's fine by me (though it's a little more than just a device ID).
It's a quirk too :)
Ok, but 1bd92af877 does not apply cleanly (or even not cleanly) to 4.9, can someone provide me a backport?
Sure, please pick the following 3 commits, should be no conflicts then:
- 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf - just dead code removal,
avoids conflicts later.
This commit claims the hardware is now supported by a different driver. Is that support in 4.9? I couldn't figure it out :(
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org