On Wed, Jun 11, 2014 at 02:49:41PM -0700, Mike Larkin wrote: > On Thu, Jun 12, 2014 at 12:45:23AM +0300, Paul Irofti wrote: > > 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 <remi.loche...@relo.ch> > > > > > > > > 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. > > /me ducks :) >
I don't think there's any need for ducking, last I remember you don't own a Samsung machine.
