These need a subsystem prefix in the subject line:
[PATCH 1/3] staging: goldfish: Fix checkpatch warnings in goldfish_audio.c
On Thu, May 31, 2018 at 05:22:21PM -0700, r...@google.com wrote:
> -#define AUDIO_READ(data, addr) (readl(data->reg_base + addr))
> -#define AUDIO_WRITE(data
On Thu, May 31, 2018 at 05:30:24PM +, Dilger, Andreas wrote:
> On May 31, 2018, at 18:54, Greg Kroah-Hartman
> wrote:
> >
> > On Tue, May 29, 2018 at 10:21:45AM -0400, James Simmons wrote:
> >> From: "John L. Hammond"
> >>
> >> Pre 2.10.1 MDTs will crash when they receive a listxattr (MDS_
On Tue, May 29, 2018 at 10:21:40AM -0400, James Simmons wrote:
> From: James Simmons
>
> Recently lustre support has been expanded to extreme machines with as
> many as a 1000+ cores. On the other end lustre also has been ported
> to platforms like ARM and KNL which have uniquie NUMA and core set
On Tue, May 29, 2018 at 10:21:47AM -0400, James Simmons wrote:
> From: Amir Shehata
>
> Move from num_possible_cpus() to nr_cpu_ids.
Nit, when doing a "v2" of a patch, in a series that is not all "v2", put
the moniker after the patch number. Otherwise it does not sort properly
in anyone's email
On Tue, May 29, 2018 at 10:21:47AM -0400, James Simmons wrote:
> From: Amir Shehata
>
> Move from num_possible_cpus() to nr_cpu_ids.
This says what you did, not _why_ you did it. If these functions are
really identical, why do we have both of them? :)
greg k-h
On Tue, May 29, 2018 at 10:21:58AM -0400, James Simmons wrote:
> From: Dmitry Eremin
>
> Change goto label out to err.
Again, this says what it does, not why.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/
On Tue, May 29, 2018 at 10:21:48AM -0400, James Simmons wrote:
> From: Amir Shehata
>
> This patch adds NUMA node support.
Really? It looks like you just added an empty data structure pointer
that doesn't really do anything at all.
Where are you reading the host memory NUMA information from?
On Tue, May 29, 2018 at 10:21:53AM -0400, James Simmons wrote:
> int cfs_cpt_set_nodemask(struct cfs_cpt_table *cptab,
> - int cpt, nodemask_t *mask);
> + int cpt, const nodemask_t *mask);
This is not a coding style change. It is a semi-functional change
On Tue, May 29, 2018 at 10:21:51AM -0400, James Simmons wrote:
> From: Amir Shehata
>
> On systems with large number of NUMA nodes and cores it is easy
> to incorrectly configure their use with Lustre. Provide debugfs
> files which can help track down any issues.
>
> Signed-off-by: Amir Shehata
On Tue, May 29, 2018 at 10:22:03AM -0400, James Simmons wrote:
> From: Dmitry Eremin
>
> Currently the module param string for CPU pattern can be
> modified which is wrong. Rewrite CPU pattern parsing code
> to avoid the passed buffer from being changed. This change
> also enables us to add real
On Sat, May 26, 2018 at 09:10:18AM +0100, John Whitmore wrote:
> Coding style requires blank line after definitions and function definition,
> blank lines removed. Correction of some indentation.
Do not change indentation in the same patch you should only be doing
blank line removal or adding in.
On Sat, May 26, 2018 at 09:10:19AM +0100, John Whitmore wrote:
> Missed these in the last pass. Coding style does not require blank line after
> opening brace of a function.
This should have been merged with the previous patch :(
___
devel mailing list
The Lustre filesystem has been in the kernel tree for over 5 years now.
While it has been an endless source of enjoyment for new kernel
developers learning how to do basic codingstyle cleanups, as well as an
semi-entertaining source of bewilderment from the vfs developers any
time they have looked
On Fri, Jun 01, 2018 at 12:25:43AM +0530, Sankalp Negi wrote:
> This patch fixes following checkpatch.pl issues:
>
> WARNING : line over 80 characters
> ERROR : code indent should use tabs where possible
> WARNING : no spaces at the start of a line
> ERROR : switch and case should be at the sa
On Thu, May 31, 2018 at 02:20:49PM +0200, Sergio Paracuellos wrote:
> On Thu, May 31, 2018 at 03:27:46PM +1000, NeilBrown wrote:
> > On Wed, May 30 2018, Sergio Paracuellos wrote:
> >
> > > Most gpio chips have two cells for interrupts and this should be also.
> > > Set this property in the device
Function to_mediatek_gpio can directly return without declaring
anything else in its body improving readability. Also change
pointer '*' declaration to be with return type in the upper line.
Signed-off-by: Sergio Paracuellos
Reviewed-by: NeilBrown
---
drivers/staging/mt7621-gpio/gpio-mt7621.c |
This commit update documentation for #interrupt-cells property in
the gpio node which has been changed from '1' to '2'.
Signed-off-by: Sergio Paracuellos
Reviewed-by: NeilBrown
---
drivers/staging/mt7621-gpio/mediatek,mt7621-gpio.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions
This commit reviews driver includes reordering them in
alphabetic order. This improves readability.
Signed-off-by: Sergio Paracuellos
Reviewed-by: NeilBrown
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/
There is no special gain in using pointers for 'gc_map' inside
'mtk_data' structure. We know the number of banks which is fixed
to MTK_BANK_CNT and we can just statically allocate them without
using kernel allocators.
Signed-off-by: Sergio Paracuellos
Reviewed-by: NeilBrown
---
drivers/staging/
Most gpio chips have two cells for interrupts and this should be also.
Set this property in the device tree accordly fixing this up. In order
to make this working properly the xlate function for the irq_domain must
be updated to use the 'irq_domain_xlate_twocell' one in the driver.
One more minima
There are macros in gpio kernel's headers to define direction
of a gpio. Use them instead of return custom '0' and '1' values.
Signed-off-by: Sergio Paracuellos
Reviewed-by: NeilBrown
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
On Fri, Jun 01, 2018 at 11:18:07AM +0200, Greg KH wrote:
> On Thu, May 31, 2018 at 02:20:49PM +0200, Sergio Paracuellos wrote:
> > On Thu, May 31, 2018 at 03:27:46PM +1000, NeilBrown wrote:
> > > On Wed, May 30 2018, Sergio Paracuellos wrote:
> > >
> > > > Most gpio chips have two cells for interr
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Clean up the vchiq_arm code by not caring about the value of debugfs
calls. This ends up removing a number of lines
On Wed, May 30, 2018 at 12:51:12PM -0700, Eric Anholt wrote:
> Greg Kroah-Hartman writes:
>
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do something different based on this.
> >
> > Cle
vchiq_debugfs_top() is only a wrapper around a pointer to a dentry, so
just use the dentry directly instead, making it a static variable
instead of part of a static structure.
This also removes the pointless BUG_ON() when checking that dentry as no
one should ever care if debugfs is working or not
This does not need to be part of a wrapper function, or in a structure,
just properly reference it directly as a single variable.
The whole variable will be going away soon anyway, this is just a step
toward that direction.
Suggested-by: Eric Anholt
Cc: Stefan Wahren
Cc: Kees Cook
Cc: Dan Carp
This structure, and the one static variable that was declared with it,
were not being used for anything. The log_categories field was being
set, but never used again. So just remove it entirely as it is not
needed at all.
Suggested-by: Eric Anholt
Cc: Stefan Wahren
Cc: Kees Cook
Cc: Dan Carpe
The log entry dentries are only set, never referenced, so no need to
keep them around. Remove the pointer from struct
vchiq_debugfs_log_entry as it is not needed anymore and get rid of the
separate vchiq_debugfs_create_log_entries() function as it is only used
in one place.
Suggested-by: Eric Anh
There's no need to set this to be int * when it is only used as a void *.
This lets us remove the unneeded cast, and unneeded temporary variable
the one place it is referenced in the code.
Suggested-by: Eric Anholt
Cc: Stefan Wahren
Cc: Kees Cook
Cc: Dan Carpenter
Cc: Arnd Bergmann
Cc: Keerth
Thanks,
all that churn without much visible progress to a mergeable codebase
was really ennoying.
I'd recommend if people want to merge lustre they start with a managable
subset first, e.g. the fs client code with simple IP-only networking.
___
devel ma
Move the mt7621-gpio driver out of staging and into mainline
Signed-off-by: Sergio Paracuellos
---
.../devicetree/bindings/gpio}/mediatek,mt7621-gpio.txt | 0
drivers/gpio/Kconfig | 7 +++
drivers/gpio/Makefile
Add a rw semaphore fixing potential NULL pointer dereferences in the
pi433 driver.
If pi433_release and pi433_ioctl are concurrently called,
pi433_release might set filp->private_data to NULL while pi433_ioctl
is still accessing it, leading to NULL pointer dereference. This issue
might also affect
Hi Valdis,
> > @@ -805,9 +809,11 @@ pi433_read(struct file *filp, char __user *buf, size_t
> > size, loff_t *f_pos)
> > if (bytes_received > 0) {
> > retval = copy_to_user(buf, device->rx_buffer, bytes_received);
> > if (retval)
> > + up_read(&instanc
On Fri, 01 Jun 2018 08:50:37 -0400, Hugo Lefeuvre said:
> @@ -805,9 +809,11 @@ pi433_read(struct file *filp, char __user *buf, size_t
> size, loff_t *f_pos)
> if (bytes_received > 0) {
> retval = copy_to_user(buf, device->rx_buffer, bytes_received);
> if (retval)
On Fri, Jun 01, 2018 at 08:50:37AM -0400, Hugo Lefeuvre wrote:
> Add a rw semaphore fixing potential NULL pointer dereferences in the
> pi433 driver.
Unless you can measure the performance difference, do not use a rw
semaphore, just use a normal mutex please. Odds are it will be faster
in the end
Greg Kroah-Hartman writes:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Clean up the vchiq_arm code by not caring about the value of debugfs
> calls.
On Fri, Jun 01, 2018 at 02:02:50PM +0200, Sergio Paracuellos wrote:
> Move the mt7621-gpio driver out of staging and into mainline
>
> Signed-off-by: Sergio Paracuellos
> ---
> .../devicetree/bindings/gpio}/mediatek,mt7621-gpio.txt | 0
> drivers/gpio/Kconfig
On Jun 1, 2018, at 7:41 AM, Christoph Hellwig wrote:
>
> Thanks,
>
> all that churn without much visible progress to a mergeable codebase
> was really ennoying.
>
> I'd recommend if people want to merge lustre they start with a managable
> subset first, e.g. the fs client code with simple IP-on
Would it makes sense to land LNet and LNDs on their own first? Get the
networking house in order first before layering on the file system?
Doug
> On Jun 1, 2018, at 11:20 AM, Andreas Dilger wrote:
>
> On Jun 1, 2018, at 7:41 AM, Christoph Hellwig wrote:
>>
>> Thanks,
>>
>> all that churn w
From: Roman Kiryanov
Address issues pointed by checkpatch.pl
Signed-off-by: Roman Kiryanov
---
drivers/staging/goldfish/goldfish_audio.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/goldfish/goldfish_audio.c
b/drivers/staging/goldfish/goldfish_aud
On Jun 1, 2018, at 5:11 AM, Greg Kroah-Hartman
wrote:
>
> The Lustre filesystem has been in the kernel tree for over 5 years now.
> While it has been an endless source of enjoyment for new kernel
> developers learning how to do basic codingstyle cleanups, as well as an
> semi-entertaining source
On Fri, Jun 1, 2018 at 3:22 AM, wrote:
> From: Joshua Lang
>
> The buffer_status field is interrupt updated. After every read request,
> the buffer_status read field should be reset so that on the next loop
> iteration we don't read a stale value and read data before the
> device is ready.
>
> S
The ncpfs code moved into the staging tree back in November 2017 and no
one has complained or even noticed it was gone. Because of that, let's
just delete it.
Cc: Stephen Hemminger
Cc: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/Kconfig|2 -
drive
Now that ncpfs is gone from the tree, no need to have the compatibility
thunking layer around, it will not actually go anywhere :)
So delete that logic from fs/compat.c, it is no longer needed.
Signed-off-by: Greg Kroah-Hartman
---
fs/compat.c | 72 +-
Now that ncpfs is removed from the tree, there is no need to keep the
uapi header files around as no one uses them, and it is not a feature
that the kernel supports anymore.
Signed-off-by: Greg Kroah-Hartman
---
include/uapi/linux/ncp.h | 202 -
include/uapi
No need for any more ncpfs documentation around given that the
filesystem is now removed.
Signed-off-by: Greg Kroah-Hartman
---
Documentation/filesystems/00-INDEX | 2 --
Documentation/filesystems/ncpfs.txt | 12
2 files changed, 14 deletions(-)
delete mode 100644 Documentation/f
The ipx code moved into the staging tree back in November 2017 and no
one has complained or even noticed it was gone. Because of that, let's
just delete it.
Note, the ipx header files are not removed here, that will come later
through the networking tree, as that takes a bit more work to unwind.
The ncpfs filesystem and ipx networking code moved into the
drivers/staging/ tree back in November of last year. Since then, no one
has steped up to take over maintance of this code. Given that it has
been more than 6 months, it is time to delete it.
Note, there is more work to be done to remove
Updated. Thank you.
On Fri, Jun 1, 2018 at 11:40 AM Dan Carpenter wrote:
>
> On Fri, Jun 1, 2018 at 3:22 AM, wrote:
> > From: Joshua Lang
> >
> > The buffer_status field is interrupt updated. After every read request,
> > the buffer_status read field should be reset so that on the next loop
> >
> I suggest you submit this as a new driver to the gpio maintainer and
> developers and then if/when it is merged into that tree, we can then
> delete the staging tree version. That makes it easier for the gpio
> developers to review it and makes any cross-tree merge issues go away.
I see. Ok, I'
From: Joshua Lang
The buffer_status field is interrupt updated. After every read request,
the buffer_status read field should be reset so that on the next loop
iteration we don't read a stale value and read data before the
device is ready.
Signed-off-by: “Joshua Lang”
---
drivers/staging/goldf
On Fri, Jun 01, 2018 at 02:30:49PM -0400, Andreas Dilger wrote:
> On Jun 1, 2018, at 5:11 AM, Greg Kroah-Hartman
> wrote:
> >
> > The Lustre filesystem has been in the kernel tree for over 5 years now.
> > While it has been an endless source of enjoyment for new kernel
> > developers learning ho
On Fri, Jun 01, 2018 at 11:31:21AM -0700, r...@google.com wrote:
> From: Roman Kiryanov
>
> Address issues pointed by checkpatch.pl
"issues"? Plural?
>
> Signed-off-by: Roman Kiryanov
> ---
> drivers/staging/goldfish/goldfish_audio.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletio
On Fri, Jun 01, 2018 at 11:31:22AM -0700, r...@google.com wrote:
> From: Yu Ning
>
> Besides adding ACPI bindings to the goldfish audio driver, modify the
> ACPI driver to inform it that the driver is a platform device.
>
> Signed-off-by: Yu Ning
> Signed-off-by: Roman Kiryanov
> ---
> driver
On Fri, Jun 01, 2018 at 11:31:23AM -0700, r...@google.com wrote:
> From: Joshua Lang
>
> The buffer_status field is interrupt updated. After every read request,
> the buffer_status read field should be reset so that on the next loop
> iteration we don't read a stale value and read data before the
From: Joshua Lang
The buffer_status field is interrupt updated. After every read request,
the buffer_status read field should be reset so that on the next loop
iteration we don't read a stale value and read data before the
device is ready.
Signed-off-by: “Joshua Lang”
Signed-off-by: Roman Kirya
I remember checkpatch complained about aligning to the first argument.
Somehow I cannot reproduce this now. Feel free to drop this patch.
Thank you.
On Fri, Jun 1, 2018 at 12:11 PM Greg KH wrote:
>
> On Fri, Jun 01, 2018 at 11:31:21AM -0700, r...@google.com wrote:
> > From: Roman Kiryanov
> >
>
On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote:
> On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote:
> > On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez
> > wrote:
> > > Is ptr below
> > >
> > > ret = request_firmware_into_buf(&seg_fw, fw_name, dev,
> >
> On Jun 1, 2018, at 2:30 PM, Andreas Dilger wrote:
>
> On Jun 1, 2018, at 5:11 AM, Greg Kroah-Hartman
> wrote:
>>
>> The Lustre filesystem has been in the kernel tree for over 5 years now.
>> While it has been an endless source of enjoyment for new kernel
>> developers learning how to do bas
Quoting Rui Miguel Silva (2018-05-22 07:52:36)
> Fix the mipi dphy root divider to mipi_dphy_pre_div, this would remove a
> orphan
> clock and set the correct parent.
>
> before:
> cat clk_orphan_summary
> enable prepare protect
>clock
Quoting Rui Miguel Silva (2018-05-22 07:52:37)
> To guarantee that we do not get Overflow in image FIFO the outer bandwidth has
> to be faster than inputer bandwidth. For that it must be possible to set a
> faster frequency clock. So set new parent to sys_pfd3 clock for the mipi csi
> block.
>
> A
From: Joshua Lang
The buffer_status field is interrupt updated. After every read request,
the buffer_status read field should be reset so that on the next loop
iteration we don't read a stale value and read data before the
device is ready.
Signed-off-by: Joshua Lang
Signed-off-by: Roman Kiryano
I fixed "". They were in the original commit, I thought that was a
reason for this.
On Fri, Jun 1, 2018 at 12:13 PM Greg KH wrote:
>
> On Fri, Jun 01, 2018 at 11:31:23AM -0700, r...@google.com wrote:
> > From: Joshua Lang
> >
> > The buffer_status field is interrupt updated. After every read requ
On Fri, Jun 01 2018, Doug Oucharek wrote:
> Would it makes sense to land LNet and LNDs on their own first? Get
> the networking house in order first before layering on the file
> system?
I'd like to turn that question on it's head:
Do we need LNet and LNDs? What value do they provide?
(this i
On Fri, Jun 01 2018, Sergio Paracuellos wrote:
>> I suggest you submit this as a new driver to the gpio maintainer and
>> developers and then if/when it is merged into that tree, we can then
>> delete the staging tree version. That makes it easier for the gpio
>> developers to review it and makes
On Fri, Jun 01 2018, Greg Kroah-Hartman wrote:
>
> So, let's just delete the whole mess. Now the lustre developers can go
> off and work in their out-of-tree codebase and not have to worry about
> providing valid changelog entries and breaking their patches up into
> logical pieces.
I find it in
66 matches
Mail list logo
