Thank you for the clarification Bjorn! I was on vacation..sorry for my delay.
Closing the loop here, I understand we're not getting this patch
merged (due to its restriction to domain 0) and there was a suggestion
in the thread of trying to block MSIs from the IOMMU init code (which
also have the
it failed with ftrace_size.
Apologies for the inconvenience!
Cheers,
Guilherme
appreciated.
Thanks in advance,
Guilherme
d-up being implemented in another patch, I appreciate a lot.
Thanks in advance! Below, some references to lore archives.
Cheers,
Guilherme
References:
This V7 link:
https://lore.kernel.org/linux-pci/546d346644654915877365b19ea534378db0894d.1602788209.git.sathyanarayanan.kuppusw...@linux.inte
Hi Ashish, non-technical comment: in the subject, you might want to
s/SWIOTBL/SWIOTLB .
cheers,
Guilherme
Hi Dave and Kairui, thanks for your responses! OK, if that makes sense
to you I'm fine with it. I'd just recommend to test recent kernels in
multiple distros with the minimum "range" to see if 64M is enough for
crashkernel, maybe we'd need to bump that.
Cheers,
Guilherme
hink a bit more consideration is
needed in the ranges, at least accounting the number of devices of the
machine or something like that.
Cheers,
Guilherme
[0] https://salsa.debian.org/debian/makedumpfile/-/merge_requests/7
[1] Minimal as having a reduced initrd + "shrinking" parameters (like
nr_cpus=1).
Thank you Vincent, much appreciated! I'll respond in the patch thread,
hopefully we can get that included in 5.4.y .
Cheers,
Guilherme
On 19/11/2020 05:36, Vincent Guittot wrote:
> On Thu, 19 Nov 2020 at 01:36, Tao Zhou wrote:
>>
>> On Thu, Nov 19, 2020 at 07:50:15AM +0800, Tao Zhou wrote:
>>> On Wed, Nov 18, 2020 at 07:56:38PM -0300, Guilherme G. Piccoli wrote:
>>>> Hi Vincent (an
suggesting such backport to 5.4
and introduce complex-to-debug issues.
Let me know your thoughts Vincent (and all CCed), thanks in advance.
Cheers,
Guilherme
P.S. For those that deleted this thread from the email client, here's a
link:
https://lore.kernel.org/lkml/20200513135528.4742-1-vincent.guit...@
Thanks a lot Bjorn! I confess except for PPC64 Server machines, I
never saw other "domains" or segments. Is it common in x86 to have
that? The early_quirks() are restricted to the first segment, no
matter how many host bridges we have in segment ?
Thanks again!
ad 3 parents in the PCI tree (as per lspci -t), :00, :ff and
:80 - are those all under "segment 0" as per your verbiage? In our
case the troublemaker was under 0000:80, and the early_quirks() shut
the device up successfully.
Thanks,
Guilherme
On Mon, Nov 16, 2020 at 6:45 PM Eric W. Biederman wrote:
> The way to do that would be to collect the set of pci devices when the
> kexec on panic kernel is loaded, not during crash_kexec. If someone
> performs a device hotplug they would need to reload the kexec on panic
> kernel.
>
> I am not
the
limitations of early_quirks(), this problem seems not to be trivial.
I'm a bit against doing that in crash_kexec() for the reasons mentioned
in the thread, specially by Thomas and Eric - but if there's no other
way...maybe this is the way to go.
Cheers,
Guilherme
P.S. Fixed Gavin's bouncing address, sorry for that.
On 23/10/2018 14:03, Bjorn Helgaas wrote:
> On Mon, Oct 22, 2018 at 05:35:06PM -0300, Guilherme G. Piccoli wrote:
>> On 18/10/2018 19:15, Bjorn Helgaas wrote:
>>> On Thu, Oct 18, 2018 at 03:37:19PM -0300, Guilherme G. Piccoli wrote:
>>> [...]
>> I u
MSIs. The
> only cure is to disable interrupts or disable MSIs on all PCI[E] devices
> early on. Disabling interrupts is not so much of an option obviously :)
Great to know that, we imagined if it would be possible to have a more
"soft" option, but it seems clearing MSIs is the way to
On Mon, Oct 26, 2020 at 4:59 PM Thomas Gleixner wrote:
>
> On Mon, Oct 26 2020 at 12:06, Guilherme Piccoli wrote:
> > On Sun, Oct 25, 2020 at 8:12 AM Pingfan Liu wrote:
> >
> > Some time ago (2 years) we faced a similar issue in x86-64, a hard to
> > debug pro
ntually was narrowed to a buggy NIC FW
flooding IRQs in kdump kernel, and no messages showed (although kernel
changed a lot since that time, today we might have better IRQ
handling/warning). We tried an early-boot fix, by disabling MSIs (as
per PCI spec) early in x86 boot, but it wasn't acc
On Tue, Sep 22, 2020 at 11:53 AM wrote:
>
>
> On 9/22/20 6:58 AM, Philipp Rudo wrote:
> >
> > AFAIK pstore requires UEFI to work. So what's the point to enable it on
> > non-UEFI
> > systems?
>
>
> I don't think UEFI is required, ERST can specify its own backend. And that,
> in fact, can be
a special reason to not have it on long-term stables, like 4.9
or 4.14. It's a subtle portion of arch code, so I'm afraid I didn't see
something that prevents its backport for previous versions.
Thanks in advance,
Guilherme
On 17/08/2020 13:49, Greg KH wrote:
> [...]
>> I'm sorry, I hoped the subject + thread would suffice heh
>
> There is no thread here :(
>
Wow, that's odd. I've sent with In-Reply-To, I'd expect it'd get
threaded with the original message. Looking in lore archive [1], it
seems my first message
On Mon, Aug 17, 2020 at 2:05 PM Greg KH wrote:
>
> On Mon, Aug 17, 2020 at 01:59:00PM -0300, Guilherme G. Piccoli wrote:
> > On 17/08/2020 13:49, Greg KH wrote:
> > > [...]
> > >> I'm sorry, I hoped the subject + thread would suffice heh
> > >
> >
On 17/08/2020 13:21, Greg KH wrote:
> On Mon, Aug 17, 2020 at 12:36:25PM -0300, Guilherme G. Piccoli wrote:
>> Hi Greg / Thomas and all involved here. First, apologies for
>> necro-bumping this thread, but I'm working a backport of this patch to
>> kernel 4.15 (Ubuntu) and t
Great catch Colin, thanks!
Feel free to add my:
Reviewed-by: Guilherme G. Piccoli
P.S. Not sure if it's only me, but the diff is soo much easier to
read when git is set to use patience diff algorithm:
https://termbin.com/f8ig
Thanks Vlastimil! I agree with you..it's a good new behavior to report
that case, I guess.
Cheers,
Guilherme
On Tue, Jun 16, 2020 at 5:02 AM Vlastimil Babka wrote:
>
> On 6/16/20 9:38 AM, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the following
Hi Jan and all involved here, I'd like to know if there was any news on
this patch - seems users are still facing this issue on AMD systems.
Thanks in advance,
Guilherme
On Mon, May 18, 2020 at 9:54 AM Enderborg, Peter
wrote:
> Usually change existing causes confusion. It should not be a problem but it
> happen.
>
I am sorry, but I really didn't understand your statement, can you be
more specific?
Thanks again!
case here) ?
Cheers,
Guilherme
ing
that because kernel mm subsystem statistics seem pretty.."comfortable"
the way they are, in files like vmstat, zoneinfo, etc. Let me know
your thoughts on this, if I could work on that or should wait statsfs.
Thanks,
Guilherme
ng, at least for some users. What if
we add that as a per-node stat in zoneinfo?
Cheers,
Guilherme
[0] lore.kernel.org/kvm/20200427141816.16703-1-eespo...@redhat.com
plenty of sysctls, but not all of them have identical/duplicate
boot params, so I went with the obvious ones, that I use more.
Cheers,
Guilherme
the problem we are trying to solve was more
like...admin forgot if they triggered or not the compaction hehe
So, counting on the user to keep track of it is what I'd like to
avoid. And thinking about drop_caches (that have an indication when
triggered) makes me think this indeed does make sense for compaction
too.
Cheers,
Guilherme
.
Signed-off-by: Guilherme G. Piccoli
---
This patch was based on linux-next/akpm branch, at d0f3f6070c3a.
Thanks in advance for reviews!
Cheers,
Guilherme
mm/compaction.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index
converted hung_task_panic
(see the patch series [0]) and put the alias table in alphabetical order.
[0] lore.kernel.org/lkml/20200427180433.7029-1-vba...@suse.cz
Signed-off-by: Guilherme G. Piccoli
---
This patch is based on linux-next/akpm branch, at d0f3f6070c3a. Thanks
in advance for reviews
On 10/15/19 11:05 AM, Michal Hocko wrote:
On Tue 15-10-19 10:58:36, Guilherme G. Piccoli wrote:
On 10/15/19 9:18 AM, Michal Hocko wrote:
I do agree with Qian Cai here. Kdump kernel requires a very tailored
environment considering it is running in a very restricted
configuration. The hugetlb
it's wrong to do this way -
although I agree initrd-only approach is more safe. But since Ubuntu
kdump rely on rootfs mount, we couldn't find a way to effectively
prevent the creation of hugepages completely, hence we tried to
introduce one.
Cheers,
Guilherme
have kdump scripts removing the kernel command-line options to
set hugepages, but it's not straightforward to prevent sysctl/sysfs
configuration, given it happens in later boot or anytime when the
system is running.
Signed-off-by: Guilherme G. Piccoli
---
.../admin-guide/kernel-parameters.txt
bling hugepages, something we don't currently
have on kernel. I'll submit a V2, for Ubuntu kdump specially this is
quite helpful!
Cheers,
Guilherme
, so I don't think we should rely
on "rootfs kdump is wrong" to refuse this patch's idea. If so, we
should then formalize the right way of kdumping.
Of course, this is only my opinion, let's see what people think about it!
Thanks,
Guilherme
tem.
Even in initrd-only approaches, we could have sysctl.conf being copied
to initramfs, and hugepages end-up getting set.
Also, I don't think the "nohugepages" is useful only for kdump - I
found odd we cannot prevent the creation of hugepages at all when
using sysfs writes.
Cheers,
Guilherme
have kdump scripts removing the kernel command-line options to
set hugepages, but it's not straightforward to prevent sysctl/sysfs
configuration, given it happens in later boot or anytime when the
system is running.
Signed-off-by: Guilherme G. Piccoli
---
About some decisions took in this patch
vcfg_name,
> + MEDIA_ENT_F_FLASH, 0, NULL,
> + NULL, _fla_ops);
> + if (ret)
> + goto err_free_hdl;
> +
> + /* Initialize standard values */
> + vfla->indicator_intensity = 0;
> + vfla->torch_intensity = 0;
> + vfla->flash_intensity = 0;
> + vfla->is_strobe = false;
> + vfla->timeout = 0;
> + vfla->last_strobe = 0;
> + vfla->led_mode = V4L2_FLASH_LED_MODE_NONE;
> +
> + return >ved;
> +
> +err_free_hdl:
> + v4l2_ctrl_handler_free(>hdl);
> +err_free_vfla:
> + kfree(vfla);
> +
> + return NULL;
> +}
> +
> +void vimc_fla_rm(struct vimc_device *vimc, struct vimc_ent_device *ved)
> +{
> + struct vimc_fla_device *vfla;
> +
> + if (!ved)
> + return;
> +
> + vfla = container_of(ved, struct vimc_fla_device, ved);
> + vimc_ent_sd_unregister(ved, >sd);
> +}
> --
> 2.23.0
>
>
> ___
> Lkcamp mailing list
> lkc...@lists.libreplanetbr.org
> https://lists.libreplanetbr.org/mailman/listinfo/lkcamp
Regards,
Guilherme
Hi David, was there any respin for this patch? I couldn't find it upstream.
This message shows a lot in the xfstests against cifs.
Thanks in advance,
Guilherme
No problem. In a previous patch I had one for each item, but I thought
it could be packed in a single one - and avoid '[PATCH n/m]'.
Thanks.
On 3/12/19, Dan Carpenter wrote:
> On Tue, Mar 12, 2019 at 11:39:13AM -0300, Guilherme T Maeoka wrote:
>> From: Guilherme T Maeoka
>>
>
From: Guilherme T Maeoka
Change 'if (a)' to 'if (!a)' and return. Otherwise, continue with
the previouly wrapped block of control. This reduces the indentation
level by 2 and 1.
I'm not if this commit contributes to the coding style.
Signed-off-by: Guilherme T Maeoka
---
drivers/staging
From: Guilherme T Maeoka
Fix coding style errors and warns complained by checkpatck.pl. To list:
- remove braces for single statements blocks,
- add space required around operators,
- replace spaces with tabs to indent,
- add blank line after declarations
Thank you for the review Joe. I'll have that in mind in the next patch.
On 3/9/19, Joe Perches wrote:
> On Sat, 2019-03-09 at 15:30 -0300, Guilherme Tadashi Maeoka wrote:
>> Fix an assignment in if condition.
>>
>> Signed-off-by: Guilherme Tadashi Maeoka
>> ---
&g
Pointer definition "foo * bar" should be "foo *bar".
Signed-off-by: Guilherme Tadashi Maeoka
---
drivers/staging/rtl8723bs/os_dep/osdep_service.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
b/drive
Fix space around operators, pointer definition, constant on the right
side, assignment outside of if condition and else to follow close brace
at staging: rtl8723bs: os_dep.
Guilherme Tadashi Maeoka (5):
Staging: rtl8723bs: os_dep: Fix assignment in if condition
Staging: rtl8723bs: os_dep: Fix
Place a constant on the right side of the test.
Signed-off-by: Guilherme Tadashi Maeoka
---
drivers/staging/rtl8723bs/os_dep/osdep_service.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
b/drivers/staging/rtl8723bs
Fix multiple space required coding style.
Signed-off-by: Guilherme Tadashi Maeoka
---
.../staging/rtl8723bs/os_dep/osdep_service.c | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
b/drivers/staging
Fix an assignment in if condition.
Signed-off-by: Guilherme Tadashi Maeoka
---
drivers/staging/rtl8723bs/os_dep/osdep_service.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
b/drivers/staging/rtl8723bs/os_dep
Fix else not following close brace '}'.
Signed-off-by: Guilherme Tadashi Maeoka
---
drivers/staging/rtl8723bs/os_dep/osdep_service.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
b/drivers/staging/rtl8723bs/os_dep
Fix some space required coding style.
Signed-off-by: Guilherme Tadashi Maeoka
---
drivers/staging/mt7621-pci/pci-mt7621.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 31310b6fb7db
efully this time the series gets merged
in Linus tree and we have the fix for this long-standing issue.
Cheers,
Guilherme
efully this time the series gets merged
in Linus tree and we have the fix for this long-standing issue.
Cheers,
Guilherme
Hi, thanks Dmitry for the re-spin - hopefully now the pa-risc issues
are fixed.
BTW, any news on the pa-risc testing? We're just waiting on this to get
the patchset merged?
Thanks in advance,
Guilherme
Hi, thanks Dmitry for the re-spin - hopefully now the pa-risc issues
are fixed.
BTW, any news on the pa-risc testing? We're just waiting on this to get
the patchset merged?
Thanks in advance,
Guilherme
On Fri, Oct 12, 2018 at 12:57 PM Dmitry Safonov wrote:
>
> Hi Guilherme,
>
> Just to let you know - I've done with more urgent issues now,
> so I'll be back on this patch on Monday, installing qemu-system-hppa
> and debugging the root case.
>
> Thanks,
> Dmi
On Fri, Oct 12, 2018 at 12:57 PM Dmitry Safonov wrote:
>
> Hi Guilherme,
>
> Just to let you know - I've done with more urgent issues now,
> so I'll be back on this patch on Monday, installing qemu-system-hppa
> and debugging the root case.
>
> Thanks,
> Dmi
couldn't find it in LKML heheh
> > >
> > > Oh, if you can CC me in future spins of this patch (in case there
> > > any),
> > > I'd really be glad.
>
> Sure, will enlarge Cc list ;)
>
Thanks again!
Cheers,
Guilherme
couldn't find it in LKML heheh
> > >
> > > Oh, if you can CC me in future spins of this patch (in case there
> > > any),
> > > I'd really be glad.
>
> Sure, will enlarge Cc list ;)
>
Thanks again!
Cheers,
Guilherme
On 01/10/2018 15:32, Guilherme G. Piccoli wrote:
> Hi Dmitry, thanks for the patch. It's very promising, we have some
> reports of this issue and I'm building a kernel with this patch in
> order the reporter can test it. But based in the previous feedback,
> this seems to be ver
On 01/10/2018 15:32, Guilherme G. Piccoli wrote:
> Hi Dmitry, thanks for the patch. It's very promising, we have some
> reports of this issue and I'm building a kernel with this patch in
> order the reporter can test it. But based in the previous feedback,
> this seems to be ver
On Mon, Oct 1, 2018 at 12:50 PM Arnd Bergmann wrote:
>
> Hi Guilherme,
>
> I think what happened is that nobody felt responsible for picking
> it up. The patch was sent 'to: linux-kernel@vger.kernel.org'
> with a number of people in Cc but nobody listed as a recipient
>
On Mon, Oct 1, 2018 at 12:50 PM Arnd Bergmann wrote:
>
> Hi Guilherme,
>
> I think what happened is that nobody felt responsible for picking
> it up. The patch was sent 'to: linux-kernel@vger.kernel.org'
> with a number of people in Cc but nobody listed as a recipient
>
On 05/02/2018 11:13, Guilherme G. Piccoli wrote:
> On 05/02/2018 11:10, Mauro S. M. Rodrigues wrote:
>> Guilherme is no longer available to maintain the driver. I'll assume his
>> position for now on.
>>
>> Signed-off-by: Mauro S. M. Rodrigues
>
> Thanks a lot
On 05/02/2018 11:13, Guilherme G. Piccoli wrote:
> On 05/02/2018 11:10, Mauro S. M. Rodrigues wrote:
>> Guilherme is no longer available to maintain the driver. I'll assume his
>> position for now on.
>>
>> Signed-off-by: Mauro S. M. Rodrigues
>
> Thanks a lot
On 05/02/2018 11:10, Mauro S. M. Rodrigues wrote:
> Guilherme is no longer available to maintain the driver. I'll assume his
> position for now on.
>
> Signed-off-by: Mauro S. M. Rodrigues <maur...@linux.vnet.ibm.com>
Thanks a lot Mauro!
Acked-by: Guilherme G. Piccoli <g
On 05/02/2018 11:10, Mauro S. M. Rodrigues wrote:
> Guilherme is no longer available to maintain the driver. I'll assume his
> position for now on.
>
> Signed-off-by: Mauro S. M. Rodrigues
Thanks a lot Mauro!
Acked-by: Guilherme G. Piccoli
> ---
> MAINTAINERS | 2 +-
&g
r patch...but it's correct the way I see it.
So, what do you prefer? Send it yourself, or want me to send
it with your sign-off too? (since was your idea).
Thanks,
Guilherme
>
> Regards,
> Markus
>
r patch...but it's correct the way I see it.
So, what do you prefer? Send it yourself, or want me to send
it with your sign-off too? (since was your idea).
Thanks,
Guilherme
>
> Regards,
> Markus
>
This is a clean-up patch, no functional changes intended.
It removes an unused variable from do_execute_ddcb() and
also renames the function free_user_pages(), prepending
"genwqe" prefix in order to clarify the code.
Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com&
This is a clean-up patch, no functional changes intended.
It makes all defines uppercase, following a "tradition"
that helps to make code clearer.
Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com>
---
drivers/misc/genwqe/card_base.c| 16
dri
This is a clean-up patch, no functional changes intended.
It removes an unused variable from do_execute_ddcb() and
also renames the function free_user_pages(), prepending
"genwqe" prefix in order to clarify the code.
Signed-off-by: Guilherme G. Piccoli
---
drivers/misc/genwqe/card_de
This is a clean-up patch, no functional changes intended.
It makes all defines uppercase, following a "tradition"
that helps to make code clearer.
Signed-off-by: Guilherme G. Piccoli
---
drivers/misc/genwqe/card_base.c| 16
drivers/misc/genwqe/card_base
This is a clean-up patch, no functional changes intended.
It removes the unused parameter of type "struct ddcb_requ*" from
the functions genwqe_user_vmap() and genwqe_user_vunmap().
Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com>
---
drivers/misc/genwqe/c
This patchset is composed by 3 small clean-ups to genwqe
driver. It aims to improve code clarity, by removing unused
stuff and make the code follow some conventions.
It was built and tested against v4.15-rc3, and aims merge
in v4.16 if possible.
Thanks in advance!
Guilherme G. Piccoli (3
This is a clean-up patch, no functional changes intended.
It removes the unused parameter of type "struct ddcb_requ*" from
the functions genwqe_user_vmap() and genwqe_user_vunmap().
Signed-off-by: Guilherme G. Piccoli
---
drivers/misc/genwqe/card_base.h | 6 ++
drivers/m
This patchset is composed by 3 small clean-ups to genwqe
driver. It aims to improve code clarity, by removing unused
stuff and make the code follow some conventions.
It was built and tested against v4.15-rc3, and aims merge
in v4.16 if possible.
Thanks in advance!
Guilherme G. Piccoli (3
e clean-up!
Acked-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com>
> ---
> drivers/misc/genwqe/card_base.c | 1 -
> drivers/misc/genwqe/card_ddcb.c | 1 -
> drivers/misc/genwqe/card_utils.c | 2 --
> 3 files changed, 4 deletions(-)
>
> diff --git a/drivers/misc/genwqe/
On 12/06/2017 02:54 PM, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
>
> Signed-off-by: Pravin Shedge
Thanks for the clean-up!
Acked-by: Guilherm
he fix.
I was on vacation - but now seeing all the analysis made here, if "ch"
can't be NULL then please go ahead and remove the check =)
I observed that this check comes from before Git, so really ancient code...
Cheers,
Guilherme
he fix.
I was on vacation - but now seeing all the analysis made here, if "ch"
can't be NULL then please go ahead and remove the check =)
I observed that this check comes from before Git, so really ancient code...
Cheers,
Guilherme
erative mood i.e 'Fix foo' instead of
> 'fixed foo'.
>
> On Tue, Nov 21, 2017 at 05:17:53PM -0200, Guilherme Tadashi Maeoka wrote:
> > Fixed some code style issues.
>
> This is not descriptive enough. You may like to read
>
> Documentation/process/submitting-patch
erative mood i.e 'Fix foo' instead of
> 'fixed foo'.
>
> On Tue, Nov 21, 2017 at 05:17:53PM -0200, Guilherme Tadashi Maeoka wrote:
> > Fixed some code style issues.
>
> This is not descriptive enough. You may like to read
>
> Documentation/process/submitting-patch
Fix some coding styles.
Signed-off-by: Guilherme Tadashi Maeoka <gui.mae...@gmail.com>
---
net/wireless/nl80211.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b1ac23ca20c8..0d7e77e03db5 100644
--- a/net/wi
Fix some coding styles.
Signed-off-by: Guilherme Tadashi Maeoka
---
net/wireless/nl80211.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b1ac23ca20c8..0d7e77e03db5 100644
--- a/net/wireless/nl80211.c
+++ b/net
Fixed some code style issues.
Signed-off-by: Guilherme Tadashi Maeoka <gui.mae...@gmail.com>
---
drivers/staging/comedi/drivers/adl_pci9118.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/
Fixed some code style issues.
Signed-off-by: Guilherme Tadashi Maeoka
---
drivers/staging/comedi/drivers/adl_pci9118.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
ing: Value stored to 'ts'
> is never read
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Thanks Colin!
Acked-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com>
> ---
> drivers/tty/serial/jsm/jsm_tty.c | 2 --
> 1 file changed, 2 deletions(-)
&
ever read
>
> Signed-off-by: Colin Ian King
Thanks Colin!
Acked-by: Guilherme G. Piccoli
> ---
> drivers/tty/serial/jsm/jsm_tty.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/tty/serial/jsm/jsm_tty.c
> b/drivers/tty/serial/jsm/jsm_tt
Gimcuan!
For the entire series:
Acked-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com>
Gimcuan!
For the entire series:
Acked-by: Guilherme G. Piccoli
V2 just sent to linuxppc-dev[0] list, with some simplifications.
This one is then officially dropped!
Thanks,
Guilherme
[0] http://patchwork.ozlabs.org/patch/830320
V2 just sent to linuxppc-dev[0] list, with some simplifications.
This one is then officially dropped!
Thanks,
Guilherme
[0] http://patchwork.ozlabs.org/patch/830320
On 10/21/2017 05:51 AM, Greg KH wrote:
> Is this a regression? It seems like it's just a "fix something that has
> always been broken but no one has noticed yet" type of thing, right?
>
Yes, this a fix for something that always has been broken, not a regression!
Thanks,
On 10/21/2017 05:51 AM, Greg KH wrote:
> Is this a regression? It seems like it's just a "fix something that has
> always been broken but no one has noticed yet" type of thing, right?
>
Yes, this a fix for something that always has been broken, not a regression!
Thanks,
of read-only-pages).
Signed-off-by: Frank Haverkamp <ha...@linux.vnet.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com>
---
Arnd/Greg, we found this bug recently, although not critical,
it's really a boring issue affecting driver functionality.
If it's poss
of read-only-pages).
Signed-off-by: Frank Haverkamp
Signed-off-by: Guilherme G. Piccoli
---
Arnd/Greg, we found this bug recently, although not critical,
it's really a boring issue affecting driver functionality.
If it's possible to take this patch still on v4.14, we'd be
really thankful!
But we
1 - 100 of 196 matches
Mail list logo
