linux-kernel - Re: [PATCH 2/2] leds: Add ASIC3 LED support

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: <430965.32751.qm@web29011.mail.ird.yahoo.com>
Date:	Tue, 3 May 2011 21:25:19 +0100 (BST)
From:	Paul Parsons <lost.distance@...oo.com>
To:	Philipp Zabel <philipp.zabel@...il.com>
Cc:	linux-kernel@...r.kernel.org, rpurdie@...ys.net
Subject: Re: [PATCH 2/2] leds: Add ASIC3 LED support

Hi Philipp,

--- On Tue, 3/5/11, Philipp Zabel <philipp.zabel@...il.com> wrote:

> About this, see the other patch I sent. This should work
> with the GPIOs
> configured as outputs.
See my response on the other thread.

> I'd just use DIV_ROUND_CLOSEST((ms)*1024, 32000) here.
Will change.

> Could be moved into struct resource definitions in
> asic3.c.
> Get to them with platform_get_resource() in
> asic3_led_probe().
> After calculating the bus shift from the resource size, you
> have
> everything you need to get rid of the
> asic3_write_register() export.
I understand, but my feeling is that implementing a more generic mechanism will add complexity for little obvious gain. If the LED driver ever needs to be more generic then this can be revisited.

> Why not just return mfd_cell_disable(pdev);?
It wasn't always at the end of the function as it is now! Will change.

Regards,
Paul
--
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/