On Wed, Mar 08, 2017 at 12:52:38AM +0100, Robin Krahl wrote:
> So my question is: Does it make sense to replace the audio_* and LOG_*
> macros with the standard dev_* functions?
Yes.
> And is it okay to remove log messages like "IN" and "OUT" that are
> only used to track function entries and ex
On Wed, Mar 08, 2017 at 12:12:50AM +0100, Peter Senna Tschudin wrote:
> On Tue, Mar 7, 2017 at 10:29 PM, Tobin C. Harding wrote:
> > I would like to know the correct protocol in order to make the
> > maintainers job as easy as possible please.
> >
> > Once a patch has been reviewed and the review
Hi there,
the TODO file for drivers/staging/vc04_services/bcm2835-audio contains
the following item:
> 4) Cleanup the logging mechanism. The driver should probably be using
> the standard kernel logging mechanisms such as dev_info, dev_dbg, and
> friends.
Currently there are macros audio_debug,
On Tue, Mar 7, 2017 at 11:20 PM, Tobin C. Harding wrote:
> Question relating to the validity/usefulness of patching calls to sizeof.
>
> >From Documentation/process/coding-style.rst
>
> The preferred form for passing a size of a struct is the following:
>
> .. code-block:: c
>
> p = kmall
Question relating to the validity/usefulness of patching calls to sizeof.
>From Documentation/process/coding-style.rst
The preferred form for passing a size of a struct is the following:
.. code-block:: c
p = kmalloc(sizeof(*p), ...);
The alternative form where struct name is spelled o
On Tue, Mar 7, 2017 at 10:29 PM, Tobin C. Harding wrote:
> I would like to know the correct protocol in order to make the
> maintainers job as easy as possible please.
>
> Once a patch has been reviewed and the review makes good points that
> mean the patch is invalid/unnecessary what is the proto
I would like to know the correct protocol in order to make the
maintainers job as easy as possible please.
Once a patch has been reviewed and the review makes good points that
mean the patch is invalid/unnecessary what is the protocol from then?
Assuming one replies to the reviewer with thanks an
Worked. I can change the value, but this didn't change how the firmware works.
At least for my lenovo 700 17ISK
On Mon, Mar 6, 2017 at 9:39 AM, Lucas Tanure wrote:
> Hi,
>
> I didn't tried this yet. I will try today.
>
> Thanks!
>
> On Sun, Mar 5, 2017 at 2:20 PM, Markus Böhme
> wrote:
>> On 03
Hello all,
In kernels 3.X up to 4.2 execve(|) system call was for x86_64 architecture
the the system call was made through some
magic ( I can't say I understand it ) assembly stub in
arch/x86/kernel/entry_64.S
so up to kernel 4.2 it was possble to patch this assembly to install the hook,
ex.
On Tue, 07 Mar 2017 20:22:33 +0100, Greg KH said:
> On Mon, Mar 06, 2017 at 10:18:26AM +0300, Lev Olshvang wrote:
> Why do you want to hook a syscall? that's a very complex, and broken,
> and ill-advised thing to do. Please don't do that.
>
> What problem are you trying to solve here that led yo
On Mon, Mar 06, 2017 at 10:18:26AM +0300, Lev Olshvang wrote:
> Hello all,
>
> In kernels 3.X up to 4.2 execve(|) system call was for x86_64 architecture
> the the system call was made through some
> magic ( I can't say I understand it ) assembly stub in
> arch/x86/kernel/entry_64.S
> so up t
11 matches
Mail list logo
