linux-kernel - Re: [PATCH] Driver for GE PIO2 VME Card

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EB7BCAE.90004@ge.com>
Date:	Mon, 07 Nov 2011 11:10:38 +0000
From:	Martyn Welch <martyn.welch@...com>
To:	Paul Bolle <pebolle@...cali.nl>
CC:	gregkh@...e.de, Grant Likely <grant.likely@...retlab.ca>,
	devel@...verdev.osuosl.org, manohar.vanga@...n.ch, cota@...ap.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Driver for GE PIO2 VME Card

On 07/11/11 09:55, Paul Bolle wrote:
> On Mon, 2011-11-07 at 09:34 +0000, Martyn Welch wrote:
>> On 04/11/11 19:55, Paul Bolle wrote:
>>>> +	  implementing 32 solid-state relay switched IO lines, in 4 groups of 8.
>>>> +	  The IO lines are provided as input, output or both as a build time
>>>> +	  option.
>>>
>>> What option would that be? 
>>
>> I think "Each bank of IO lines is pre-configured as input, output or both
>> depending on the variant of the card" may be a bit clearer?
> 
> So this concerns a physical build option! Anything that makes that clear
> (like your alternative does) is fine with me. (Perhaps "is
> pre-configured" could be "functions", as that's less ambiguous in a
> Kconfig file, but that's debatable.)
> 

Yes, with this card it is a physical build option.

>>> All module parameters have a sysfs visibility (or permission) of zero.
>>> Why is that? (This might very well be a naive question. But I often
>>> wonder why a certain parameter's permission isn't at least 400, just to
>>> allow a quick check of that parameter.) Are arrays tricky in sysfs? 
>>
>> Hadn't really thought about it to be honest. There seems to be plenty of
>> examples where it's set to non-zero.
> 
> (Perhaps you meant to write "set to zero" here.)
> 

I had a look to see what other drivers did before I saw Greg's email. I was
planning to at least change these to S_IRUGO for the next revision of the
patch as it would probably make sense for now I think.

> Greg already explained that it's OK to leave the code as is for now
> (since all these control knobs need to be provided via "real" sysfs
> files in the long run anyhow).
> 
>
> Paul Bolle
>

Not quite sure how that would work, would the driver be loaded then the values
written into sysfs to bind to each instance? A set of parameters are required
for each card (bus, base, vector, level and variant), I can't think of an
example of this, any ideas?

Martyn

-- 
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms                   | Wales (3828642) at 100
T +44(0)1327322748                         | Barbirolli Square, Manchester,
E martyn.welch@...com                      | M2 3AB  VAT:GB 927559189
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/