On Wed, Jun 11, 2014 at 09:42:56PM +0200, Mark Kettenis wrote: > > Date: Wed, 11 Jun 2014 08:40:51 +0200 > > From: Remi Locherer <[email protected]> > > > > On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: > > > On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: > > > > On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: > > > > > After discussions with Theo we decided to walk the table where needed > > > > > instead of using the soft state variables. > > > > > > > > > > Also adding all the Samsung models to the quirks table (as per the > > > > > Linux EC quirks table). > > > > > > > > > > > > > I tried this diff with my Samsung notebook. With sysctl hw.sensors or > > > > apm the state of the power supply is displayed correctly. If I change > > > > the > > > > status (disconnect or connect again) this is then also showed correctly. > > > > > > So this time it works... Did you apply the diff on top of a current sys? > > > > I did a cvs up on June 10 and applied this diff on top of that. > > > > > > > > > But a current kernel (checkout from June 10) with this patch applied > > > > does > > > > not show the acpibat0 sensor values correctly. > > > > > > And this time it does not? > > > > With this diff hw.sensors.acpiac0.indicator0 works correctly but > > hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 > > and June 10 it's the other way round. > > > > > > > > I'm confused :-) > > > > I can imagin - the complexity of acpi combined with Samsung's implementation > > and my imprecise description ... ;-) > > Our acpi code does something wrong. This seems to be the root cause > of the acpitz(4) problems that we're seeing on a wider variety of > hardware. I really think we should try to fix that broader issue > before trying to fix this more specific suspend/resume issue on > Samsung hardware.
Sure. This is not at all urgent. It can wait for someone to fix acpitz(4) on those machines.
