We should use NULL to compare with pointer-typed value rather than
0. The issue is detected with the help of Coccinelle.
Signed-off-by: zhong jiang
---
drivers/ide/pmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
index c5b902b..ca
On 2018/8/17 21:23, zhong jiang wrote:
> We should use NULL to compare with pointer-typed value rather than
> 0. The issue is detected with the help of Coccinelle.
>
> Signed-off-by: zhong jiang
> ---
> drivers/ide/pmac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dr
Lieber Freund,
Ich bin Herr Richard Wahl der Mega-Gewinner von $ 533M In Mega Millions Jackpot
spende ich an 5 zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde
Ihre E-Mail nach einem Spinball ausgewählt. Ich habe den größten Teil meines
Vermögens auf eine Reihe von Wohltätigkeits
Andrew Morton writes:
> Dude, lighten up.
This was in response to being asked by a the maintainers of a bot that has
wasted copious quanties of my time to please not waste their time.
To prevent the wasting of time it was requested that when syzbot would
be enabled on linux-next again that it o
Hi Boris,
Thanks for the review.
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Friday, August 17, 2018 11:29 PM
> To: Naga Sureshkumar Relli
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; ma
Sir/Madam,
I have access to very vital information that can be used to move huge amount of
money. I have done my homework very well and i have the machineries in place to
get it done since I am still in active service. If it was possible for me to do
it alone I would not have bothered contacti
Hi Miquel,
Thanks for the review.
> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Friday, August 17, 2018 8:08 PM
> To: Naga Sureshkumar Relli
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; mare
On Fri, 2018-08-17 at 20:15 +0200, Lukas Wunner wrote:
>
> The two steps (enumeration and driver attachment) are protected by
> pci_lock_rescan_remove(). Initially, when a pci_dev is newly allocated
> with kzalloc(), is_added is 0. The transition from 0 to 1 happens while
> under pci_lock_rescan
On Fri, 2018-08-17 at 11:25 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 17, 2018 at 02:48:58PM +1000, Benjamin Herrenschmidt wrote:
> > This re-fixes the bug reported by Hari Vyas
> > after my revert of his commit but in a much simpler way.
> >
> > The main issues is that is_added was being set aft
On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote:
> > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76.
>
> Just to be clear, if I understand correctly, this is a pure revert of
> 44bda4b7d26e and as such i
> Plus I'd have expected the problem to have been in mainline too, and
> apparently it's just the 4.4 and 4.9 backports.
There's another problem in 4.17, but not 4.18, see
https://bugzilla.redhat.com/show_bug.cgi?id=1618792
Could be the same or different.
-Andi
>
> Your test-case does have mp
This reverts commit de48844398f81cfdf087d56e12c920d620dae8d5.
Linus would prefer that __deprecated never produce a warning in an
allyesconfig compile. Since we have been at this state for some time,
the option no longer has a purpose.
Link:
https://lkml.kernel.org/r/ca+55afyglkszs8o3m4jae69wum03
Quoting Taniya Das (2018-08-10 18:53:54)
> [v4]
> * Add recalc_clk_ops to calculate the clock frequency reading the current
> perf state, also add CLK_GET_RATE_NOCACHE flag.
> * Cleanup 'goto' during mode check in 'clk_rcg2_calculate_freq'.
> * cleanup return from function 'com_cc_regist
On 8/15/18 11:21 PM, Anup Patel wrote:
On Thu, Aug 16, 2018 at 11:10 AM, Atish Patra wrote:
On 8/15/18 10:02 PM, Anup Patel wrote:
On Thu, Aug 16, 2018 at 5:26 AM, Atish Patra wrote:
Defining cpu_operations now helps adding cpu hotplug
support in proper manner. Moreover, it provides flexib
On Fri, Aug 17, 2018 at 04:18:34PM -0700, Roman Gushchin wrote:
> - scan = div64_u64(scan * fraction[file],
> - denominator);
> + if (scan > 1)
> + scan = div64_u64(scan * fraction[file],
> +
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem. You will get:
- a new driver for Rohm BU21029 touch controller
- new bitmap APIs: bitmap_alloc, bitmap_zalloc and bitmap_free
- updates to Atm
On Fri, Aug 17, 2018 at 04:47:39PM -0700, justinpo...@gmail.com wrote:
> From: Justin Chen
>
> Sometimes we have empty banks within the GPIO block. This commit allows
> proper handling of 0 width GPIO banks.
Hi Justin
This is coming from DT? Why do you put 0 width banks in DT in the
first place
On 08/17/2018 05:25 PM, Linus Torvalds wrote:
On Fri, Aug 17, 2018 at 3:27 PM Guenter Roeck wrote:
[6.649970] random: crng init done
[6.689002] BUG: unable to handle kernel paging request at eafffa1a0020
Hmm. Lots of bits set.
[6.689082] RIP: 0010:[] []
page_remove_rmap+0
On Fri, Aug 17, 2018 at 4:40 PM, Moritz Fischer wrote:
> Replace dev_get_drvdata() with platform_get_drvdata() to
> match the platform_set_drvdata() in the probe function of
> the platform driver.
>
> Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
> FME")
> Signed-off-b
Hi,
Looks like I missed the email to read for a patch
(mmots/broken-out/fat-propagate-64-bit-inode-timestamps.patch). Well,
so FWIW,
Acked-by: OGAWA Hirofumi
And additionally cleanup patch here (this would be better to be folded
into his patch).
Thanks.
--
OGAWA Hirofumi
[PATCH] Cleanup "f
On Fri, Aug 17, 2018 at 3:27 PM Guenter Roeck wrote:
>
> [6.649970] random: crng init done
> [6.689002] BUG: unable to handle kernel paging request at eafffa1a0020
Hmm. Lots of bits set.
> [6.689082] RIP: 0010:[] []
> page_remove_rmap+0x10/0x230
> [6.689082] RSP: 0018:c
Add reg-names and interrupts for LLCC documentation and the usage
examples. llcc broadcast base is added in addition to llcc base,
which is used for llcc broadcast writes.
Signed-off-by: Venkata Narendra Kumar Gutta
---
Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt | 15 ++-
Cache error reporting controller is to detect and report single
and double bit errors on Last Level Cache Controller (LLCC) cache.
Add required support to register LLCC EDAC driver as platform driver,
from LLCC driver.
Signed-off-by: Venkata Narendra Kumar Gutta
---
drivers/soc/qcom/llcc-slice.c
This series implements EDAC driver for QCOM SoCs. As of now, this driver
supports EDAC for Last Level Cache Controller (LLCC). LLCC EDAC driver is
to detect and report single and double bit errors on Last Level Cache
Controller (LLCC) cache. This driver also takes care of dumping registers
and also
Currently, boradcast base is set to end of the LLCC banks, which may
not be correct always. As the number of banks may vary for each chipset
and the broadcast base could be at a different address as well. This info
depends on the chipset, so get the broadcast base info from the device
tree (DT). Ad
From: Channagoud Kadabi
Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
Errors (DBEs). As of now, this driver supports erp for Last Level Cache
Controller (LLCC). This driver takes care of dumping registers and adding
config options to enable and disable panic when the erro
On Fri, Aug 17, 2018 at 2:17 PM Jason Gunthorpe wrote:
>
> Would you like a patch to remove that CONFIG option?
I've definitely considered it and would almost certainly just apply a
patch that removed it.
We haven't had this issue for a while (because people stopped using
the deprecated thing),
Replace dev_get_drvdata() with platform_get_drvdata() to
match the platform_set_drvdata() in the probe function of
the platform driver.
Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
FME")
Signed-off-by: Moritz Fischer
---
drivers/fpga/dfl-fme-region.c | 2 +-
1 file
On 08/17/2018 04:47 PM, justinpo...@gmail.com wrote:
> From: Justin Chen
>
> Sometimes we have empty banks within the GPIO block. This commit allows
> proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
> incrementing the bank and number of GPIOs, but not initializing them.
> T
From: Justin Chen
Sometimes we have empty banks within the GPIO block. This commit allows
proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
incrementing the bank and number of GPIOs, but not initializing them.
This will mean a call into the non-existent GPIOs will return an e
Dear Friend, My sincere apologies for this unsolicited mail to
you, my name is Barrister Luis Carlos Delgado, theCEO/founder
of (LCD ABOGADOS) with offices in Madrid and Portugal. We consult for NGOs,
Companiesand individuals on Family Law, Intellectual Property,
I've noticed, that dying memory cgroups are often pinned
in memory by a single pagecache page. Even under moderate
memory pressure they sometimes stayed in such state
for a long time. That looked strange.
My investigation showed that the problem is caused by
applying the LRU pressure balancing ma
On Thu, Aug 16, 2018 at 12:06:06AM -0500, Eric W. Biederman wrote:
> So I don't think we can completely abandon the option for filesystems
> to always create a new filesystem instance when mount(8) is called.
Huh? If filesystem wants to create a new instance on each ->mount(),
it can bloody well
The mm-of-the-moment snapshot 2018-08-17-15-48 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You wi
On Fri, Aug 17, 2018 at 03:39:07PM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 03:27:33PM -0700, Guenter Roeck wrote:
> > Hi,
> >
> > the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> > with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
>
>
On Fri, Aug 17, 2018 at 03:27:33PM -0700, Guenter Roeck wrote:
> Hi,
>
> the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
Just to confirm, it's not in mainline right? So only in backports?
There
Hi,
the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
[6.649970] random: crng init done
[6.689002] BUG: unable to handle kernel paging request at eafffa1a0020
[6.689082] IP: [] page_
On Thu, Aug 16, 2018 at 11:56 PM, Christian Kujau wrote:
> On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
>> Bart Massey reported what turned out to be a usercopy whitelist false
>> positive in JFS when symlink contents exceeded 128 bytes. The inline
>> inode data (i_inline) is actually d
On 08/15/2018 08:05 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 30 Jul 2018 19:02:10 +1000 Stephen Rothwell
> wrote:
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>> drivers/xen/gntdev.c
>>
>> between commit:
>>
>> 1d3145675538 ("xen/gntdev: Make private rou
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://github.com/andersson/remoteproc tags/hwlock-v4.19
for you to fetch changes up to ddb34f480d1b8051bc18e6ff22e93a6c9a33f94f:
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://github.com/andersson/remoteproc tags/rpmsg-v4.19
for you to fetch changes up to 00b645e0b4e4a3e5f8d88a4e9acf7e80045c34b4:
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://github.com/andersson/remoteproc tags/rproc-v4.19
for you to fetch changes up to b2201ee554a5811f569f31280b0079e7d6177606:
On Tue 14 Aug 10:06 PDT 2018, Douglas Anderson wrote:
> Not all regulator consumers call regulator_set_load(). On some
> regulators (like on RPMh-regulator) this could be bad since the
> regulator framework will treat this as if consumer needs no load.
> It's much better to assume that a dumb cli
On Fri, Aug 17, 2018 at 01:27:02PM -0700, Linus Torvalds wrote:
> On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe wrote:
> >
> > We often have merge conflicts with RDMA, how do you prefer to get the
> > PR? I'm actually not very clear on this part of the process.
>
> I generally prefer the non-m
The WaRP7 has one mikroBUS socket on the back to plug click boards.
This patch allows to interact with some of these
i2c modules (EEPROM, RTC and so on).
Signed-off-by: Pierre-Jean Texier
---
arch/arm/boot/dts/imx7s-warp.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arc
From: RaviChandra Sadineni
hi Merek,
Unfortunately I could not get the device to boot even after using the
exynos_defconfig.
Can you please try this patch and see if this fixes the issue. If not can you
enable the
debug logs and send me the logs.
Currently on every resume we check for mkbp
On Fri, Aug 17, 2018 at 01:50:05PM -0700, Linus Torvalds wrote:
> On Fri, Aug 17, 2018 at 12:44 PM Linus Torvalds
> wrote:
> >
> > Ok, everything but the max_sge thing was trivial. I just took yours.
>
> Oh, and doing the full test compile, I notice there are new warnings.
>
> That is *NOT* ok.
On Fri, Aug 17, 2018 at 12:44 PM Linus Torvalds
wrote:
>
> Ok, everything but the max_sge thing was trivial. I just took yours.
Oh, and doing the full test compile, I notice there are new warnings.
That is *NOT* ok.
The whole "x is deprecated" is not a useful warning. If you can't
remove somet
On August 17, 2018 1:39:35 PM PDT, Andrew Morton
wrote:
>On Fri, 17 Aug 2018 12:10:35 +0200 Rasmus Villemoes
> wrote:
>
>> Appararently, it's possible to have a non-trivial TU include a few
>headers,
>> including linux/build_bug.h, without ending up with linux/types.h. So
>> the 0day bot sent me
On Fri, 17 Aug 2018 12:10:35 +0200 Rasmus Villemoes
wrote:
> Appararently, it's possible to have a non-trivial TU include a few headers,
> including linux/build_bug.h, without ending up with linux/types.h. So
> the 0day bot sent me
What's a "TU"?
>
> config: um-x86_64_defconfig (attached as .
On Fri, 2018-08-17 at 22:16 +0200, Andreas Bosch wrote:
> Added PCI ID for Sunrise Point-H ISH.
>
> Signed-off-by: Andreas Bosch
Acked-by: Srinivas Pandruvada
> ---
> I hope this patch arrives correctly.
> ---
> drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
> drivers/hid/intel-ish-hid/ipc/pci
I remember having sent this on Wednesday, but for some reason I don't see it in
your tree or my outbox so I might be crazy. I was planning submitting some
more patches next week anyway, so while I'm OK just rolling these up as well
it'd be slightly easier if we can get these into -rc1 so we can te
On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe wrote:
>
> We often have merge conflicts with RDMA, how do you prefer to get the
> PR? I'm actually not very clear on this part of the process.
I generally prefer the non-merged version, but with comments about
the conflicts.
In fact, the really p
Pulling in stable releases into v4.14-rt I triggered this with my CPU
hotplug test:
[ cut here ]
kernel BUG at /work/rt/stable-rt.git/kernel/sched/core.c:1639!
invalid opcode: [#1] PREEMPT SMP PTI
Modules linked in: sunrpc ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6
On 08/16/2018 02:09 PM, Dan Jacobson wrote:
> The kernel should really say what the
> [ cut here ]
> lines are called, else users will say things like:
>
> "I discovered that the user needs to use xrandr in _two_ steps for
> certain resolutions, else he will trigger a
> ker
While compiling the mainline kernel in android env with latest gcc 8 the
compiler threw this warning Thanks to the advantage of improved static analysis
in newer gcc we are now able to
see this warning this patch resolves the detected compiler warnings.
Signed-off-by: Harshit Jain
---
scripts/
Added PCI ID for Sunrise Point-H ISH.
Signed-off-by: Andreas Bosch
---
I hope this patch arrives correctly.
---
drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
b/d
On Fri, Aug 17, 2018 at 12:31:00PM -0700, Linus Torvalds wrote:
> On Thu, Aug 16, 2018 at 2:57 PM Jason Gunthorpe wrote:
> >
> > This time there are many merge conflicts, all due to various tree-wide or
> > RDMA
> > subystem wide changes done by various people. The resolution is tricky, as
> > g
On Fri, Aug 17, 2018 at 12:22:44PM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 07:57:46PM +0200, Adam Borowski wrote:
> > > The "favourite compressor" seems to roughly change every year, so if
> > > we keep adding new ones things will get more and more convoluted.
> >
> > The above patchset
On Fri, Aug 17, 2018 at 03:56:41PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 17, 2018 at 03:28:49PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Aug 17, 2018 at 03:23:15PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa escreve
Jacek
On 08/17/2018 02:37 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 08/16/2018 10:44 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 08/16/2018 02:58 PM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> Thank you for the patch.
>>>
>>> I didn't review DT parsing details in v3, but now I've produced
>>> diff betw
On Fri, Aug 17, 2018 at 12:31 PM Linus Torvalds
wrote:
>
> Oh well. I'll look at what the conflicts were, but may end up just
> taking your resolution.
Ok, everything but the max_sge thing was trivial. I just took yours.
Linus
Dan,
On 08/16/2018 10:44 PM, Dan Murphy wrote:
> Jacek
>
> On 08/16/2018 02:58 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> Thank you for the patch.
>>
>> I didn't review DT parsing details in v3, but now I've produced
>> diff between v3 and v4 to check what has changed.
>>
>> I'm quite surprised re
On Thu, Aug 16, 2018 at 2:57 PM Jason Gunthorpe wrote:
>
> This time there are many merge conflicts, all due to various tree-wide or RDMA
> subystem wide changes done by various people. The resolution is tricky, as git
> does not highlight two areas that need revision.
I was confused by this, bec
Please ignore this series. The series is incorrectly marked as v2. I am
resending it as v1.
On Fri, Aug 17 2018 at 10:39 -0600, Lina Iyer wrote:
Hi,
Changes in v1:
- Avoid GPIO-PDC map in .c file
- Trigger GPIO by writing to the hardware
- Hooked up to suspend/resume c
On Fri, 17 Aug 2018 13:46:36 -0500 ebied...@xmission.com (Eric W. Biederman)
wrote:
> Dmitry Vyukov writes:
>
> > On Wed, Aug 15, 2018 at 9:04 PM, Eric W. Biederman
> > wrote:
> >>
> >> Recently syzbot reported crashes in send_sigio_to_task and
> >> send_sigurg_to_task in linux-next. Despite
On Fri, Aug 17, 2018 at 07:57:46PM +0200, Adam Borowski wrote:
> > The "favourite compressor" seems to roughly change every year, so if
> > we keep adding new ones things will get more and more convoluted.
>
> The above patchset drops just bzip2. It is the only one that's strictly
> beaten in eve
Update the documentation to use interrupts-extended format for
specifying the TLMM summary IRQ line that is requested from GIC and the
PDC interrupts corresponding to the wakeup capable GPIOs.
Update the example to show PDC interrupts for the wakeup capable GPIOs
for SDM845.
Cc: devicet...@vger.k
Hi,
Resending as v1. The series was sent incorrectly as v2.
Changes in v1:
- Avoid GPIO-PDC map in .c file
- Trigger GPIO by writing to the hardware
- Hooked up to suspend/resume callbacks
- Dropped PDC DT bindings (see dependencies)
Dependencies:
https://
From: Marc Zyngier
Although GICv3 doesn't directly offers support for wake-up interrupts
and relies on external HW for this, it shouldn't prevent the driver
for such HW from doing it work.
Let's set the required flags on the irq_chip structures.
Reported-by: Lina Iyer
Signed-off-by: Marc Zyngi
During suspend the system may power down some of the system rails. As a
result, the TLMM hw block may not be operational anymore and wakeup
capable GPIOs will not be detected. The PDC however will be operational
and the GPIOs that are routed to the PDC as IRQs can wake the system up.
To avoid bein
GPIOs that are wakeup capable have interrupt lines that are routed to
the always-on interrupt controller (PDC) in parallel to the pinctrl. The
interrupts listed here are the wake up lines corresponding to GPIOs.
Signed-off-by: Lina Iyer
---
Changes in v1:
- Use interrupt-extended for all
---
drivers/pinctrl/qcom/pinctrl-sdm845.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c
b/drivers/pinctrl/qcom/pinctrl-sdm845.c
index 2ab7a8885757..cc333b8afb99 100644
--- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
+++ b/drivers/pinctrl/qcom/pinctrl-
On 08/17/2018 09:27 AM, Cornelia Huck wrote:
On Fri, 17 Aug 2018 09:18:51 -0400
Tony Krowiak wrote:
On 08/14/2018 04:43 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:01 -0400
Tony Krowiak wrote:
From: Harald Freudenberger
Move all the inline functions from the ap bus header
file a
On 08/17/2018 05:38 AM, Cornelia Huck wrote:
On Wed, 15 Aug 2018 17:05:48 -0400
Tony Krowiak wrote:
On 08/15/2018 12:38 PM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:15 -0400
Tony Krowiak wrote:
+ case VFIO_DEVICE_RESET:
+ ret = vfio_ap_mdev_reset_queues(mdev, true)
On 08/17/2018 04:43 AM, Cornelia Huck wrote:
On Thu, 16 Aug 2018 12:24:16 -0400
Tony Krowiak wrote:
On 08/14/2018 07:19 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:06 -0400
Tony Krowiak wrote:
+static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
+{
+
On Fri, Aug 17, 2018 at 6:20 PM Boris Brezillon
wrote:
>
> On Fri, 17 Aug 2018 15:56:23 +
> "Luck, Tony" wrote:
>
> > >> - Some targets don't have any support for I/O space on their PCI bus and
> > >> just
> > >>want to get things to compile by setting PCI_IOBASE to zero, this
> > >> st
Em Fri, Aug 17, 2018 at 03:28:49PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Aug 17, 2018 at 03:23:15PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa escreveu:
> > > static const struct {
> > > const char *fmt;
> > > int (*decompres
Dmitry Vyukov writes:
> On Wed, Aug 15, 2018 at 9:04 PM, Eric W. Biederman
> wrote:
>>
>> Recently syzbot reported crashes in send_sigio_to_task and
>> send_sigurg_to_task in linux-next. Despite finding a reproducer
>> syzbot apparently did not bisected this or otherwise track down the
>> offen
On Fri, Aug 17, 2018 at 11:22 AM, Eric W. Biederman
wrote:
> Dmitry Vyukov writes:
>
>> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
>> wrote:
>>> Dmitry Vyukov writes:
>>>
On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
wrote:
> On Mon, Aug 13, 2018 at 06:33:02AM -0700,
On Fri, Aug 17, 2018 at 01:22:31PM -0500, Eric W. Biederman wrote:
> Dmitry Vyukov writes:
>
> > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> > wrote:
> >> Dmitry Vyukov writes:
> >>
> >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
> >>> wrote:
> On Mon, Aug 13, 2018 at 06
The constant sHTCLng causes a checkpatch issue, due to its use of
CamelCase naming. To correct the issue the constant has been renamed
to HTCLNG.
I'm not sure this is a good name as it communicates very little and
contradicts the block comment above its definition. MCS_LEN might
be a better name i
The structure HT_CAPABILITY_ELE causes a number of checkpatch / coding
style issues. The structure uses a 'typedef' directive causing an
issue regarding defining new types in the code. The name of the
structure should be lowercase, and the '__packed' directive is prefered
over the attribute directi
The enumerated type CHNLOP is only used as a member variable of the
structure RT_HIGH_THROUGHPUT. Whilst this member variable is initialised
it is never actually used in the code. To simplify the code both the
enumerated type and the member variable have been removed.
This is a coding style change
Correct the block comments so they conform to coding standard.
This is a coding style change which should not impact on runtime
code execution.
Signed-off-by: John Whitmore
---
.../staging/rtl8192u/ieee80211/rtl819x_HT.h | 73 +--
1 file changed, 36 insertions(+), 37 deletions
Two unions HT_CAPABILITY and HT_CAPABILITY_MACPARA have previously been
commented out of code. Since they are obviously not used in code and
the commented out unions add nothing to the code they have been removed.
This is a coding style change which should have no impact on runtime
code execution.
The macro CHHLOP_IN_PROGRESS is never used in code, so has been
removed.
This is a coding style change which should have no impact on runtime
code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 4
1 file changed, 4 deletions(-)
diff --git a/d
A few coding style changes in the file rtl819x_HT.h
John Whitmore (10):
staging:rtl8192u: Replace magic number with defined constant - Style
staging:rtl8192u: Rename sHTCLng - Style
staging:rtl8192u: Remove unnecessary blank lines - Style
staging:rtl8192u: Add required spaces - Style
sta
Remove unused constants, this is a coding style change which should
have no impact on runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
b
The defined constant MIMO_PS_STATIC is used for this test for zero
elsewhere in code so the magic number '0' has been replaced with that
comment, which was actually explicitly mentioned in the comment.
This is a simple coding style change which should have no impact on
runtime code execution.
Sig
Add spaces required by coding style to clear checkpatch issues.
This is a coding style change which should have no impact on runtime
code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-
Removed blank lines which cause checkpatch issues.
This is a simple coding style change which should have no impact on
runtime code execution.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/sta
Em Fri, Aug 17, 2018 at 03:23:15PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa escreveu:
> > static const struct {
> > const char *fmt;
> > int (*decompress)(const char *input, int output);
> > } compressions[] = {
> > + [COMP_ID__NONE
From: John Dias
When rt_mutex_setprio changes a task's scheduling class to RT,
we're seeing cases where the task's vruntime is not updated
correctly upon return to the fair class.
Specifically, the following is being observed:
- task is deactivated while still in the fair class
- task is boosted
Em Fri, Aug 17, 2018 at 11:48:06AM +0200, Jiri Olsa escreveu:
> Storing decompression ID in the struct kmod_path, so it
> can be later stored in the struct dso.
>
> Switching the struct kmod_path::comp from bool to int
> to return the compressions array index. Adding 0 index
> item into compressio
Dmitry Vyukov writes:
> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
> wrote:
>> Dmitry Vyukov writes:
>>
>>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
>>> wrote:
On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following c
On Fri, Aug 17, 2018 at 11:25:34AM -0500, Bjorn Helgaas wrote:
> The "bind driver, then set dev->added = 1" order seems to have been
> there since the beginning of dev->is_added:
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8a1bc9013a03
>
> This patch seems reason
Something is amiss. A "make install" of an already compiled 4.18.1
kernel is taking 10 minutes or so. The same thing for a 4.17.14 kernel
takes all of a minute.
And during that 10 minutes
or so we seem hung up on i915.ko
2626 pts/8S+ 0:00 make -f ./scripts/Makefile.build obj=arch/x86/
Hi Naga,
On Fri, 17 Aug 2018 18:49:24 +0530
Naga Sureshkumar Relli wrote:
> +static int anfc_exec_op_cmd(struct nand_chip *chip,
> +const struct nand_subop *subop)
> +{
> + const struct nand_op_instr *instr;
> + struct anfc_op nfc_op = {};
> + struct a
On Fri, Aug 17, 2018 at 09:54:03AM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote:
> > Hey,
> >
> > is there any mainline future for this zstd support?
> > Currently my most favourite compressor for this, and for what it’s worth
> > zstd/initrd now even tested
1 - 100 of 351 matches
Mail list logo
