ly;
ftrace should be used instead.
Signed-off-by: Filip Kolev
---
drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
index eecefcd734d0e..1
On 06-Jan-21 09:51, Greg Kroah-Hartman wrote:
On Tue, Jan 05, 2021 at 10:29:18PM +0200, Filip Kolev wrote:
There is a debug message using hardcoded function name instead of the
__func__ macro. Replace it.
Report from checkpatch.pl on the file:
WARNING: Prefer using '"%s..."
.\n");
Signed-off-by: Filip Kolev
---
drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
index eecefcd734d0
LTE module MR400 embedded in TL-MR6400 v4 requires DTR to be set.
Signed-off-by: Filip Moc
---
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index afeb09b9624e..d166c321ee9b 100644
pletely
>> different voltage regulator with different controls. And since Linux
>> already has voltage regulator class, lets not limit ourselves to gpio
>> pins.
>
> Well, notice I'm converting existing driver to device tree. And that
> one already has GPIO dependency. It is possible that more work needs
> to be done there, but that should not be a reason to delay this. Feel
> free to help.
>
> Pavel
>
According to N9 schematics
http://www.s-manuals.com/manuals/phone/nokia/nokia_n9_rm-696_service_schematics_v1.pdf
it's in fact GPIO pin that is connected to reset line (labeled
CODEC_RST). So calling it "power" might be misleading, but the driver
code is quite clear as it labels that GPIO as "tlv320dac33 reset"
Filip
ifferent voltage regulator with different controls. And since Linux
>> already has voltage regulator class, lets not limit ourselves to gpio
>> pins.
>
> Well, notice I'm converting existing driver to device tree. And that
> one already has GPIO dependency. It is possible that more work needs
> to be done there, but that should not be a reason to delay this. Feel
> free to help.
>
> Pavel
>
According to N9 schematics
http://www.s-manuals.com/manuals/phone/nokia/nokia_n9_rm-696_service_schematics_v1.pdf
it's in fact GPIO pin that is connected to reset line (labeled
CODEC_RST). So calling it "power" might be misleading, but the driver
code is quite clear as it labels that GPIO as "tlv320dac33 reset"
Filip
ment on that, but
they are in there but probably need some work.
>
> Pavel
>
Best regards,
Filip
ment on that, but
they are in there but probably need some work.
>
> Pavel
>
Best regards,
Filip
ak8975@0f {
>> +compatible = "asahi-kasei,ak8975";
>> +reg = <0x0f>;
>> +};
>> };
>
> Looking at the N9 board file this is missing a rotation matrix. This
> is supported by the binding:
>
> Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
>
>>
>> {
>
> -- Sebastian
>
Best regards,
Filip
t; +compatible = "asahi-kasei,ak8975";
>> +reg = <0x0f>;
>> +};
>> };
>
> Looking at the N9 board file this is missing a rotation matrix. This
> is supported by the binding:
>
> Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
>
>>
>> {
>
> -- Sebastian
>
Best regards,
Filip
Hi Sakari,
and thank you for your input - I've added a few comments below.
On 12/27/2017 07:00 PM, Sakari Ailus wrote:
> Hi Pavel,
>
> Thanks for the patch. Please see my comments below.
>
> On Wed, Dec 27, 2017 at 10:18:28AM +0100, Pavel Machek wrote:
>> From: Filip Matij
Hi Sakari,
and thank you for your input - I've added a few comments below.
On 12/27/2017 07:00 PM, Sakari Ailus wrote:
> Hi Pavel,
>
> Thanks for the patch. Please see my comments below.
>
> On Wed, Dec 27, 2017 at 10:18:28AM +0100, Pavel Machek wrote:
>>
mage to panel with
MIPI_DCS_WRITE_MEMORY_START/MIPI_DCS_READ_MEMORY_CONTINUE) so I hope
you'll have more luck than me!
Filip
mage to panel with
MIPI_DCS_WRITE_MEMORY_START/MIPI_DCS_READ_MEMORY_CONTINUE) so I hope
you'll have more luck than me!
Filip
that kernel
should apply (2.6 and 3.5 do that). I'm not sure if that would cause
booting to fail on that specific device, but can you compare kernel
params on S and P devices (by using 3.5.3 for P device)?
Filip
that kernel
should apply (2.6 and 3.5 do that). I'm not sure if that would cause
booting to fail on that specific device, but can you compare kernel
params on S and P devices (by using 3.5.3 for P device)?
Filip
> any ideas, let me know.
Last time I couldn't get output on serial I used CONFIG_DEBUG_LL,
CONFIG_DEBUG_OMAP3UART3, CONFIG_EARLY_PRINTK... and ignore_loglevel
earlyprintk kernel params to get output early enough - I guess you
already tried that.
Regards,
Filip
> any ideas, let me know.
Last time I couldn't get output on serial I used CONFIG_DEBUG_LL,
CONFIG_DEBUG_OMAP3UART3, CONFIG_EARLY_PRINTK... and ignore_loglevel
earlyprintk kernel params to get output early enough - I guess you
already tried that.
Regards,
Filip
onsidered ok, because the change is semantically "internal" and does
not originate through any userspace-visible mountpoint. Superblock
watches would solve this case.
Otherwise it seems feasible to pass a path to all VFS functions.
Filip
onsidered ok, because the change is semantically "internal" and does
not originate through any userspace-visible mountpoint. Superblock
watches would solve this case.
Otherwise it seems feasible to pass a path to all VFS functions.
Filip
nd in general I think there will be situations where you would need
to call VFS functions without paths.
Thus I suggested either
(a) wrapping the VFS functions with path variants, or
(b) giving them an optional vfsmount argument that can be set to NULL
when it does not make sense
Filip
nd in general I think there will be situations where you would need
to call VFS functions without paths.
Thus I suggested either
(a) wrapping the VFS functions with path variants, or
(b) giving them an optional vfsmount argument that can be set to NULL
when it does not make sense
Filip
notification), as I suggested earlier.
(c) Give the vfs_* functions an *optional* vfsmount argument.
In the end I probably find (c) the most elegant but this
can be discussed later, even after your changes are merged.
Filip
notification), as I suggested earlier.
(c) Give the vfs_* functions an *optional* vfsmount argument.
In the end I probably find (c) the most elegant but this
can be discussed later, even after your changes are merged.
Filip
esumably
could be implemented on top of your suggested patches.
Either way, I suggest that implementing the nameless filename events
is a good idea. I do not know whether they will be the best choice
for my application but they probably will be useful for some
applications.
Filip
esumably
could be implemented on top of your suggested patches.
Either way, I suggest that implementing the nameless filename events
is a good idea. I do not know whether they will be the best choice
for my application but they probably will be useful for some
applications.
Filip
o keep an elevated refcount of the object
> in the events queue.
That sounds good but from what I've understood, not all
filesystems support handles. Is this a concern? (Maybe the
right answer is to extend handle support...)
Filip
o keep an elevated refcount of the object
> in the events queue.
That sounds good but from what I've understood, not all
filesystems support handles. Is this a concern? (Maybe the
right answer is to extend handle support...)
Filip
gy
either, there are always compromises.
> If you don't specify FAN_EVENT_INFO_NAME, you can get filename events
> FAN_MOVE|FAN_CREATE|FAN_DELETE without the name.
>
> What you do get is the file descriptor of the parent. sounds familiar? ;-)
I didn't notice this bit. That sounds like a win-win.
Filip
gy
either, there are always compromises.
> If you don't specify FAN_EVENT_INFO_NAME, you can get filename events
> FAN_MOVE|FAN_CREATE|FAN_DELETE without the name.
>
> What you do get is the file descriptor of the parent. sounds familiar? ;-)
I didn't notice this bit. That sounds like a win-win.
Filip
An example userspace program that uses FAN_MODIFY_DIR to reliably keep
an up-to-date internal representation of the file system. It uses some
filehandle trickery to identify inodes, other heuristics could be also
used.
---
//#define _GNU_SOURCE
#include
#include
#include
#include
#include
An example userspace program that uses FAN_MODIFY_DIR to reliably keep
an up-to-date internal representation of the file system. It uses some
filehandle trickery to identify inodes, other heuristics could be also
used.
---
//#define _GNU_SOURCE
#include
#include
#include
#include
#include
-by: Filip Štědronský <r.l...@regnarg.cz>
---
An alternative might be to create wrapper functions like
vfs_path_(rename|unlink|...). They could also take care of calling
security_path_(rename|unlink|...), which is currently also up to
the indvidual callers (possibly with a flag because it
-by: Filip Štědronský
---
An alternative might be to create wrapper functions like
vfs_path_(rename|unlink|...). They could also take care of calling
security_path_(rename|unlink|...), which is currently also up to
the indvidual callers (possibly with a flag because it might not
be always desired
files).
Signed-off-by: Filip Štědronský <r.l...@regnarg.cz>
---
An alternative might be to create wrapper functions like
vfs_path_(rename|unlink|...). They could also take care of calling
security_path_(rename|unlink|...), which is currently also up to
the indvidual callers (possibly with
files).
Signed-off-by: Filip Štědronský
---
An alternative might be to create wrapper functions like
vfs_path_(rename|unlink|...). They could also take care of calling
security_path_(rename|unlink|...), which is currently also up to
the indvidual callers (possibly with a flag because it might
use): 0x
Signed-off-by: Filip Matusiak <filip.matus...@tieto.com>
---
net/mac80211/vht.c | 16
1 file changed, 16 insertions(+)
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index ee71576..6832bf6 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -270
use): 0x
Signed-off-by: Filip Matusiak
---
net/mac80211/vht.c | 16
1 file changed, 16 insertions(+)
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index ee71576..6832bf6 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -270,6 +27
) in all supported channel widths.
For some devices firmware asserts if such situation occurs.
Signed-off-by: Filip Matusiak <filip.matus...@tieto.com>
---
net/mac80211/vht.c | 16
1 file changed, 16 insertions(+)
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
) in all supported channel widths.
For some devices firmware asserts if such situation occurs.
Signed-off-by: Filip Matusiak
---
net/mac80211/vht.c | 16
1 file changed, 16 insertions(+)
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index ee71576..ce93cff 100644
Replace simple_strto with appropriate kstrto functions as recommended
by checkpatch, removing no longer required variables.
Change pid, sig types from long to pid_t, int respectively.
Signed-off-by: Filip Ayazi
Reviewed-by: Daniel Thompson
---
changes from v2:
store kstrto return value
On 06/01/2015 11:28 AM, Daniel Thompson wrote:
> On 31/05/15 18:59, Filip Ayazi wrote:
>> Replace simple_strto with appropriate kstrto functions as recommended
>> by checkpatch, change pid, sig types to unsigned int, int respectively.
>
> A changelog describing the changes ar
On 06/01/2015 11:28 AM, Daniel Thompson wrote:
On 31/05/15 18:59, Filip Ayazi wrote:
Replace simple_strto with appropriate kstrto functions as recommended
by checkpatch, change pid, sig types to unsigned int, int respectively.
A changelog describing the changes are in v2 would be nice here
Replace simple_strto with appropriate kstrto functions as recommended
by checkpatch, removing no longer required variables.
Change pid, sig types from long to pid_t, int respectively.
Signed-off-by: Filip Ayazi filipay...@gmail.com
Reviewed-by: Daniel Thompson daniel.thomp...@linaro.org
Replace simple_strto with appropriate kstrto functions as recommended
by checkpatch, change pid, sig types to unsigned int, int respectively.
Signed-off-by: Filip Ayazi
---
kernel/debug/kdb/kdb_main.c | 56 +++--
1 file changed, 19 insertions(+), 37
On 05/31/2015 02:29 PM, Alexey Dobriyan wrote:
Replace obsolete simple_strto* calls with appropriate kstrto*
functions.
static int kdb_kill(int argc, const char **argv)
{
long sig, pid;
- char *endp;
struct task_struct *p;
struct siginfo info;
if (argc
Replace obsolete simple_strto* calls with appropriate kstrto* functions.
Signed-off-by: Filip Ayazi
---
kernel/debug/kdb/kdb_main.c | 53 +++--
1 file changed, 17 insertions(+), 36 deletions(-)
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb
On 05/31/2015 02:29 PM, Alexey Dobriyan wrote:
Replace obsolete simple_strto* calls with appropriate kstrto*
functions.
static int kdb_kill(int argc, const char **argv)
{
long sig, pid;
- char *endp;
struct task_struct *p;
struct siginfo info;
if (argc
Replace simple_strto with appropriate kstrto functions as recommended
by checkpatch, change pid, sig types to unsigned int, int respectively.
Signed-off-by: Filip Ayazi filipay...@gmail.com
---
kernel/debug/kdb/kdb_main.c | 56 +++--
1 file changed, 19
Replace obsolete simple_strto* calls with appropriate kstrto* functions.
Signed-off-by: Filip Ayazi filipay...@gmail.com
---
kernel/debug/kdb/kdb_main.c | 53 +++--
1 file changed, 17 insertions(+), 36 deletions(-)
diff --git a/kernel/debug/kdb/kdb_main.c
, I think it's best if
this patch is ignored (for now), and I'll submit a patch series for the
8306 and a custom board in a couple of weeks/months, when I find some
time to clean up the board code.
- Filip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
, I think it's best if
this patch is ignored (for now), and I'll submit a patch series for the
8306 and a custom board in a couple of weeks/months, when I find some
time to clean up the board code.
- Filip
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On 4/3/2015 2:01 PM, Paul Bolle wrote:
On Fri, 2015-04-03 at 12:44 +0200, Filip Brozovic wrote:
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
+# used for gpio
+config PPC_MPC830x
+ bool
+ select ARCH_WANT_OPTIONAL_GPIOLIB
+
+config
Add chip specific initialization for the MPC8306.
Signed-off-by: Filip Brozovic
---
Changes from v1:
- Fix multiplatform support for setting QE SNUMs
arch/powerpc/platforms/83xx/Kconfig | 8
arch/powerpc/platforms/83xx/mpc83xx.h | 4
arch/powerpc/platforms/83xx/usb.c | 14
Add chip specific initialization for the MPC8306.
Signed-off-by: Filip Brozovic fbrozo...@gmail.com
---
Changes from v1:
- Fix multiplatform support for setting QE SNUMs
arch/powerpc/platforms/83xx/Kconfig | 8
arch/powerpc/platforms/83xx/mpc83xx.h | 4
arch/powerpc/platforms
On 4/3/2015 2:01 PM, Paul Bolle wrote:
On Fri, 2015-04-03 at 12:44 +0200, Filip Brozovic wrote:
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
+# used for gpio
+config PPC_MPC830x
+ bool
+ select ARCH_WANT_OPTIONAL_GPIOLIB
+
+config
On 3/31/2015 7:54 PM, Scott Wood wrote:
This breaks multiplatform support. You need to determine this at
runtime.
Understood, but I'm unsure of how to do this exactly. Would it be
appropriate to define another array, snum_init_14, with the SNUM values
for the MPC8306 QE, change the minimum
On 3/31/2015 7:54 PM, Scott Wood wrote:
This breaks multiplatform support. You need to determine this at
runtime.
Understood, but I'm unsure of how to do this exactly. Would it be
appropriate to define another array, snum_init_14, with the SNUM values
for the MPC8306 QE, change the minimum
Add chip specific initialization for the MPC8306.
Signed-off-by: Filip Brozovic
---
arch/powerpc/platforms/83xx/Kconfig | 8
arch/powerpc/platforms/83xx/mpc83xx.h | 4
arch/powerpc/platforms/83xx/usb.c | 14 +++---
arch/powerpc/platforms/Kconfig| 10
Add chip specific initialization for the MPC8306.
Signed-off-by: Filip Brozovic fbrozo...@gmail.com
---
arch/powerpc/platforms/83xx/Kconfig | 8
arch/powerpc/platforms/83xx/mpc83xx.h | 4
arch/powerpc/platforms/83xx/usb.c | 14 +++---
arch/powerpc/platforms/Kconfig
Commit 98dc070373 ("Input: synaptics - add quirk for Thinkpad E440") had
a typo in ymax, this changes the value to the one reported by
touchpad-edge-detector and mentioned in the commit.
Signed-off-by: Filip Ayazi
---
drivers/input/mouse/synaptics.c | 2 +-
1 file changed, 1 inser
On 03/25/2015 06:22 PM, Dmitry Torokhov wrote:
On Wed, Mar 25, 2015 at 09:57:51AM -0300, Ramiro Morales wrote:
On Wed, Mar 25, 2015 at 6:04 AM, Daniel Martin wrote:
On 25 March 2015 at 02:20, Filip Ayazi wrote:
Sets min_max_quirk values for LEN2006 touchpad found in Lenovo Thinkpad E440
On 03/25/2015 06:22 PM, Dmitry Torokhov wrote:
On Wed, Mar 25, 2015 at 09:57:51AM -0300, Ramiro Morales wrote:
On Wed, Mar 25, 2015 at 6:04 AM, Daniel Martin consume.no...@gmail.com wrote:
On 25 March 2015 at 02:20, Filip Ayazi filipay...@gmail.com wrote:
Sets min_max_quirk values for LEN2006
Commit 98dc070373 (Input: synaptics - add quirk for Thinkpad E440) had
a typo in ymax, this changes the value to the one reported by
touchpad-edge-detector and mentioned in the commit.
Signed-off-by: Filip Ayazi filipay...@gmail.com
---
drivers/input/mouse/synaptics.c | 2 +-
1 file changed, 1
Sets min_max_quirk values for LEN2006 touchpad found in Lenovo Thinkpad E440
(board_id=2691).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=89641
Signed-off-by: Filip Ayazi
---
drivers/input/mouse/synaptics.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/input/mouse
Sets min_max_quirk values for LEN2006 touchpad found in Lenovo Thinkpad E440
(board_id=2691).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=89641
Signed-off-by: Filip Ayazi filipay...@gmail.com
---
drivers/input/mouse/synaptics.c | 5 +
1 file changed, 5 insertions(+)
diff --git
On 02/28/2015 08:55 PM, Emmanuel Grumbach wrote:
On Sat, Feb 28, 2015 at 1:10 AM, Filip Ayazi wrote:
On the 7260 time event was often ended before end_time and connections failed
with "No association and the time event is over already...".
This checks that the time event is act
On 02/28/2015 08:55 PM, Emmanuel Grumbach wrote:
On Sat, Feb 28, 2015 at 1:10 AM, Filip Ayazi filipay...@gmail.com wrote:
On the 7260 time event was often ended before end_time and connections failed
with No association and the time event is over already
This checks that the time event
On the 7260 time event was often ended before end_time and connections failed
with "No association and the time event is over already...".
This checks that the time event is actually over before disconnecting.
Signed-off-by: Filip Ayazi
---
drivers/net/wireless/iwlwifi/mvm/time-e
On the 7260 time event was often ended before end_time and connections failed
with No association and the time event is over already
This checks that the time event is actually over before disconnecting.
Signed-off-by: Filip Ayazi filipay...@gmail.com
---
drivers/net/wireless/iwlwifi/mvm
Shift the I2S mode value by the necessary amount before writing the
registers. This makes Right Justified and PCM mode work in addition to
the default Left Justified mode.
Signed-off-by: Filip Brozovic
---
sound/soc/codecs/sgtl5000.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions
Shift the I2S mode value by the necessary amount before writing the
registers. This makes Right Justified and PCM mode work in addition to
the default Left Justified mode.
Signed-off-by: Filip Brozovic fbrozo...@gmail.com
---
sound/soc/codecs/sgtl5000.c | 10 +-
1 file changed, 5
, that we are
able to use successfully with kernel 2.6.16.20.
Have you any suggestions to resolve this issue ?
Thanks in advance,
Filip Majewski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
to use successfully with kernel 2.6.16.20.
Have you any suggestions to resolve this issue ?
Thanks in advance,
Filip Majewski
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
]: *** [_dir_kernel] Error 2
make[1]: Leaving directory `/usr/src/linux'
make: *** [stamp-build] Error 2
lucretia:/usr/src/linux$
Regards,
Filip
--
My opinions may have changed, but not the fact that I am right
-- Daniel Vogel
PGP signature
]: *** [_dir_kernel] Error 2
make[1]: Leaving directory `/usr/src/linux'
make: *** [stamp-build] Error 2
lucretia:/usr/src/linux$
Regards,
Filip
--
My opinions may have changed, but not the fact that I am right
-- Daniel Vogel
PGP signature
ls and all was fine - so it is most likely a vfat related
problem.
Also, the file was written to the vfat partition in 2.4.2, so writing may not
even be affected by this possible bug.
Regards,
Filip
--
Sometimes it pays to stay in bed on Monday, rather than spending the rest of
the week debuggin
ls and all was fine - so it is most likely a vfat related
problem.
Also, the file was written to the vfat partition in 2.4.2, so writing may not
even be affected by this possible bug.
Regards,
Filip
--
Sometimes it pays to stay in bed on Monday, rather than spending the rest of
the week debuggin
78 matches
Mail list logo