Export DSR register through sysfs same as we did for the CID, CSD and OCR
registers.
Signed-off-by: Bojan Prtvar
---
v2: Extended to cover SD cards
Documentation/mmc/mmc-dev-attrs.txt | 1 +
drivers/mmc/core/mmc.c | 17 +
drivers/mmc/core/sd.c | 17
A recent commit added a write to the watchdog test code for doing the "magic
close", but that caused a compile-time warning:
Documentation/watchdog/src/watchdog-test.c: In function ‘main’:
Documentation/watchdog/src/watchdog-test.c:94:5: warning: ignoring return value
of ‘write’, declared with at
Am 18.07.2016 um 13:54 schrieb Mauro Carvalho Chehab :
> Em Sun, 17 Jul 2016 20:37:19 -0600
> Jonathan Corbet escreveu:
>
>> [Back home and trying to get going on stuff for real. I'll look at the
>> issues listed in this message one at a time.]
>>
>> On Sun, 17 Jul 2016 10:01:54 -0300
>> Maur
On 19 July 2016 at 11:16, Bojan Prtvar wrote:
> Export DSR register through sysfs same as we did for the CID, CSD and OCR
> registers.
>
> Signed-off-by: Bojan Prtvar
Thanks, applied for next!
Kind regards
Uffe
> ---
> v2: Extended to cover SD cards
>
> Documentation/mmc/mmc-dev-attrs.txt |
Em Tue, 19 Jul 2016 11:19:11 +0200
Hans Verkuil escreveu:
> > All those documents are built automatically, once by day, at linuxtv.org:
> >
> > uAPI:
> > https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html
>
> Erm, there is nothing there, only the top-level menu.
Gah! Th
These are the leftovers I could only track down using keep_warnings =
True. For some of them we might want to update our style guide on how
to reference structures and constants, not sure ...
Cc: Markus Heiser
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
Signed-off-by: Daniel Vetter
---
d
Unfortunately warnings generated after parsing in sphinx can end up
with entirely bogus files and line numbers as sources. Strangely for
outright errors this is not a problem. Trying to convert warnings to
errors also doesn't fix it.
The only way to get useful output out of sphinx to be able to ro
Am 19.07.2016 um 13:12 schrieb Mauro Carvalho Chehab :
> Em Tue, 19 Jul 2016 11:19:11 +0200
> Hans Verkuil escreveu:
>
>>> All those documents are built automatically, once by day, at linuxtv.org:
>>>
>>> uAPI:
>>> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html
>>
On Tue, Jul 19, 2016 at 01:42:55PM +0200, Daniel Vetter wrote:
> These are the leftovers I could only track down using keep_warnings =
> True. For some of them we might want to update our style guide on how
> to reference structures and constants, not sure ...
>
> Cc: Markus Heiser
> Cc: Jonathan
Dmitry,
On 6/16/2016 4:17 PM, Vignesh R wrote:
[...]
>>> On 5/20/2016 10:04 PM, Dmitry Torokhov wrote:
On Thu, May 19, 2016 at 02:34:00PM +0530, Vignesh R wrote:
> There are rotary-encoders where GPIO lines reflect the actual position
> of the rotary encoder dial. For example, if dial
On 07/19/2016 02:24 AM, Arnd Bergmann wrote:
A recent commit added a write to the watchdog test code for doing the "magic
close", but that caused a compile-time warning:
Documentation/watchdog/src/watchdog-test.c: In function ‘main’:
Documentation/watchdog/src/watchdog-test.c:94:5: warning: igno
Rusty, this looks like it will work. I tested this by adding
module_blacklist=acpi_cpufreq,dummy_module
as a kernel parameter, and verified that acpi_cpufreq was not loaded
during the initrd and systemd phases of the boot. I then tried to
manually load a simple module called dummy_modul
On 07/19/16 02:24, Arnd Bergmann wrote:
> A recent commit added a write to the watchdog test code for doing the "magic
> close", but that caused a compile-time warning:
>
> Documentation/watchdog/src/watchdog-test.c: In function ‘main’:
> Documentation/watchdog/src/watchdog-test.c:94:5: warning: i
Em Tue, 19 Jul 2016 14:31:18 +0200
Markus Heiser escreveu:
> > I really hate stupid toolchains that require everybody to upgrade to
> > the very latest version of it every time.
>
> Hi Mauro,
>
> It might be annoying how sphinx handles errors, but normally a build
> process should report err
Am 19.07.2016 um 13:42 schrieb Daniel Vetter :
> Unfortunately warnings generated after parsing in sphinx can end up
> with entirely bogus files and line numbers as sources. Strangely for
> outright errors this is not a problem. Trying to convert warnings to
> errors also doesn't fix it.
>
> The
On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser
wrote:
>
> Am 19.07.2016 um 13:42 schrieb Daniel Vetter :
>
>> Unfortunately warnings generated after parsing in sphinx can end up
>> with entirely bogus files and line numbers as sources. Strangely for
>> outright errors this is not a problem. Trying
On Tue, Jul 19, 2016 at 5:25 PM, Daniel Vetter wrote:
> On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser
> wrote:
>>
>> Am 19.07.2016 um 13:42 schrieb Daniel Vetter :
>>
>>> Unfortunately warnings generated after parsing in sphinx can end up
>>> with entirely bogus files and line numbers as sources
Em Tue, 19 Jul 2016 11:53:19 -0300
Mauro Carvalho Chehab escreveu:
> Yet, this doesn't solve the specific issue for the TOC index
> name. How this could be done in a way that would be backward
> compatible to 1.2.x?
Answering myself, the following patch should trick Sphinx to
allow the media boo
A recent commit added a write to the watchdog test code for doing the "magic
close", but that caused a compile-time warning:
Documentation/watchdog/src/watchdog-test.c: In function ‘main’:
Documentation/watchdog/src/watchdog-test.c:94:5: warning: ignoring return value
of ‘write’, declared with at
Am 19.07.2016 um 16:53 schrieb Mauro Carvalho Chehab :
> Em Tue, 19 Jul 2016 14:31:18 +0200
> Markus Heiser escreveu:
>
>
>>> I really hate stupid toolchains that require everybody to upgrade to
>>> the very latest version of it every time.
>>
>> Hi Mauro,
>>
>> It might be annoying how sp
On 07/18/16 22:52, Tejun Heo wrote:
> On Fri, Jul 15, 2016 at 05:15:41PM +, Topi Miettinen wrote:
>> There are clear semantics for the limits themselves, either they apply
>> per task or per user. It makes sense to gather values according to these
>> semantics. Then with systemd or other tools
Em Tue, 19 Jul 2016 18:42:50 +0200
Markus Heiser escreveu:
> > What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The
> > site only has documentation for the very latest version, making harder
> > to ensure that we're using only the tags supported by a certain version.
>
> We c
Hello, Topi.
On Tue, Jul 19, 2016 at 04:57:10PM +, Topi Miettinen wrote:
> Then there would need to be new limit checks at cgroup level. Would you
> see problems with that approach?
I'm worried that you're rushing this feature without thinking through
it. You were mixing up completely orthog
This patch adds the DMA_ATTR_PRIVILEGED attribute to the DMA-mapping
subsystem.
Some advanced peripherals such as remote processors and GPUs perform
accesses to DMA buffers in both privileged "supervisor" and unprivileged
"user" modes. This attribute is used to indicate to the DMA-mapping
subsyst
On Tue, 19 Jul 2016 13:42:54 +0200
Daniel Vetter wrote:
> Unfortunately warnings generated after parsing in sphinx can end up
> with entirely bogus files and line numbers as sources. Strangely for
> outright errors this is not a problem. Trying to convert warnings to
> errors also doesn't fix it.
On Mon, 18 Jul 2016 15:55:00 -0400
Mahesh Khanwalkar wrote:
> Moved sample code found in Documentation/ to samples/ but kept actual
> documentation where it is, while updating any in-text references to the
> moved code. Updated the Documentation/Makefile and samples/Makefile to
> reflect the chan
On 07/19/16 15:35, Jonathan Corbet wrote:
> On Mon, 18 Jul 2016 15:55:00 -0400
> Mahesh Khanwalkar wrote:
>
>> Moved sample code found in Documentation/ to samples/ but kept actual
>> documentation where it is, while updating any in-text references to the
>> moved code. Updated the Documentation/
On Tue, 19 Jul 2016 11:53:19 -0300
Mauro Carvalho Chehab wrote:
> So, I guess we should set the minimal requirement to 1.2.x.
*sigh*.
I hate to do that; things are happening quickly enough with Sphinx that
it would be nice to be able to count on a newer version. That said, one
of my goals in t
On Tue, Jul 19, 2016 at 04:35:25PM -0600, Jonathan Corbet wrote:
> So, while I'm generally in favor of moving this code over to samples/,
> I'm a bit nervous about a single, do-it-all patch. I'd rather see each
> subsystem's stuff moved separately, with (1) review from the appropriate
> maintainer
On Tue, 19 Jul 2016 12:00:24 +0200
Markus Heiser wrote:
> I recommend to consider to switch to the python version of the parser.
> I know, that there is a natural shyness about a reimplementation in python
> and thats why I offer to support it for a long time period .. it would
> be a joy for me
On Sun, 17 Jul 2016 10:01:54 -0300
Mauro Carvalho Chehab wrote:
> 2) For functions, kernel-doc is now an all or nothing. If not all
> functions are declared, it outputs this warning:
>
> ./include/media/media-devnode.h:1: warning: no structured comments
>
> And give up. No functions are e
On Sun, 17 Jul 2016 10:01:54 -0300
Mauro Carvalho Chehab wrote:
> 3) When there's an asterisk inside the source code, for example, to
> document a pointer, or when something else fails when parsing a
> header file, kernel-doc handler just outputs:
> /devel/v4l/patchwork/Documentation/media/
On Sun, 17 Jul 2016 10:01:54 -0300
Mauro Carvalho Chehab wrote:
> 4) There are now several errors when parsing functions. Those seems to
> happen when an argument is a function pointer, like:
>
> /devel/v4l/patchwork/Documentation/media/kapi/v4l2-core.rst:757: WARNING:
> Error when parsing func
Em Tue, 19 Jul 2016 16:49:16 -0600
Jonathan Corbet escreveu:
> On Tue, 19 Jul 2016 11:53:19 -0300
> Mauro Carvalho Chehab wrote:
>
> > So, I guess we should set the minimal requirement to 1.2.x.
>
> *sigh*.
>
> I hate to do that; things are happening quickly enough with Sphinx that
> it wou
Em Tue, 19 Jul 2016 17:16:35 -0600
Jonathan Corbet escreveu:
> On Sun, 17 Jul 2016 10:01:54 -0300
> Mauro Carvalho Chehab wrote:
>
> > 3) When there's an asterisk inside the source code, for example, to
> > document a pointer, or when something else fails when parsing a
> > header file, kernel-
Em Tue, 19 Jul 2016 17:01:33 -0600
Jonathan Corbet escreveu:
> On Sun, 17 Jul 2016 10:01:54 -0300
> Mauro Carvalho Chehab wrote:
>
> > 2) For functions, kernel-doc is now an all or nothing. If not all
> > functions are declared, it outputs this warning:
> >
> > ./include/media/media-devnod
Em Tue, 19 Jul 2016 17:30:24 -0600
Jonathan Corbet escreveu:
> On Sun, 17 Jul 2016 10:01:54 -0300
> Mauro Carvalho Chehab wrote:
>
> > 4) There are now several errors when parsing functions. Those seems to
> > happen when an argument is a function pointer, like:
> >
> > /devel/v4l/patchwork/Do
On Fri, Jul 15, 2016 at 11:10:45PM +0200, Rafał Miłecki wrote:
> This commit adds a new trigger that can turn on LED when USB device gets
> connected to the USB port. This can be useful for various home routers
> that have USB port and a proper LED telling user a device is connected.
>
> Right now
On 07/19/2016 08:41 AM, Arnd Bergmann wrote:
A recent commit added a write to the watchdog test code for doing the "magic
close", but that caused a compile-time warning:
Documentation/watchdog/src/watchdog-test.c: In function ‘main’:
Documentation/watchdog/src/watchdog-test.c:94:5: warning: igno
Am 20.07.2016 um 00:58 schrieb Jonathan Corbet :
> On Tue, 19 Jul 2016 12:00:24 +0200
> Markus Heiser wrote:
>
>> I recommend to consider to switch to the python version of the parser.
>> I know, that there is a natural shyness about a reimplementation in python
>> and thats why I offer to supp
Am 20.07.2016 um 02:09 schrieb Mauro Carvalho Chehab :
> Em Tue, 19 Jul 2016 17:16:35 -0600
> Jonathan Corbet escreveu:
>
>> On Sun, 17 Jul 2016 10:01:54 -0300
>> Mauro Carvalho Chehab wrote:
>>
>>> 3) When there's an asterisk inside the source code, for example, to
>>> document a pointer, or
Am 20.07.2016 um 02:00 schrieb Mauro Carvalho Chehab :
> Em Tue, 19 Jul 2016 16:49:16 -0600
> Jonathan Corbet escreveu:
>
>> On Tue, 19 Jul 2016 11:53:19 -0300
>> Mauro Carvalho Chehab wrote:
>>
>>> So, I guess we should set the minimal requirement to 1.2.x.
>>
>> *sigh*.
>>
>> I hate to
42 matches
Mail list logo
