linux-kernel - Re: [PATCH] Add sysfs support for fbdefio delay

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: <49e34e8ba40c44c622171868798f9919.squirrel@intranet.cs.nmsu.edu>
Date:	Thu, 25 Feb 2010 15:41:21 -0700
From:	"Rick L. Vinyard, Jr." <rvinyard@...nmsu.edu>
To:	Bruno PrÃ©mont <bonbons@...ux-vserver.org>
Cc:	linux-kernel@...r.kernel.org, npavel@...ner.com,
	tomi.valkeinen@...ia.com, tony@...mide.com,
	florianschandinat@....de, krzysztof.h1@...pl,
	akpm@...ux-foundation.org, linux-fbdev@...r.kernel.org,
	jkosina@...e.cz
Subject: Re: [PATCH] Add sysfs support for fbdefio delay


Bruno PrÃ©mont wrote:
> On Thu, 25 February 2010 "Rick L. Vinyard Jr." <rvinyard@...nmsu.edu>
> wrote:
>> This patch adds support for examining and modifying the fbdefio delay
>> parameter through sysfs. It also adds two driver definable minimum
>> and maximum bounds.
>>
>> The default behavior is to not permit modifications if delay_max is 0,
>> thus preventing modification of the delay if the driver does not
>> explicitly permit modification.
>>
>
> ...
>
>> @@ -503,6 +584,12 @@ static struct device_attribute device_attrs[] = {
>>  #ifdef CONFIG_FB_BACKLIGHT
>>  	__ATTR(bl_curve, S_IRUGO|S_IWUSR, show_bl_curve, store_bl_curve),
>>  #endif
>> +#ifdef CONFIG_FB_DEFERRED_IO
>> +	__ATTR(defio_delay, S_IRUGO|S_IWUSR,
>> +	       show_defio_delay, store_defio_delay),
>> +	__ATTR(defio_delay_min, S_IRUGO, show_defio_delay_min, NULL),
>> +	__ATTR(defio_delay_max, S_IRUGO, show_defio_delay_max, NULL),
>> +#endif
>>  };
>>
>>  int fb_init_device(struct fb_info *fb_info)
>
> Would it be reasonable to add these attributes in
> fb_deferred_io_init() and remove them in fb_deferred_io_cleanup()?
> This would also make it possible to add write permission to delay
> attribute only when it effectively can be modified.
>
> IMHO having only attributes pertinent to the features supported by the
> framebuffer is better than having all the possible ones and those of
> unsupported features returning -ENODEV.
>
> Bruno
>

I looked at that, but it seems like all the sysfs stuff has been
co-located in fbsysfs.c, so I tried to just follow the pattern of the
backlight code which takes the same approach.

-- 

Rick

--
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/