On Aug 17, 2005, at 01:33:00, Matt Domsch wrote:
This is conceptually similar to how SCSI Generic (either
/dev/sg or ioctl(SG_IO)) works (userspace passes in preformated SCSI
CDBs and gets back the resultant CDBs and extended sense data). The
sg driver doesn't look at the data being passed down
On Tue, Aug 16, 2005 at 06:47:45PM -0500, [EMAIL PROTECTED] wrote:
> > From: Greg KH [mailto:[EMAIL PROTECTED]
> > > And just to re-iterate one more time, we can already directly hook
> > > into
> > > hardware from userspace without any kernel auditing. We are
> > just trying
> > > to set this
On Wed, 2005-08-17 at 02:23 +0200, Andi Kleen wrote:
> <[EMAIL PROTECTED]> writes:
> > 2) Dell OpenManage
> > The main use of this driver by openmanage will be to read the System
> > Event Log that BIOS keeps. Here are some other random relevant points:
>
> Are there machine check events from
<[EMAIL PROTECTED]> writes:
> 2) Dell OpenManage
> The main use of this driver by openmanage will be to read the System
> Event Log that BIOS keeps. Here are some other random relevant points:
Are there machine check events from the last boot in that event log?
If yes it would be extremly c
> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 16, 2005 6:24 PM
> To: Brown, Michael E
> Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
> Warzecha, Douglas; Domsch, Matt
> Subject: Re: [RFC][PATCH 2.6.13-rc6] add Dell
On Mon, Aug 15, 2005 at 10:52:48PM -0700, Greg KH wrote:
> On Mon, Aug 15, 2005 at 03:05:22PM -0500, Doug Warzecha wrote:
> > +
> > +1) Lock smi_data.
> > +2) Determine buffer size needed for system management command.
> > +3) Write buffer size needed to smi_data_buf_size.
> > + (Driver will ensu
On Tue, Aug 16, 2005 at 06:11:13PM -0500, [EMAIL PROTECTED] wrote:
>
> The main use of this driver by libsmbios will be to set BIOS F2
> options. Based on your feedback, I will _NOT_ be implementing any
> fan/sensor functionality in libsmbios, but will work with the lmsensors
> guys to do t
Greg KH wrote:
>On Tue, Aug 16, 2005 at 08:34:24AM -0500, Michael E Brown wrote:
>
>
>>On Tue, 2005-08-16 at 01:16 -0700, Greg KH wrote:
>>
>>
>>>No, export this data properly through sysfs like all other temperature
>>>and sensor data is. Don't create a new one, no matter how much you
>>>w
On Tue, Aug 16, 2005 at 08:34:24AM -0500, Michael E Brown wrote:
> On Tue, 2005-08-16 at 01:16 -0700, Greg KH wrote:
> > On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
> > > To take a concrete example, I suggested to Doug to mention fan status. I
> > > get the feeling that you pos
Hi!
> > > To take a concrete example, I suggested to Doug to mention fan status. I
> > > get the feeling that you possibly think that this would be better
> > > integrated into lmsensors, or something like that.
> >
> > Yes it should. That way you get the benifit of all userspace
> > application
On Tue, 2005-08-16 at 01:16 -0700, Greg KH wrote:
> On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
> > To take a concrete example, I suggested to Doug to mention fan status. I
> > get the feeling that you possibly think that this would be better
> > integrated into lmsensors, or s
On 228, 08 16, 2005 at 01:36:19AM -0400, [EMAIL PROTECTED] wrote:
> On Mon, 15 Aug 2005 23:58:43 CDT, Michael E Brown said:
>
> > No, this is an _EXCELLENT_ reason why _LESS_ of this should be in the
> > kernel. Why should we have to duplicate a _TON_ of code inside the
> > kernel to figure out wh
On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
> To take a concrete example, I suggested to Doug to mention fan status. I
> get the feeling that you possibly think that this would be better
> integrated into lmsensors, or something like that.
Yes it should. That way you get the
On Tue, 16 Aug 2005 01:10:23 CDT, Michael E Brown said:
> Ok, very nice. Finally some actual code review, thanks. :-)
I have to admit I'm not qualified to do a detailed review, but I try.. ;)
> These are all just standard CMOS port numbers that pretty much every
> chipset uses to access CMOS.
T
On Mon, Aug 15, 2005 at 03:05:22PM -0500, Doug Warzecha wrote:
> This patch adds the Dell Systems Management Base Driver with sysfs support.
>
> This driver has been tested with Dell OpenManage.
Much better, but I still have a few questions:
> +System Management Interrupt
> +
> +On some Dell sys
On Tue, 2005-08-16 at 01:36 -0400, [EMAIL PROTECTED] wrote:
> On Mon, 15 Aug 2005 23:58:43 CDT, Michael E Brown said:
>
> > No, this is an _EXCELLENT_ reason why _LESS_ of this should be in the
> > kernel. Why should we have to duplicate a _TON_ of code inside the
> > kernel to figure out which pl
On Mon, Aug 15, 2005 at 10:10:28PM -0500, Michael E Brown wrote:
> On Mon, 2005-08-15 at 21:29 -0400, Kyle Moffett wrote:
> > On Aug 15, 2005, at 18:58:56, [EMAIL PROTECTED] wrote:
> > >> Why can't you just implement the system management actions in
> > >> the kernel driver? This is tantamount to
On Mon, 2005-08-15 at 22:35 -0700, Chris Wedgwood wrote:
> On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote:
>
> > Hmm... did I mention libsmbios? :-)
> > http://linux.dell.com/libsmbios/main.
>
> I'm aware of it --- it seems pretty limited right now and I'm still
> irked Dell isn'
On Mon, 15 Aug 2005 23:58:43 CDT, Michael E Brown said:
> No, this is an _EXCELLENT_ reason why _LESS_ of this should be in the
> kernel. Why should we have to duplicate a _TON_ of code inside the
> kernel to figure out which platform we are on, and then look up in a
> table which method to use fo
On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote:
> Hmm... did I mention libsmbios? :-)
> http://linux.dell.com/libsmbios/main.
I'm aware of it --- it seems pretty limited right now and I'm still
irked Dell isn't more forthcoming with documentation.
> SMI support is not yet implem
On Tue, 2005-08-16 at 01:17 -0400, [EMAIL PROTECTED] wrote:
> On Mon, 15 Aug 2005 23:09:28 CDT, you said:
>
> > No, dcdbas has nothing to do with this. I'll have to submit a patch
> > against the docs. The program you need to use already exists and is
> > open source. You can use libsmbios to do t
Again, please cc Doug and I on replies...
Kyle Moffett wrote:
>On Aug 16, 2005, at 00:34:51, Chris Wedgwood wrote:
>> On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
>>> Why can't you just implement the system management actions in the
>>> kernel driver?
>>
>> Why put things in the k
On Mon, 15 Aug 2005 23:09:28 CDT, you said:
> No, dcdbas has nothing to do with this. I'll have to submit a patch
> against the docs. The program you need to use already exists and is
> open source. You can use libsmbios to do this.
> http://linux.dell.com/libsmbios/main.
Now I'm confoozled. May
On Tue, Aug 16, 2005 at 12:55:35AM -0400, Kyle Moffett wrote:
> I'm worried that it might be more of a mess in userspace than it
> could be if done properly in the kernel.
I would rather if it's gonna be a mess it's, then we put that mess in
userspace rather than in the kernel.
> Hardware driver
I am not subscribed to linux-kernel. Please cc me (and Doug) on all
replies. Sorry if I'm breaking peoples threading, but I am cut-and-
pasting this from web archives, since this wasn't cc-d to me
originally.
>On Aug 15, 2005, at 19:38:49, Doug Warzecha wrote:
>> On Mon, Aug 15, 2005 at 04:23:37P
On Aug 16, 2005, at 00:34:51, Chris Wedgwood wrote:
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
Why can't you just implement the system management actions in the
kernel driver?
Why put things in the kernel unless it's really needed?
I'm not thrillied about the lack of usersp
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
> Why can't you just implement the system management actions in the
> kernel driver?
Why put things in the kernel unless it's really needed?
I'm not thrillied about the lack of userspace support for this driver
but that still doesn't
>On Mon, 15 Aug 2005 18:38:49 CDT, Doug Warzecha said:
>
>> > If this is supposed to be used with the RBU code to trigger a BIOS
>> > update, ...
>>
>> This driver is not needed by the RBU code.
>
> Documentation/dell_rbu.txt says:
>
>> The rbu driver needs to have an application which will info
On Mon, 2005-08-15 at 21:29 -0400, Kyle Moffett wrote:
> On Aug 15, 2005, at 18:58:56, [EMAIL PROTECTED] wrote:
> >> Why can't you just implement the system management actions in
> >> the kernel driver? This is tantamount to a binary SMI hook to
> >> userspace. What functionality does this provid
On Mon, 15 Aug 2005 18:38:49 CDT, Doug Warzecha said:
> > If this is supposed to be used with the RBU code to trigger a BIOS
> > update, ...
>
> This driver is not needed by the RBU code.
Documentation/dell_rbu.txt says:
> The rbu driver needs to have an application which will inform the BIOS
On Aug 15, 2005, at 19:38:49, Doug Warzecha wrote:
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
Why can't you just implement the system management actions in the
kernel
driver?
We want to minimize the amount of code in the kernel and avoid
having to
update the driver each
On Aug 15, 2005, at 18:58:56, [EMAIL PROTECTED] wrote:
Why can't you just implement the system management actions in
the kernel driver? This is tantamount to a binary SMI hook to
userspace. What functionality does this provide on a dell
system from an administrator's point of view?
Kyle,
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
> On Aug 15, 2005, at 16:05:22, Doug Warzecha wrote:
> >This patch adds the Dell Systems Management Base Driver with sysfs
> >support.
>
> >+On some Dell systems, systems management software must access certain
> >+management informat
>> +On some Dell systems, systems management software must access
certain
>> +management information via a system management interrupt (SMI).
>> The SMI data
>> +buffer must reside in 32-bit address space, and the physical
>> address of the
>> +buffer is required for the SMI. The driver maint
On Aug 15, 2005, at 16:05:22, Doug Warzecha wrote:
This patch adds the Dell Systems Management Base Driver with sysfs
support.
+On some Dell systems, systems management software must access certain
+management information via a system management interrupt (SMI).
The SMI data
+buffer must r
35 matches
Mail list logo
