First patch fixes a sparse issue and cleans up accessors to avoid
casting to __iomem. The second one cleans up the Makefile, to make
it easier to add new entries.
Third patch just registers the PCIe endpoint device containing
the MDIO registers as a standalone MDIO bus driver, to provide
an
Clean up overcomplicated makefile to make it more maintainable.
Basically, there's a set of common objects shared between
the PF and VF driver modules. This can be implemented in a
simpler way, without conditionals, less repetition, allowing
also for easier updates in the future.
Signed-off-by:
What's needed is basically a pointer to the mdio registers.
This is one way to store it inside bus->priv allocated space,
without upsetting sparse.
Reworked accessors to avoid __iomem casting.
Used devm_* variant to further clean up the init error /
remove paths.
Fixes following sparse warning:
ENETC ports can manage the MDIO bus via local register
interface. However there's also a centralized way
to manage the MDIO bus, via the MDIO PCIe endpoint
device integrated by the same root complex that also
integrates the ENETC ports (eth controllers).
Depending on board design and use case,
The on-chip PCIe root complex that integrates the ENETC ethernet
controllers also integrates a PCIe endpoint for the MDIO controller
providing for centralized control of the ENETC mdio bus.
Add bindings for this "central" MDIO Integrated PCIe Endpoint.
Signed-off-by: Claudiu Manoil
Reviewed-by:
Hello,
On Thu, Aug 01, 2019 at 10:59:54AM +, Schrempf Frieder wrote:
> So I would rather go with a variation of your second proposal and keep
> the dummy implementation, but let it return NULL instead of an error
> pointer, as all the mctrl_gpio_*() functions already seem to have a
> check
On Thu, Aug 1, 2019 at 9:18 AM Antoine Tenart
wrote:
>
> Hi Matteo,
>
> On Wed, Jul 31, 2019 at 08:31:16PM +0200, Matteo Croce wrote:
> >
> > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > index c51f1d5b550b..5002d51fc9d6
> On Aug 1, 2019, at 2:51 AM, Minchan Kim wrote:
>
> On Wed, Jul 31, 2019 at 02:18:00PM -0400, Qian Cai wrote:
>> On Wed, 2019-07-31 at 12:09 -0400, Qian Cai wrote:
>>> On Wed, 2019-07-31 at 14:34 +0900, Minchan Kim wrote:
On Tue, Jul 30, 2019 at 12:25:28PM -0400, Qian Cai wrote:
>
On 15.07.19 13:53:07, Hanna Hawa wrote:
> Add a counter parameter in order to avoid losing errors count for edac
> device, the error count reports the number of errors reported by an edac
> device similar to the way MC_EDAC do.
>
> Signed-off-by: Hanna Hawa
> ---
> drivers/edac/altera_edac.c
On 7/31/19 8:27 PM, Paul Moore wrote:
On Wed, Jul 31, 2019 at 1:26 PM Casey Schaufler wrote:
On 7/31/2019 8:34 AM, Aaron Goidel wrote:
As of now, setting watches on filesystem objects has, at most, applied a
check for read access to the inode, and in the case of fanotify, requires
On Thu, Aug 01, 2019 at 03:01:32AM +0200, Thomas Gleixner wrote:
> @@ -1931,7 +1932,7 @@ static void __jbd2_journal_temp_unlink_b
> transaction_t *transaction;
> struct buffer_head *bh = jh2bh(jh);
>
> - J_ASSERT_JH(jh, jbd_is_locked_bh_state(bh));
> +
On Wed, Jul 31, 2019 at 10:05 PM Kees Cook wrote:
>
> On Wed, Jul 31, 2019 at 12:35:09PM -0700, Matthew Wilcox wrote:
> > On Wed, Jul 31, 2019 at 03:32:40PM -0400, Laura Abbott wrote:
> > > Fix this by ensuring the value we set with set_freepointer is either NULL
> > > or another value in the
On Mon, Jul 29, 2019 at 06:49:17PM -0700, Deepa Dinamani wrote:
> Fill in the appropriate limits to avoid inconsistencies
> in the vfs cached inode times when timestamps are
> outside the permitted range.
>
> Also fix timestamp calculation to avoid overflow
> while converting from days to
On Thu, Aug 01, 2019 at 01:13:53PM +0200, Peter Zijlstra wrote:
> The SPI thingies request FIFO-99 by default, reduce this to FIFO-50.
I don't have a cover letter or any other context, what's going on here
with dependencies?
signature.asc
Description: PGP signature
Hi Peter,
On Thu, Aug 1, 2019 at 1:18 PM Peter Zijlstra wrote:
> The SPI thingies request FIFO-99 by default, reduce this to FIFO-50.
>
> FIFO-99 is the very highest priority available to SCHED_FIFO and
> it not a suitable default; it would indicate the SPI work is the
> most important work on
cc'ing Doug as he might be really interested on this patch
On 1/8/19 13:13, Peter Zijlstra wrote:
> The SPI thingies request FIFO-99 by default, reduce this to FIFO-50.
>
You say below that is not a suitable default but there is any other reason? Did
you observed problems with this?
>
On 29-Jul 13:06, Tejun Heo wrote:
> Hello,
Hi Tejun,
> Looks good to me. On cgroup side,
>
> Acked-by: Tejun Heo
Thanks!
Happy we converged toward something working for you.
I'll add the two small changes suggested by Michal and respin a v13
with your ACK on the series.
Cheers Patrick
--
Hello,
We have some grant on your familyname kindly Contact me here
"{info.attltz244(at)gmail.com}" for more.
Regards,
Albrecht
On Wed, Jul 31, 2019 at 11:33:29AM -0700, Song Liu wrote:
> Changes v1 => v2:
> 1. Call collapse_pte_mapped_thp() directly from uprobe_write_opcode();
> 2. Add VM_BUG_ON() for addr alignment in khugepaged_add_pte_mapped_thp()
>and collapse_pte_mapped_thp().
>
> This set is the newer version
The SPI thingies request FIFO-99 by default, reduce this to FIFO-50.
FIFO-99 is the very highest priority available to SCHED_FIFO and
it not a suitable default; it would indicate the SPI work is the
most important work on the machine.
Cc: Benson Leung
Cc: Enric Balletbo i Serra
Cc: Guenter
A rather embarrasing mistake had us call sched_setscheduler() before
initializing the parameters passed to it.
Cc: Juri Lelli
Cc: "Paul E. McKenney"
Fixes: 1a763fd7c633 ("rcu/tree: Call setschedule() gp ktread to SCHED_FIFO
outside of atomic region")
Signed-off-by: Peter Zijlstra (Intel)
---
I noticed a bunch of kthreads defaulted to FIFO-99, fix them.
The generic default is FIFO-50, the admin will have to configure the system
anyway.
For some the purpose is to be above OTHER and then FIFO-1 really is sufficient.
The ivtv driver creates a FIFO-99 thread by default, reduce this to
FIFO-1.
FIFO-99 is the very highest priority available to SCHED_FIFO and
it not a suitable default; it would indicate the ivtv work is the
most important work on the machine.
FIFO-1 gets it above all OTHER tasks, which seems
PSI defaults to a FIFO-99 thread, reduce this to FIFO-1.
FIFO-99 is the very highest priority available to SCHED_FIFO and
it not a suitable default; it would indicate the psi work is the
most important work on the machine.
Since Real-Time tasks will have pre-allocated memory and locked it in
30.07.2019 19:56, Dmitry Osipenko пишет:
> A proper External Memory Controller clock rounding and parent selection
> functionality is required by the EMC drivers, it is not available using
> the generic clock implementation because only the Memory Controller driver
> is aware of what clock rates
On 25-Jul 13:41, Michal Koutný wrote:
> On Thu, Jul 18, 2019 at 07:17:45PM +0100, Patrick Bellasi
> wrote:
> > The clamp values are not tunable at the level of the root task group.
> > That's for two main reasons:
> >
> > - the root group represents "system resources" which are always
> >
'xive_irq_bitmap_add()' can return -ENOMEM.
In this case, we should free the memory already allocated and return
'false' to the caller.
Also add an error path which undoes the 'tima = ioremap(...)'
Signed-off-by: Christophe JAILLET
---
NOT compile tested (I don't have a cross compiler and won't
30.07.2019 19:56, Dmitry Osipenko пишет:
> Add device-tree binding for NVIDIA Tegra30 External Memory Controller.
> The binding is based on the Tegra124 EMC binding since hardware is
> similar, although there are couple significant differences.
>
> Note that the memory timing description is given
On Thu, Aug 01, 2019 at 10:03:41AM +, Borislav Petkov wrote:
> On Wed, Jul 31, 2019 at 02:05:54AM +0300, Kirill A. Shutemov wrote:
> > Add support for a new instruction MOVDIR64B. The instruction moves
> > 64-bytes as direct-store with 64-byte write atomicity from source memory
> > address to
On Mon, Jul 22, 2019 at 9:17 AM Vasily Averin wrote:
>
> From: Maxim Patlasov
> fuse_wait_on_page_writeback() always returns zero and nobody cares.
> Let's make it void.
Applied.
Thanks,
Miklos
Hello.
Thanks for a patch, but I have a question.
On 2019/08/01 3:54, Gustavo A. R. Silva wrote:
> profile is controlled by user-space via /sys/kernel/security/tomoyo/profile,
It is true that "profile" value is given from user-space, and it will be true
that speculative execution would access
On Tue, Jul 23, 2019 at 8:33 AM Vasily Averin wrote:
>
> commit 963545357202 ("fuse: reduce allocation size for splice_write")
> changed size of bufs array, so first BUG_ON should be corrected too.
> Second BUG_ON become useless, first one also includes the second check:
> any unsigned nbuf value
This add support for the MediaTek MT2712 RTC. It was SoC based RTC, but
had different architecture compared with MT7622 RTC.
Signed-off-by: Ran Bi
---
drivers/rtc/Kconfig | 10 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-mt2712.c | 444 +++
3
This patch add MT2712 RTC related files to MAINTAINERS.
Signed-off-by: Ran Bi
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 783569e3c4b4..11f73a4c75eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1892,7 +1892,9 @@ M:Sean Wang
This patch add device node for MT2712 RTC.
Signed-off-by: Ran Bi
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 43307bad3f0d..31166c17c39a 100644
This patchset add support to MT2712 RTC. MT2712 RTC is a SoC based RTC
with different architecture compared to MT7622 RTC.
Changes in V2:
1. change minimum year from 1968 to 2000
2. fix lock usage
3. stop to calculate useless day of week
4. stop to set default date after init
5. change the prefix
Document the binding for MT2712 RTC implemented by rtc-mt2712.
Signed-off-by: Ran Bi
Reviewed-by: Rob Herring
---
.../devicetree/bindings/rtc/rtc-mt2712.txt | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt2712.txt
On 01.08.19 11:55, Uwe Kleine-König wrote:
> On Thu, Aug 01, 2019 at 09:28:33AM +, Schrempf Frieder wrote:
>> Hi Uwe,
>>
>> On 01.08.19 10:48, Uwe Kleine-König wrote:
>>> On Thu, Aug 01, 2019 at 08:18:05AM +, Schrempf Frieder wrote:
From: Frieder Schrempf
If CONFIG_GPIOLIB
Hi Tzung-Bi
On 30/7/19 16:07, Tzung-Bi Shih wrote:
> Hi Enric,
>
> I found it is error-prone to replace the EC_CMDS after updated.
> Perhaps, we should introduce an intermediate file "cros_ec_trace.inc".
I am not sure I get you here, a .inc? could you explain a bit more?
Thanks,
~ Enric
> The
On Tue, 2019-06-11 at 14:13 +0200, Nicolas Saenz Julienne wrote:
> Some a4tech mice use the 'GenericDesktop.00b8' usage to inform whether
> the previous wheel report was horizontal or vertical. Before
> c01908a14bf73 ("HID: input: add mapping for "Toggle Display" key") this
> usage was being
On Thu, 1 Aug 2019 10:32:42 +0200
Christophe JAILLET wrote:
> The result of this kzalloc is not checked. Add a check and corresponding
> error handling code.
>
> Signed-off-by: Christophe JAILLET
> ---
Reviewed-by: Greg Kurz
> Note that 'xive_irq_bitmap_add()' failures are not handled in
>
Hi Paul,
On 2019年08月01日 04:34, Paul Burton wrote:
Hi Zhou,
On Wed, Jul 31, 2019 at 12:39:03PM +0800, Zhou Yanjie wrote:
1.fix bugs when detecting L2 cache sets value.
2.fix bugs when detecting L2 cache ways value.
3.fix bugs when calculate bogoMips and loops_per_jiffy.
This should be split
01.08.2019 0:04, Sowjanya Komatineni пишет:
>
> On 7/31/19 4:11 AM, Dmitry Osipenko wrote:
>> 31.07.2019 3:20, Sowjanya Komatineni пишет:
>>> This patch adds support for saving OSC clock frequency and the
>>> drive-strength during OSC clock init and creates an API to restore
>>> OSC control
I have been expecting your responds regarding the previous mail I sent to
you, please acknowledge if your email is still valid
(richardazizlawf...@gmail.com)
On Wed, Jul 31, 2019 at 03:23:46PM -0700, Joe Perches wrote:
> On Wed, 2019-07-31 at 16:58 -0400, Neil Horman wrote:
> > On Wed, Jul 31, 2019 at 09:35:31AM -0700, Joe Perches wrote:
> > > On Wed, 2019-07-31 at 08:16 -0400, Neil Horman wrote:
> > > > On Wed, Jul 31, 2019 at 04:32:43AM -0700, Joe
On Tue, Jul 30, 2019 at 04:42:25PM -0400, Michael S. Tsirkin wrote:
> On Tue, Jul 30, 2019 at 11:35:39AM +0200, Stefano Garzarella wrote:
(...)
> >
> > The problem here is the compatibility. Before this series virtio-vsock
> > and vhost-vsock modules had the RX buffer size hard-coded
> >
01.08.2019 0:08, Sowjanya Komatineni пишет:
>
> On 7/31/19 4:04 AM, Dmitry Osipenko wrote:
>> 31.07.2019 3:20, Sowjanya Komatineni пишет:
>>> This patch updates device tree for RTC and PMC to allow system wake
>>> from deep sleep on RTC alarm.
>>>
>>> Signed-off-by: Sowjanya Komatineni
>>> ---
Hi Linus,
Here's a PR with a couple of MMC fixes intended for v5.3-rc3. Details about the
highlights are as usual found in the signed tag.
Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21
On Thu, 1 Aug 2019 10:32:31 +0200
Christophe JAILLET wrote:
> There is no need to use GFP_ATOMIC here. GFP_KERNEL should be enough.
> GFP_KERNEL is also already used for another allocation just a few lines
> below.
>
> Signed-off-by: Christophe JAILLET
> ---
Good catch.
Reviewed-by: Greg
On 25-Jul 13:41, Michal Koutný wrote:
> On Thu, Jul 18, 2019 at 07:17:43PM +0100, Patrick Bellasi
> wrote:
> > +static ssize_t cpu_uclamp_min_write(struct kernfs_open_file *of,
> > + char *buf, size_t nbytes,
> > + loff_t off)
> > +{
>
01.08.2019 13:18, Dmitry Osipenko пишет:
> 01.08.2019 0:10, Sowjanya Komatineni пишет:
>> This patch implements DFLL suspend and resume operation.
>>
>> During system suspend entry, CPU clock will switch CPU to safe
>> clock source of PLLP and disables DFLL clock output.
>>
>> DFLL driver suspend
Hey all
I'm a bit pressed for time these days, so I won't be able to do any
tests any time soon.
Also have to admit that I lost interest in UDF a bit, since we ended up
looking towards hardware solutions for write-protections instead.
But when/if mkudffs includes an option to create a
Document the parameters for bus_find_next_device() to avoid
htmldocs build warnings as reported below :
include/linux/device.h:236: warning: Function parameter or member 'bus' not
described in 'bus_find_next_device'
include/linux/device.h:236: warning: Function parameter or member 'cur' not
Fix a typo in the comment describing the parameters for the new API, which
triggers the following warning for htmldocs:
include/linux/device.h:479: warning: Function parameter or member 'drv' not
described in 'driver_find_device_by_acpi_dev'
Reported-by: kbuild test robot
Cc: Greg
The patch "drivers: Introduce device lookup variants by ACPI_COMPANION device"
converted an incorrect instance in i2c driver to a new helper. Revert this
change.
Reported-by: Stephen Rothwell
Cc: Mika Westerberg
Cc: Wolfram Sang
Cc: Greg Kroah-Hartman
Signed-off-by: Suzuki K Poulose
---
The Mihawk BMC is an ASPEED ast2500 based BMC that is part of an
OpenPower Power9 server.
Signed-off-by: Ben Pai
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts | 902
2 files changed, 903 insertions(+)
create mode
01.08.2019 0:10, Sowjanya Komatineni пишет:
> This patch implements DFLL suspend and resume operation.
>
> During system suspend entry, CPU clock will switch CPU to safe
> clock source of PLLP and disables DFLL clock output.
>
> DFLL driver suspend confirms DFLL disable state and errors out on
>
On Thu, 1 Aug 2019, Daniel Drake wrote:
> On Thu, Aug 1, 2019 at 3:16 PM Aubrey Li wrote:
> However, the only way this can be called is from hpet_enable().
>
> hpet_enable() is called from 2 places:
> 1. From hpet_time_init(). This is the default x86 timer_init that
>
On Tue, 2019-07-02 at 10:02 +0200, Greg Kroah-Hartman wrote:
> From: Xin Long
>
> commit c3bcde026684c62d7a2b6f626dc7cf763833875c upstream.
>
> udp_tunnel(6)_xmit_skb() called by tipc_udp_xmit() expects a tunnel
> device
> to count packets on dev->tstats, a perpcu variable. However, TIPC is
>
On Thu, 1 Aug 2019, Li, Aubrey wrote:
> On 2019/8/1 16:13, Thomas Gleixner wrote:
> > The point is that it does not matter which vendor a CPU comes from. The
> > kernel does support legacyless boot when the frequencies are known. Whether
> > that's currently possible on that particular CPU is a
On Wed, Jul 31, 2019 at 03:37:48PM +0800, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/infiniband/hw/hns/hns_roce_hw_v2.c: In function
> hns_roce_v2_cleanup_eq_table:
> drivers/infiniband/hw/hns/hns_roce_hw_v2.c:5920:6:
> warning: variable irq_num set but not
Hi!
> > The use-case for this is different: the ^T-line as proposed by this
> > patch is for the user that interacts with a system through a terminal, who
> > wants to be informed not about the whole system (sort of what SysRq-t
> > tells you), but about what they run on that particular tty.
>
>
From: Jitendra Sharma
Add initial pinctrl driver to support pin configuration with
pinctrl framework for SC7180
Signed-off-by: Jitendra Sharma
Signed-off-by: Vivek Gautam
[rnayak: modify to use upstream tile support
sort and squash some functions]
Signed-off-by: Rajendra Nayak
---
From: Jitendra Sharma
Add the binding for the TLMM pinctrl block found in the SC7180 platform
Signed-off-by: Jitendra Sharma
Signed-off-by: Vivek Gautam
[rnayak: Fix some copy-paste issues, sort and fix functions]
Signed-off-by: Rajendra Nayak
---
On Wed, Jul 31, 2019 at 02:05:54AM +0300, Kirill A. Shutemov wrote:
> Add support for a new instruction MOVDIR64B. The instruction moves
> 64-bytes as direct-store with 64-byte write atomicity from source memory
> address to destination memory address.
>
> MOVDIR64B requires the destination
On Thu, Aug 1, 2019 at 3:22 PM Vinod Koul wrote:
>
> The adc nodes have reg property but were missing the unit name, so add
> that to fix these warnings:
>
> arch/arm64/boot/dts/qcom/pms405.dtsi:91.12-94.6: Warning
> (unit_address_vs_reg): /soc@0/spmi@200f000/pms405@0/adc@3100/ref_gnd: node
>
On Tue, Jul 23, 2019 at 10:47 AM Shawn Guo wrote:
>
> On Tue, Jul 23, 2019 at 10:44:09AM +0300, Daniel Baluta wrote:
> > Just realized that for this patch I forgot to add [PATCH v3]. Shawn,
> > should I resend?
>
> No need.
Just sent v4 out there adding support for remove. Hope you can have some
Some of i.MX8 processors (e.g i.MX8QM, i.MX8QXP) contain
the Tensilica HiFi4 DSP for advanced pre- and post-audio
processing.
The communication between Host CPU and DSP firmware is
taking place using a shared memory area for message passing
and a dedicated Messaging Unit for notifications.
DSP
On Thu, Aug 01, 2019 at 09:28:33AM +, Schrempf Frieder wrote:
> Hi Uwe,
>
> On 01.08.19 10:48, Uwe Kleine-König wrote:
> > On Thu, Aug 01, 2019 at 08:18:05AM +, Schrempf Frieder wrote:
> >> From: Frieder Schrempf
> >>
> >> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() will return
>
On Sun, Jul 28, 2019 at 5:30 PM Bin Meng wrote:
>
> The unit-address must match the first address specified in the
> reg property of the node.
>
> Signed-off-by: Bin Meng
> ---
>
> Documentation/devicetree/bindings/pci/pci-msi.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Sun, Jul 28, 2019 at 5:30 PM Bin Meng wrote:
>
> The base address of msi-controller@c should be set to c.
>
> Signed-off-by: Bin Meng
> ---
>
> Documentation/devicetree/bindings/interrupt-controller/msi.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
So this is second installment of my work to fix warns on qcom DTS, this time
the traget is qcs404 platform.
Changes since v1:
- Fix node addresses as pointed by Amit
- Add review tags of Amit
Vinod Koul (3):
arm64: dts: qcom: pms405: add unit name adc nodes
arm64: dts: qcom:
pms405@1 nodes specified unnecessary #address-cells/#size-cells but the
subnodes dont have "ranges" or "reg" so remove it
arch/arm64/boot/dts/qcom/pms405.dtsi:141.21-150.4: Warning
(avoid_unnecessary_addr_size): /soc@0/spmi@200f000/pms405@1: unnecessary
#address-cells/#size-cells without
The thermal trip points have unit name but no reg property, so we can
remove them
arch/arm64/boot/dts/qcom/qcs404.dtsi:1080.31-1084.7: Warning
(unit_address_vs_reg): /thermal-zones/aoss-thermal/trips/trip-point@0: node has
a unit name, but no reg property
The adc nodes have reg property but were missing the unit name, so add
that to fix these warnings:
arch/arm64/boot/dts/qcom/pms405.dtsi:91.12-94.6: Warning (unit_address_vs_reg):
/soc@0/spmi@200f000/pms405@0/adc@3100/ref_gnd: node has a reg or ranges
property, but no unit name
On 31/07/2019 23:41, Suman Anna wrote:
> From: "Andrew F. Davis"
>
> The Programmable Real-Time Unit Subsystem (PRUSS) contains a local
> interrupt controller (INTC) that can handle various system input events
> and post interrupts back to the device-level initiators. The INTC can
> support upto
On Thu, Aug 01, 2019 at 04:33:40PM +0800, Jiping Ma wrote:
> In arm64, the PC of the frame is matched to the last frame function,
> rather than the function of his frame. For the following example, the
> stack size of occupy_stack_init function should be 3376, rather than 176.
>
> Wrong info:
>
- Ursprüngliche Mail -
>> Do you have numbers how many attempts were needed to get a free block?
> I tested it dozens of times. The biggest number of attempts I've ever had so
> far
> is 6. In most cases, it only takes 2 or 3 times.
So raising the retry count to, let's say, 10 would work
On Thu, Aug 01, 2019 at 05:33:47AM -0400, Brian Masney wrote:
> On Thu, Aug 01, 2019 at 03:35:57PM +0800, Chuhong Yuan wrote:
> > Use devm_add_action_or_reset to remove the call to
> > tsl2772_disable_regulators_action to simplify the error path.
> >
> > Signed-off-by: Chuhong Yuan
>
> For the
On 01/08/2019 10:32, Christophe JAILLET wrote:
> There is no need to use GFP_ATOMIC here. GFP_KERNEL should be enough.
> GFP_KERNEL is also already used for another allocation just a few lines
> below.
This is correct.
> Signed-off-by: Christophe JAILLET
Reviewed-by: Cédric Le Goater
Hi Mason,
masonccy...@mxic.com.tw wrote on Thu, 1 Aug 2019 17:32:04 +0800:
> Hi Miquel,
>
> > > Document the bindings used by the Macronix raw NAND controller.
> > >
> > > Signed-off-by: Mason Yang
> > > ---
> > > Documentation/devicetree/bindings/mtd/mxic-nand.txt | 19
>
On Thu, Aug 01, 2019 at 03:36:05PM +0800, Chuhong Yuan wrote:
> Use devm_add_action_or_reset to call tsl2772_chip_off
> when the device is removed.
> This also fixes the issue that the chip is turned off
> before the device is unregistered.
>
> Fixes: 4e24c1719f34 ("staging: iio: tsl2x7x: rename
On Thu, Aug 01, 2019 at 08:06:21AM +1000, Stephen Rothwell wrote:
> In commit
>
> 97d5db366224 ("arm64: Lower priority mask for GIC_PRIO_IRQON")
>
> Fixes tag
>
> Fixes: bd82d4bd21880b7c ("arm64: Fix incorrect irqflag restore for
>
> has these problem(s):
>
> - Subject has leading but
Hi Miquel,
> > Document the bindings used by the Macronix raw NAND controller.
> >
> > Signed-off-by: Mason Yang
> > ---
> > Documentation/devicetree/bindings/mtd/mxic-nand.txt | 19
+++
> > 1 file changed, 19 insertions(+)
> > create mode 100644
On Thu, Aug 01, 2019 at 03:35:57PM +0800, Chuhong Yuan wrote:
> Use devm_add_action_or_reset to remove the call to
> tsl2772_disable_regulators_action to simplify the error path.
>
> Signed-off-by: Chuhong Yuan
For the whole series:
Reviewed-by: Brian Masney
I forgot to mention this before,
Hi Uwe,
On 01.08.19 10:48, Uwe Kleine-König wrote:
> On Thu, Aug 01, 2019 at 08:18:05AM +, Schrempf Frieder wrote:
>> From: Frieder Schrempf
>>
>> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() will return
>> -ENOSYS and cause the probing of the imx UART to fail. As the
>> GPIOs are
> You send this patch three times, I guess your mail setup has issues? :-)
Sorry, I thought I hadn't sent the first two e-mails. (The Patch work website
refreshes slowly)
> Do you have numbers how many attempts were needed to get a free block?
I tested it dozens of times. The biggest number of
On Thu, 1 Aug 2019 17:17:29 +0800
masonccy...@mxic.com.tw wrote:
> Hi Boris,
>
> > On Thu, 1 Aug 2019 11:55:10 +0800
> > Mason Yang wrote:
> >
> > > Document the bindings used by the Macronix raw NAND controller.
> > >
> > > Signed-off-by: Mason Yang
> > > ---
> > >
- Ursprüngliche Mail -
> Von: "chengzhihao1"
> An: "richard" , "yi zhang"
> CC: "linux-mtd" , "linux-kernel"
>
> Gesendet: Donnerstag, 1. August 2019 11:13:20
> Betreff: 答复: [PATCH RFC] ubi: ubi_wl_get_peb: Replace a limited number of
> attempts with polling while getting PEB
> I
On Thu, Aug 01, 2019 at 01:23:59AM +0300, Arseny Maslennikov wrote:
> On Tue, Jul 30, 2019 at 06:19:40PM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Jun 25, 2019 at 07:11:53PM +0300, Arseny Maslennikov wrote:
> > > If the three termios local flags isig, icanon, iexten are enabled
> > > and the
Hi Boris,
> On Thu, 1 Aug 2019 11:55:10 +0800
> Mason Yang wrote:
>
> > Document the bindings used by the Macronix raw NAND controller.
> >
> > Signed-off-by: Mason Yang
> > ---
> > Documentation/devicetree/bindings/mtd/mxic-nand.txt | 19
+++
> > 1 file changed, 19
On 01.08.19 09:48, Michal Hocko wrote:
> On Thu 01-08-19 09:39:57, Michal Hocko wrote:
>> On Thu 01-08-19 09:31:09, David Hildenbrand wrote:
>>> On 01.08.19 09:26, David Hildenbrand wrote:
>> [...]
I am not sure about the implications of having
pfn_valid()/pfn_present()/pfn_online()
On Thu, Aug 01 2019, Sergei Turchanov wrote:
> Hello!
>
> [
> As suggested in previous discussion this behavior may be caused by your
> commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and
> interface")
> ]
Yes I think I can see what happened.
removing:
-
I don't quite understand why a limited number of attempts have been made to get
a free PEB in ubi_wl_get_peb (in fastmap-wl.c). I proposed this PATCH with
reference to the implementation of ubi_wl_get_peb (in wl.c). As far as I know,
getting PEB by polling probably won't fall into soft-lockup.
Running pressure test io_paral (A pressure ubi test in mtd-utils) on an
UBI device with fewer PEBs (fastmap enabled) may cause ENOSPC errors and
make UBI device read-only, but there are still free PEBs on the UBI
device. This problem can be easily reproduced by performing the following
steps on a
at 06:33, Rafael J. Wysocki wrote:
On Thu, Aug 1, 2019 at 12:22 AM Keith Busch wrote:
On Wed, Jul 31, 2019 at 11:25:51PM +0200, Rafael J. Wysocki wrote:
A couple of remarks if you will.
First, we don't know which case is the majority at this point. For
now, there is one example of each,
On Thu, Jul 25, 2019 at 04:01:40PM -0600, Jane Chu wrote:
> add_to_kill() expects the first 'tk' to be pre-allocated, it makes
> subsequent allocations on need basis, this makes the code a bit
> difficult to read. Move all the allocation internal to add_to_kill()
> and drop the **tk argument.
>
>
On Thu, Jul 25, 2019 at 04:01:41PM -0600, Jane Chu wrote:
> Mmap /dev/dax more than once, then read the poison location using address
> from one of the mappings. The other mappings due to not having the page
> mapped in will cause SIGKILLs delivered to the process. SIGKILL succeeds
> over SIGBUS,
On Thu 01-08-19 03:01:31, Thomas Gleixner wrote:
> journal_unmap_buffer() checks first whether the buffer head is a journal.
> If so it takes locks and then invokes jbd2_journal_grab_journal_head()
> followed by another check whether this is journal head buffer.
>
> The double checking is
I don't quite understand why a limited number of attempts have been made to get
a free PEB in ubi_wl_get_peb (in fastmap-wl.c). I proposed this PATCH with
reference to the implementation of ubi_wl_get_peb (in wl.c). As far as I know,
getting PEB by polling probably won't fall into soft-lockup.
801 - 900 of 1042 matches
Mail list logo
