This pms driver is becoming a nightmare, full of messy code that
only a few people understand all the secrets behind.
Can someone out there put a serious effort into refactoring this
so that there is a layer inside it, with sub-drivers for specific
models?
I say this, because I senes this problem
On Thu, 2 Apr 2015 18:51:38 +0200
Martin Pieuchot wrote:
> Even if that's true, nothing prevent us to commit this diff first, as
> long as it does not introduce regression and then work on the possible
> refactoring needed to support debounce packets :)
That is great to hear.
Because the way pms_
On 02/04/15(Thu) 18:43, Ulf Brosziewski wrote:
> On 04/02/2015 03:39 AM, Fasse wrote:
> >On Wed, 01 Apr 2015 21:23:15 +0200
> >Ulf Brosziewski wrote:
> >>Yes, without some refactoring there won't be an elegant way.
> >>pms_sync_elantech_v2 encodes some sync state in the 'flags' field
> >>(ELANTECH
On 04/02/2015 03:39 AM, Fasse wrote:
On Wed, 01 Apr 2015 21:23:15 +0200
Ulf Brosziewski wrote:
Yes, without some refactoring there won't be an elegant way.
pms_sync_elantech_v2 encodes some sync state in the 'flags' field
(ELANTECH_F_2FINGER_PACKET), but doing the same in the v3/CRC case might
> Date: Sat, 28 Mar 2015 23:27:30 +1000
> From: Jonathan Matthew
>
> The diff below fixes a uvm fault I'm seeing when booting an MP kernel on a
> hp bc2500 blade, somewhere during acpi attach. SP kernels don't crash, but
> I think that's down to luck. It looks like this:
>
> ioapic0 at mainbus
